From owner-freebsd-stable@FreeBSD.ORG Sun Sep 5 06:55:18 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44DB910656BA; Sun, 5 Sep 2010 06:55:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id EEF5A8FC15; Sun, 5 Sep 2010 06:55:17 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o856tG7L017502; Sun, 5 Sep 2010 02:55:16 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o856tGLb017501; Sun, 5 Sep 2010 06:55:16 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 06:55:16 GMT Message-Id: <201009050655.o856tGLb017501@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on i386/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 06:55:18 -0000 TB --- 2010-09-05 06:17:15 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 06:17:15 - starting RELENG_8 tinderbox run for i386/i386 TB --- 2010-09-05 06:17:15 - cleaning the object tree TB --- 2010-09-05 06:17:59 - cvsupping the source tree TB --- 2010-09-05 06:17:59 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/i386/supfile TB --- 2010-09-05 06:55:16 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 06:55:16 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 06:55:16 - 1.18 user 28.98 system 2280.93 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Sun Sep 5 06:59:48 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03D6F10656BE; Sun, 5 Sep 2010 06:59:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id B99BF8FC14; Sun, 5 Sep 2010 06:59:47 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o856xk0e020080; Sun, 5 Sep 2010 02:59:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o856xkjE020079; Sun, 5 Sep 2010 06:59:46 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 06:59:46 GMT Message-Id: <201009050659.o856xkjE020079@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on i386/pc98 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 06:59:48 -0000 TB --- 2010-09-05 06:19:40 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 06:19:40 - starting RELENG_8 tinderbox run for i386/pc98 TB --- 2010-09-05 06:19:40 - cleaning the object tree TB --- 2010-09-05 06:20:15 - cvsupping the source tree TB --- 2010-09-05 06:20:15 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/pc98/supfile TB --- 2010-09-05 06:59:46 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 06:59:46 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 06:59:46 - 0.81 user 25.10 system 2406.32 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Sun Sep 5 07:13:47 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F61C10656D3; Sun, 5 Sep 2010 07:13:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 38A1F8FC0A; Sun, 5 Sep 2010 07:13:46 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o857DkSw031637; Sun, 5 Sep 2010 03:13:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o857DkJw031636; Sun, 5 Sep 2010 07:13:46 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 07:13:46 GMT Message-Id: <201009050713.o857DkJw031636@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 07:13:47 -0000 TB --- 2010-09-05 06:32:43 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 06:32:43 - starting RELENG_8 tinderbox run for ia64/ia64 TB --- 2010-09-05 06:32:43 - cleaning the object tree TB --- 2010-09-05 06:33:16 - cvsupping the source tree TB --- 2010-09-05 06:33:16 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/ia64/ia64/supfile TB --- 2010-09-05 07:13:46 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 07:13:46 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 07:13:46 - 0.77 user 25.16 system 2462.80 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Sun Sep 5 07:33:18 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8275410656C8; Sun, 5 Sep 2010 07:33:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 3F5718FC0C; Sun, 5 Sep 2010 07:33:17 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o857XH6f031705; Sun, 5 Sep 2010 03:33:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o857XHTR031704; Sun, 5 Sep 2010 07:33:17 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 07:33:17 GMT Message-Id: <201009050733.o857XHTR031704@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on mips/mips X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 07:33:18 -0000 TB --- 2010-09-05 06:55:17 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 06:55:17 - starting RELENG_8 tinderbox run for mips/mips TB --- 2010-09-05 06:55:17 - cleaning the object tree TB --- 2010-09-05 06:55:33 - cvsupping the source tree TB --- 2010-09-05 06:55:33 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/mips/mips/supfile TB --- 2010-09-05 07:33:17 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 07:33:17 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 07:33:17 - 0.48 user 13.61 system 2280.27 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-mips-mips.full From owner-freebsd-stable@FreeBSD.ORG Sun Sep 5 07:40:18 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D69510656D8; Sun, 5 Sep 2010 07:40:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id ED9A88FC0A; Sun, 5 Sep 2010 07:40:17 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o857eHdW031727; Sun, 5 Sep 2010 03:40:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o857eHPN031726; Sun, 5 Sep 2010 07:40:17 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 07:40:17 GMT Message-Id: <201009050740.o857eHPN031726@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 07:40:18 -0000 TB --- 2010-09-05 06:59:47 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 06:59:47 - starting RELENG_8 tinderbox run for powerpc/powerpc TB --- 2010-09-05 06:59:47 - cleaning the object tree TB --- 2010-09-05 07:00:11 - cvsupping the source tree TB --- 2010-09-05 07:00:11 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/powerpc/powerpc/supfile TB --- 2010-09-05 07:40:17 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 07:40:17 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 07:40:17 - 0.75 user 19.12 system 2430.05 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Sun Sep 5 07:47:15 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B3BD10656D5; Sun, 5 Sep 2010 07:47:15 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E0F2D8FC13; Sun, 5 Sep 2010 07:47:14 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o857lEGu031758; Sun, 5 Sep 2010 03:47:14 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o857lEVf031757; Sun, 5 Sep 2010 07:47:14 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 07:47:14 GMT Message-Id: <201009050747.o857lEVf031757@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 07:47:15 -0000 TB --- 2010-09-05 07:10:52 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 07:10:52 - starting RELENG_8 tinderbox run for sparc64/sparc64 TB --- 2010-09-05 07:10:52 - cleaning the object tree TB --- 2010-09-05 07:11:18 - cvsupping the source tree TB --- 2010-09-05 07:11:18 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/sparc64/sparc64/supfile TB --- 2010-09-05 07:47:14 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 07:47:14 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 07:47:14 - 0.80 user 19.98 system 2181.25 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Sun Sep 5 10:17:57 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDD90106564A; Sun, 5 Sep 2010 10:17:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7AB7D8FC12; Sun, 5 Sep 2010 10:17:57 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o85AHuJi032336; Sun, 5 Sep 2010 06:17:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o85AHuPL032335; Sun, 5 Sep 2010 10:17:56 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 10:17:56 GMT Message-Id: <201009051017.o85AHuPL032335@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_0 tinderbox] failure on i386/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 10:17:57 -0000 TB --- 2010-09-05 09:42:58 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 09:42:58 - starting RELENG_8_0 tinderbox run for i386/i386 TB --- 2010-09-05 09:42:58 - cleaning the object tree TB --- 2010-09-05 09:43:27 - cvsupping the source tree TB --- 2010-09-05 09:43:27 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/i386/i386/supfile TB --- 2010-09-05 10:17:56 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 10:17:56 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 10:17:56 - 0.84 user 17.45 system 2097.45 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Sun Sep 5 10:18:39 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9681C10656C1; Sun, 5 Sep 2010 10:18:39 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 590358FC2C; Sun, 5 Sep 2010 10:18:39 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o85AIcCK032344; Sun, 5 Sep 2010 06:18:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o85AIcdI032343; Sun, 5 Sep 2010 10:18:38 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 10:18:38 GMT Message-Id: <201009051018.o85AIcdI032343@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_0 tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 10:18:39 -0000 TB --- 2010-09-05 09:42:58 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 09:42:58 - starting RELENG_8_0 tinderbox run for amd64/amd64 TB --- 2010-09-05 09:42:58 - cleaning the object tree TB --- 2010-09-05 09:43:38 - cvsupping the source tree TB --- 2010-09-05 09:43:38 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/amd64/amd64/supfile TB --- 2010-09-05 10:18:38 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 10:18:38 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 10:18:38 - 1.03 user 20.73 system 2139.63 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Sun Sep 5 10:20:10 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 282A310656B1; Sun, 5 Sep 2010 10:20:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id DF6C78FC1D; Sun, 5 Sep 2010 10:20:09 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o85AK9er032360; Sun, 5 Sep 2010 06:20:09 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o85AK9uK032359; Sun, 5 Sep 2010 10:20:09 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 10:20:09 GMT Message-Id: <201009051020.o85AK9uK032359@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_0 tinderbox] failure on i386/pc98 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 10:20:10 -0000 TB --- 2010-09-05 09:42:58 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 09:42:58 - starting RELENG_8_0 tinderbox run for i386/pc98 TB --- 2010-09-05 09:42:58 - cleaning the object tree TB --- 2010-09-05 09:43:24 - cvsupping the source tree TB --- 2010-09-05 09:43:24 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/i386/pc98/supfile TB --- 2010-09-05 10:20:09 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 10:20:09 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 10:20:09 - 0.83 user 14.70 system 2230.30 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Sun Sep 5 10:20:11 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3551110656B3; Sun, 5 Sep 2010 10:20:11 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E65208FC21; Sun, 5 Sep 2010 10:20:10 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o85AKAUt032367; Sun, 5 Sep 2010 06:20:10 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o85AKAsa032366; Sun, 5 Sep 2010 10:20:10 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 10:20:10 GMT Message-Id: <201009051020.o85AKAsa032366@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_0 tinderbox] failure on arm/arm X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 10:20:11 -0000 TB --- 2010-09-05 09:42:58 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 09:42:58 - starting RELENG_8_0 tinderbox run for arm/arm TB --- 2010-09-05 09:42:58 - cleaning the object tree TB --- 2010-09-05 09:43:11 - cvsupping the source tree TB --- 2010-09-05 09:43:11 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/arm/arm/supfile TB --- 2010-09-05 10:20:10 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 10:20:10 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 10:20:10 - 0.45 user 6.68 system 2231.31 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-arm-arm.full From owner-freebsd-stable@FreeBSD.ORG Sun Sep 5 10:24:27 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8FEB10656B3 for ; Sun, 5 Sep 2010 10:24:27 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id E45988FC08 for ; Sun, 5 Sep 2010 10:24:26 +0000 (UTC) Received: by iwn34 with SMTP id 34so3639238iwn.13 for ; Sun, 05 Sep 2010 03:24:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type; bh=oX+yvLYD1BvcGMhyQSYC4mg3EFD2PkCga5K7ELcFiMY=; b=rGFd3fl7ZHAZPxBxbUzsKweH9KMApRXN5FsguNFwZgVyqopzrUMFKxcGb+XI4yMOUW VIKGzeJhRhZuTZbG3+JWF1tc1KlrJs6Q17JJ0oP1SIXejjg+WLohMaWT99gPMxlzgAJN vELs1tgWIHOLjWYvGLbLLPIz5dIzW9p7VeLxY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; b=yIADxfmcfhBNXIWAEBlQK+r2YlSminBBZhW5yFKwdC/+Cytfoz99wmSj9D/emENWu0 r+yR6ZXqDwfKop+6Zb8gOhSDbvuw/d1hkPFdqpkJsIR/XgaN3nazrQsieZrLf2oK1lu+ sE4P8YCsJcJF1gCb58HrUUlTrNrDJ7/C0qXmI= Received: by 10.231.193.11 with SMTP id ds11mr3743548ibb.192.1283682266054; Sun, 05 Sep 2010 03:24:26 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-137-20.dsl.klmzmi.sbcglobal.net [99.181.137.20]) by mx.google.com with ESMTPS id z6sm4434660ibc.6.2010.09.05.03.24.23 (version=SSLv3 cipher=RC4-MD5); Sun, 05 Sep 2010 03:24:24 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C836FD6.5040200@DataIX.net> Date: Sun, 05 Sep 2010 06:24:22 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100806 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Jeremy Chadwick References: <20100902055630.GA55668@zibbi.meraka.csir.co.za> <20100902061656.GA29424@icarus.home.lan> In-Reply-To: <20100902061656.GA29424@icarus.home.lan> X-Enigmail-Version: 1.1.2 Content-Type: multipart/mixed; boundary="------------030405040708020004050605" Cc: mux@freebsd.org, lulf@freebsd.org, stable@freebsd.org, Dmitry Morozovsky Subject: Re: csup in repomirror mode dumps core @ stable/8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 10:24:27 -0000 This is a multi-part message in MIME format. --------------030405040708020004050605 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/02/2010 02:16, Jeremy Chadwick wrote: > On Thu, Sep 02, 2010 at 07:56:31AM +0200, John Hay wrote: >> On Thu, Sep 02, 2010 at 03:59:07AM +0400, Dmitry Morozovsky wrote: >>> Dear colleagues, >>> >>> some 2 days ago my repo mirror (stable/8@amd64) starts dumping >>> core on copying repo: >>> >>> ... SetAttrs CVSROOT-src/Emptydir Edit CVSROOT-src/access,v >>> Segmentation fault (core dumped) >>> >>> deleting files from sup/cvsroot-all/ did not help >>> >>> unfortunately, quick usual `make -DDEBUG_FLAGS=-g' in >>> /usr/src/usr.bin/csup does not work, and I did not dig into this >>> deeply yet, so trace are without parameters: > > This won't work. You need to do: make DEBUG_FLAGS="-g3 -ggdb -O0" > > The important part is not using -D. make.conf variables aren't > exported into the compiler environment (I'm not phrasing this > eloquently because I don't know how to describe it). The rest of the > gcc arguments I provided are highly recommended (especially -O0, > otherwise you probably won't get access to any variable data). > > I can confirm this works, by the way. Look closely at the cc line > (past the initial -O2 -pipe -march=nocona). > > cc -O2 -pipe -march=nocona -I. > -I/usr/src/usr.bin/csup/../../contrib/csup -DHAVE_FFLAGS -DNDEBUG > -ggdb -g3 -O0 -std=gnu99 -fstack-protector -Wsystem-headers -Werror > -Wno-pointer-sign -c > /usr/src/usr.bin/csup/../../contrib/csup/updater.c > Not being picky but just wanted to let you know that the flags specified to DEBUG_FLAGS that you have listed above are perfectly fine but for those without the knowledge of how this is done, the last flag specified is usually the flag that wins. So for DEBUG_FLAGS="-g3 -ggdb -O0" the -ggdb flag would be the debugging type of ELF binary produced making the '-g3' flag just redundant. Now in case you wanted the effect of '-g3' and '-ggdb' you can specify '-ggdb3' instead. As for the compile that was listed above it seems as if the flags were reorganized in some way leading to '-g3' ultimately taking the cake. Irregardless you will still end up with a binary that can be debugged by gdb(1)/kgdb(1) either way. Attached is a script that I use after buildworld installworld to rebuild libthr and libc that is helpful for debugging that you may or may not find useful. Regards, - -- jhell,v -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMg2/VAAoJEJBXh4mJ2FR+0k4H/RhffEPOsykY777HLm+PgSxF EGmXHGDO/E3q3SRwcq062wLqa3r6sEcFh3claXamNRyCCsMvzvOEo/id77GA9lGe SMlJGjsI8WyA0ZZl9SonsFN9bU4KFS2OfCzXBpUHbdDBZ0huaLlJNOq41HBxv55B MSqTxfOXWUANZ2zzDiuKwdtY+MwiXwEwj8nJV0SAryGjcwEZoC/34nZfHCF2Y/uU sKVhrZmzg/jbXxVtDuFfJ5uhk9UoLRWeAf0huUpfZJ6k7FtzjL4pP/EEMPyJhGtK fVNYiOuQr9ZAErRg27LDgfT/fKwffbONeYQ9Q0osV44GYcateO5RhBdA7UEEAxE= =fmjo -----END PGP SIGNATURE----- --------------030405040708020004050605 Content-Type: text/plain; name="builddbglibs.sh" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="builddbglibs.sh" #! /bin/sh LIBDIR="/usr/src/lib" DBGLIBS="libc libthr" DBGFLAGS="-g3 -O0" TARGETS="obj depend includes" NUMCPUS=$((($(sysctl -n kern.smp.cpus)*2)+(10))) for dbglib in $DBGLIBS; do for target in $TARGETS; do make -C $LIBDIR/$dbglib $target DEBUG_FLAGS="${DBGFLAGS}" done nice make -C $LIBDIR/$dbglib DEBUG_FLAGS="${DBGFLAGS}" && make -C $LIBDIR/$dbglib install DEBUG_FLAGS="${DBGFLAGS}" done --------------030405040708020004050605 Content-Type: application/octet-stream; name="builddbglibs.sh.sig" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="builddbglibs.sh.sig" iQEcBAABAgAGBQJMg2/VAAoJEJBXh4mJ2FR+/MsH/j3CCxGK+5ceDH2iUcV7S1GRfMcty1pj QhSCIgiOdC/3s8/mQymJ5DxI/zKL/slxRW/czg9x5fUHx++tlJ61pwh+GrnMaa1Lm6fYbsvL /xzpVs8FfDzQb7fCKTlqq8VCFThzON/JR+7aJd4lbhj4I7nUXpXpPT39WOiy+2x1/qMNFkAo p601NbmwTMdTS8q389tA3pZJqS4d+P41GKuADIzptjF9eHtW/lDcxUoPuXnw/6xq0Z09C3+R mWqxfz/aeEJWQzZNZm6tSxBzDhyb2fAQ0GjW3jrSMCmtcTZvt24E14NWCw23/YC/aTqmy8B3 D3u/+5mDIrv6Ybaj+8C5sNw= --------------030405040708020004050605-- From owner-freebsd-stable@FreeBSD.ORG Sun Sep 5 10:47:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD67E1065697; Sun, 5 Sep 2010 10:47:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 91A728FC13; Sun, 5 Sep 2010 10:47:30 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id EA62046B5C; Sun, 5 Sep 2010 06:47:29 -0400 (EDT) Date: Sun, 5 Sep 2010 11:47:29 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Hans Petter Selasky In-Reply-To: <201009011902.06538.hselasky@c2i.net> Message-ID: References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <201009011902.06538.hselasky@c2i.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Stable , Deb Goodkin , security-officer@freebsd.org, gljennjohn@googlemail.com, freebsd security , "Julian H. Stacey" Subject: Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 10:47:30 -0000 On Wed, 1 Sep 2010, Hans Petter Selasky wrote: >>> - Or whatever other method to get ISDN back in kernel ? >> >> It seems code exists :-) >> >> http://old.nabble.com/ISDN4BSD-on-8-current-td23919925.html >> ISDN4BSD package has been updated to compile on FreeBSD >> 8-current >> >> http://www.selasky.org/hans_petter/isdn4bsd/ >> >> Apparently needs massaging into main FreeBSD tree. > > I agree that my I4B code should be re-written somewhat before committed. > Possibly we should update the API's present too, to support IP-telephony > aswell. Just to clarify things a little for those following it: the original I4B code was removed for entirely practical reasons: it couldn't run without the Giant lock, and support for the Giant lock over the network stack was removed. I'm happy to see ISDN support reintroduced as long as it will see ongoing maintenance/etc. I'm not familiar with Hans's most recent code, but the integration of his USB stack and his recent receipt of a FreeBSD commit bit suggest a promising future. I would suggest trying to rope in a reveiwer and collaborator (perhaps someone like Bjoern Zeeb?) to work through it before considering a merge, however. This is especially important with projects like VIMAGE, network stack parallelism projects, etc, on-going to make sure that the new ISDN code will be able to support these new features rather than become a potential obstacle (as the old code did for the MPSAFEty work). Robert From owner-freebsd-stable@FreeBSD.ORG Sun Sep 5 10:55:10 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DF0F10656B8; Sun, 5 Sep 2010 10:55:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D586F8FC0C; Sun, 5 Sep 2010 10:55:09 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o85At9aK032507; Sun, 5 Sep 2010 06:55:09 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o85At9Qe032506; Sun, 5 Sep 2010 10:55:09 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 10:55:09 GMT Message-Id: <201009051055.o85At9Qe032506@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_0 tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 10:55:10 -0000 TB --- 2010-09-05 10:17:56 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 10:17:56 - starting RELENG_8_0 tinderbox run for ia64/ia64 TB --- 2010-09-05 10:17:56 - cleaning the object tree TB --- 2010-09-05 10:18:10 - cvsupping the source tree TB --- 2010-09-05 10:18:10 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/ia64/ia64/supfile TB --- 2010-09-05 10:55:08 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 10:55:08 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 10:55:08 - 0.54 user 7.76 system 2232.41 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Sun Sep 5 10:56:15 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBD441065672; Sun, 5 Sep 2010 10:56:15 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7E91C8FC19; Sun, 5 Sep 2010 10:56:15 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o85AuEci032515; Sun, 5 Sep 2010 06:56:14 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o85AuEAU032514; Sun, 5 Sep 2010 10:56:14 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 10:56:14 GMT Message-Id: <201009051056.o85AuEAU032514@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_0 tinderbox] failure on mips/mips X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 10:56:15 -0000 TB --- 2010-09-05 10:18:38 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 10:18:38 - starting RELENG_8_0 tinderbox run for mips/mips TB --- 2010-09-05 10:18:38 - cleaning the object tree TB --- 2010-09-05 10:18:44 - cvsupping the source tree TB --- 2010-09-05 10:18:44 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/mips/mips/supfile TB --- 2010-09-05 10:56:14 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 10:56:14 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 10:56:14 - 0.34 user 4.54 system 2255.98 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-mips-mips.full From owner-freebsd-stable@FreeBSD.ORG Sun Sep 5 10:58:05 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E58210656A8; Sun, 5 Sep 2010 10:58:05 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5BAEB8FC1D; Sun, 5 Sep 2010 10:58:05 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o85Aw4e5032523; Sun, 5 Sep 2010 06:58:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o85Aw4Ub032522; Sun, 5 Sep 2010 10:58:04 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 10:58:04 GMT Message-Id: <201009051058.o85Aw4Ub032522@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_0 tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 10:58:05 -0000 TB --- 2010-09-05 10:20:10 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 10:20:10 - starting RELENG_8_0 tinderbox run for sparc64/sparc64 TB --- 2010-09-05 10:20:10 - cleaning the object tree TB --- 2010-09-05 10:20:24 - cvsupping the source tree TB --- 2010-09-05 10:20:24 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/sparc64/sparc64/supfile TB --- 2010-09-05 10:58:04 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 10:58:04 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 10:58:04 - 0.47 user 9.04 system 2274.04 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Sun Sep 5 10:59:30 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29B2310656B2; Sun, 5 Sep 2010 10:59:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id DB8E88FC12; Sun, 5 Sep 2010 10:59:29 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o85AxT1T032531; Sun, 5 Sep 2010 06:59:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o85AxTv7032530; Sun, 5 Sep 2010 10:59:29 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 10:59:29 GMT Message-Id: <201009051059.o85AxTv7032530@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_0 tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 10:59:30 -0000 TB --- 2010-09-05 10:20:09 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 10:20:09 - starting RELENG_8_0 tinderbox run for powerpc/powerpc TB --- 2010-09-05 10:20:09 - cleaning the object tree TB --- 2010-09-05 10:20:21 - cvsupping the source tree TB --- 2010-09-05 10:20:21 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/powerpc/powerpc/supfile TB --- 2010-09-05 10:59:29 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 10:59:29 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 10:59:29 - 0.44 user 8.16 system 2359.78 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Sun Sep 5 11:31:45 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0B7310656A3; Sun, 5 Sep 2010 11:31:45 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 835CB8FC27; Sun, 5 Sep 2010 11:31:45 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o85BViLJ032641; Sun, 5 Sep 2010 07:31:44 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o85BVi9h032640; Sun, 5 Sep 2010 11:31:44 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 11:31:44 GMT Message-Id: <201009051131.o85BVi9h032640@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_1 tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 11:31:45 -0000 TB --- 2010-09-05 10:55:09 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 10:55:09 - starting RELENG_8_1 tinderbox run for amd64/amd64 TB --- 2010-09-05 10:55:09 - cleaning the object tree TB --- 2010-09-05 10:55:24 - cvsupping the source tree TB --- 2010-09-05 10:55:24 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/amd64/amd64/supfile TB --- 2010-09-05 11:31:44 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 11:31:44 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 11:31:44 - 0.65 user 10.70 system 2195.64 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Sun Sep 5 11:34:06 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 997AF10656AE; Sun, 5 Sep 2010 11:34:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 56DB98FC08; Sun, 5 Sep 2010 11:34:06 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o85BY5ci032661; Sun, 5 Sep 2010 07:34:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o85BY55p032660; Sun, 5 Sep 2010 11:34:05 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 11:34:05 GMT Message-Id: <201009051134.o85BY55p032660@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_1 tinderbox] failure on arm/arm X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 11:34:06 -0000 TB --- 2010-09-05 10:56:14 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 10:56:14 - starting RELENG_8_1 tinderbox run for arm/arm TB --- 2010-09-05 10:56:14 - cleaning the object tree TB --- 2010-09-05 10:56:21 - cvsupping the source tree TB --- 2010-09-05 10:56:21 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/arm/arm/supfile TB --- 2010-09-05 11:34:05 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 11:34:05 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 11:34:05 - 0.40 user 4.66 system 2270.75 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-arm-arm.full From owner-freebsd-stable@FreeBSD.ORG Sun Sep 5 11:36:25 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70B9B10656C3; Sun, 5 Sep 2010 11:36:25 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 338E98FC0A; Sun, 5 Sep 2010 11:36:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o85BaOC7032677; Sun, 5 Sep 2010 07:36:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o85BaOYs032676; Sun, 5 Sep 2010 11:36:24 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 11:36:24 GMT Message-Id: <201009051136.o85BaOYs032676@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_1 tinderbox] failure on i386/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 11:36:25 -0000 TB --- 2010-09-05 10:58:04 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 10:58:04 - starting RELENG_8_1 tinderbox run for i386/i386 TB --- 2010-09-05 10:58:04 - cleaning the object tree TB --- 2010-09-05 10:58:18 - cvsupping the source tree TB --- 2010-09-05 10:58:18 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/i386/i386/supfile TB --- 2010-09-05 11:36:24 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 11:36:24 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 11:36:24 - 0.58 user 9.55 system 2299.91 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Sun Sep 5 11:38:27 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC60A10656BD; Sun, 5 Sep 2010 11:38:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 765788FC1F; Sun, 5 Sep 2010 11:38:27 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o85BcQaV032687; Sun, 5 Sep 2010 07:38:26 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o85BcQnF032686; Sun, 5 Sep 2010 11:38:26 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 11:38:26 GMT Message-Id: <201009051138.o85BcQnF032686@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_1 tinderbox] failure on i386/pc98 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 11:38:27 -0000 TB --- 2010-09-05 10:59:29 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 10:59:29 - starting RELENG_8_1 tinderbox run for i386/pc98 TB --- 2010-09-05 10:59:29 - cleaning the object tree TB --- 2010-09-05 10:59:43 - cvsupping the source tree TB --- 2010-09-05 10:59:43 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/i386/pc98/supfile TB --- 2010-09-05 11:38:26 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 11:38:26 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 11:38:26 - 0.49 user 10.27 system 2337.23 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Sun Sep 5 12:11:51 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E0FE1065693; Sun, 5 Sep 2010 12:11:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E553E8FC13; Sun, 5 Sep 2010 12:11:50 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o85CBoan032811; Sun, 5 Sep 2010 08:11:50 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o85CBofc032810; Sun, 5 Sep 2010 12:11:50 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 12:11:50 GMT Message-Id: <201009051211.o85CBofc032810@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_1 tinderbox] failure on mips/mips X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 12:11:51 -0000 TB --- 2010-09-05 11:34:05 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 11:34:05 - starting RELENG_8_1 tinderbox run for mips/mips TB --- 2010-09-05 11:34:05 - cleaning the object tree TB --- 2010-09-05 11:34:13 - cvsupping the source tree TB --- 2010-09-05 11:34:13 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/mips/mips/supfile TB --- 2010-09-05 12:11:50 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 12:11:50 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 12:11:50 - 0.41 user 5.88 system 2264.37 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-mips-mips.full From owner-freebsd-stable@FreeBSD.ORG Sun Sep 5 12:12:12 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 991B410657FB; Sun, 5 Sep 2010 12:12:12 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5CC2D8FC12; Sun, 5 Sep 2010 12:12:12 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o85CCBJS032819; Sun, 5 Sep 2010 08:12:11 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o85CCBh0032818; Sun, 5 Sep 2010 12:12:11 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 12:12:11 GMT Message-Id: <201009051212.o85CCBh0032818@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_1 tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 12:12:12 -0000 TB --- 2010-09-05 11:31:45 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 11:31:45 - starting RELENG_8_1 tinderbox run for ia64/ia64 TB --- 2010-09-05 11:31:45 - cleaning the object tree TB --- 2010-09-05 11:32:00 - cvsupping the source tree TB --- 2010-09-05 11:32:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/ia64/ia64/supfile TB --- 2010-09-05 12:12:11 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 12:12:11 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 12:12:11 - 0.57 user 10.48 system 2426.68 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Sun Sep 5 12:14:22 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DA1810656B1; Sun, 5 Sep 2010 12:14:22 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 207F98FC0A; Sun, 5 Sep 2010 12:14:21 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o85CELbB032827; Sun, 5 Sep 2010 08:14:21 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o85CELkL032826; Sun, 5 Sep 2010 12:14:21 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 12:14:21 GMT Message-Id: <201009051214.o85CELkL032826@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_1 tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 12:14:22 -0000 TB --- 2010-09-05 11:36:24 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 11:36:24 - starting RELENG_8_1 tinderbox run for powerpc/powerpc TB --- 2010-09-05 11:36:24 - cleaning the object tree TB --- 2010-09-05 11:36:41 - cvsupping the source tree TB --- 2010-09-05 11:36:41 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/powerpc/powerpc/supfile TB --- 2010-09-05 12:14:21 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 12:14:21 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 12:14:21 - 0.55 user 10.39 system 2276.54 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Sun Sep 5 12:15:34 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DA7C10656B0; Sun, 5 Sep 2010 12:15:34 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 27DD98FC1D; Sun, 5 Sep 2010 12:15:33 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o85CFXHA032843; Sun, 5 Sep 2010 08:15:33 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o85CFXHj032842; Sun, 5 Sep 2010 12:15:33 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 12:15:33 GMT Message-Id: <201009051215.o85CFXHj032842@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_1 tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 12:15:34 -0000 TB --- 2010-09-05 11:38:26 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 11:38:26 - starting RELENG_8_1 tinderbox run for sparc64/sparc64 TB --- 2010-09-05 11:38:26 - cleaning the object tree TB --- 2010-09-05 11:38:41 - cvsupping the source tree TB --- 2010-09-05 11:38:41 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/sparc64/sparc64/supfile TB --- 2010-09-05 12:15:33 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 12:15:33 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 12:15:33 - 0.62 user 10.39 system 2226.56 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Sun Sep 5 14:57:11 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB01E10656C7; Sun, 5 Sep 2010 14:57:11 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 67A7E8FC0A; Sun, 5 Sep 2010 14:57:11 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o85EvARe028185; Sun, 5 Sep 2010 10:57:10 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o85EvAq9028184; Sun, 5 Sep 2010 14:57:10 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 14:57:10 GMT Message-Id: <201009051457.o85EvAq9028184@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on mips/mips X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 14:57:11 -0000 TB --- 2010-09-05 14:14:24 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 14:14:24 - starting RELENG_8 tinderbox run for mips/mips TB --- 2010-09-05 14:14:24 - cleaning the object tree TB --- 2010-09-05 14:14:24 - cvsupping the source tree TB --- 2010-09-05 14:14:24 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/mips/mips/supfile TB --- 2010-09-05 14:57:10 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 14:57:10 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 14:57:10 - 0.04 user 0.00 system 2566.10 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-mips-mips.full From owner-freebsd-stable@FreeBSD.ORG Sun Sep 5 14:59:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6DB91065698 for ; Sun, 5 Sep 2010 14:59:27 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9744F8FC16 for ; Sun, 5 Sep 2010 14:59:27 +0000 (UTC) Received: by iwn34 with SMTP id 34so3832158iwn.13 for ; Sun, 05 Sep 2010 07:59:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=61wfXfLT9L61exi/RUxJ2e5m6FsQIY5noDJnY4XqBZ4=; b=Yuj8+bEHjXaOhMZTBAdvlrb3lh9xYEmAELSVODMT1Woc0ZCCGKgVlsSmAhrvkutuCF U1ka1uy59TAwadWZJzuUlWFM8gYxNSZt3JRrEEoc4RXx6plDHX+8RxhYmqHEgqkPgKZR mEXfFoA2QgFTs1bJDe0Y00FB2LCI5N2V8SZGg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=FXklfWArx9r3bf7Dsk0NzqooaiOo9/KBu+oI3IdkjF5hvphHWXoenAtXNcAYa+C2Do UbT/GBCQDT5UCugKJIo1ukQaVcFU9xmReXp/3PRlCLPCpA5LAFo2OGDs6hZjwSh/nRcu 6Jj2WfetCMOKnAFddnmI9m6QngVeKfiCDi4dc= Received: by 10.231.30.68 with SMTP id t4mr4492477ibc.129.1283698766857; Sun, 05 Sep 2010 07:59:26 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-137-20.dsl.klmzmi.sbcglobal.net [99.181.137.20]) by mx.google.com with ESMTPS id i6sm1854752iba.8.2010.09.05.07.59.25 (version=SSLv3 cipher=RC4-MD5); Sun, 05 Sep 2010 07:59:26 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C83B04C.60901@DataIX.net> Date: Sun, 05 Sep 2010 10:59:24 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100806 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <201009051017.o85AHuPL032335@freebsd-current.sentex.ca> In-Reply-To: <201009051017.o85AHuPL032335@freebsd-current.sentex.ca> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Labor day Tinderbox/csup(1) Vacation. bad route. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 14:59:27 -0000 On 09/05/2010 06:17, FreeBSD Tinderbox wrote: > TB --- 2010-09-05 09:42:58 - tinderbox 2.6 running on freebsd-current.sentex.ca > TB --- 2010-09-05 09:42:58 - starting RELENG_8_0 tinderbox run for i386/i386 > TB --- 2010-09-05 09:42:58 - cleaning the object tree > TB --- 2010-09-05 09:43:27 - cvsupping the source tree > TB --- 2010-09-05 09:43:27 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/i386/i386/supfile > TB --- 2010-09-05 10:17:56 - WARNING: /usr/bin/csup returned exit code 1 > TB --- 2010-09-05 10:17:56 - ERROR: unable to cvsup the source tree > TB --- 2010-09-05 10:17:56 - 0.84 user 17.45 system 2097.45 real > > > http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-i386-i386.full It's not Labor day in the U.S. yet!... ;) BACK TO WORK! -- jhell,v From owner-freebsd-stable@FreeBSD.ORG Sun Sep 5 15:00:01 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C733C1065697; Sun, 5 Sep 2010 15:00:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7DB228FC18; Sun, 5 Sep 2010 15:00:01 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o85F00q1030658; Sun, 5 Sep 2010 11:00:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o85F008d030657; Sun, 5 Sep 2010 15:00:00 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 15:00:00 GMT Message-Id: <201009051500.o85F008d030657@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 15:00:01 -0000 TB --- 2010-09-05 14:19:29 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 14:19:29 - starting RELENG_8 tinderbox run for powerpc/powerpc TB --- 2010-09-05 14:19:29 - cleaning the object tree TB --- 2010-09-05 14:19:29 - cvsupping the source tree TB --- 2010-09-05 14:19:29 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/powerpc/powerpc/supfile TB --- 2010-09-05 15:00:00 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 15:00:00 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 15:00:00 - 0.03 user 0.01 system 2431.09 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Sun Sep 5 15:21:17 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57D7110656CE; Sun, 5 Sep 2010 15:21:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 1148D8FC08; Sun, 5 Sep 2010 15:21:16 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o85FLGNp060241; Sun, 5 Sep 2010 11:21:16 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o85FLGDj060229; Sun, 5 Sep 2010 15:21:16 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Sep 2010 15:21:16 GMT Message-Id: <201009051521.o85FLGDj060229@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 15:21:17 -0000 TB --- 2010-09-05 14:39:33 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-05 14:39:33 - starting RELENG_8 tinderbox run for sparc64/sparc64 TB --- 2010-09-05 14:39:33 - cleaning the object tree TB --- 2010-09-05 14:39:33 - cvsupping the source tree TB --- 2010-09-05 14:39:33 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/sparc64/sparc64/supfile TB --- 2010-09-05 15:21:16 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-05 15:21:16 - ERROR: unable to cvsup the source tree TB --- 2010-09-05 15:21:16 - 0.03 user 0.02 system 2503.09 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Sun Sep 5 19:42:06 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FFB410656C7 for ; Sun, 5 Sep 2010 19:42:06 +0000 (UTC) (envelope-from doublef-ctm@yandex.ru) Received: from forward3.mail.yandex.net (forward3.mail.yandex.net [77.88.46.8]) by mx1.freebsd.org (Postfix) with ESMTP id 22F568FC12 for ; Sun, 5 Sep 2010 19:42:05 +0000 (UTC) Received: from smtp2.mail.yandex.net (smtp2.mail.yandex.net [77.88.46.102]) by forward3.mail.yandex.net (Yandex) with ESMTP id 818E356D8E42; Sun, 5 Sep 2010 23:28:18 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1283714898; bh=rKQ33K5t3fAll7hzAD9UNOpzWwRbcLrqftB/OWolSso=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=TLzB6Yaz3ep6gb8Qgrti2br3Yf/irfgdZwKthLYH1HcZ0n/fzkPkTz/+QCdf3PqTO 4t4RNonfB9fqHHP4eVspK1jTVcVwXFGBtVBXmLRMiltw5cym8dIdr5MrtgmvewJjun A2kWLz3V1/521h9xz5z/kheH2izIgQIK/nWwKeRA= Received: from nautilus (unknown [178.155.56.14]) by smtp2.mail.yandex.net (Yandex) with ESMTPA id 2DB9F52806B; Sun, 5 Sep 2010 23:28:18 +0400 (MSD) Received: by nautilus (Postfix, from userid 1001) id 558501DD43D; Sun, 5 Sep 2010 23:28:16 +0400 (MSD) Date: Sun, 5 Sep 2010 23:28:16 +0400 From: Sergey Zaharchenko To: freebsd-stable@freebsd.org Message-ID: <20100905192816.GA9110@nautilus.vmks.ru> References: <20100821220435.GA6208@carrick-users.bishnet.net> <20100821222429.GB73221@dan.emsphone.com> <20100831133556.GB45316@carrick-users.bishnet.net> <20100831155829.GC5913@dan.emsphone.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+QahgC5+KEYLbs62" Content-Disposition: inline In-Reply-To: <20100831155829.GC5913@dan.emsphone.com> X-Listening-To: Silence User-Agent: Mutt/1.5.20 (2009-06-14) X-Yandex-TimeMark: 1283714898 X-Yandex-Spam: 1 X-Yandex-Front: smtp2.mail.yandex.net Cc: Dan Nelson Subject: Re: 8.1R ZFS almost locking up system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 19:42:06 -0000 --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello list! Thu, Jan 01, 1970 at 12:00:00AM +0000 Dan Nelson wrote: > In the last episode (Aug 31), Tim Bishop said: > > On Sat, Aug 21, 2010 at 05:24:29PM -0500, Dan Nelson wrote: > > > In the last episode (Aug 21), Tim Bishop said: > > > > A few items from top, including zfskern: > > > >=20 > > > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU = COMMAND > > > > 5 root 4 -8 - 0K 60K zio->i 0 54:38 3.47% = zfskern > > > > 91775 70 1 44 0 53040K 31144K tx->tx 1 2:11 0.00% = postgres > > > > 39661 tdb 1 44 0 55776K 32968K tx->tx 0 0:39 0.00% = mutt > > > > 14828 root 1 47 0 14636K 1572K tx->tx 1 0:03 0.00% = zfs > > > > 11188 root 1 51 0 14636K 1572K tx->tx 0 0:03 0.00% = zfs > > > >=20 I'm seeing a similar problem on a remote server (unpatched 8.1-RELEASE, amd64, quad-core, raidz pool on 8 drives). However, it's also different in what seems to be important. Please advise. Portions of top: CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Mem: 75M Active, 31M Inact, 1352M Wired, 136K Cache, 812M Buf, 6458M Free 35769 root 1 52 0 2740K 744K zilog- 1 0:00 0.00% sync 35625 df 1 44 0 14636K 1856K zio->i 2 0:00 0.00% zfs 35920 root 1 44 0 15668K 1836K scl->s 0 0:00 0.00% zpo= ol 35607 root 1 44 0 8260K 2284K zio->i 0 0:00 0.00% csh > > 0 100084 kernel zfs_vn_rele_task mi_switch+0x16f sleepq_w= ait+0x42 _sleep+0x31c taskqueue_thread_loop+0xb7 fork_exit+0x118 fork_tramp= oline+0xe=20 > > 5 100031 zfskern arc_reclaim_thre mi_switch+0x16f sleepq_t= imedwait+0x42 _cv_timedwait+0x129 arc_reclaim_thread+0x2d1 fork_exit+0x118 = fork_trampoline+0xe=20 > > 5 100032 zfskern l2arc_feed_threa mi_switch+0x16f sleepq_t= imedwait+0x42 _cv_timedwait+0x129 l2arc_feed_thread+0x1be fork_exit+0x118 f= ork_trampoline+0xe=20 > > 5 100085 zfskern txg_thread_enter mi_switch+0x16f sleepq_w= ait+0x42 _cv_wait+0x111 txg_thread_wait+0x79 txg_quiesce_thread+0xb5 fork_e= xit+0x118 fork_trampoline+0xe=20 > > 5 100086 zfskern txg_thread_enter mi_switch+0x16f sleepq_w= ait+0x42 _cv_wait+0x111 zio_wait+0x61 dsl_pool_sync+0xea spa_sync+0x355 txg= _sync_thread+0x195 fork_exit+0x118 fork_trampoline+0xe=20 procstat -kk -a: 0 100114 kernel zfs_vn_rele_task mi_switch+0x16f sleepq_wait+= 0x42 _sleep+0x31c taskqueue_thread_loop+0xb7 fork_exit+0x118 fork_trampolin= e+0xe 0 100123 kernel zil_clean mi_switch+0x16f sleepq_wait+= 0x42 _sleep+0x31c taskqueue_thread_loop+0xb7 fork_exit+0x118 fork_trampolin= e+0xe 16 100065 syncer - mi_switch+0x16f sleepq_wait+= 0x42 _cv_wait+0x111 zio_wait+0x61 zil_commit+0x3e1 zfs_sync+0xa6 sync_fsync= +0x184 sync_vnode+0x16b sched_sync+0x1c9 fork_exit+0x118 fork_trampoline+0xe 39 100079 zfskern arc_reclaim_thre mi_switch+0x16f sleepq_timed= wait+0x42 _cv_timedwait+0x129 arc_reclaim_thread+0x2d1 fork_exit+0x118 fork= _trampoline+0xe 39 100086 zfskern l2arc_feed_threa mi_switch+0x16f sleepq_timed= wait+0x42 _cv_timedwait+0x129 l2arc_feed_thread+0x1be fork_exit+0x118 fork_= trampoline+0xe 39 100115 zfskern txg_thread_enter mi_switch+0x16f sleepq_wait+= 0x42 _cv_wait+0x111 txg_thread_wait+0x79 txg_quiesce_thread+0xb5 fork_exit+= 0x118 fork_trampoline+0xe 39 100116 zfskern txg_thread_enter mi_switch+0x16f sleepq_wait+= 0x42 _cv_wait+0x111 zio_wait+0x61 dsl_pool_sync+0xea spa_sync+0x355 txg_syn= c_thread+0x195 35625 100151 zfs - mi_switch+0x16f sleepq_wait+= 0x42 _cv_wait+0x111 zio_wait+0x61 dbuf_read+0x39a dmu_buf_hold+0xcc zap_loc= kdir+0x52 zap_cursor_retrieve+0x194 dsl_prop_get_all+0x187 zfs_ioc_objset_s= tats+0x7b zfsdev_ioctl+0x8d devfs_ioctl_f+0x77 kern_ioctl+0xf6 ioctl+0xfd s= yscall+0x1e7 35769 100212 sync - mi_switch+0x16f sleepq_wait+= 0x42 _cv_wait+0x111 zil_commit+0x7a zfs_sync+0xa6 sync+0x20e syscall+0x1e7 = Xfast_syscall+0xe1 etc. etc... Seems pretty identical... But gstat seems different: dT: 1.008s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name =2E.. 3 0 0 0 0.0 0 0 0.0 0.0 da0 3 0 0 0 0.0 0 0 0.0 0.0 da1 3 0 0 0 0.0 0 0 0.0 0.0 da2 35 0 0 0 0.0 0 0 0.0 0.0 da3 3 0 0 0 0.0 0 0 0.0 0.0 da4 2 0 0 0 0.0 0 0 0.0 0.0 da5 3 0 0 0 0.0 0 0 0.0 0.0 da6 35 0 0 0 0.0 0 0 0.0 0.0 da7 Note the huge wait queues... I've tried reading from the disks (dd), camcontrol inquiry'ing them, but all of these methods fail: %dd if=3D/dev/da3 of=3D/dev/null bs=3D1024k load: 0.00 cmd: dd 37770 [physrd] 2.67r 0.00u 0.00s 0% 1168k [and nothing input/output] So, one could suspect a hardware problem. FWIW the RAID h/w is a RocketRaid: hptiop0: adapter at PCI 5:0:0, IRQ 16 hptiop0: mem 0xdd800000-0xddffffff irq 16 at device 0.0 on pci5 hptiop0: 0 RocketRAID 3xxx/4xxx controller driver v1.3 (010208) hptiop0: [GIANT-LOCKED] hptiop0: [ITHREAD] > if your FS has been near 99%, you may not have any large runs > of freespace left. <3GB out of 12TB is used in my case. > L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name > 1 48 48 3042 9.8 0 0 0.0 47.6| ad4 > 0 38 38 2406 10.5 0 0 0.0 39.5| ad6 >=20 > You have a pair of mirrored disks, each doing around 40% I/O load, which = is > 80% load if a single-threaded task is driving all the I/O. No load at all in my case... > I see the syncer > process is also trying to write to the ZIL. Are you running something th= at > does a lot of fsync calls (a database server for example)? There's a postgresql database there but it was inactive at the time the first hung processes showed up. > Is this system an NFS server maybe? No. Peculiarities include using ez-jail for a couple of jails over ZFS (also using nullfs). > Try setting the sysctl vfs.zfs.zil_disable=3D1 and see > if your performance improves. Sure enough, it didn't help the existing processes, but I'll try it after a reboot. How likely do you think a hardware error is in this setup? Can I do anything else to help diagnose this problem? Thanks for any other input, --=20 DoubleF --+QahgC5+KEYLbs62 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkyD708ACgkQwo7hT/9lVdxJLgCfdlkQXw85usOxvR/l1StLM+N3 X1oAmwXy551/MeYxLNNzooVrDAJdzRyp =EgCL -----END PGP SIGNATURE----- --+QahgC5+KEYLbs62-- From owner-freebsd-stable@FreeBSD.ORG Sun Sep 5 20:35:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9314A10656D6 for ; Sun, 5 Sep 2010 20:35:27 +0000 (UTC) (envelope-from benschumacher@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 50BAE8FC19 for ; Sun, 5 Sep 2010 20:35:27 +0000 (UTC) Received: by gxk24 with SMTP id 24so1676725gxk.13 for ; Sun, 05 Sep 2010 13:35:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=EQ0a/YIFbvgO93BAWQuiwfzCeQl8rDInLeIRS4YhvBE=; b=dsTrJf2Crxxb61YFj/MPda82wDdt7Mci7qsLv+U6FTtUE0UohK5QGa2bdmTUSiHKMd 5ddxTNw5gv7Wvyz6fNTx01rZdnW9DTuiyJCBxmmTytfTRZMtDRHxjSJr3hrv9xKEqLne mbzbRguqJ5HcXi77DLRmrzYYf2E/PN9G3DnOw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=AI76VjftebaHbAYeBYkwJ0ECNc6R27tpMUkbOyBPxgLCY40aJF7y2KYBAY/iX/YClt wAVPAdvgPSGbmlu54xButWeihPrqbw2gCywgtthKbV79wuJcgLlr57NEdIIPnEGSgxV0 2llcuB+X0+zeKC90noLGw18vJlsWJWGM0swyw= MIME-Version: 1.0 Received: by 10.100.139.10 with SMTP id m10mr297109and.132.1283718926492; Sun, 05 Sep 2010 13:35:26 -0700 (PDT) Received: by 10.100.243.20 with HTTP; Sun, 5 Sep 2010 13:35:26 -0700 (PDT) Date: Sun, 5 Sep 2010 14:35:26 -0600 Message-ID: From: Ben Schumacher To: apcupsd-users@lists.sourceforge.net, freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: apcupsd, USB and FreeBSD 8.1 aren't getting along (SOLVED) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 20:35:27 -0000 On Sat, Sep 4, 2010 at 5:37 AM, Mike Tancsa wrote: > At 04:44 PM 9/3/2010, Ben Schumacher wrote: >> >> All- >> >> It seems that something about the combination of FreeBSD 8.1 and >> apcupsd connecting to an APC Back-UPS RS 1500. >> >> Here's what I've got: >> 1. FreeBSD 8.1 (source compiled up to RELENG_8_1 for security fixes) >> 2. apcupsd 3.14.8 compiled from FreeBSD Ports >> 3. APC Back-UPS RS 1500 > > Hi, > =C2=A0 =C2=A0 =C2=A0 =C2=A0I am running RELENG_8 with such a ups. > > 8.1-STABLE FreeBSD 8.1-STABLE #1: Wed Sep =C2=A01 11:42:00 EDT 2010 Mike- Thanks for your help. Your email encouraged me to keep digging and I eventually figured out the problem. For some reason (I'm not sure why/when/how) I had managed to get libusb installed from ports and apcupsd (and other tools) was linked against that version of libusb. I figured this out with ldd. After removing that port (on which nothing else I had installed depended) with pkg_delete and a rebuild from the apcupsd port, everything is working fine again. I've migrated this machine from FreeBSD 7.0-BETA1 forward using source upgrades and I'd guess that at some point along the way something required the libusb from ports, but that dependency appears to be gone now. Just thought I'd shared this back with the mailing lists in case anybody else runs into a similar issue. Thanks again! Ben From owner-freebsd-stable@FreeBSD.ORG Sun Sep 5 22:58:42 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A1A810656A4 for ; Sun, 5 Sep 2010 22:58:42 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2-6.sentex.ca [IPv6:2607:f3e0:80:80::2]) by mx1.freebsd.org (Postfix) with ESMTP id 198888FC12 for ; Sun, 5 Sep 2010 22:58:42 +0000 (UTC) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.4/8.14.4) with ESMTP id o85MwVfr077422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 5 Sep 2010 18:58:32 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o85MwULx042437; Sun, 5 Sep 2010 18:58:30 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201009052258.o85MwULx042437@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 05 Sep 2010 18:58:33 -0400 To: jhell , freebsd-stable@freebsd.org From: Mike Tancsa In-Reply-To: <4C83B04C.60901@DataIX.net> References: <201009051017.o85AHuPL032335@freebsd-current.sentex.ca> <4C83B04C.60901@DataIX.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.67 on 205.211.164.50 Cc: Subject: Re: Labor day Tinderbox/csup(1) Vacation. bad route. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 22:58:42 -0000 At 10:59 AM 9/5/2010, jhell wrote: > > TB --- 2010-09-05 10:17:56 - ERROR: unable to cvsup the source tree > > TB --- 2010-09-05 10:17:56 - 0.84 user 17.45 system 2097.45 real > > > > > > http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-i386-i386.full > >It's not Labor day in the U.S. yet!... ;) BACK TO WORK! Some more hardware problems with the local cvsup mirror. For now, I have pointed it elsewhere until we figure out the source of the hardware issue. Perhaps bad MB or bad NIC. We swapped out the NIC for now and will monitor over the next few days before pointing it back. ---Mike >-- > > jhell,v >_______________________________________________ >freebsd-stable@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-stable >To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-stable@FreeBSD.ORG Mon Sep 6 12:17:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC98F10656D3; Mon, 6 Sep 2010 12:17:45 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 639378FC19; Mon, 6 Sep 2010 12:17:44 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA01838; Mon, 06 Sep 2010 15:17:42 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4C84DBE6.5010809@freebsd.org> Date: Mon, 06 Sep 2010 15:17:42 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100823 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <4C782D3B.6020407@icyb.net.ua> <201008271743.29393.jkim@FreeBSD.org> <4C7835E6.6070309@icyb.net.ua> <4C7A2782.5040009@freebsd.org> In-Reply-To: <4C7A2782.5040009@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jeff Roberson , Jung-uk Kim Subject: Re: patch for topology detection of Intel CPUs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2010 12:17:45 -0000 on 29/08/2010 12:25 Andriy Gapon said the following: > The below patch is against sources in FreeBSD tree, it should be applied > either to sys/amd64/amd64/mp_machdep.c or sys/i386/i386/mp_machdep.c depending > on the desired architecture: > http://people.freebsd.org/~avg/intel-cpu-topo.diff I see that I am not getting as many testers as I expected, so I am going to commit the patch. You still have a short while to either objectively object to the patch or to voluntary test it :-) -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Sep 6 12:23:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9F7910656D8 for ; Mon, 6 Sep 2010 12:23:27 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by mx1.freebsd.org (Postfix) with ESMTP id BFC498FC21 for ; Mon, 6 Sep 2010 12:23:27 +0000 (UTC) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta11.emeryville.ca.mail.comcast.net with comcast id 3QLm1f0020QkzPwABQPTME; Mon, 06 Sep 2010 12:23:27 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta02.emeryville.ca.mail.comcast.net with comcast id 3QPS1f0023LrwQ28NQPS6g; Mon, 06 Sep 2010 12:23:26 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 1C66A9B425; Mon, 6 Sep 2010 05:23:26 -0700 (PDT) Date: Mon, 6 Sep 2010 05:23:26 -0700 From: Jeremy Chadwick To: Andriy Gapon Message-ID: <20100906122325.GA78727@icarus.home.lan> References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <4C782D3B.6020407@icyb.net.ua> <201008271743.29393.jkim@FreeBSD.org> <4C7835E6.6070309@icyb.net.ua> <4C7A2782.5040009@freebsd.org> <4C84DBE6.5010809@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C84DBE6.5010809@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Jeff Roberson , freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Jung-uk Kim Subject: Re: patch for topology detection of Intel CPUs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2010 12:23:28 -0000 On Mon, Sep 06, 2010 at 03:17:42PM +0300, Andriy Gapon wrote: > on 29/08/2010 12:25 Andriy Gapon said the following: > > The below patch is against sources in FreeBSD tree, it should be applied > > either to sys/amd64/amd64/mp_machdep.c or sys/i386/i386/mp_machdep.c depending > > on the desired architecture: > > http://people.freebsd.org/~avg/intel-cpu-topo.diff > > I see that I am not getting as many testers as I expected, so I am going to commit > the patch. > > You still have a short while to either objectively object to the patch or to > voluntary test it :-) I would gladly assist in testing this, except there doesn't appear to be an authoritative statement that it will apply to RELENG_8; when I see WIP, I assume -CURRENT/HEAD only. Let me know, since all the systems I have are Intel multi-core. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Sep 6 12:56:06 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11D6F10656A7; Mon, 6 Sep 2010 12:56:06 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 253BC8FC25; Mon, 6 Sep 2010 12:56:04 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA02386; Mon, 06 Sep 2010 15:56:01 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4C84E4E1.8010709@freebsd.org> Date: Mon, 06 Sep 2010 15:56:01 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100823 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jeremy Chadwick References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <4C782D3B.6020407@icyb.net.ua> <201008271743.29393.jkim@FreeBSD.org> <4C7835E6.6070309@icyb.net.ua> <4C7A2782.5040009@freebsd.org> <4C84DBE6.5010809@freebsd.org> <20100906122325.GA78727@icarus.home.lan> In-Reply-To: <20100906122325.GA78727@icarus.home.lan> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: patch for topology detection of Intel CPUs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2010 12:56:06 -0000 on 06/09/2010 15:23 Jeremy Chadwick said the following: > On Mon, Sep 06, 2010 at 03:17:42PM +0300, Andriy Gapon wrote: >> on 29/08/2010 12:25 Andriy Gapon said the following: >>> The below patch is against sources in FreeBSD tree, it should be applied >>> either to sys/amd64/amd64/mp_machdep.c or sys/i386/i386/mp_machdep.c depending >>> on the desired architecture: >>> http://people.freebsd.org/~avg/intel-cpu-topo.diff >> >> I see that I am not getting as many testers as I expected, so I am going to commit >> the patch. >> >> You still have a short while to either objectively object to the patch or to >> voluntary test it :-) > > I would gladly assist in testing this, except there doesn't appear to be > an authoritative statement that it will apply to RELENG_8; when I see > WIP, I assume -CURRENT/HEAD only. patch -C is much better than any statement :) > Let me know, since all the systems I have are Intel multi-core. Yes, the patch should be applicable to stable/8 without any issues. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Sep 6 13:12:06 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3EF010656AC for ; Mon, 6 Sep 2010 13:12:05 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by mx1.freebsd.org (Postfix) with ESMTP id 9C82D8FC1D for ; Mon, 6 Sep 2010 13:12:05 +0000 (UTC) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta02.westchester.pa.mail.comcast.net with comcast id 3QTz1f0031ap0As52RC5i6; Mon, 06 Sep 2010 13:12:05 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta22.westchester.pa.mail.comcast.net with comcast id 3RC41f0083LrwQ23iRC5zF; Mon, 06 Sep 2010 13:12:05 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 8E1559B425; Mon, 6 Sep 2010 06:12:03 -0700 (PDT) Date: Mon, 6 Sep 2010 06:12:03 -0700 From: Jeremy Chadwick To: Andriy Gapon Message-ID: <20100906131203.GA80251@icarus.home.lan> References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <4C782D3B.6020407@icyb.net.ua> <201008271743.29393.jkim@FreeBSD.org> <4C7835E6.6070309@icyb.net.ua> <4C7A2782.5040009@freebsd.org> <4C84DBE6.5010809@freebsd.org> <20100906122325.GA78727@icarus.home.lan> <4C84E4E1.8010709@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C84E4E1.8010709@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: patch for topology detection of Intel CPUs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2010 13:12:06 -0000 On Mon, Sep 06, 2010 at 03:56:01PM +0300, Andriy Gapon wrote: > on 06/09/2010 15:23 Jeremy Chadwick said the following: > > On Mon, Sep 06, 2010 at 03:17:42PM +0300, Andriy Gapon wrote: > >> on 29/08/2010 12:25 Andriy Gapon said the following: > >>> The below patch is against sources in FreeBSD tree, it should be applied > >>> either to sys/amd64/amd64/mp_machdep.c or sys/i386/i386/mp_machdep.c depending > >>> on the desired architecture: > >>> http://people.freebsd.org/~avg/intel-cpu-topo.diff > >> > >> I see that I am not getting as many testers as I expected, so I am going to commit > >> the patch. > >> > >> You still have a short while to either objectively object to the patch or to > >> voluntary test it :-) > > > > I would gladly assist in testing this, except there doesn't appear to be > > an authoritative statement that it will apply to RELENG_8; when I see > > WIP, I assume -CURRENT/HEAD only. > > patch -C is much better than any statement :) > > > Let me know, since all the systems I have are Intel multi-core. > > Yes, the patch should be applicable to stable/8 without any issues. Great, thanks! I'll be testing this out on two separate systems, both RELENG_8: - Supermicro X7SBA + Intel C2D E8400 (stepping 10) - Supermicro X7SBL-LN2 + Intel C2D E6600 (stepping 6) I'll make sure to provide what the topology looks like before and after. Is CPU-relevant dmesg output sufficient? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Sep 6 13:28:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CE4F1065794; Mon, 6 Sep 2010 13:28:07 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8191F8FC22; Mon, 6 Sep 2010 13:28:06 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA02987; Mon, 06 Sep 2010 16:28:03 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4C84EC62.6020205@freebsd.org> Date: Mon, 06 Sep 2010 16:28:02 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100823 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jeremy Chadwick References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <4C782D3B.6020407@icyb.net.ua> <201008271743.29393.jkim@FreeBSD.org> <4C7835E6.6070309@icyb.net.ua> <4C7A2782.5040009@freebsd.org> <4C84DBE6.5010809@freebsd.org> <20100906122325.GA78727@icarus.home.lan> <4C84E4E1.8010709@freebsd.org> <20100906131203.GA80251@icarus.home.lan> In-Reply-To: <20100906131203.GA80251@icarus.home.lan> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: patch for topology detection of Intel CPUs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2010 13:28:07 -0000 on 06/09/2010 16:12 Jeremy Chadwick said the following: > Great, thanks! I'll be testing this out on two separate systems, both > RELENG_8: > > - Supermicro X7SBA + Intel C2D E8400 (stepping 10) > - Supermicro X7SBL-LN2 + Intel C2D E6600 (stepping 6) > > I'll make sure to provide what the topology looks like before and after. > Is CPU-relevant dmesg output sufficient? If you mean something like the below, then yes. Thanks! CPU: Intel(R) Core(TM)2 Duo CPU E7300 @ 2.66GHz (2653.35-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Family = 6 Model = 17 Stepping = 6 Features=0xbfebfbff Features2=0x8e39d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant [snip] FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Sep 6 14:37:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71DAA10656D9 for ; Mon, 6 Sep 2010 14:37:48 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 252F38FC16 for ; Mon, 6 Sep 2010 14:37:47 +0000 (UTC) Received: by qyk31 with SMTP id 31so2541154qyk.13 for ; Mon, 06 Sep 2010 07:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=Tu3oZZ8nssdQ+ZWi7EDhlnZj+l/vaBn4Fn2En5+KtGM=; b=EBJq9EZluvvGuED1HLgFpT2KuwCOI2NNJPfBHfC5QN7rAqezvQUDjB+87DO++QEidA YbeGJLv94H4HxS8ToggARKSOkPkwOgwjjD5r9prc/wb1GWB3lvXC7sSDX+b7CsP7gLWf BrMF6gKOufSs592nPzmwJ/Ne4t13/VsN3SHwI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=u2l03ZLpJNUl2FT/RP3uCLMs4h0/45hIKGE2mKz7Oo8kHHioNlNB+qSaT6myLAeGcd Kb/uql7+SRFpy4o8wxDR7Jv0lIH13MwLYUIDXnrb3NALlEesu4xbqlHGCdWOCX3PGdT3 ZPUwJABIhj/ryPsQZ+vGt/gC7I9JPcMC0Wh78= MIME-Version: 1.0 Received: by 10.229.236.213 with SMTP id kl21mr1061051qcb.120.1283783866648; Mon, 06 Sep 2010 07:37:46 -0700 (PDT) Received: by 10.229.19.206 with HTTP; Mon, 6 Sep 2010 07:37:46 -0700 (PDT) In-Reply-To: References: Date: Mon, 6 Sep 2010 18:37:46 +0400 Message-ID: From: pluknet To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: uma_ref_cnt: vm_fault: fault on nofault entry X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2010 14:37:49 -0000 On 3 August 2010 15:29, pluknet wrote: > > The second panic seen today on the same box at uma_find_refcnt(). > I'm unsure if it might be caused by Xen hvm setup. Okey, updating the system to 8.1-R seems to fix this. 13 days of uptime since then, while with 8.0 it panicked every 3-4 days. > > db> bt > Tracing pid 12 tid 100035 td 0xc776f480 > kdb_enter(c0c8dce2,c0c8dce2,c0cab939,c73678b8,0,...) at kdb_enter+0x3a > panic(c0cab939,c14b3000,1,c73679e8,c73679d8,...) at panic+0x136 > vm_fault(c1490000,c14b3000,1,0,c7a81760,...) at vm_fault+0x197 > trap_pfault(c7bb1748,c7367aa0,c7f7e7bf,c7bb1700,c755c7f8,...) at > trap_pfault+0x20e > trap(c7367b04) at trap+0x455 > calltrap() at calltrap+0x6 > --- trap 0xc, eip = 0xc0af336b, esp = 0xc7367b44, ebp = 0xc7367b4c --- > uma_find_refcnt(c147f700,cbe96800,1,1,cbe96800,...) at uma_find_refcnt+0x5b > mb_ctor_clust(cbe96800,800,c7f2a700,1,c0dd7b40,...) at mb_ctor_clust+0x9c > uma_zalloc_arg(c147f700,c7f2a700,1,c776f000,0,...) at uma_zalloc_arg+0x8a > igb_get_buf(c0dd6e40,c0dd6e40,c0dd6e40,c7367c38,c08a9d00,...) at > igb_get_buf+0x146 > igb_rxeof(c775f540,0,0,c775f5c0,c7762a00,...) at igb_rxeof+0x2b0 > igb_msix_rx(c7760a00,0,109,e3c02e88,2a1bf,...) at igb_msix_rx+0x29 > intr_event_execute_handlers(c755c7f8,c7762a00,c0c8ab0b,4f6,c7762a70,...) > at intr_event_execute_handlers+0x14b > ithread_loop(c7772930,c7367d38,0,0,0,...) at ithread_loop+0x6b > fork_exit(c0861b20,c7772930,c7367d38) at fork_exit+0x91 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xc7367d70, ebp = 0 --- > -- wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Mon Sep 6 15:40:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7174F10656B0 for ; Mon, 6 Sep 2010 15:40:51 +0000 (UTC) (envelope-from sterling@camdensoftware.com) Received: from wh2.interactivevillages.com (wh2.interactivevillages.com [75.125.250.34]) by mx1.freebsd.org (Postfix) with ESMTP id 357908FC21 for ; Mon, 6 Sep 2010 15:40:50 +0000 (UTC) Received: from 174-21-101-5.tukw.qwest.net ([174.21.101.5] helo=_HOSTNAME_) by wh2.interactivevillages.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OsdgK-0000pr-OW for freebsd-stable@freebsd.org; Mon, 06 Sep 2010 08:32:31 -0700 Received: by _HOSTNAME_ (sSMTP sendmail emulation); Mon, 06 Sep 2010 08:40:43 -0700 Date: Mon, 6 Sep 2010 08:40:43 -0700 From: Chip Camden To: freebsd-stable@freebsd.org Message-ID: <20100906154043.GB18512@libertas.local.camdensoftware.com> Mail-Followup-To: freebsd-stable@freebsd.org References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <4C782D3B.6020407@icyb.net.ua> <201008271743.29393.jkim@FreeBSD.org> <4C7835E6.6070309@icyb.net.ua> <4C7A2782.5040009@freebsd.org> <4C84DBE6.5010809@freebsd.org> <20100906122325.GA78727@icarus.home.lan> <4C84E4E1.8010709@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gj572EiMnwbLXET9" Content-Disposition: inline In-Reply-To: <4C84E4E1.8010709@freebsd.org> User-Agent: Mutt/1.4.2.3i Company: Camden Software Consulting URL: http://camdensoftware.com X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wh2.interactivevillages.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - camdensoftware.com Subject: Re: patch for topology detection of Intel CPUs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2010 15:40:51 -0000 --gj572EiMnwbLXET9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoth Andriy Gapon on Monday, 06 September 2010: > on 06/09/2010 15:23 Jeremy Chadwick said the following: > > On Mon, Sep 06, 2010 at 03:17:42PM +0300, Andriy Gapon wrote: > >> on 29/08/2010 12:25 Andriy Gapon said the following: > >>> The below patch is against sources in FreeBSD tree, it should be appl= ied > >>> either to sys/amd64/amd64/mp_machdep.c or sys/i386/i386/mp_machdep.c = depending > >>> on the desired architecture: > >>> http://people.freebsd.org/~avg/intel-cpu-topo.diff > >> > >> I see that I am not getting as many testers as I expected, so I am goi= ng to commit > >> the patch. > >> > >> You still have a short while to either objectively object to the patch= or to > >> voluntary test it :-) > >=20 > > I would gladly assist in testing this, except there doesn't appear to be > > an authoritative statement that it will apply to RELENG_8; when I see > > WIP, I assume -CURRENT/HEAD only. >=20 > patch -C is much better than any statement :) >=20 > > Let me know, since all the systems I have are Intel multi-core. >=20 > Yes, the patch should be applicable to stable/8 without any issues. >=20 > --=20 > Andriy Gapon > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" OK, I'll try it out too then. --=20 Sterling (Chip) Camden | sterling@camdensoftware.com | 2048D/3A978E4F http://camdensoftware.com | http://chipstips.com | http://chipsquips= .com --gj572EiMnwbLXET9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iQEcBAEBAgAGBQJMhQt7AAoJEIpckszW26+RVRMH/Rbskifgo9rn099qNFeyJcpu euPP9g9AiCgiN8m8KHtyaXa/eL0P18lCAMuLZXufiNWjmpIRb+FpvXLG3y28MXMx lt7M6TctssiT4zizP52BePPxzYDaHOIK5/9UdFrKXarEjaGda/l0K4QpG/6Lu4II T7L635ps78rXSsAgmpIx12Y5pncBUEhnu8FLye7gc3ZiuNEn7Htlji/gNgyPK69b SS50LN74uoqfl/MsBAn5k6X6Tw/8P1k7ZUyCDdrrqfzTqoL8CcrFuT1hxiSnjOCt AclXyUOlkWuS2DDskxiT4qq3i7hcaILbRf4VzzLELognwy8DVOwy7ks7P9DYkFo= =IKt/ -----END PGP SIGNATURE----- --gj572EiMnwbLXET9-- From owner-freebsd-stable@FreeBSD.ORG Mon Sep 6 16:22:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C01721065697 for ; Mon, 6 Sep 2010 16:22:32 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id A14F28FC1A for ; Mon, 6 Sep 2010 16:22:32 +0000 (UTC) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta12.emeryville.ca.mail.comcast.net with comcast id 3Sno1f0011zF43QACUNY1Y; Mon, 06 Sep 2010 16:22:32 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta24.emeryville.ca.mail.comcast.net with comcast id 3UNX1f0013LrwQ28kUNXC8; Mon, 06 Sep 2010 16:22:31 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id C8BE29B423; Mon, 6 Sep 2010 09:22:30 -0700 (PDT) Date: Mon, 6 Sep 2010 09:22:30 -0700 From: Jeremy Chadwick To: Andriy Gapon Message-ID: <20100906162230.GA1444@icarus.home.lan> References: <4C782D3B.6020407@icyb.net.ua> <201008271743.29393.jkim@FreeBSD.org> <4C7835E6.6070309@icyb.net.ua> <4C7A2782.5040009@freebsd.org> <4C84DBE6.5010809@freebsd.org> <20100906122325.GA78727@icarus.home.lan> <4C84E4E1.8010709@freebsd.org> <20100906131203.GA80251@icarus.home.lan> <4C84EC62.6020205@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C84EC62.6020205@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: patch for topology detection of Intel CPUs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2010 16:22:32 -0000 On Mon, Sep 06, 2010 at 04:28:02PM +0300, Andriy Gapon wrote: > on 06/09/2010 16:12 Jeremy Chadwick said the following: > > Great, thanks! I'll be testing this out on two separate systems, both > > RELENG_8: > > > > - Supermicro X7SBA + Intel C2D E8400 (stepping 10) > > - Supermicro X7SBL-LN2 + Intel C2D E6600 (stepping 6) > > > > I'll make sure to provide what the topology looks like before and after. > > Is CPU-relevant dmesg output sufficient? > > If you mean something like the below, then yes. Thanks! > [...] All done. Good news (I think): there's no difference in the CPU-related topology on either system with your patch, aside from kernel build date. The topologies are still detected correctly. In case you want them: Supermicro X7SBA Intel C2D E8400 (stepping 10) =============================== Copyright (c) 1992-2010 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 8.1-STABLE #0: Mon Sep 6 09:06:52 PDT 2010 root@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz (2992.52-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x1067a Family = 6 Model = 17 Stepping = 10 Features=0xbfebfbff Features2=0x408e3fd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 4112097280 (3921 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 ichwd module loaded acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 cpu1: on acpi0 Supermicro X7SBL-LN2 Intel C2D E6600 (stepping 6) ============================== Copyright (c) 1992-2010 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 8.1-STABLE #1: Mon Sep 6 07:59:49 PDT 2010 root@gujoja.home.lan:/usr/obj/usr/src/sys/X7SBL_RELENG_8_amd64 amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz (2394.01-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Family = 6 Model = f Stepping = 6 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 8589934592 (8192 MB) avail memory = 8261648384 (7878 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ichwd module loaded acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 cpu1: on acpi0 All other systems I have are C2D and C2Q-based, but I can't easily test on those given their production roles. If there's a particular Intel processor family/model you're interested in, let me know and I can dig around to see if I have access to one. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Sep 6 16:30:13 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89EED10656DA for ; Mon, 6 Sep 2010 16:30:13 +0000 (UTC) (envelope-from lordcow@lordcow.org) Received: from lordcow.org (lordcow.org [41.203.5.188]) by mx1.freebsd.org (Postfix) with ESMTP id AD56B8FC21 for ; Mon, 6 Sep 2010 16:30:12 +0000 (UTC) Received: from lordcow.org (localhost [127.0.0.1]) by lordcow.org (8.14.4/8.14.4) with ESMTP id o86FrtiU050169 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Mon, 6 Sep 2010 17:53:55 +0200 (SAST) (envelope-from lordcow@lordcow.org) Received: (from lordcow@localhost) by lordcow.org (8.14.4/8.14.4/Submit) id o86Frojr050168 for stable@freebsd.org; Mon, 6 Sep 2010 17:53:50 +0200 (SAST) (envelope-from lordcow) Date: Mon, 6 Sep 2010 17:53:50 +0200 From: Gareth de Vaux To: stable@freebsd.org Message-ID: <20100906155350.GA50151@lordcow.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lordcow.org Cc: Subject: MSIX failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2010 16:30:13 -0000 Hi all, I moved from 8.0-RELEASE to last week's -STABLE: $ uname -v FreeBSD 8.1-STABLE #0: Thu Sep 2 16:38:02 SAST 2010 root@XXXXX:/usr/obj/usr/src/sys/GENERIC and all seems well except my network card is unusable. On boot up: em0: port 0x3040-0x305f mem 0xe3200000-0xe321ffff,0xe3220000-0xe3220fff irq 10 at device 25.0 on pci0 em0: Setup MSIX failure em0: [FILTER] em0: Ethernet address: 00:27:0e:1e:5e:e3 em1: port 0x1000-0x103f mem 0xe3120000-0xe313ffff,0xe3100000-0xe311ffff irq 9 at device 1.0 on pci5 em1: [FILTER] em1: Ethernet address: 00:1b:21:5b:f2:18 em0 is a PCI 'Intel(R) PRO/1000 GT Desktop Adapter' which worked up until now. em1 is onboard which didn't work with 8.0-RELEASE either. $ ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=219b ether 00:27:0e:1e:5e:e3 inet XXXXXXXX media: Ethernet autoselect status: no carrier pciconf -lv: em0@pci0:0:25:0: class=0x020000 card=0x00008086 chip=0x10f08086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet em1@pci0:5:1:0: class=0x020000 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' class = network subclass = ethernet (no device listing for em0) Swapping the PCI card with a PCI-X version gives the same behaviour. Setting hw.pci.enable_msix and hw.pci.enable_msi to 0 doesn't help in either case. From owner-freebsd-stable@FreeBSD.ORG Mon Sep 6 16:33:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C13F10656CB; Mon, 6 Sep 2010 16:33:26 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 733D38FC18; Mon, 6 Sep 2010 16:33:25 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA05715; Mon, 06 Sep 2010 19:33:21 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4C8517D1.3050603@freebsd.org> Date: Mon, 06 Sep 2010 19:33:21 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100823 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jeremy Chadwick References: <4C782D3B.6020407@icyb.net.ua> <201008271743.29393.jkim@FreeBSD.org> <4C7835E6.6070309@icyb.net.ua> <4C7A2782.5040009@freebsd.org> <4C84DBE6.5010809@freebsd.org> <20100906122325.GA78727@icarus.home.lan> <4C84E4E1.8010709@freebsd.org> <20100906131203.GA80251@icarus.home.lan> <4C84EC62.6020205@freebsd.org> <20100906162230.GA1444@icarus.home.lan> In-Reply-To: <20100906162230.GA1444@icarus.home.lan> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: patch for topology detection of Intel CPUs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2010 16:33:26 -0000 on 06/09/2010 19:22 Jeremy Chadwick said the following: > On Mon, Sep 06, 2010 at 04:28:02PM +0300, Andriy Gapon wrote: >> on 06/09/2010 16:12 Jeremy Chadwick said the following: >>> Great, thanks! I'll be testing this out on two separate systems, both >>> RELENG_8: >>> >>> - Supermicro X7SBA + Intel C2D E8400 (stepping 10) >>> - Supermicro X7SBL-LN2 + Intel C2D E6600 (stepping 6) >>> >>> I'll make sure to provide what the topology looks like before and after. >>> Is CPU-relevant dmesg output sufficient? >> >> If you mean something like the below, then yes. Thanks! >> [...] > > All done. Good news (I think): there's no difference in the CPU-related > topology on either system with your patch, aside from kernel build date. > The topologies are still detected correctly. In case you want them: > Thanks a lot for the test! [test results snipped] > All other systems I have are C2D and C2Q-based, but I can't easily test > on those given their production roles. If there's a particular Intel > processor family/model you're interested in, let me know and I can dig > around to see if I have access to one. No particular models in mind. If you have systems with more complex topologies, like multiple physical packages or HTT enabled, I will be interested in seeing test results for those. Thanks again. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Sep 6 17:12:31 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 473DC10656AE; Mon, 6 Sep 2010 17:12:31 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id EEBFD8FC12; Mon, 6 Sep 2010 17:12:30 +0000 (UTC) Received: by iwn34 with SMTP id 34so5038316iwn.13 for ; Mon, 06 Sep 2010 10:12:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.149.3 with SMTP id r3mr6355954ibv.109.1283793150285; Mon, 06 Sep 2010 10:12:30 -0700 (PDT) Received: by 10.231.149.8 with HTTP; Mon, 6 Sep 2010 10:12:30 -0700 (PDT) In-Reply-To: <4C8517D1.3050603@freebsd.org> References: <4C782D3B.6020407@icyb.net.ua> <201008271743.29393.jkim@FreeBSD.org> <4C7835E6.6070309@icyb.net.ua> <4C7A2782.5040009@freebsd.org> <4C84DBE6.5010809@freebsd.org> <20100906122325.GA78727@icarus.home.lan> <4C84E4E1.8010709@freebsd.org> <20100906131203.GA80251@icarus.home.lan> <4C84EC62.6020205@freebsd.org> <20100906162230.GA1444@icarus.home.lan> <4C8517D1.3050603@freebsd.org> Date: Mon, 6 Sep 2010 19:12:30 +0200 Message-ID: From: Olivier Smedts To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: patch for topology detection of Intel CPUs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2010 17:12:31 -0000 2010/9/6 Andriy Gapon : > on 06/09/2010 19:22 Jeremy Chadwick said the following: >> On Mon, Sep 06, 2010 at 04:28:02PM +0300, Andriy Gapon wrote: >>> on 06/09/2010 16:12 Jeremy Chadwick said the following: >>>> Great, thanks! =A0I'll be testing this out on two separate systems, bo= th >>>> RELENG_8: >>>> >>>> - Supermicro X7SBA =A0 =A0 + Intel C2D E8400 (stepping 10) >>>> - Supermicro X7SBL-LN2 + Intel C2D E6600 (stepping 6) >>>> >>>> I'll make sure to provide what the topology looks like before and afte= r. >>>> Is CPU-relevant dmesg output sufficient? >>> >>> If you mean something like the below, then yes. =A0Thanks! >>> [...] >> >> All done. =A0Good news (I think): there's no difference in the CPU-relat= ed >> topology on either system with your patch, aside from kernel build date. >> The topologies are still detected correctly. =A0In case you want them: >> > > Thanks a lot for the test! Here is mine : no difference before and after the patch : FreeBSD 8.1-STABLE #0 r212258M: Mon Sep 6 18:36:00 CEST 2010 root@q.gid0.org:/usr/obj/usr/src/sys/QUAD amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPU Q9450 @ 2.66GHz (2999.87-MHz K8-class = CPU) Origin =3D "GenuineIntel" Id =3D 0x10677 Family =3D 6 Model =3D 17 St= epping =3D 7 Features=3D0xbfebfbff Features2=3D0x8e3fd AMD Features=3D0x20100800 AMD Features2=3D0x1 TSC: P-state invariant real memory =3D 2147483648 (2048 MB) avail memory =3D 2029350912 (1935 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 The only thing I noticed is this, after the patch : ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: ATA-7 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 152627MB (312581808 512 byte sectors: 16H 63S/T 16383C) SMP: AP CPU #1 Launched!cd0 at ahcich2 bus 0 scbus2 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! Trying to mount root from zfs:tank/freebsd Before the patch, all the "SMP: AP CPU #X Launched!" were correctly displayed, with carriage returns. Yes, I use "options PRINTF_BUFR_SIZE=3D128". And I don't know if that's related to the patch. Cheers, Olivier > > [test results snipped] > >> All other systems I have are C2D and C2Q-based, but I can't easily test >> on those given their production roles. =A0If there's a particular Intel >> processor family/model you're interested in, let me know and I can dig >> around to see if I have access to one. > > No particular models in mind. > If you have systems with more complex topologies, like multiple physical = packages > or HTT enabled, I will be interested in seeing test results for those. > Thanks again. > -- > Andriy Gapon > _______________________________________________ > 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= " > --=20 Olivier Smedts=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 _ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 ASCII ribbon campaign ( ) e-mail: olivier@gid0.org=A0 =A0 =A0 =A0 - against HTML email & vCards=A0 X www: http://www.gid0.org=A0 =A0 - against proprietary attachments / \ =A0 "Il y a seulement 10 sortes de gens dans le monde : =A0 ceux qui comprennent le binaire, =A0 et ceux qui ne le comprennent pas." From owner-freebsd-stable@FreeBSD.ORG Mon Sep 6 18:53:09 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4102B1065693 for ; Mon, 6 Sep 2010 18:53:09 +0000 (UTC) (envelope-from sterling@camdensoftware.com) Received: from wh2.interactivevillages.com (wh2.interactivevillages.com [75.125.250.34]) by mx1.freebsd.org (Postfix) with ESMTP id 041BD8FC14 for ; Mon, 6 Sep 2010 18:53:08 +0000 (UTC) Received: from 174-21-101-5.tukw.qwest.net ([174.21.101.5] helo=_HOSTNAME_) by wh2.interactivevillages.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OsggR-00048a-Sn for freebsd-stable@freebsd.org; Mon, 06 Sep 2010 11:44:49 -0700 Received: by _HOSTNAME_ (sSMTP sendmail emulation); Mon, 06 Sep 2010 11:53:03 -0700 Date: Mon, 6 Sep 2010 11:53:03 -0700 From: Chip Camden To: freebsd-stable@freebsd.org Message-ID: <20100906185303.GA26054@libertas.local.camdensoftware.com> Mail-Followup-To: freebsd-stable@freebsd.org References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <4C782D3B.6020407@icyb.net.ua> <201008271743.29393.jkim@FreeBSD.org> <4C7835E6.6070309@icyb.net.ua> <4C7A2782.5040009@freebsd.org> <4C84DBE6.5010809@freebsd.org> <20100906122325.GA78727@icarus.home.lan> <4C84E4E1.8010709@freebsd.org> <20100906154043.GB18512@libertas.local.camdensoftware.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: <20100906154043.GB18512@libertas.local.camdensoftware.com> User-Agent: Mutt/1.4.2.3i Company: Camden Software Consulting URL: http://camdensoftware.com X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wh2.interactivevillages.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - camdensoftware.com Subject: Re: patch for topology detection of Intel CPUs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2010 18:53:09 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoth Chip Camden on Monday, 06 September 2010: >=20 > OK, I'll try it out too then. Here are the only differences before/after the patch on my system: 5c6 < FreeBSD 8.1-STABLE #50: Sun Sep 5 13:08:14 PDT 2010 --- > FreeBSD 8.1-STABLE #51: Mon Sep 6 09:10:35 PDT 2010 8c9 < CPU: Intel(R) Core(TM) i3 CPU M 350 @ 2.27GHz (2261.01-MHz K8-clas= s CPU) --- > CPU: Intel(R) Core(TM) i3 CPU M 350 @ 2.27GHz (2261.02-MHz K8-clas= s CPU) 125c126 < vboxdrv: fAsync=3D0 offMin=3D0x1b0 offMax=3D0x438 --- > vboxdrv: fAsync=3D0 offMin=3D0x1b8 offMax=3D0x3e4 140d140 < SMP: AP CPU #2 Launched! 141a142 > SMP: AP CPU #2 Launched! I don't see what that last one is. Here's the complete new topology: CPU: Intel(R) Core(TM) i3 CPU M 350 @ 2.27GHz (2261.02-MHz K8-class = CPU) Origin =3D "GenuineIntel" Id =3D 0x20652 Family =3D 6 Model =3D 25 St= epping =3D 2 Features=3D0xbfebfbff Features2=3D0x98e3bd AMD Features=3D0x28100800 AMD Features2=3D0x1 TSC: P-state invariant real memory =3D 4294967296 (4096 MB) avail memory =3D 3886858240 (3706 MB) ACPI APIC Table: <_ASUS_ Notebook> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 5 ACPI Warning: 32/64X FACS address mismatch in FADT - 0xBADB7F40/0x00000000B= ADD1D40, using 32 (20100331/tbfadt-586) ioapic0 irqs 0-23 on motherboard I was getting that ACPI warning before, but I have no idea what it means. --=20 Sterling (Chip) Camden | sterling@camdensoftware.com | 2048D/3A978E4F http://camdensoftware.com | http://chipstips.com | http://chipsquips= .com --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iQEcBAEBAgAGBQJMhTiPAAoJEIpckszW26+RTRgH/AtvWjl2frn4JH4GzqHJfj7c gmfqNbqWx0ZAjW64fGH0m0LSzuCTeeSiFw19y99vP3dyNXoO066un/MwMT8i9XMK d/5N8MsFrzQidpRkswqjaWI8hgl/sEcIO2ZH1nijDo9Ll06AupCB8pyNDt6LS4h/ F8UCPWKfolP4L70FSxtyikS0YRSoG6kLreQl2pmqj5XGrnj3gcO3bjdibahrPB6D MlI7vc0yya+VSlNjEm0eQiQYR0bL99FandgiqR+wiJ5luRnjdw3LqVKHN3H9JitA +GcXrJqP48XBsSQYxgEaa9xPOnILeHnZSifK+J7dzpXQsSJSLXE179/7itIxwVM= =ZdeJ -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO-- From owner-freebsd-stable@FreeBSD.ORG Mon Sep 6 18:59:31 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A0D110656D8 for ; Mon, 6 Sep 2010 18:59:31 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 894348FC19 for ; Mon, 6 Sep 2010 18:59:30 +0000 (UTC) Received: by wyb33 with SMTP id 33so5823986wyb.13 for ; Mon, 06 Sep 2010 11:59:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ksRS/vWFIrfn13QjN4vAD27QwCJOIpxcKiocmyfpI/E=; b=R3DsHTHK3HtUAaHQOo6vW8EehVgPpRq2fVrNCvb671OcNNTngYI9+qMEvpFqEV6ihm n0CbZQ3uyu8d471vPKy63JmDCHlukmqH+5SXlcbJ/nDuX1+Pe6X0HpjhiuZSOEPYRMTu c7M4Lu6sICke11H5bueCw1nxiQNwS5JVGQSgI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wZ/gdMR+MFXIyi3OVsNJkitjHnHV0es+1YGAl/jYVWDmOM3GTrn/4qerZx0e9o6SDi OhSAE/fmv24fRyHuxFg++abBmUlG0slmakw1N7YjZ10l0uwzJ+K5CXBMTfCOyPg4yEQC /e3Kyo+q4psb+JxIWipquTb1kAn3i/wfvDKCQ= MIME-Version: 1.0 Received: by 10.216.35.75 with SMTP id t53mr2760628wea.95.1283798194498; Mon, 06 Sep 2010 11:36:34 -0700 (PDT) Received: by 10.216.49.78 with HTTP; Mon, 6 Sep 2010 11:36:34 -0700 (PDT) In-Reply-To: <20100906155350.GA50151@lordcow.org> References: <20100906155350.GA50151@lordcow.org> Date: Mon, 6 Sep 2010 11:36:34 -0700 Message-ID: From: Jack Vogel To: Gareth de Vaux Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: stable@freebsd.org Subject: Re: MSIX failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2010 18:59:31 -0000 In the future make sure that you put E1000 or EM in the title otherwise I might miss it, fortunately I looked at this :) I'm on a holiday weekend, I will investigate this tomorrow. Jack On Mon, Sep 6, 2010 at 8:53 AM, Gareth de Vaux wrote: > Hi all, I moved from 8.0-RELEASE to last week's -STABLE: > > $ uname -v > FreeBSD 8.1-STABLE #0: Thu Sep 2 16:38:02 SAST 2010 root@XXXXX > :/usr/obj/usr/src/sys/GENERIC > > and all seems well except my network card is unusable. On boot up: > > em0: port 0x3040-0x305f mem > 0xe3200000-0xe321ffff,0xe3220000-0xe3220fff irq 10 at device 25.0 on pci0 > em0: Setup MSIX failure > em0: [FILTER] > em0: Ethernet address: 00:27:0e:1e:5e:e3 > > em1: port 0x1000-0x103f > mem 0xe3120000-0xe313ffff,0xe3100000-0xe311ffff irq 9 at device 1.0 on pci5 > em1: [FILTER] > em1: Ethernet address: 00:1b:21:5b:f2:18 > > > em0 is a PCI 'Intel(R) PRO/1000 GT Desktop Adapter' which worked up until > now. > em1 is onboard which didn't work with 8.0-RELEASE either. > > > $ ifconfig em0 > em0: flags=8843 metric 0 mtu 1500 > > options=219b > ether 00:27:0e:1e:5e:e3 > inet XXXXXXXX > media: Ethernet autoselect > status: no carrier > > > pciconf -lv: > > em0@pci0:0:25:0: class=0x020000 card=0x00008086 chip=0x10f08086 > rev=0x05 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > > em1@pci0:5:1:0: class=0x020000 card=0x13768086 chip=0x107c8086 rev=0x05 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' > class = network > subclass = ethernet > > (no device listing for em0) > > Swapping the PCI card with a PCI-X version gives the same behaviour. > Setting > hw.pci.enable_msix and hw.pci.enable_msi to 0 doesn't help in either case. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Mon Sep 6 19:05:59 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E82F10656E4; Mon, 6 Sep 2010 19:05:59 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id A80548FC19; Mon, 6 Sep 2010 19:05:58 +0000 (UTC) Received: by qwg5 with SMTP id 5so4422351qwg.13 for ; Mon, 06 Sep 2010 12:05:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=OyHC+PWwdPWKvh6WeKGlZZ5K+NQB7loAE+StokO9iEc=; b=A2hh97mpvm+MBJo1F6DaxZNIoyd7rmH7k805YZxY8nBxz7hZWye6aVQRMa3Sy8DoTI ET6YkALy6Y4u42H/ovoPJ8F8XQQZcnn81QHP7tnaGyQb83nOgo9Rd8sAYpQApx8ax4kr JVsZ3Nfwm06i4WWqpbVHPVgguGBAWvktzxoLE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=Fg7SNIg2UvEZkVYQrXDkj7IWPbMTh5GsTmtwwftWQ/oL6whnJi6KIWXm9pOigTJra2 pV47Q/zhuPQRSFxKoBbO2LLRJQrO+DKiUtAnUuAHZGG1HF3aam1fTABQ7jX2ZMFfERPz P8bSoiQl8cM1sRjpfmbJwcCyMgjJvJdhiwYI8= Received: by 10.224.119.20 with SMTP id x20mr65532qaq.249.1283799957745; Mon, 06 Sep 2010 12:05:57 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-137-20.dsl.klmzmi.sbcglobal.net [99.181.137.20]) by mx.google.com with ESMTPS id t24sm5939891qcs.47.2010.09.06.12.05.54 (version=SSLv3 cipher=RC4-MD5); Mon, 06 Sep 2010 12:05:55 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C853B91.4090601@DataIX.net> Date: Mon, 06 Sep 2010 15:05:53 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100806 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: David Xu References: <4C7F7C0F.8080004@icyb.net.ua> <4C818F65.3000603@freebsd.org> In-Reply-To: <4C818F65.3000603@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: jan.grant@bristol.ac.uk, freebsd-stable@freebsd.org, Andriy Gapon , Ivan Voras Subject: Re: Tuning the scheduler? Desktop with a CPU-intensive task becomes rapidly unusable. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2010 19:05:59 -0000 On 09/03/2010 20:14, David Xu wrote: > jan.grant@bristol.ac.uk wrote: >> On Thu, 2 Sep 2010, Andriy Gapon wrote: >> >> >>> on 02/09/2010 12:08 jan.grant@bristol.ac.uk said the following: >>> >>>> On Wed, 1 Sep 2010, Ivan Voras wrote: >>>> >>>> >>>>> On 09/01/10 15:08, jan.grant@bristol.ac.uk wrote: >>>>> >>>>>> I'm running -STABLE with a kde-derived desktop. This setup >>>>>> (which is pretty standard) is providing abysmal interactive >>>>>> performance on an eight-core machine whenever I try to do >>>>>> anything CPU-intensive (such as building a port). >>>>>> >>>>>> Basically, trying to build anything from ports rapidly >>>>>> renders everything else so "non-interactive" in the eyes of >>>>>> the scheduler that, for instance, switching between virtual >>>>>> desktops (I have six of them in reasonably frequent use) >>>>>> takes about a minute of painful waiting on redraws to >>>>>> complete. >>>>>> >>>>> Are you sure this is about the scheduler or maybe bad X11 >>>>> drivers? >>>>> >>>> Not 100%, but mostly convinced; I've just started looking at >>>> this. It's my first stab at what might be going on. X11 >>>> performance is usually pretty snappy. There's no paging >>>> pressure at all. >>>> >>> From my experience: 1. system with Athlon II X2 250 CPU and >>> onboard AMD graphics - no issues with interaction between >>> buildworld and GUI with all KDE4 effects enabled (OpenGL). 2. >>> system with comparable Core2 Duo CPU and onboard Intel graphics >>> (G33) - enabling OpenGL desktop effects in KDE4 leads to the >>> consequences like what you describe. With all GUI bells and >>> whistles disabled the system behaves quite like the AMD system. >>> >> >> All desktop effects are disabled. The graphics are from an nVidia >> GeForce 8500 GT (G86) with the X.org driver. (It's not _just_ >> desktop behaviour that's affected, though: the box runs a number of >> small headless [interactive] server processes which also appear to >> get rapidly starved of CPU time.) >> >> The behaviour isn't visible with the 4bsd scheduler; "stuff" >> generally remains snappy and responsive. >> >> I'll keep poking around and see if I can get to the bottom of it. >> >> >> >> > I think sysctl kern.sched.preempt_thresh is too low, default is only > 64. I always tune it up to 200 on my desktop machine which is > running gnome and other GUI applications, for a heavy GUI deskkop, I > would tune it up to 224 to get better result. > For reference how did you arrive at 224 for a result ? -- jhell,v From owner-freebsd-stable@FreeBSD.ORG Mon Sep 6 23:10:09 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 819821065788 for ; Mon, 6 Sep 2010 23:10:09 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1E8F88FC1D for ; Mon, 6 Sep 2010 23:10:08 +0000 (UTC) Received: by qyk4 with SMTP id 4so4945220qyk.13 for ; Mon, 06 Sep 2010 16:10:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:organization:x-operation-sytem; bh=5QVOSMazo/UxKmwZOh46cBOAlkchYFxC4Sz6v1yBGUA=; b=RCJfswMq9Shzb0/MhJJ2yDAMT/AWaQclnK2cEmqPlSHFrV4rlHEDIzZrPWsS0e1+bV FdTRp+QKGT9/4bhY03tykza24CXBMqikRJV6GI215eYgn8dGrhnT89Z49sjrC9IAKEO+ oqVbrnANrVTtJvcWt3f42GaSjA5sUr66kEGDw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent:organization:x-operation-sytem; b=rkZp5OzNDHxeJ1zP/Xx7zvU0Sbgrh0NOpLE+5kbKxEhSnsITFNyrwIW3QD5X3g+5/T 7V4wXeLEJ+zp2mr8rWXAwrZgvGVeeGEUCyi+LKqUpQlwJiLbdxKLKdwb1WvJaEUj58KD YYuXIguJSet95SseMfSH6C/9U4y8oOG3l7cF8= Received: by 10.224.104.132 with SMTP id p4mr370306qao.322.1283812798204; Mon, 06 Sep 2010 15:39:58 -0700 (PDT) Received: from weongyo ([174.35.1.224]) by mx.google.com with ESMTPS id q8sm6185909qcs.36.2010.09.06.15.39.56 (version=SSLv3 cipher=RC4-MD5); Mon, 06 Sep 2010 15:39:57 -0700 (PDT) Received: by weongyo (sSMTP sendmail emulation); Mon, 6 Sep 2010 15:39:57 -0700 From: Weongyo Jeong Date: Mon, 6 Sep 2010 15:39:57 -0700 To: Baby Boy Message-ID: <20100906223957.GB1328@weongyo> Mail-Followup-To: Baby Boy , freebsd-stable@freebsd.org References: <4C7AC69A.2080001@freebsd-go-go.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C7AC69A.2080001@freebsd-go-go.ru> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: freebsd-stable@freebsd.org Subject: Re: Broadcom 4315 not working X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2010 23:10:09 -0000 On Mon, Aug 30, 2010 at 12:44:10AM +0400, Baby Boy wrote: > Hi. > > WiFi BCM4315 not working. Please help me. > > ------- > = 1 > ------- > # uname -a > FreeBSD 8.1-STABLE FreeBSD 8.1-STABLE #0 r211965: Sun Aug 29 22:18:05 > MSD 2010 root@:/usr/obj/usr/src/sys/GENERIC i386 > > # cd /usr/src/sys/modules/siba_bwn && make && make install > > # cat /boot/loader.conf > if_bwn_load="YES" > > # pciconf -lvbc > siba_bwn0@pci0:3:0:0: class=0x028000 card=0x1508103c chip=0x431514e4 > rev=0x01 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'Broadcom Wireless b/g (BCM4315/BCM22062000)' > class = network > bar [10] = type Memory, range 64, base 0xd4200000, size 16384, > enabled > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > cap 09[58] = vendor (length 120) > cap 05[e8] = MSI supports 1 message, 64 bit enabled with 1 message > cap 10[d0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) > > # reboot > > # kldstat > Id Refs Address Size Name > 1 8 0xc0400000 bc14f4 kernel > 2 1 0xc0fc2000 37248 if_bwn.ko > 3 2 0xc0ffa000 a1dc siba_bwn.ko > > # ifconfig > bwn0: flags=8802 metric 0 mtu 2290 > ether 0c:ee:e6:a1:50:cc > media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) > status: no carrier > .... > > ------- > = 2 > ------- > > # kldload bwn_v4_lp_ucode.ko > # ifconfig wlan0 create wlandev bwn0 > # ifconfig wlan0 up > > # ifconfig > bwn0: flags=8843 metric 0 mtu 2290 > ether 0c:ee:e6:a1:50:cc > media: IEEE 802.11 Wireless Ethernet autoselect mode 11g > status: associated > ... > wlan0: flags=8843 metric 0 mtu 1500 > ether 0c:ee:e6:a1:50:cc > media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) > status: no carrier > ssid "" channel 4 (2427 MHz 11g) > country US authmode OPEN privacy OFF txpower 30 bmiss 7 > scanvalid 60 > bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 > protmode CTS wme bintval 0 > > in series ifconfig can see: > ... channel 4 (2427 MHz 11g) ... > ... channel 5 (2432 MHz 11g) ... > ... channel 9 (2452 MHz 11g) ... > ... channel 12 (2467 MHz 11g) ... > ... channel 14 (2484 MHz 11g) ... > ... channel 1 (2412 MHz 11g) ... > ... > > # cat /var/log/messages > Aug 30 00:11:19 kernel: wlan0: Ethernet address: 0c:ee:e6:a1:50:cc > Aug 30 00:11:41 kernel: bwn0: firmware version (rev 478 patch 104 date > 0x8701 time 0x657) > Aug 30 00:11:42 kernel: wlan0: ieee80211_new_state_locked: pending INIT > -> SCAN transition lost > Aug 30 00:12:09 kernel: bwn0: status of RF switch is changed to OFF > Aug 30 00:12:09 kernel: bwn0: please turns on the RF switch > Aug 30 00:12:10 kernel: bwn0: status of RF switch is changed to ON > Aug 30 00:12:17 kernel: bwn0: status of RF switch is changed to OFF > Aug 30 00:12:17 kernel: bwn0: please turns on the RF switch > Aug 30 00:12:19 kernel: bwn0: status of RF switch is changed to ON > Aug 30 00:12:21 kernel: bwn0: status of RF switch is changed to OFF > Aug 30 00:12:21 kernel: bwn0: please turns on the RF switch > Aug 30 00:12:25 kernel: bwn0: status of RF switch is changed to ON > Aug 30 00:12:33 kernel: bwn0: status of RF switch is changed to OFF > Aug 30 00:12:33 kernel: bwn0: please turns on the RF switch > Aug 30 00:12:34 kernel: bwn0: status of RF switch is changed to ON > Aug 30 00:12:35 kernel: bwn0: status of RF switch is changed to OFF > Aug 30 00:12:35 kernel: bwn0: please turns on the RF switch > Aug 30 00:12:36 kernel: bwn0: status of RF switch is changed to ON > Aug 30 00:13:49 kernel: bwn0: status of RF switch is changed to OFF > Aug 30 00:13:49 kernel: bwn0: please turns on the RF switch > Aug 30 00:13:50 kernel: bwn0: status of RF switch is changed to ON > Aug 30 00:14:39 kernel: bwn0: status of RF switch is changed to OFF > Aug 30 00:14:39 kernel: bwn0: please turns on the RF switch > Aug 30 00:14:40 kernel: bwn0: status of RF switch is changed to ON Today I MFCed a patch for LP PHY devices to STABLE_8. Could you please test with latest? One thing you can test is that using PIO mode. Thank you. regards, Weongyo Jeong From owner-freebsd-stable@FreeBSD.ORG Tue Sep 7 02:12:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C132710656D7 for ; Tue, 7 Sep 2010 02:12:38 +0000 (UTC) (envelope-from drsweetlips@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 609DD8FC19 for ; Tue, 7 Sep 2010 02:12:37 +0000 (UTC) Received: by yxn35 with SMTP id 35so1986121yxn.13 for ; Mon, 06 Sep 2010 19:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:content-type :content-transfer-encoding; bh=ny7GmojylnzWtowdcwu4CfxslPvg8ZVpf2DE1C/i0Hk=; b=cEjckiP9JLn2JpF5dzW1S2D5qssQaY1sbVWWlVQ6yEaa2TTHJRb+AcWHXharSUZ7ZN WzwhZysz02m1sR7ZYFG3xwxeCBb/LyMWx4qeBxGjTHFDEpREh838P+uH8oT+obvOEu/u 2Pxgx4B5bS4CLOhnsv7QB+SzfnPruoW6taH2A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :content-type:content-transfer-encoding; b=trHDEHDXPx66qK7Jp3kF5t9scQS5ZLIECRcZE3kgXexcMwMgvngbaqZO2Wq8eA0s1j U/NbLAxD7CglarCMQyIgmLvdqhasyLMheZgC+tgi6H1iDyyUeVunGGoQimA4kmJmeOa3 kKxJIWcuOFci7LcbrhhGUzWubGxOl4oGXqHEQ= Received: by 10.101.185.37 with SMTP id m37mr181305anp.0.1283825557373; Mon, 06 Sep 2010 19:12:37 -0700 (PDT) Received: from [172.16.1.90] ([208.72.134.40]) by mx.google.com with ESMTPS id c7sm10361004ana.18.2010.09.06.19.12.36 (version=SSLv3 cipher=RC4-MD5); Mon, 06 Sep 2010 19:12:36 -0700 (PDT) Message-ID: <4C859F99.90209@gmail.com> Date: Mon, 06 Sep 2010 22:12:41 -0400 From: FOSS Deluxe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: 20100810075945.GI51934@home.opsec.eu Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: 8.1 stable ar9285 ath0 problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 02:12:39 -0000 Hey Chadd, how is the codin' goin' on there bud? I was browsing through the NetBSD forums and those guys seem to have an ar9285 driver working by looking around in the forums. From owner-freebsd-stable@FreeBSD.ORG Tue Sep 7 05:15:18 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C34810656E1 for ; Tue, 7 Sep 2010 05:15:18 +0000 (UTC) (envelope-from return1@e-mail-system.com) Received: from mail209.e-mail-system.com (mail209.e-mail-system.com [62.93.8.210]) by mx1.freebsd.org (Postfix) with ESMTP id E65F98FC12 for ; Tue, 7 Sep 2010 05:15:17 +0000 (UTC) Received: from localhost (mail209.e-mail-system.com [62.93.8.210]) by mail209.e-mail-system.com (Postfix) with ESMTP id 7A5C296D004 for ; Tue, 7 Sep 2010 07:31:07 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable From: Anja Schmidt To: stable@freebsd.org Message-Id: <20100907053107.7A5C296D004@mail209.e-mail-system.com> Date: Tue, 7 Sep 2010 07:31:07 +0200 (CEST) Cc: Subject: [Wichtig] Haben Sie verglichen, Kundennummer KK-57776? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 05:15:18 -0000 Guten Tag Kundennummer KK-57776,=20 ich habe Sie vor ein paar Tagen schon einmal angeschrieben. Es ist derzeit wichtig, dass Sie Ihren Krankenkassentarif =FCberpr=FCfen.= =20 Verpassen Sie die Wechsel-Frist, bleiben Sie in Ihrem teuren Vertrag f=FCr = ein weiteres Jahr. Mit unserem kostenlosen Vergeich finden Sie den g=FCnstigsten Tarif f=FCr e= ine private Krankenkasse. So sparen Sie bis zu 2.500 Euro im Jahr! Bitte klicken Sie hier: http://cvergleich-pkv-30.com/k-162-5587908.htm Beste Gr=FCsse,=20 Ihre Anja Schmidt Sie erhalten dieses E-Mailing, da Sie uns oder einem unserer Partner Ihre E= inwilligung dazu gegeben haben. Gerne k=F6nnen Sie Ihre E-Mail Adresse l=F6= schen. Klicken Sie dazu einfach hier: http://cvergleich-pkv-30.com/a/?i=3D7297192&e=3Dstable%40freebsd.org&c=3D55= 87908 Anbieter: Privacy GG Limited, 99 Albert Street, Belize City, CA From owner-freebsd-stable@FreeBSD.ORG Tue Sep 7 05:42:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 793051065695; Tue, 7 Sep 2010 05:42:33 +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 587098FC08; Tue, 7 Sep 2010 05:42:31 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id IAA15173; Tue, 07 Sep 2010 08:42:30 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Osqww-000Meq-4H; Tue, 07 Sep 2010 08:42:30 +0300 Message-ID: <4C85D0C5.7060603@icyb.net.ua> Date: Tue, 07 Sep 2010 08:42:29 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: David Xu References: <4C7F7C0F.8080004@icyb.net.ua> <4C818F65.3000603@freebsd.org> In-Reply-To: <4C818F65.3000603@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: jan.grant@bristol.ac.uk, freebsd-stable@freebsd.org, Ivan Voras Subject: Re: Tuning the scheduler? Desktop with a CPU-intensive task becomes rapidly unusable. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 05:42:33 -0000 on 04/09/2010 03:14 David Xu said the following: > I think sysctl kern.sched.preempt_thresh is too low, default is only 64. I > always tune > it up to 200 on my desktop machine which is running gnome and other GUI > applications, > for a heavy GUI deskkop, I would tune it up to 224 to get better result. And turns out I have this in my sysctl.conf :-) # should give more responsivness on desktop # suggested by David Xu kern.sched.preempt_thresh=220 Apparently I have it for so long in there that I forgot that I do. Thanks again! -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Sep 7 05:54:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 227611065697 for ; Tue, 7 Sep 2010 05:54:41 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id 042088FC26 for ; Tue, 7 Sep 2010 05:54:40 +0000 (UTC) Received: from omta01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by qmta08.emeryville.ca.mail.comcast.net with comcast id 3hjC1f0010EPchoA8hugZc; Tue, 07 Sep 2010 05:54:40 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta01.emeryville.ca.mail.comcast.net with comcast id 3hue1f0063LrwQ28Mhueny; Tue, 07 Sep 2010 05:54:39 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 247589B423; Mon, 6 Sep 2010 22:54:38 -0700 (PDT) Date: Mon, 6 Sep 2010 22:54:38 -0700 From: Jeremy Chadwick To: jhell Message-ID: <20100907055438.GA20878@icarus.home.lan> References: <4C7F7C0F.8080004@icyb.net.ua> <4C818F65.3000603@freebsd.org> <4C853B91.4090601@DataIX.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C853B91.4090601@DataIX.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: jan.grant@bristol.ac.uk, freebsd-stable@freebsd.org, David Xu , Ivan Voras , Andriy Gapon Subject: Re: Tuning the scheduler? Desktop with a CPU-intensive task becomes rapidly unusable. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 05:54:41 -0000 On Mon, Sep 06, 2010 at 03:05:53PM -0400, jhell wrote: > On 09/03/2010 20:14, David Xu wrote: > > jan.grant@bristol.ac.uk wrote: > >> On Thu, 2 Sep 2010, Andriy Gapon wrote: > >> > >> > >>> on 02/09/2010 12:08 jan.grant@bristol.ac.uk said the following: > >>> > >>>> On Wed, 1 Sep 2010, Ivan Voras wrote: > >>>> > >>>> > >>>>> On 09/01/10 15:08, jan.grant@bristol.ac.uk wrote: > >>>>> > >>>>>> I'm running -STABLE with a kde-derived desktop. This setup > >>>>>> (which is pretty standard) is providing abysmal interactive > >>>>>> performance on an eight-core machine whenever I try to do > >>>>>> anything CPU-intensive (such as building a port). > >>>>>> > >>>>>> Basically, trying to build anything from ports rapidly > >>>>>> renders everything else so "non-interactive" in the eyes of > >>>>>> the scheduler that, for instance, switching between virtual > >>>>>> desktops (I have six of them in reasonably frequent use) > >>>>>> takes about a minute of painful waiting on redraws to > >>>>>> complete. > >>>>>> > >>>>> Are you sure this is about the scheduler or maybe bad X11 > >>>>> drivers? > >>>>> > >>>> Not 100%, but mostly convinced; I've just started looking at > >>>> this. It's my first stab at what might be going on. X11 > >>>> performance is usually pretty snappy. There's no paging > >>>> pressure at all. > >>>> > >>> From my experience: 1. system with Athlon II X2 250 CPU and > >>> onboard AMD graphics - no issues with interaction between > >>> buildworld and GUI with all KDE4 effects enabled (OpenGL). 2. > >>> system with comparable Core2 Duo CPU and onboard Intel graphics > >>> (G33) - enabling OpenGL desktop effects in KDE4 leads to the > >>> consequences like what you describe. With all GUI bells and > >>> whistles disabled the system behaves quite like the AMD system. > >>> > >> > >> All desktop effects are disabled. The graphics are from an nVidia > >> GeForce 8500 GT (G86) with the X.org driver. (It's not _just_ > >> desktop behaviour that's affected, though: the box runs a number of > >> small headless [interactive] server processes which also appear to > >> get rapidly starved of CPU time.) > >> > >> The behaviour isn't visible with the 4bsd scheduler; "stuff" > >> generally remains snappy and responsive. > >> > >> I'll keep poking around and see if I can get to the bottom of it. > >> > >> > >> > >> > > I think sysctl kern.sched.preempt_thresh is too low, default is only > > 64. I always tune it up to 200 on my desktop machine which is > > running gnome and other GUI applications, for a heavy GUI deskkop, I > > would tune it up to 224 to get better result. > > > > For reference how did you arrive at 224 for a result ? Can someone explain exactly what this sysctl does? The description is only useful if you have familiarity with the scheduler internals: $ sysctl -d kern.sched.preempt_thresh kern.sched.preempt_thresh: Min priority for preemption, lower priorities have greater precedence The source code doesn't really explain it either -- but I will point out that there's a change in the default value based on an option called FULL_PREEMPTION: src/sys/kern/sched_ule.c 192 #ifdef PREEMPTION 193 #ifdef FULL_PREEMPTION 194 static int preempt_thresh = PRI_MAX_IDLE; 195 #else 196 static int preempt_thresh = PRI_MIN_KERN; 197 #endif 198 #else 199 static int preempt_thresh = 0; 200 #endif src/sys/sys/priority.h 81 #define PRI_MAX (255) /* Lowest priority. */ 97 #define PRI_MIN_KERN (64) ... 121 #define PRI_MAX_IDLE (PRI_MAX) Secondly, this tunable isn't mentioned in any man page, so I'm not sure how users would even come across it: $ zgrep -r preempt_thresh /usr/share/man $ Thirdly, does this sysctl only exist if "options PREEMPTION" is included in one's kernel config? (I did not dig through kernel source thoroughly) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Sep 7 06:02:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A422010656A7; Tue, 7 Sep 2010 06:02:20 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B29658FC1E; Tue, 7 Sep 2010 06:02:19 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA15404; Tue, 07 Sep 2010 09:02:14 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OsrG2-000Mfc-CJ; Tue, 07 Sep 2010 09:02:14 +0300 Message-ID: <4C85D566.1040006@freebsd.org> Date: Tue, 07 Sep 2010 09:02:14 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Olivier Smedts References: <4C782D3B.6020407@icyb.net.ua> <201008271743.29393.jkim@FreeBSD.org> <4C7835E6.6070309@icyb.net.ua> <4C7A2782.5040009@freebsd.org> <4C84DBE6.5010809@freebsd.org> <20100906122325.GA78727@icarus.home.lan> <4C84E4E1.8010709@freebsd.org> <20100906131203.GA80251@icarus.home.lan> <4C84EC62.6020205@freebsd.org> <20100906162230.GA1444@icarus.home.lan> <4C8517D1.3050603@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: patch for topology detection of Intel CPUs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 06:02:20 -0000 on 06/09/2010 20:12 Olivier Smedts said the following: > Here is mine : no difference before and after the patch : Thanks! [snip] > The only thing I noticed is this, after the patch : > ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 > ada1: ATA-7 SATA 2.x device > ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada1: Command Queueing enabled > ada1: 152627MB (312581808 512 byte sectors: 16H 63S/T 16383C) > SMP: AP CPU #1 Launched!cd0 at ahcich2 bus 0 scbus2 target 0 lun 0 > > cd0: Removable CD-ROM SCSI-0 device > cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) > cd0: Attempt to query device size failed: NOT READY, Medium not present > SMP: AP CPU #3 Launched! > SMP: AP CPU #2 Launched! > Trying to mount root from zfs:tank/freebsd > > > Before the patch, all the "SMP: AP CPU #X Launched!" were correctly > displayed, with carriage returns. Yes, I use "options > PRINTF_BUFR_SIZE=128". And I don't know if that's related to the > patch. No, it's not related, it's a probabilistic thing. Those "Launched!" messages are printed from threads running on freshly started APs and thus are executed truly parallel to BSP. BTW, is the above snippet from /var/log/messages or from actual console (e.g. ttyv0)? If it's from message, then could you please check how it looks on the console? -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Sep 7 06:04:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A83B210656D3; Tue, 7 Sep 2010 06:04:11 +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 83D508FC12; Tue, 7 Sep 2010 06:04:10 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA15425; Tue, 07 Sep 2010 09:04:05 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OsrHp-000Mfm-BD; Tue, 07 Sep 2010 09:04:05 +0300 Message-ID: <4C85D5D4.1020201@icyb.net.ua> Date: Tue, 07 Sep 2010 09:04:04 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jeremy Chadwick References: <4C7F7C0F.8080004@icyb.net.ua> <4C818F65.3000603@freebsd.org> <4C853B91.4090601@DataIX.net> <20100907055438.GA20878@icarus.home.lan> In-Reply-To: <20100907055438.GA20878@icarus.home.lan> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: jhell , freebsd-stable@freebsd.org, David Xu , Ivan Voras , jan.grant@bristol.ac.uk Subject: Re: Tuning the scheduler? Desktop with a CPU-intensive task becomes rapidly unusable. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 06:04:11 -0000 on 07/09/2010 08:54 Jeremy Chadwick said the following: > Can someone explain exactly what this sysctl does? The description is > only useful if you have familiarity with the scheduler internals: > > $ sysctl -d kern.sched.preempt_thresh > kern.sched.preempt_thresh: Min priority for preemption, lower priorities have greater precedence > > The source code doesn't really explain it either -- but I will point out > that there's a change in the default value based on an option called > FULL_PREEMPTION: > > src/sys/kern/sched_ule.c > 192 #ifdef PREEMPTION > 193 #ifdef FULL_PREEMPTION > 194 static int preempt_thresh = PRI_MAX_IDLE; > 195 #else > 196 static int preempt_thresh = PRI_MIN_KERN; > 197 #endif > 198 #else > 199 static int preempt_thresh = 0; > 200 #endif > > src/sys/sys/priority.h > 81 #define PRI_MAX (255) /* Lowest priority. */ > 97 #define PRI_MIN_KERN (64) > ... > 121 #define PRI_MAX_IDLE (PRI_MAX) > Well, I think you quoted almost all relevant source to get an understanding. Take a look also at sched_shouldpreempt() in sched_ule.c. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Sep 7 06:50:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98E7810656E1 for ; Tue, 7 Sep 2010 06:50:11 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2EC038FC26 for ; Tue, 7 Sep 2010 06:50:10 +0000 (UTC) Received: by bwz20 with SMTP id 20so4684278bwz.13 for ; Mon, 06 Sep 2010 23:50:10 -0700 (PDT) Received: by 10.204.50.204 with SMTP id a12mr371124bkg.117.1283842209970; Mon, 06 Sep 2010 23:50:09 -0700 (PDT) Received: from jessie.localnet (p5B0E3EAE.dip0.t-ipconnect.de [91.14.62.174]) by mx.google.com with ESMTPS id x13sm4975255bki.12.2010.09.06.23.50.07 (version=SSLv3 cipher=RC4-MD5); Mon, 06 Sep 2010 23:50:08 -0700 (PDT) From: Bernhard Schmidt To: Dominic Fandrey Date: Tue, 7 Sep 2010 08:50:06 +0200 User-Agent: KMail/1.13.2 (Linux/2.6.32-24-generic; KDE/4.4.2; i686; ; ) References: <4C716382.3040605@bsdforen.de> <4C776AEE.7070309@bsdforen.de> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009070850.06584.bschmidt@techwires.net> Cc: freebsd-stable@freebsd.org Subject: Re: wpa_supplicant does not create pidfile X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 06:50:11 -0000 On Friday, August 27, 2010 09:42:30 Bernhard Schmidt wrote: > On Fri, Aug 27, 2010 at 09:36, Dominic Fandrey wrote: > > On 27/08/2010 09:28, Bernhard Schmidt wrote: > >> On Sun, Aug 22, 2010 at 19:50, Dominic Fandrey wrote: > >>> wpa_supplicant doesn't create the pidfile if the target directory > >>> does not exist. Because /var/run is wiped with every boot I added > >>> the following line to my rc.local to workaround this issue: > >>> > >>> /bin/mkdir -p /var/run/wpa_supplicant > >>> > >>> I'm running RELENG_8. > >> > >> How about this? > >> > >> Index: etc/mtree/BSD.var.dist > >> =================================================================== > >> --- etc/mtree/BSD.var.dist>.....(revision 211568) > >> +++ etc/mtree/BSD.var.dist>.....(working copy) > >> @@ -64,6 +64,8 @@ > >> .. > >> ppp gname=network mode=0770 > >> .. > >> + wpa_supplicant > >> + .. > >> .. > >> rwho gname=daemon mode=0775 > >> .. > > > > Is the mtree built every time the system boots? Because my /var/run > > is a tmpfs. And even if it wasn't, I think it's wiped every boot > > any way. > > Not build but, according to /etc/rc.d/var mtree is run on every boot. > I actually tried that and it works just fine. Did you have a chance to try this? Given positive feedback I'd like to commit it. -- Bernhard From owner-freebsd-stable@FreeBSD.ORG Tue Sep 7 07:01:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 035DB10656C5 for ; Tue, 7 Sep 2010 07:01:25 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id B3BD98FC0A for ; Tue, 7 Sep 2010 07:01:24 +0000 (UTC) Received: from mobileKamikaze.norad (unknown [46.114.201.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 64C9B8A265A; Tue, 7 Sep 2010 09:01:22 +0200 (CEST) Message-ID: <4C85E33E.4060504@bsdforen.de> Date: Tue, 07 Sep 2010 09:01:18 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-GB; rv:1.9.1.11) Gecko/20100722 Thunderbird/3.0.6 MIME-Version: 1.0 To: Bernhard Schmidt References: <4C716382.3040605@bsdforen.de> <4C776AEE.7070309@bsdforen.de> <201009070850.06584.bschmidt@techwires.net> In-Reply-To: <201009070850.06584.bschmidt@techwires.net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: wpa_supplicant does not create pidfile X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 07:01:25 -0000 On 07/09/2010 08:50, Bernhard Schmidt wrote: > On Friday, August 27, 2010 09:42:30 Bernhard Schmidt wrote: >> On Fri, Aug 27, 2010 at 09:36, Dominic Fandrey wrote: >>> On 27/08/2010 09:28, Bernhard Schmidt wrote: >>>> On Sun, Aug 22, 2010 at 19:50, Dominic Fandrey > wrote: >>>>> wpa_supplicant doesn't create the pidfile if the target directory >>>>> does not exist. Because /var/run is wiped with every boot I added >>>>> the following line to my rc.local to workaround this issue: >>>>> >>>>> /bin/mkdir -p /var/run/wpa_supplicant >>>>> >>>>> I'm running RELENG_8. >>>> >>>> How about this? >>>> >>>> Index: etc/mtree/BSD.var.dist >>>> =================================================================== >>>> --- etc/mtree/BSD.var.dist>.....(revision 211568) >>>> +++ etc/mtree/BSD.var.dist>.....(working copy) >>>> @@ -64,6 +64,8 @@ >>>> .. >>>> ppp gname=network mode=0770 >>>> .. >>>> + wpa_supplicant >>>> + .. >>>> .. >>>> rwho gname=daemon mode=0775 >>>> .. >>> >>> Is the mtree built every time the system boots? Because my /var/run >>> is a tmpfs. And even if it wasn't, I think it's wiped every boot >>> any way. >> >> Not build but, according to /etc/rc.d/var mtree is run on every boot. >> I actually tried that and it works just fine. > > Did you have a chance to try this? Given positive feedback I'd like to commit > it. > No, doesn't work. The named and ppp directories also don't exist. Sorry about the delay. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-stable@FreeBSD.ORG Tue Sep 7 07:04:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D37F910656D3 for ; Tue, 7 Sep 2010 07:04:50 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 941538FC14 for ; Tue, 7 Sep 2010 07:04:50 +0000 (UTC) Received: from mobileKamikaze.norad (unknown [46.114.201.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 79DC98A265A; Tue, 7 Sep 2010 09:04:48 +0200 (CEST) Message-ID: <4C85E40C.30506@bsdforen.de> Date: Tue, 07 Sep 2010 09:04:44 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-GB; rv:1.9.1.11) Gecko/20100722 Thunderbird/3.0.6 MIME-Version: 1.0 To: Bernhard Schmidt References: <4C716382.3040605@bsdforen.de> <4C776AEE.7070309@bsdforen.de> <201009070850.06584.bschmidt@techwires.net> In-Reply-To: <201009070850.06584.bschmidt@techwires.net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: wpa_supplicant does not create pidfile X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 07:04:50 -0000 On 07/09/2010 08:50, Bernhard Schmidt wrote: > On Friday, August 27, 2010 09:42:30 Bernhard Schmidt wrote: >> On Fri, Aug 27, 2010 at 09:36, Dominic Fandrey wrote: >>> On 27/08/2010 09:28, Bernhard Schmidt wrote: >>>> On Sun, Aug 22, 2010 at 19:50, Dominic Fandrey > wrote: >>>>> wpa_supplicant doesn't create the pidfile if the target directory >>>>> does not exist. Because /var/run is wiped with every boot I added >>>>> the following line to my rc.local to workaround this issue: >>>>> >>>>> /bin/mkdir -p /var/run/wpa_supplicant >>>>> >>>>> I'm running RELENG_8. >>>> >>>> How about this? >>>> >>>> Index: etc/mtree/BSD.var.dist >>>> =================================================================== >>>> --- etc/mtree/BSD.var.dist>.....(revision 211568) >>>> +++ etc/mtree/BSD.var.dist>.....(working copy) >>>> @@ -64,6 +64,8 @@ >>>> .. >>>> ppp gname=network mode=0770 >>>> .. >>>> + wpa_supplicant >>>> + .. >>>> .. >>>> rwho gname=daemon mode=0775 >>>> .. >>> >>> Is the mtree built every time the system boots? Because my /var/run >>> is a tmpfs. And even if it wasn't, I think it's wiped every boot >>> any way. >> >> Not build but, according to /etc/rc.d/var mtree is run on every boot. >> I actually tried that and it works just fine. > > Did you have a chance to try this? Given positive feedback I'd like to commit > it. > Just had this idea, that it might be run, before the tmpfs is mounted. Seems unlikely, though. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-stable@FreeBSD.ORG Tue Sep 7 07:09:31 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FB7710656D8 for ; Tue, 7 Sep 2010 07:09:31 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id F065B8FC1F for ; Tue, 7 Sep 2010 07:09:30 +0000 (UTC) Received: by fxm4 with SMTP id 4so3259705fxm.13 for ; Tue, 07 Sep 2010 00:09:29 -0700 (PDT) Received: by 10.223.114.83 with SMTP id d19mr2530350faq.62.1283843369621; Tue, 07 Sep 2010 00:09:29 -0700 (PDT) Received: from jessie.localnet (p5B0E3EAE.dip0.t-ipconnect.de [91.14.62.174]) by mx.google.com with ESMTPS id k15sm2673746fai.40.2010.09.07.00.09.28 (version=SSLv3 cipher=RC4-MD5); Tue, 07 Sep 2010 00:09:28 -0700 (PDT) From: Bernhard Schmidt To: Dominic Fandrey Date: Tue, 7 Sep 2010 09:09:25 +0200 User-Agent: KMail/1.13.2 (Linux/2.6.32-24-generic; KDE/4.4.2; i686; ; ) References: <4C716382.3040605@bsdforen.de> <201009070850.06584.bschmidt@techwires.net> <4C85E33E.4060504@bsdforen.de> In-Reply-To: <4C85E33E.4060504@bsdforen.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201009070909.26304.bschmidt@techwires.net> Cc: freebsd-stable@freebsd.org Subject: Re: wpa_supplicant does not create pidfile X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 07:09:31 -0000 On Tuesday, September 07, 2010 09:01:18 Dominic Fandrey wrote: > On 07/09/2010 08:50, Bernhard Schmidt wrote: > > On Friday, August 27, 2010 09:42:30 Bernhard Schmidt wrote: > >> On Fri, Aug 27, 2010 at 09:36, Dominic Fandrey wrote: > >>> On 27/08/2010 09:28, Bernhard Schmidt wrote: > >>>> On Sun, Aug 22, 2010 at 19:50, Dominic Fandrey > > > > wrote: > >>>>> wpa_supplicant doesn't create the pidfile if the target directory > >>>>> does not exist. Because /var/run is wiped with every boot I added > >>>>> the following line to my rc.local to workaround this issue: > >>>>> > >>>>> /bin/mkdir -p /var/run/wpa_supplicant > >>>>> > >>>>> I'm running RELENG_8. > >>>> > >>>> How about this? > >>>> > >>>> Index: etc/mtree/BSD.var.dist > >>>> =================================================================== > >>>> --- etc/mtree/BSD.var.dist>.....(revision 211568) > >>>> +++ etc/mtree/BSD.var.dist>.....(working copy) > >>>> @@ -64,6 +64,8 @@ > >>>> > >>>> .. > >>>> ppp gname=network mode=0770 > >>>> .. > >>>> > >>>> + wpa_supplicant > >>>> + .. > >>>> > >>>> .. > >>>> rwho gname=daemon mode=0775 > >>>> .. > >>> > >>> Is the mtree built every time the system boots? Because my /var/run > >>> is a tmpfs. And even if it wasn't, I think it's wiped every boot > >>> any way. > >> > >> Not build but, according to /etc/rc.d/var mtree is run on every boot. > >> I actually tried that and it works just fine. > > > > Did you have a chance to try this? Given positive feedback I'd like to > > commit it. > > No, doesn't work. The named and ppp directories also don't exist. > > Sorry about the delay. Ok, thanks. Is it only /var/run/* that is wiped for you, or /var/* itself? I just checked rc.d/var and it looks like this: if [ -d /var/run -a -d /var/db -a -d /var/empty ] ; then true elif [ -x /usr/sbin/mtree ] ; then populate_var So.. if var/run does exist, populate_var isn't run. -- Bernhard From owner-freebsd-stable@FreeBSD.ORG Tue Sep 7 07:14:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 606F91065670 for ; Tue, 7 Sep 2010 07:14:29 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 1EA648FC1D for ; Tue, 7 Sep 2010 07:14:28 +0000 (UTC) Received: from mobileKamikaze.norad (unknown [46.114.201.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id DF1558A2663; Tue, 7 Sep 2010 09:14:03 +0200 (CEST) Message-ID: <4C85E638.4070403@bsdforen.de> Date: Tue, 07 Sep 2010 09:14:00 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-GB; rv:1.9.1.11) Gecko/20100722 Thunderbird/3.0.6 MIME-Version: 1.0 To: Bernhard Schmidt References: <4C716382.3040605@bsdforen.de> <201009070850.06584.bschmidt@techwires.net> <4C85E33E.4060504@bsdforen.de> <201009070909.26304.bschmidt@techwires.net> In-Reply-To: <201009070909.26304.bschmidt@techwires.net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: wpa_supplicant does not create pidfile X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 07:14:29 -0000 On 07/09/2010 09:09, Bernhard Schmidt wrote: > On Tuesday, September 07, 2010 09:01:18 Dominic Fandrey wrote: >> On 07/09/2010 08:50, Bernhard Schmidt wrote: >>> On Friday, August 27, 2010 09:42:30 Bernhard Schmidt wrote: >>>> On Fri, Aug 27, 2010 at 09:36, Dominic Fandrey > wrote: >>>>> On 27/08/2010 09:28, Bernhard Schmidt wrote: >>>>>> On Sun, Aug 22, 2010 at 19:50, Dominic Fandrey >>> >>> wrote: >>>>>>> wpa_supplicant doesn't create the pidfile if the target directory >>>>>>> does not exist. Because /var/run is wiped with every boot I added >>>>>>> the following line to my rc.local to workaround this issue: >>>>>>> >>>>>>> /bin/mkdir -p /var/run/wpa_supplicant >>>>>>> >>>>>>> I'm running RELENG_8. >>>>>> >>>>>> How about this? >>>>>> >>>>>> Index: etc/mtree/BSD.var.dist >>>>>> =================================================================== >>>>>> --- etc/mtree/BSD.var.dist>.....(revision 211568) >>>>>> +++ etc/mtree/BSD.var.dist>.....(working copy) >>>>>> @@ -64,6 +64,8 @@ >>>>>> >>>>>> .. >>>>>> ppp gname=network mode=0770 >>>>>> .. >>>>>> >>>>>> + wpa_supplicant >>>>>> + .. >>>>>> >>>>>> .. >>>>>> rwho gname=daemon mode=0775 >>>>>> .. >>>>> >>>>> Is the mtree built every time the system boots? Because my /var/run >>>>> is a tmpfs. And even if it wasn't, I think it's wiped every boot >>>>> any way. >>>> >>>> Not build but, according to /etc/rc.d/var mtree is run on every boot. >>>> I actually tried that and it works just fine. >>> >>> Did you have a chance to try this? Given positive feedback I'd like to >>> commit it. >> >> No, doesn't work. The named and ppp directories also don't exist. >> >> Sorry about the delay. > > Ok, thanks. > > Is it only /var/run/* that is wiped for you, or /var/* itself? I just checked > rc.d/var and it looks like this: > if [ -d /var/run -a -d /var/db -a -d /var/empty ] ; then > true > elif [ -x /usr/sbin/mtree ] ; then > populate_var > > So.. if var/run does exist, populate_var isn't run. > Only /var/run and /var/log are tmpfs (notebook, reduce HD access to allow HD spindown). I wouldn't wipe my /var/db every boot. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-stable@FreeBSD.ORG Tue Sep 7 07:18:57 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E373D10656B1 for ; Tue, 7 Sep 2010 07:18:57 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3A7E38FC0A for ; Tue, 7 Sep 2010 07:18:56 +0000 (UTC) Received: by bwz20 with SMTP id 20so4698516bwz.13 for ; Tue, 07 Sep 2010 00:18:45 -0700 (PDT) Received: by 10.204.54.72 with SMTP id p8mr3678856bkg.163.1283843925771; Tue, 07 Sep 2010 00:18:45 -0700 (PDT) Received: from jessie.localnet (p5B0E3EAE.dip0.t-ipconnect.de [91.14.62.174]) by mx.google.com with ESMTPS id 24sm4995398bkr.7.2010.09.07.00.18.44 (version=SSLv3 cipher=RC4-MD5); Tue, 07 Sep 2010 00:18:44 -0700 (PDT) From: Bernhard Schmidt To: Dominic Fandrey Date: Tue, 7 Sep 2010 09:18:42 +0200 User-Agent: KMail/1.13.2 (Linux/2.6.32-24-generic; KDE/4.4.2; i686; ; ) References: <4C716382.3040605@bsdforen.de> <201009070909.26304.bschmidt@techwires.net> <4C85E638.4070403@bsdforen.de> In-Reply-To: <4C85E638.4070403@bsdforen.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201009070918.42959.bschmidt@techwires.net> Cc: freebsd-stable@freebsd.org Subject: Re: wpa_supplicant does not create pidfile X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 07:18:58 -0000 On Tuesday, September 07, 2010 09:14:00 Dominic Fandrey wrote: > On 07/09/2010 09:09, Bernhard Schmidt wrote: > > On Tuesday, September 07, 2010 09:01:18 Dominic Fandrey wrote: > >> On 07/09/2010 08:50, Bernhard Schmidt wrote: > >>> On Friday, August 27, 2010 09:42:30 Bernhard Schmidt wrote: > >>>> On Fri, Aug 27, 2010 at 09:36, Dominic Fandrey > > > > wrote: > >>>>> On 27/08/2010 09:28, Bernhard Schmidt wrote: > >>>>>> On Sun, Aug 22, 2010 at 19:50, Dominic Fandrey > >>>>>> > >>> > >>> wrote: > >>>>>>> wpa_supplicant doesn't create the pidfile if the target directory > >>>>>>> does not exist. Because /var/run is wiped with every boot I added > >>>>>>> the following line to my rc.local to workaround this issue: > >>>>>>> > >>>>>>> /bin/mkdir -p /var/run/wpa_supplicant > >>>>>>> > >>>>>>> I'm running RELENG_8. > >>>>>> > >>>>>> How about this? > >>>>>> > >>>>>> Index: etc/mtree/BSD.var.dist > >>>>>> =================================================================== > >>>>>> --- etc/mtree/BSD.var.dist>.....(revision 211568) > >>>>>> +++ etc/mtree/BSD.var.dist>.....(working copy) > >>>>>> @@ -64,6 +64,8 @@ > >>>>>> > >>>>>> .. > >>>>>> ppp gname=network mode=0770 > >>>>>> .. > >>>>>> > >>>>>> + wpa_supplicant > >>>>>> + .. > >>>>>> > >>>>>> .. > >>>>>> rwho gname=daemon mode=0775 > >>>>>> .. > >>>>> > >>>>> Is the mtree built every time the system boots? Because my /var/run > >>>>> is a tmpfs. And even if it wasn't, I think it's wiped every boot > >>>>> any way. > >>>> > >>>> Not build but, according to /etc/rc.d/var mtree is run on every boot. > >>>> I actually tried that and it works just fine. > >>> > >>> Did you have a chance to try this? Given positive feedback I'd like to > >>> commit it. > >> > >> No, doesn't work. The named and ppp directories also don't exist. > >> > >> Sorry about the delay. > > > > Ok, thanks. > > > > Is it only /var/run/* that is wiped for you, or /var/* itself? I just > > checked > > > > rc.d/var and it looks like this: > > if [ -d /var/run -a -d /var/db -a -d /var/empty ] ; then > > > > true > > > > elif [ -x /usr/sbin/mtree ] ; then > > > > populate_var > > > > So.. if var/run does exist, populate_var isn't run. > > Only /var/run and /var/log are tmpfs (notebook, reduce HD access > to allow HD spindown). I wouldn't wipe my /var/db every boot. Ah, ok, that explains it. Try with populate_var=YES in rc.conf and it should create all directories under var/run. -- Bernhard From owner-freebsd-stable@FreeBSD.ORG Tue Sep 7 07:26:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9FC810656BF for ; Tue, 7 Sep 2010 07:26:47 +0000 (UTC) (envelope-from marka@isc.org) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by mx1.freebsd.org (Postfix) with ESMTP id 8AF0B8FC1E for ; Tue, 7 Sep 2010 07:26:47 +0000 (UTC) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 2487DC9421; Tue, 7 Sep 2010 07:26:36 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 76347E6030; Tue, 7 Sep 2010 07:26:35 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id ABE9842FB62; Tue, 7 Sep 2010 17:26:32 +1000 (EST) To: Dominic Fandrey From: Mark Andrews References: <4C716382.3040605@bsdforen.de> <201009070850.06584.bschmidt@techwires.net> <4C85E33E.4060504@bsdforen.de> <201009070909.26304.bschmidt@techwires.net><4C85E638.4070403@bsdforen.de> In-reply-to: Your message of "Tue, 07 Sep 2010 09:14:00 +0200." <4C85E638.4070403@bsdforen.de> Date: Tue, 07 Sep 2010 17:26:32 +1000 Message-Id: <20100907072632.ABE9842FB62@drugs.dv.isc.org> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mx.pao1.isc.org Cc: Bernhard Schmidt , freebsd-stable@freebsd.org Subject: Re: wpa_supplicant does not create pidfile X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 07:26:47 -0000 In message <4C85E638.4070403@bsdforen.de>, Dominic Fandrey writes: > On 07/09/2010 09:09, Bernhard Schmidt wrote: > > On Tuesday, September 07, 2010 09:01:18 Dominic Fandrey wrote: > >> On 07/09/2010 08:50, Bernhard Schmidt wrote: > >>> On Friday, August 27, 2010 09:42:30 Bernhard Schmidt wrote: > >>>> On Fri, Aug 27, 2010 at 09:36, Dominic Fandrey > > wrote: > >>>>> On 27/08/2010 09:28, Bernhard Schmidt wrote: > >>>>>> On Sun, Aug 22, 2010 at 19:50, Dominic Fandrey > >>> > >>> wrote: > >>>>>>> wpa_supplicant doesn't create the pidfile if the target directory > >>>>>>> does not exist. Because /var/run is wiped with every boot I added > >>>>>>> the following line to my rc.local to workaround this issue: > >>>>>>> > >>>>>>> /bin/mkdir -p /var/run/wpa_supplicant > >>>>>>> > >>>>>>> I'm running RELENG_8. > >>>>>> > >>>>>> How about this? > >>>>>> > >>>>>> Index: etc/mtree/BSD.var.dist > >>>>>> =================================================================== > >>>>>> --- etc/mtree/BSD.var.dist>.....(revision 211568) > >>>>>> +++ etc/mtree/BSD.var.dist>.....(working copy) > >>>>>> @@ -64,6 +64,8 @@ > >>>>>> > >>>>>> .. > >>>>>> ppp gname=network mode=0770 > >>>>>> .. > >>>>>> > >>>>>> + wpa_supplicant > >>>>>> + .. > >>>>>> > >>>>>> .. > >>>>>> rwho gname=daemon mode=0775 > >>>>>> .. > >>>>> > >>>>> Is the mtree built every time the system boots? Because my /var/run > >>>>> is a tmpfs. And even if it wasn't, I think it's wiped every boot > >>>>> any way. > >>>> > >>>> Not build but, according to /etc/rc.d/var mtree is run on every boot. > >>>> I actually tried that and it works just fine. > >>> > >>> Did you have a chance to try this? Given positive feedback I'd like to > >>> commit it. > >> > >> No, doesn't work. The named and ppp directories also don't exist. > >> > >> Sorry about the delay. > > > > Ok, thanks. > > > > Is it only /var/run/* that is wiped for you, or /var/* itself? I just check > ed > > rc.d/var and it looks like this: > > if [ -d /var/run -a -d /var/db -a -d /var/empty ] ; then > > true > > elif [ -x /usr/sbin/mtree ] ; then > > populate_var > > > > So.. if var/run does exist, populate_var isn't run. > > > > Only /var/run and /var/log are tmpfs (notebook, reduce HD access > to allow HD spindown). I wouldn't wipe my /var/db every boot. Then /var/run must exist as it is a mount point. > Regards > > -- > A: Because it fouls the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing on usenet and in e-mail? > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-freebsd-stable@FreeBSD.ORG Tue Sep 7 07:31:40 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A6B7106566B for ; Tue, 7 Sep 2010 07:31: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 4B48E8FC0A for ; Tue, 7 Sep 2010 07:31:38 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA16448 for ; Tue, 07 Sep 2010 10:31:38 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OsseX-000Miq-My for freebsd-stable@freebsd.org; Tue, 07 Sep 2010 10:31:37 +0300 Message-ID: <4C85EA58.5010100@icyb.net.ua> Date: Tue, 07 Sep 2010 10:31:36 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <4C782D3B.6020407@icyb.net.ua> <201008271743.29393.jkim@FreeBSD.org> <4C7835E6.6070309@icyb.net.ua> <4C7A2782.5040009@freebsd.org> <4C84DBE6.5010809@freebsd.org> <20100906122325.GA78727@icarus.home.lan> <4C84E4E1.8010709@freebsd.org> <20100906154043.GB18512@libertas.local.camdensoftware.com> <20100906185303.GA26054@libertas.local.camdensoftware.com> In-Reply-To: <20100906185303.GA26054@libertas.local.camdensoftware.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Subject: Re: patch for topology detection of Intel CPUs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 07:31:40 -0000 on 06/09/2010 21:53 Chip Camden said the following: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs Thanks -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Sep 7 07:34:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6299B10656D1; Tue, 7 Sep 2010 07:34:20 +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 6E8E08FC17; Tue, 7 Sep 2010 07:34:18 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA16472; Tue, 07 Sep 2010 10:34:15 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Ossh5-000Mj2-HH; Tue, 07 Sep 2010 10:34:15 +0300 Message-ID: <4C85EAF7.3040803@icyb.net.ua> Date: Tue, 07 Sep 2010 10:34:15 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: jhell References: <4C7F7C0F.8080004@icyb.net.ua> <4C818F65.3000603@freebsd.org> <4C853B91.4090601@DataIX.net> In-Reply-To: <4C853B91.4090601@DataIX.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, David Xu Subject: Re: Tuning the scheduler? Desktop with a CPU-intensive task becomes rapidly unusable. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 07:34:20 -0000 on 06/09/2010 22:05 jhell said the following: > On 09/03/2010 20:14, David Xu wrote: >> I think sysctl kern.sched.preempt_thresh is too low, default is only >> 64. I always tune it up to 200 on my desktop machine which is >> running gnome and other GUI applications, for a heavy GUI deskkop, I >> would tune it up to 224 to get better result. >> > > For reference how did you arrive at 224 for a result ? As Jeremy has already discovered, take a look at sys/sys/priority.h, especially PRI_MIN_IDLE. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Sep 7 10:38:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6652106567A for ; Tue, 7 Sep 2010 10:38:30 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 6943C8FC1A for ; Tue, 7 Sep 2010 10:38:29 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OsvZH-0005Mu-Ju for freebsd-stable@freebsd.org; Tue, 07 Sep 2010 12:38:23 +0200 Received: from nuclight.avtf.net ([217.29.94.29]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 Sep 2010 12:38:23 +0200 Received: from vadim_nuclight by nuclight.avtf.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 Sep 2010 12:38:23 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Vadim Goncharov Date: Tue, 7 Sep 2010 10:38:12 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 27 Message-ID: References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <201009011902.06538.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: nuclight.avtf.net X-Comment-To: Robert Watson User-Agent: slrn/0.9.9p1 (FreeBSD) Cc: freebsd-security@freebsd.org Subject: Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 10:38:30 -0000 Hi Robert Watson! On Sun, 5 Sep 2010 11:47:29 +0100 (BST); Robert Watson wrote about 'Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon': >>> It seems code exists :-) >>> >>> http://old.nabble.com/ISDN4BSD-on-8-current-td23919925.html >>> ISDN4BSD package has been updated to compile on FreeBSD >>> 8-current >>> >>> http://www.selasky.org/hans_petter/isdn4bsd/ >>> >>> Apparently needs massaging into main FreeBSD tree. >> >> I agree that my I4B code should be re-written somewhat before committed. >> Possibly we should update the API's present too, to support IP-telephony >> aswell. > Just to clarify things a little for those following it: the original I4B code > was removed for entirely practical reasons: it couldn't run without the Giant > lock, and support for the Giant lock over the network stack was removed. But if it was used, removing a component just because of Giant lock is not practical and is purely ideologic, isn't it? -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-stable@FreeBSD.ORG Tue Sep 7 11:41:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B8A510656DD; Tue, 7 Sep 2010 11:41:14 +0000 (UTC) (envelope-from pistoletik@freebsd-go-go.ru) Received: from freebsd-go-go.ru (freebsd-go-go.ru [217.149.183.250]) by mx1.freebsd.org (Postfix) with ESMTP id 354AA8FC13; Tue, 7 Sep 2010 11:41:14 +0000 (UTC) Received: from [172.16.16.50] (port=1950) by freebsd-go-go.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OswY4-000DXD-EF; Tue, 07 Sep 2010 15:41:12 +0400 Message-ID: <4C8624D7.20502@freebsd-go-go.ru> Date: Tue, 07 Sep 2010 15:41:11 +0400 From: Baby Boy User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; ru; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Weongyo Jeong References: <4C7AC69A.2080001@freebsd-go-go.ru> <20100906223957.GB1328@weongyo> In-Reply-To: <20100906223957.GB1328@weongyo> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 172.16.16.50 X-SA-Exim-Mail-From: pistoletik@freebsd-go-go.ru X-SA-Exim-Scanned: No (on freebsd-go-go.ru); SAEximRunCond expanded to false Cc: freebsd-stable@freebsd.org Subject: Re: Broadcom 4315 not working X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 11:41:14 -0000 > Today I MFCed a patch for LP PHY devices to STABLE_8. > Could you please test with latest? ОК. !!!!!! > One thing you can test is that using PIO mode. Thank you. Please tell my how I do it? From owner-freebsd-stable@FreeBSD.ORG Tue Sep 7 11:53:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDE6D10656E9 for ; Tue, 7 Sep 2010 11:53:14 +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 221308FC1A for ; Tue, 7 Sep 2010 11:53:13 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA21756; Tue, 07 Sep 2010 14:53:10 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4C8627A6.1090308@icyb.net.ua> Date: Tue, 07 Sep 2010 14:53:10 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100823 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: vadim_nuclight@mail.ru References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <201009011902.06538.hselasky@c2i.net> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-security@freebsd.org, freebsd-stable@freebsd.org Subject: Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 11:53:14 -0000 on 07/09/2010 13:38 Vadim Goncharov said the following: >> Just to clarify things a little for those following it: the original I4B code >> was removed for entirely practical reasons: it couldn't run without the Giant >> lock, and support for the Giant lock over the network stack was removed. > > But if it was used, removing a component just because of Giant lock is not > practical and is purely ideologic, isn't it? Which part of "support for the Giant lock *over the network stack* was removed" [emphasis mine] do you not understand? The reason is performance for overall network stack, not ideology. BTW, there were advanced notices for users, request for volunteers, etc. So, if you didn't speak up at that time please keep silence now :-) P.S. why is security@ in cc: ? -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Sep 7 12:37:31 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE79810656A4; Tue, 7 Sep 2010 12:37:31 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 49F288FC18; Tue, 7 Sep 2010 12:37:31 +0000 (UTC) Received: from park.js.berklix.net (p549A4C99.dip.t-dialin.net [84.154.76.153]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o87CbShd060117; Tue, 7 Sep 2010 12:37:29 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o87CbMjo013534; Tue, 7 Sep 2010 14:37:22 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o87Cb2Ch035190; Tue, 7 Sep 2010 14:37:12 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201009071237.o87Cb2Ch035190@fire.js.berklix.net> To: Andriy Gapon From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Tue, 07 Sep 2010 14:53:10 +0300." <4C8627A6.1090308@icyb.net.ua> Date: Tue, 07 Sep 2010 14:37:02 +0200 Sender: jhs@berklix.com Cc: vadim_nuclight@mail.ru, freebsd-security@freebsd.org, freebsd-stable@freebsd.org Subject: Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 12:37:31 -0000 > P.S. why is security@ in cc: ? Original announcement: > Message-id: <4C7E71DC.1040808@freebsd.org> > From: FreeBSD Security Officer > Date: Wed, 01 Sep 2010 08:31:40 -0700 (17:31 CEST) > To: FreeBSD Stable , > freebsd security All respondents (I happened to be first, Wed, 01 Sep 2010 18:09:33 +0200) retained stable@ & security@ Wed, 01 Sep 2010 21:36:02 +0200 I added: > isdn@freebsd.org : I just re-subscribed (used to be on long ago) Now it's know Hans Petter Selasky has a code stack to try, & Robert Watson has posted it'd be welcome ... etc, I guess its up to us ISDN users to install, try, & discuss on a new thread on isdn@ Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text, Not HTML, quoted-printable & base 64 dumped with spam. Avoid top posting, It cripples itemised cumulative responses. From owner-freebsd-stable@FreeBSD.ORG Tue Sep 7 14:09:44 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2A2410656C4 for ; Tue, 7 Sep 2010 14:09:44 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 549068FC21 for ; Tue, 7 Sep 2010 14:09:44 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.4/8.14.4) with ESMTP id o87Dsv0G018858; Tue, 7 Sep 2010 07:54:57 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.4/8.14.4/Submit) with ESMTP id o87Dsvo9018855; Tue, 7 Sep 2010 07:54:57 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Tue, 7 Sep 2010 07:54:56 -0600 (MDT) From: Warren Block To: Baby Boy In-Reply-To: <4C8624D7.20502@freebsd-go-go.ru> Message-ID: References: <4C7AC69A.2080001@freebsd-go-go.ru> <20100906223957.GB1328@weongyo> <4C8624D7.20502@freebsd-go-go.ru> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (wonkity.com [127.0.0.1]); Tue, 07 Sep 2010 07:54:57 -0600 (MDT) Cc: freebsd-stable@freebsd.org, Weongyo Jeong Subject: Re: Broadcom 4315 not working X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 14:09:44 -0000 On Tue, 7 Sep 2010, Baby Boy wrote: >> Today I MFCed a patch for LP PHY devices to STABLE_8. >> Could you please test with latest? > > ??. > > > !!!!!! > >> One thing you can test is that using PIO mode. Thank you. > > Please tell my how I do it? Add to /boot/loader.conf: hw.bwn.usedma=0 From owner-freebsd-stable@FreeBSD.ORG Tue Sep 7 15:07:40 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BEB010656AA for ; Tue, 7 Sep 2010 15:07:40 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtpfb2-g21.free.fr (smtpfb2-g21.free.fr [212.27.42.10]) by mx1.freebsd.org (Postfix) with ESMTP id 777A38FC0C for ; Tue, 7 Sep 2010 15:07:37 +0000 (UTC) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by smtpfb2-g21.free.fr (Postfix) with ESMTP id A36A8CA9558 for ; Tue, 7 Sep 2010 16:50:36 +0200 (CEST) Received: from endor.tataz.chchile.org (unknown [82.233.239.98]) by smtp5-g21.free.fr (Postfix) with ESMTP id 6A965D4801F; Tue, 7 Sep 2010 16:50:29 +0200 (CEST) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id 50F6333CDC; Tue, 7 Sep 2010 14:50:28 +0000 (UTC) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id 3222FA1163; Tue, 7 Sep 2010 14:50:28 +0000 (UTC) Date: Tue, 7 Sep 2010 16:50:28 +0200 From: Jeremie Le Hen To: freebsd-stable@FreeBSD.org Message-ID: <20100907145028.GF16902@felucia.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Jeremie Le Hen Subject: Cannot install using serial console X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 15:07:40 -0000 Hi list, => Please Cc: me when replying, as I am not subscribed. <= I tried to install FreeBSD (201008 -CURRENT snapshot, but I don't think it's important here) in a KVM-backed virtual machine on a headless Linux host, following section 2.12.1 of the handbook. http://www.freebsd.org/doc/handbook/install-advanced.html I've rebuilt the ISO image with the following lines in boot/loader.conf: console="comconsole" beastie_disable="YES" The kernel boots correctly (see output below) but the output invariably stalls after the following lines: Trying to mount root from ufs:/dev/md0 /stand/sysinstal (Yes, only one `l'.) Any idea? /boot/kernel/kernel text=0x919885 data=0xe7a54+0x203be0 syms=[0x4+0xa25d0+0x4+0xde647] | Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2010 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 9.0-CURRENT-201008 #0: Tue Aug 3 20:41:56 UTC 2010 root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 WARNING: WITNESS option enabled, expect reduced performance. CPU: QEMU Virtual CPU version 0.9.1 (2667.06-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x663 Family = 6 Model = 6 Stepping = 3 Features=0x783fbfd Features2=0x1 AMD Features=0xe0100800 AMD Features2=0x4 real memory = 268435456 (256 MB) avail memory = 239321088 (228 MB) Event timer "LAPIC" frequency 0 Hz quality 500 ACPI APIC Table: ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xb008-0xb00b on acpi0 cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci_link0: BIOS IRQ 9 does not match initial IRQ 10 pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc000-0xc00f at device 1.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] uhci0: port 0xc020-0xc03f irq 11 at device 1.2 on pci0 uhci0: [ITHREAD] usbus0: controller did not stop usbus0: on uhci0 pci0: at device 1.3 (no driver attached) vgapci0: mem 0xc2000000-0xc3ffffff,0xc4000000-0xc4000fff at device 2.0 on pci0 re0: port 0xc100-0xc1ff mem 0xc4001000-0xc40010ff irq 11 at device 3.0 on pci0 re0: Chip rev. 0x74800000 re0: MAC rev. 0x00000000 miibus0: on re0 rlphy0: PHY 0 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re0: Ethernet address: 54:52:00:78:4a:3e re0: [FILTER] pci0: at device 4.0 (no driver attached) atrtc0: port 0x70-0x71,0x72-0x77 irq 8 on acpi0 atrtc0: [FILTER] Event timer "RTC" frequency 32768 Hz quality 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse Explorer, device ID 4 fdc0: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 uart0: port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart0: console (9600,n,8,1) pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 attimer0: at port 0x40 on isa0 Timecounter "i8254" frequency 1193182 Hz quality 0 attimer0: Can't map interrupt. ppc0: parallel port not found. Timecounter "TSC" frequency 2667064832 Hz quality 800 Starting kernel event timers: LAPIC @ 100Hz, RTC @ 128Hz Timecounters tick every 10.000 msec md0: Preloaded image 4423680 bytes at 0xc1186af4 usbus0: 12Mbps Full Speed USB v1.0 ad0: 10240MB at ata0-master WDMA2 ugen0.1: at usbus0 uhub0: on usbus0 acd0: CDROM at ata1-master WDMA2 WARNING: WITNESS option enabled, expect reduced performance. Root mount waiting for: usbus0 uhub0: 2 ports with 2 removable, self powered Trying to mount root from ufs:/dev/md0 -- Jeremie Le Hen Humans are born free and equal. But some are more equal than others. Coluche From owner-freebsd-stable@FreeBSD.ORG Tue Sep 7 17:13:46 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA067106566B for ; Tue, 7 Sep 2010 17:13:46 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 673B18FC18 for ; Tue, 7 Sep 2010 17:13:46 +0000 (UTC) Received: by wwb18 with SMTP id 18so879891wwb.31 for ; Tue, 07 Sep 2010 10:13:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=Zw6swUwLstHIZ7+oK45Lfe1kMFs2PPjofJNy3hy/UGc=; b=wDkXI/P9uAZDEiaybXEoyABsb6wpGn7I8imdrl2Si0/o3jHCSOq4NJeZ4R2wcfjXp6 HVVjtUs91eXQNIgHtX6lSQLPfAuL7vzx1j/MnLZ1kBiObSnPAGLU6/mY/i6aJOzyRkrJ 9CiOvZMWUcemCjjOX+E4VwV077UaGBuxFajuc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=BNOXAFfI7ZbRLJ3+I3T9gIfR4xijbjsRzDQGb3yV6Sk6MHscLf/egZy5RvdiZ2T5YX Q0C5th5OzmT62DYyHjbPvurj0ZhRqWio2WT3ltFrYtNsvPuGvlxcWjd8g9tM5ArJPsec HqS383hIP8axvlTksyINgP6RJtrWmLs2K8+Jg= MIME-Version: 1.0 Received: by 10.216.15.10 with SMTP id e10mr66805wee.21.1283878801841; Tue, 07 Sep 2010 10:00:01 -0700 (PDT) Received: by 10.216.49.78 with HTTP; Tue, 7 Sep 2010 10:00:01 -0700 (PDT) In-Reply-To: References: <20100906155350.GA50151@lordcow.org> Date: Tue, 7 Sep 2010 10:00:01 -0700 Message-ID: From: Jack Vogel To: FreeBSD stable Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: MSIX failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 17:13:47 -0000 Email to Gareth de Vaux is bouncing :( First off, this device was not supported in 8.0 REL, what were you running that last worked? Do you have MSI disabled on this system of yours, the reason for this message is that both MSIX and MSI setup failed, your device should succeed with MSI. Tell me more about the system please? Jack On Mon, Sep 6, 2010 at 11:36 AM, Jack Vogel wrote: > In the future make sure that you put E1000 or EM in the title otherwise I > might miss it, > fortunately I looked at this :) > > I'm on a holiday weekend, I will investigate this tomorrow. > > Jack > > > > On Mon, Sep 6, 2010 at 8:53 AM, Gareth de Vaux wrote: > >> Hi all, I moved from 8.0-RELEASE to last week's -STABLE: >> >> $ uname -v >> FreeBSD 8.1-STABLE #0: Thu Sep 2 16:38:02 SAST 2010 root@XXXXX >> :/usr/obj/usr/src/sys/GENERIC >> >> and all seems well except my network card is unusable. On boot up: >> >> em0: port 0x3040-0x305f mem >> 0xe3200000-0xe321ffff,0xe3220000-0xe3220fff irq 10 at device 25.0 on pci0 >> em0: Setup MSIX failure >> em0: [FILTER] >> em0: Ethernet address: 00:27:0e:1e:5e:e3 >> >> em1: port >> 0x1000-0x103f mem 0xe3120000-0xe313ffff,0xe3100000-0xe311ffff irq 9 at >> device 1.0 on pci5 >> em1: [FILTER] >> em1: Ethernet address: 00:1b:21:5b:f2:18 >> >> >> em0 is a PCI 'Intel(R) PRO/1000 GT Desktop Adapter' which worked up until >> now. >> em1 is onboard which didn't work with 8.0-RELEASE either. >> >> >> $ ifconfig em0 >> em0: flags=8843 metric 0 mtu 1500 >> >> options=219b >> ether 00:27:0e:1e:5e:e3 >> inet XXXXXXXX >> media: Ethernet autoselect >> status: no carrier >> >> >> pciconf -lv: >> >> em0@pci0:0:25:0: class=0x020000 card=0x00008086 chip=0x10f08086 >> rev=0x05 hdr=0x00 >> vendor = 'Intel Corporation' >> class = network >> subclass = ethernet >> >> em1@pci0:5:1:0: class=0x020000 card=0x13768086 chip=0x107c8086 rev=0x05 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' >> class = network >> subclass = ethernet >> >> (no device listing for em0) >> >> Swapping the PCI card with a PCI-X version gives the same behaviour. >> Setting >> hw.pci.enable_msix and hw.pci.enable_msi to 0 doesn't help in either case. >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > > From owner-freebsd-stable@FreeBSD.ORG Tue Sep 7 17:17:48 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 364D81065697; Tue, 7 Sep 2010 17:17:48 +0000 (UTC) (envelope-from pistoletik@freebsd-go-go.ru) Received: from freebsd-go-go.ru (freebsd-go-go.ru [217.149.183.250]) by mx1.freebsd.org (Postfix) with ESMTP id 9AEB18FC0C; Tue, 7 Sep 2010 17:17:47 +0000 (UTC) Received: from [93.157.162.67] (port=62648 helo=firma.local) by freebsd-go-go.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ot1nm-000DnC-1I; Tue, 07 Sep 2010 21:17:46 +0400 Message-ID: <4C86739D.4050407@freebsd-go-go.ru> Date: Tue, 07 Sep 2010 21:17:17 +0400 From: Baby Boy User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100806 Thunderbird/3.1.2 MIME-Version: 1.0 To: Weongyo Jeong References: <4C7AC69A.2080001@freebsd-go-go.ru> <20100906223957.GB1328@weongyo> In-Reply-To: <20100906223957.GB1328@weongyo> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 93.157.162.67 X-SA-Exim-Mail-From: pistoletik@freebsd-go-go.ru X-SA-Exim-Scanned: No (on freebsd-go-go.ru); SAEximRunCond expanded to false Cc: Warren Block , freebsd-stable@freebsd.org Subject: Re: Broadcom 4315 not working X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 17:17:48 -0000 On 07.09.2010 02:39, Weongyo Jeong wrote: > Today I MFCed a patch for LP PHY devices to STABLE_8. Could you please > test with latest? > > One thing you can test is that using PIO mode. Thank you. > > regards, > Weongyo Jeong > Hello everybody! All operations are executed on a completely new/clean OS. Access Point ASUS WL-330gE, Authentication Method selected Open System. ################################################################### === PREPARATION === # svn checkout svn://svn.freebsd.org/base/stable/8 /usr/src ... ... # uname -a FreeBSD 8.1-STABLE FreeBSD 8.1-STABLE #0 r212293: Tue Sep 7 19:21:04 MSD 2010 dm@:/usr/obj/usr/src/sys/GENERIC i386 Update ports and: # cd /usr/ports/net/bwn-firmware-kmod && make install clean ... ===> Registering installation for bwn-firmware-kmod-0.1.0 ===> Cleaning for b43-fwcutter-012 ===> Cleaning for bwn-firmware-kmod-0.1.0 # rehash # pciconf -lvbc none2@pci0:3:0:0: class=0x028000 card=0x1508103c chip=0x431514e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' device = 'Broadcom Wireless b/g (BCM4315/BCM22062000)' class = network bar [10] = type Memory, range 64, base 0xd4200000, size 16384, enabled cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 09[58] = vendor (length 120) cap 05[e8] = MSI supports 1 message, 64 bit cap 10[d0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) # echo if_bwn_load=\"YES\" >> /boot/loader.conf # shutdown -r now # kldstat Id Refs Address Size Name 1 8 0xc0400000 bc242c kernel 2 1 0xc0fc3000 37248 if_bwn.ko 3 2 0xc0ffb000 a26c siba_bwn.ko # ifconfig bwn0: flags=8802 metric 0 mtu 2290 ether 0c:ee:e6:a1:50:cc media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ################################################################### === DMA === # kldload bwn_v4_lp_ucode.ko # ifconfig wlan0 create wlandev bwn0 # ifconfig wlan0 up # ifconfig bwn0: flags=8843 metric 0 mtu 2290 ether 0c:ee:e6:a1:50:cc media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated .... wlan0: flags=8843 metric 0 mtu 1500 ether 0c:ee:e6:a1:50:cc media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid "" channel 5 (2432 MHz 11g) country US authmode OPEN privacy OFF txpower 30 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme bintval 0 # ifconfig wlan0 up list ap SSID/MESH ID BSSID CHAN RATE S:N INT CAPS dlink home 11 00:1c:f0:e2:96:c5 6 54M -132:-95 100 EPS WME ATH WPS ASUS 00:1d:60:16:d5:16 1 11M -107:-95 100 E WME <<-- Is my my_home_net... 00:1c:f0:3d:5f:d9 1 54M -140:-95 100 EPS RSN WPA ATH DIR300.Augur 00:1e:58:81:50:61 1 54M -141:-95 100 EPS ATH WPS dlink DIR-400 00:01:23:45:67:89 2 54M -140:-95 100 EPS WPA WPS # cat /var/log/messages ... Sep 7 20:41:51 kernel: wlan0: Ethernet address: 0c:ee:e6:a1:50:cc Sep 7 20:42:01 kernel: bwn0: firmware version (rev 478 patch 104 date 0x8701 time 0x657) Sep 7 20:42:01 kernel: wlan0: ieee80211_new_state_locked: pending INIT -> SCAN transition lost Sep 7 20:42:01 kernel: Sep 7 20:42:04 kernel: bwn0: status of RF switch is changed to OFF Sep 7 20:42:04 kernel: bwn0: please turns on the RF switch Sep 7 20:42:05 kernel: bwn0: status of RF switch is changed to ON Sep 7 20:42:29 kernel: bwn0: status of RF switch is changed to OFF Sep 7 20:42:29 kernel: bwn0: please turns on the RF switch Sep 7 20:42:30 kernel: bwn0: status of RF switch is changed to ON Sep 7 20:42:33 kernel: bwn0: status of RF switch is changed to OFF Sep 7 20:42:33 kernel: bwn0: please turns on the RF switch Sep 7 20:42:34 kernel: bwn0: status of RF switch is changed to ON Sep 7 20:43:32 kernel: bwn0: status of RF switch is changed to OFF Sep 7 20:43:32 kernel: bwn0: please turns on the RF switch Sep 7 20:43:40 kernel: bwn0: status of RF switch is changed to ON Sep 7 20:43:53 kernel: bwn0: status of RF switch is changed to OFF Sep 7 20:43:53 kernel: bwn0: please turns on the RF switch ..... If manually press on switch WiFi On/Off, then OS response by pressing in the form of output status (ON or OFF) on monitor. ################################################################### === PIO === (Warren Block, thanks for the help) # echo hw.bwn.usedma=0 >> /boot/loader.conf # shutdown -r now # kldload bwn_v4_lp_ucode.ko # ifconfig wlan0 create wlandev bwn0 # ifconfig wlan0 up # ifconfig bwn0: flags=8843 metric 0 mtu 2290 ether 0c:ee:e6:a1:50:cc media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated ... wlan0: flags=8843 metric 0 mtu 1500 ether 0c:ee:e6:a1:50:cc media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid "" channel 3 (2422 MHz 11g) country US authmode OPEN privacy OFF txpower 30 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme bintval 0 # cat /var/log/messages ... Sep 7 20:57:34 kernel: wlan0: Ethernet address: 0c:ee:e6:a1:50:cc Sep 7 20:57:38 kernel: bwn0: firmware version (rev 478 patch 104 date 0x8701 time 0x657) Sep 7 20:57:39 kernel: wlan0: ieee80211_new_state_locked: pending INIT -> SCAN transition lost Sep 7 20:58:18 kernel: bwn0: status of RF switch is changed to OFF Sep 7 20:58:18 kernel: bwn0: please turns on the RF switch Sep 7 20:58:19 kernel: bwn0: status of RF switch is changed to ON Sep 7 20:59:17 kernel: bwn0: status of RF switch is changed to OFF Sep 7 20:59:17 kernel: bwn0: please turns on the RF switch Sep 7 20:59:21 kernel: bwn0: status of RF switch is changed to ON Sep 7 20:59:23 kernel: bwn0: status of RF switch is changed to OFF Sep 7 20:59:23 kernel: bwn0: please turns on the RF switch Sep 7 20:59:25 kernel: bwn0: status of RF switch is changed to ON Sep 7 20:59:26 kernel: bwn0: status of RF switch is changed to OFF Sep 7 20:59:26 kernel: bwn0: please turns on the RF switch Sep 7 20:59:27 kernel: bwn0: status of RF switch is changed to ON Sep 7 20:59:29 kernel: bwn0: status of RF switch is changed to OFF Sep 7 20:59:29 kernel: bwn0: please turns on the RF switch Sep 7 20:59:33 kernel: bwn0: status of RF switch is changed to ON Sep 7 20:59:34 kernel: bwn0: status of RF switch is changed to OFF Sep 7 20:59:34 kernel: bwn0: please turns on the RF switch # ifconfig wlan0 up list ap SSID/MESH ID BSSID CHAN RATE S:N INT CAPS ASUS 00:1d:60:16:d5:16 1 11M -106:-95 100 E WME <<-- Is my dlink home 11 00:1c:f0:e2:96:c5 6 54M -132:-95 100 EPS WME ATH WPS my_home_net... 00:1c:f0:3d:5f:d9 1 54M -140:-95 100 EPS RSN WPA ATH From owner-freebsd-stable@FreeBSD.ORG Tue Sep 7 20:25:56 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8928810656B6 for ; Tue, 7 Sep 2010 20:25:56 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1131C8FC0C for ; Tue, 7 Sep 2010 20:25:55 +0000 (UTC) Received: by ewy4 with SMTP id 4so2973272ewy.13 for ; Tue, 07 Sep 2010 13:25:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=FKunFlQK+vWC2IQXr6U9jEQL6f5pqPRfNX+Vg6e0qa4=; b=Odqxzvcf4u6e5jIJ5dQdV72zom0o1NSatbjdJM+0C9BFBIBEXJanMYhufuEIr6A0MS 973W959O+h3zrysYSWLDn2cfjauESIEQixtnB0TnvDwPd3/hvqiA4oCE/KsHX1QhCU0Y ANzkrY7ycX/aNSL5Xalfi04duCmN0ft+oA9rM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=cNXBlc0iXc0Fthdh6iDUHPYreIMzKeLh8Xoa1RVgXcCPNLWDovFUXDwpGZ04vSqr6e A0p/kQNS2BkorTmiKiOwhXJ2XetnHwFigCZPrDEY55n0hn/EBYXzElfuxs4Egt5Aifpp tcAK4yfXCbAhh60x3F7lxk0ew8RtFzxqpx6eU= MIME-Version: 1.0 Received: by 10.216.155.206 with SMTP id j56mr2033523wek.67.1283891154703; Tue, 07 Sep 2010 13:25:54 -0700 (PDT) Received: by 10.216.49.78 with HTTP; Tue, 7 Sep 2010 13:25:54 -0700 (PDT) In-Reply-To: References: <20100906155350.GA50151@lordcow.org> Date: Tue, 7 Sep 2010 13:25:54 -0700 Message-ID: From: Jack Vogel To: FreeBSD stable Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: MSIX failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 20:25:56 -0000 I've looked at the code, this message was misleading, what really happens is that the driver fails to be able to setup either MSIX OR MSI, when this happens it will fall back and use a Legacy interrupt, so its non-fatal and the device should work anyway. The only real reason you should see this is a) you used sysctl and turned msi and msix off, or b) a real hardware problem in the chipset has caused the failure. All devices em drives (as opposed to lem) are PCI Express and so by definition they have MSI and MSIX available. I have just checked in a new delta to em in HEAD that corrects some other issues, and I have added a changed message that will be less confusing. Regards, Jack On Tue, Sep 7, 2010 at 10:00 AM, Jack Vogel wrote: > Email to Gareth de Vaux is bouncing :( > > First off, this device was not supported in 8.0 REL, what were you running > that last > worked? > > Do you have MSI disabled on this system of yours, the reason for this > message > is that both MSIX and MSI setup failed, your device should succeed with > MSI. > > Tell me more about the system please? > > Jack > > > > On Mon, Sep 6, 2010 at 11:36 AM, Jack Vogel wrote: > >> In the future make sure that you put E1000 or EM in the title otherwise I >> might miss it, >> fortunately I looked at this :) >> >> I'm on a holiday weekend, I will investigate this tomorrow. >> >> Jack >> >> >> >> On Mon, Sep 6, 2010 at 8:53 AM, Gareth de Vaux wrote: >> >>> Hi all, I moved from 8.0-RELEASE to last week's -STABLE: >>> >>> $ uname -v >>> FreeBSD 8.1-STABLE #0: Thu Sep 2 16:38:02 SAST 2010 root@XXXXX >>> :/usr/obj/usr/src/sys/GENERIC >>> >>> and all seems well except my network card is unusable. On boot up: >>> >>> em0: port 0x3040-0x305f mem >>> 0xe3200000-0xe321ffff,0xe3220000-0xe3220fff irq 10 at device 25.0 on pci0 >>> em0: Setup MSIX failure >>> em0: [FILTER] >>> em0: Ethernet address: 00:27:0e:1e:5e:e3 >>> >>> em1: port >>> 0x1000-0x103f mem 0xe3120000-0xe313ffff,0xe3100000-0xe311ffff irq 9 at >>> device 1.0 on pci5 >>> em1: [FILTER] >>> em1: Ethernet address: 00:1b:21:5b:f2:18 >>> >>> >>> em0 is a PCI 'Intel(R) PRO/1000 GT Desktop Adapter' which worked up until >>> now. >>> em1 is onboard which didn't work with 8.0-RELEASE either. >>> >>> >>> $ ifconfig em0 >>> em0: flags=8843 metric 0 mtu 1500 >>> >>> options=219b >>> ether 00:27:0e:1e:5e:e3 >>> inet XXXXXXXX >>> media: Ethernet autoselect >>> status: no carrier >>> >>> >>> pciconf -lv: >>> >>> em0@pci0:0:25:0: class=0x020000 card=0x00008086 chip=0x10f08086 >>> rev=0x05 hdr=0x00 >>> vendor = 'Intel Corporation' >>> class = network >>> subclass = ethernet >>> >>> em1@pci0:5:1:0: class=0x020000 card=0x13768086 chip=0x107c8086 rev=0x05 >>> hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' >>> class = network >>> subclass = ethernet >>> >>> (no device listing for em0) >>> >>> Swapping the PCI card with a PCI-X version gives the same behaviour. >>> Setting >>> hw.pci.enable_msix and hw.pci.enable_msi to 0 doesn't help in either >>> case. >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org >>> " >>> >> >> > From owner-freebsd-stable@FreeBSD.ORG Tue Sep 7 21:24:40 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86F8110656CB for ; Tue, 7 Sep 2010 21:24:40 +0000 (UTC) (envelope-from tad1214@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 407698FC19 for ; Tue, 7 Sep 2010 21:24:39 +0000 (UTC) Received: by gwb15 with SMTP id 15so2411346gwb.13 for ; Tue, 07 Sep 2010 14:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:to:subject:date :mime-version:content-transfer-encoding:from:message-id:user-agent; bh=8BxA/AuTOI277eQhAgTR3HpduvBkI6Om40sNZt49uN0=; b=wUfZ5GOO4CLdAK864a58G7a8xFj34/B7d8EhONzy8HFZNgqnT9uveI9kFqEclKA/xQ rhRLYfeRBnkiU6ekkrMTZtCqYgKQ7azhcO18j8iWHLf/lI73MJEPRkn4zsc6EtLo3wKh IG89+UqfYz50zGnwCSnlTXCJrOYxYGMS3/MXU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:to:subject:date:mime-version:content-transfer-encoding :from:message-id:user-agent; b=CaQOz/gUKN6aWnfBZGfPspNGM/CDXHilpXUCPQvloPfzEBmc04jynVBfj+sijgoqUQ rKqEYy3bwaeDP3LFL1WBA2Hzi+W/eY8mWGz/SuXYQzYr4KttJIkVzf9nj+l0RyEHSMl0 jaDJL7uIW+Tsonl41iNhjWcD0qxkbKs0wLmIM= Received: by 10.150.195.3 with SMTP id s3mr607217ybf.300.1283892832238; Tue, 07 Sep 2010 13:53:52 -0700 (PDT) Received: from osprey (ng1.cptxoffice.net [208.74.121.102]) by mx.google.com with ESMTPS id t2sm5381429yba.2.2010.09.07.13.53.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 07 Sep 2010 13:53:51 -0700 (PDT) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Date: Tue, 07 Sep 2010 15:52:47 -0500 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Thomas Donnelly" Message-ID: User-Agent: Opera Mail/10.60 (FreeBSD) Subject: Cannot build 7-stable (nsn-attrab) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 21:24:41 -0000 Hello All, I am trying to do make buildworld after a fresh cvsup on a freebsd 7 box and running into some issues. I appologize if I am flooding the list with output but I want to make sure I send as much information as possible. Initially I had this error: cc -O2 -fno-strict-aliasing -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/ usr/obj/usr/src/tmp/usr\" -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/ cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/ usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/usr/src/gnu/ usr.bin/cc/cc_int/../../../../contrib/gcc/config -I/usr/src/gnu/ usr.bin/cc/cc_int/../../../../contrib/gcclibs/include -I/usr/src/gnu/ usr.bin/cc/cc_int/../../../../contrib/gcclibs/libcpp/include -I/usr/ src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libdecnumber -I/ usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/gnu/usr.bin/cc/ cc_int/../../../../contrib/gcc/tree-ssa-ccp.c {standard input}: Assembler messages: {standard input}:0: Warning: end of file not at end of a line; newline inserted cc: Internal error: Killed: 9 (program cc1) Please submit a full bug report. See for instructions. *** Error code 1 {standard input}: Assembler messages: {standard input}:1939: Warning: end of file not at end of a line; newline inserted {standard input}:2129: Error: expecting operand after ','; got nothing cc: Internal error: Killed: 9 (program cc1) Please submit a full bug report. See for instructions. *** Error code 1 2 errors *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error with this make.conf: # added by use.perl 2009-07-01 16:17:52 PERL_VERSION=5.8.9 PYTHON_DEFAULT_VERSION=python2.4 BATCH=YES WITHOUT_X11=YES SKIP_DNS_CHECK=YES CRYPT_DES=0 WITH_PORT_REPLACES_BASE_BIND8=YES WITH_PORT_REPLACES_BASE_BIND9=YES WITHOUT_ALT_CONFIG_PREFIX=YES WITH_OPENSSL_PORT=YES X11BASE=${LOCALBASE} Then I replaced that make.conf with a completely clean make.conf and got this error: cc -O2 -fno-strict-aliasing -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX= \"/usr\" -I/usr/obj/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/ src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/ cc_int/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/ cc_int/../../../../contrib/gcc/config -I/usr/src/gnu/usr.bin/cc/ cc_int/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr.bin/cc/ cc_int/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/ usr.bin/cc/cc_int/../../../../contrib/gcclibs/libdecnumber -c ../ cc_tools/insn-attrtab.c {standard input}: Assembler messages: {standard input}:24478: Warning: end of file not at end of a line; newline inserted {standard input}:25877: Error: unknown pseudo-op: `.' cc: Internal error: Killed: 9 (program cc1) Please submit a full bug report. See for instructions. *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc/cc_int. *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc. *** Error code 1 Stop in /usr/src/gnu/usr.bin. *** Error code 1 Stop in /usr/src/gnu. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. These errors happened consistently multiple times. Usually with hardware failure my experience is it is inconsistent when it breaks. I have no reason to suspect hardware failure with this machine. While I am not ruling it out, it seems unlikely. $ uname -a FreeBSD xxx.xxx.xxx 7.2-RELEASE-p2 FreeBSD 7.2-RELEASE-p2 #0: Thu Jul 2 16:07:38 UTC 2009 root@xxx/xxx/xxxx:/usr/obj/usr/src/sys/XXX amd64 Thoughts? I am not on this list so please cc me in your replies. Thanks! -=Tom -- Using Opera's revolutionary email client: http://www.opera.com/mail/ From owner-freebsd-stable@FreeBSD.ORG Tue Sep 7 21:34:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CCFC10656CE for ; Tue, 7 Sep 2010 21:34:54 +0000 (UTC) (envelope-from mahlon@martini.nu) Received: from martini.nu (martini.nu [198.145.180.83]) by mx1.freebsd.org (Postfix) with SMTP id 420A98FC12 for ; Tue, 7 Sep 2010 21:34:54 +0000 (UTC) Received: (qmail 91052 invoked by uid 1000); 7 Sep 2010 21:08:13 -0000 Date: Tue, 7 Sep 2010 14:08:13 -0700 From: "Mahlon E. Smith" To: freebsd-stable@freebsd.org Message-ID: <20100907210813.GI49065@martini.nu> Mail-Followup-To: "Mahlon E. Smith" , freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yQbNiKLmgenwUfTN" Content-Disposition: inline X-GPG-Fingerprint: 19B8 DDB3 0156 3A03 FA80 8278 C0BE 6BFB 3606 B267 X-Sysinfo: FreeBSD 7.0-RELEASE-p1 i386 User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Network memory allocation failures X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 21:34:54 -0000 --yQbNiKLmgenwUfTN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, all. I picked up a couple of Dell R810 monsters a couple of months ago. 96G of RAM, 24 core. With the aid of this list, got 8.1-RELEASE on there, and they are trucking along merrily as VirtualBox hosts. I'm seeing memory allocation errors when sending data over the network. It is random at best, however I can reproduce it pretty reliably. Sending 100M to a remote machine. Note the 2nd scp attempt worked. Most small files can make it through unmolested. obb# dd if=3D/dev/random of=3D100M-test bs=3D1M count=3D100 100+0 records in 100+0 records out 104857600 bytes transferred in 2.881689 secs (36387551 bytes/sec) obb# rsync -av 100M-test skin:/tmp/ sending incremental file list 100M-test Write failed: Cannot allocate memory rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: B= roken pipe (32) rsync: connection unexpectedly closed (28 bytes received so far) [sende= r] rsync error: unexplained error (code 255) at io.c(601) [sender=3D3.0.7] obb# scp 100M-test skin:/tmp/ 100M-test 52% 52MB 52.1MB/s 00:00 ETAWrite failed: Cannot a= llocate memory lost connection obb# scp 100M-test skin:/tmp/ 100M-test 100% 100MB 50.0MB/s 00:02 =20 obb# scp 100M-test skin:/tmp/ 100M-test 0% 0 0.0KB/s --:-- ETAWrite failed: Cannot a= llocate memory lost connection Fetching a file, however, works. obb# scp skin:/usr/local/tmp/100M-test . 100M-test 100% 100MB 20.0MB/s 00:05 =20 obb# scp skin:/usr/local/tmp/100M-test . 100M-test 100% 100MB 20.0MB/s 00:05 =20 obb# scp skin:/usr/local/tmp/100M-test . 100M-test 100% 100MB 20.0MB/s 00:05 =20 obb# scp skin:/usr/local/tmp/100M-test . 100M-test 100% 100MB 20.0MB/s 00:05 =20 ... I've ruled out bad hardware (mainly due to the behavior being *identical* on the sister machine, in a completely different data center.) It's a broadcom (bce) NIC. mbufs look fine to me. obb# netstat -m 511/6659/7170 mbufs in use (current/cache/total) 510/3678/4188/25600 mbuf clusters in use (current/cache/total/max) 510/3202 mbuf+clusters out of packet secondary zone in use (current/cache) 0/984/984/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 1147K/12956K/14104K 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/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines Plenty of available mem (not surprising): obb# vmstat -hc 5 -w 5=20 procs memory page disks faults = cpu r b w avm fre flt re pi po fr sr mf0 mf1 in sy c= s us sy id 0 0 0 722M 92G 115 0 1 0 1067 0 0 0 429 32637 65= 20 0 1 99 0 0 0 722M 92G 1 0 0 0 0 0 0 0 9 31830 32= 79 0 0 100 0 0 0 722M 92G 0 0 0 0 3 0 0 0 8 33171 32= 23 0 0 100 0 0 0 761M 92G 2593 0 0 0 1712 0 5 4 121 35384 39= 07 0 0 99 1 0 0 761M 92G 0 0 0 0 0 0 0 0 10 30237 31= 56 0 0 100 Last bit of info, and here's where it gets really weird. Remember how I said this was a VirtualBox host? Guest machines running on it (mostly centos) don't exhibit the problem, which is also why it took me so long to notice it in the host. They can merrily copy data around at will, even though they are going out through the same host interface. I'm not sure what to check for or toggle at this point. There are all sorts of tunables I've been mucking around with to no avail, and so I've reverted them to defaults. Mostly concentrating on these: hw.intr_storm_threshold net.inet.tcp.rfc1323 kern.ipc.nmbclusters kern.ipc.nmbjumbop net.inet.tcp.sendspace net.inet.tcp.recvspace kern.ipc.somaxconn kern.ipc.maxsockbuf It was suggested to me to try limiting the RAM in loader.conf to under 32G and see what happens. When doing this, it does appear to be "okay". Not sure if that's coincidence, or directly related -- something with the large amount of RAM that is confusing a data structure somewhere? Or potentially a problem with the bce driver, specifically? I've kind of reached a limit here in what to dig for / try next. What else can I do to try and determine the root problem that would be helpful? Anyone ever have to deal with or seen something like this recently? (Or hell, not recently?) Ideas appreciated! -- Mahlon E. Smith =20 http://www.martini.nu/contact.html --yQbNiKLmgenwUfTN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- iD8DBQFMhqm91bsjBDapbeMRAskpAJ9m0K/uBfhkShaHHjXkTGDbZZNJOQCePK5M E96Iyo2BCuaAhnkLNbfirkM= =1i1D -----END PGP SIGNATURE----- --yQbNiKLmgenwUfTN-- From owner-freebsd-stable@FreeBSD.ORG Tue Sep 7 22:02:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 113241065696 for ; Tue, 7 Sep 2010 22:02:30 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 966EA8FC0A for ; Tue, 7 Sep 2010 22:02:29 +0000 (UTC) Received: by fxm4 with SMTP id 4so3935021fxm.13 for ; Tue, 07 Sep 2010 15:02:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=FeqBY+z2YfsDc9+j/wJ5Q8aWYhGPxNnMoKIQoVCbBiU=; b=YgzrA392DMi7e9FX/U0u3ddkRGGY18jNuH4cgIIyx2mSk8k5QbKjUHOJ9rHgiTNNOz u1wzQi2JAJMof9L4VQ51Ch0EW1wfbpVdVzdXIQhJ9QrPkMTjpQLqcCrpg7j9J8zOFMXq 0nS1TPH8PHW4gnAUOtp2XqcY0olWAK1wPd/Vw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=QcAFjcERoUGkbbznnBZcQ4P6O3VU6vQW9qtLWLZUlJHtCUwywIE/4rz+DfESk+ZY9P X2mlN8BvFrn1sTYl00X3HqSqglqEIArBy0uMrRpObuXepV8G2k6mkwukZiZLuZqNR75T Euinm9JNZDiPtSLpRbEy6bPxW50CMKniERSqU= MIME-Version: 1.0 Received: by 10.223.119.70 with SMTP id y6mr233217faq.65.1283896946734; Tue, 07 Sep 2010 15:02:26 -0700 (PDT) Received: by 10.223.57.20 with HTTP; Tue, 7 Sep 2010 15:02:26 -0700 (PDT) In-Reply-To: <20100907210813.GI49065@martini.nu> References: <20100907210813.GI49065@martini.nu> Date: Tue, 7 Sep 2010 17:02:26 -0500 Message-ID: From: Adam Vande More To: "Mahlon E. Smith" , freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Network memory allocation failures X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 22:02:30 -0000 On Tue, Sep 7, 2010 at 4:08 PM, Mahlon E. Smith wrote: > I've kind of reached a limit here in what to dig for / try next. What > else can I do to try and determine the root problem that would be > helpful? Anyone ever have to deal with or seen something like this > recently? (Or hell, not recently?) > > Ideas appreciated! > Wild guess here, not sure all the dynamics of changing this, but you could try increasing: kern.maxdsiz It's a kern tunable, so change it in /boot/loader.conf -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Tue Sep 7 22:24:06 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4FAB10656A9 for ; Tue, 7 Sep 2010 22:24:06 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by mx1.freebsd.org (Postfix) with ESMTP id 030558FC13 for ; Tue, 7 Sep 2010 22:24:05 +0000 (UTC) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta06.westchester.pa.mail.comcast.net with comcast id 3yBc1f0050mv7h056yQ5dJ; Tue, 07 Sep 2010 22:24:06 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta11.westchester.pa.mail.comcast.net with comcast id 3yQ41f00X3LrwQ23XyQ58u; Tue, 07 Sep 2010 22:24:05 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 341B69B423; Tue, 7 Sep 2010 15:24:03 -0700 (PDT) Date: Tue, 7 Sep 2010 15:24:03 -0700 From: Jeremy Chadwick To: "Mahlon E. Smith" Message-ID: <20100907222403.GA18595@icarus.home.lan> References: <20100907210813.GI49065@martini.nu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100907210813.GI49065@martini.nu> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Yong-Hyeon PYUN , freebsd-stable@freebsd.org Subject: Re: Network memory allocation failures X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 22:24:06 -0000 On Tue, Sep 07, 2010 at 02:08:13PM -0700, Mahlon E. Smith wrote: > I picked up a couple of Dell R810 monsters a couple of months ago. 96G > of RAM, 24 core. With the aid of this list, got 8.1-RELEASE on there, > and they are trucking along merrily as VirtualBox hosts. > > I'm seeing memory allocation errors when sending data over the network. > It is random at best, however I can reproduce it pretty reliably. > > Sending 100M to a remote machine. Note the 2nd scp attempt worked. > Most small files can make it through unmolested. > > obb# dd if=/dev/random of=100M-test bs=1M count=100 > 100+0 records in > 100+0 records out > 104857600 bytes transferred in 2.881689 secs (36387551 bytes/sec) > obb# rsync -av 100M-test skin:/tmp/ > sending incremental file list > 100M-test > Write failed: Cannot allocate memory > rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32) > rsync: connection unexpectedly closed (28 bytes received so far) [sender] > rsync error: unexplained error (code 255) at io.c(601) [sender=3.0.7] > obb# scp 100M-test skin:/tmp/ > 100M-test 52% 52MB 52.1MB/s 00:00 ETAWrite failed: Cannot allocate memory > lost connection > obb# scp 100M-test skin:/tmp/ > 100M-test 100% 100MB 50.0MB/s 00:02 > obb# scp 100M-test skin:/tmp/ > 100M-test 0% 0 0.0KB/s --:-- ETAWrite failed: Cannot allocate memory > lost connection > > Fetching a file, however, works. > > obb# scp skin:/usr/local/tmp/100M-test . > 100M-test 100% 100MB 20.0MB/s 00:05 > obb# scp skin:/usr/local/tmp/100M-test . > 100M-test 100% 100MB 20.0MB/s 00:05 > obb# scp skin:/usr/local/tmp/100M-test . > 100M-test 100% 100MB 20.0MB/s 00:05 > obb# scp skin:/usr/local/tmp/100M-test . > 100M-test 100% 100MB 20.0MB/s 00:05 > ... > > > I've ruled out bad hardware (mainly due to the behavior being > *identical* on the sister machine, in a completely different data > center.) It's a broadcom (bce) NIC. This could be a bce(4) bug, meaning the "failed to allocate memory" message could be indicating DMA failure or something else from the card, and not necessarily related to mbufs. There are also changes/fixes to bce(4) that are in RELENG_8 (8.1-STABLE) that aren't in 8.1-RELEASE, but I don't know if those are responsible for your problem. Please provide output from the following: * uname -a (if desired, XXX out hostname) * vmstat -i * ifconfig -a (if desired, XXX out IPs and MACs) * netstat -inbd (if desired, XXX out MACs) * pciconf -lvc (only the bceX entry please) Also check dmesg to see if there's any error messages that correlate when the problem occurs. I'm also CC'ing Yong-Hyeon PYUN who might have some ideas. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Sep 7 23:33:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F6EC10656EB for ; Tue, 7 Sep 2010 23:33:01 +0000 (UTC) (envelope-from mahlon@martini.nu) Received: from martini.nu (martini.nu [198.145.180.83]) by mx1.freebsd.org (Postfix) with SMTP id 3E7E08FC0A for ; Tue, 7 Sep 2010 23:32:57 +0000 (UTC) Received: (qmail 12931 invoked by uid 1000); 7 Sep 2010 23:32:57 -0000 Date: Tue, 7 Sep 2010 16:32:57 -0700 From: "Mahlon E. Smith" To: Jeremy Chadwick Message-ID: <20100907233257.GA94092@martini.nu> Mail-Followup-To: "Mahlon E. Smith" , Jeremy Chadwick , freebsd-stable@freebsd.org, Yong-Hyeon PYUN References: <20100907210813.GI49065@martini.nu> <20100907222403.GA18595@icarus.home.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline In-Reply-To: <20100907222403.GA18595@icarus.home.lan> X-GPG-Fingerprint: 19B8 DDB3 0156 3A03 FA80 8278 C0BE 6BFB 3606 B267 X-Sysinfo: FreeBSD 7.0-RELEASE-p1 i386 User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Yong-Hyeon PYUN , freebsd-stable@freebsd.org Subject: Re: Network memory allocation failures X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 23:33:01 -0000 --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 07, 2010, Jeremy Chadwick wrote: >=20 > This could be a bce(4) bug, meaning the "failed to allocate memory" > message could be indicating DMA failure or something else from the card, > and not necessarily related to mbufs. >=20 > There are also changes/fixes to bce(4) that are in RELENG_8 (8.1-STABLE) > that aren't in 8.1-RELEASE, but I don't know if those are responsible > for your problem. Hmm, well -- I'm definitely not opposed to jumping to -STABLE if it might fix it. > Please provide output from the following: >=20 > * uname -a (if desired, XXX out hostname) FreeBSD jessage 8.1-RELEASE FreeBSD 8.1-RELEASE #2: Fri Aug 20 14:30:31 PDT= 2010 root@jessage:/usr/src/sys/amd64/compile/R810 amd64 Custom kernel, with additions to GENERIC (nothing removed): device carp device snp options HZ=3D1000 options DEVICE_POLLING options ALTQ options ALTQ_CBQ options ALTQ_PRIQ options SC_DISABLE_REBOOT options PANIC_REBOOT_WAIT_TIME=3D5 ALTQ and friends not actually active on the machine. I was fighting a different battle when running GENERIC, so I can't honestly recall if this problem existed then -- I'll make sure it is still happening under GENERIC for a baseline, to eliminate any potential weirdness with DEVICE_POLLING or the HZ timing. > * vmstat -i interrupt total rate irq19: ehci0 1547103 0 irq21: uhci1 uhci3+ 29 0 irq23: atapci0 35 0 irq32: mfi0 68104468 43 cpu0: timer 3093305346 1986 irq256: bce0 46587008 29 cpu19: timer 3103614834 1992 cpu1: timer 3093298527 1986 cpu4: timer 3093297557 1986 cpu10: timer 3089824707 1983 cpu12: timer 3097896788 1989 cpu16: timer 3097897232 1989 cpu22: timer 3103615267 1992 cpu2: timer 3093297601 1986 cpu5: timer 3093298349 1986 cpu3: timer 3093298637 1986 cpu6: timer 3089823402 1983 cpu18: timer 3103614571 1992 cpu13: timer 3097897961 1989 cpu20: timer 3103615299 1992 cpu23: timer 3103614783 1992 cpu9: timer 3089821582 1983 cpu17: timer 3097898138 1989 cpu11: timer 3089821712 1983 cpu14: timer 3097897190 1989 cpu7: timer 3089821360 1983 cpu21: timer 3103615012 1992 cpu15: timer 3097898081 1989 cpu8: timer 3089824487 1983 Total 74424047066 47788 > * ifconfig -a (if desired, XXX out IPs and MACs) bce0: flags=3D8943 metr= ic 0 mtu 1500 options=3Dc01bb ether 00:25:64:fd:0b:24 inet 10.5.2.69 netmask 0xfffffc00 broadcast 10.5.3.255 media: Ethernet autoselect (1000baseT ) status: active bce1: flags=3D8802 metric 0 mtu 1500 options=3Dc01bb ether 00:25:64:fd:0b:26 media: Ethernet autoselect (none) status: no carrier bce2: flags=3D8802 metric 0 mtu 1500 options=3Dc01bb ether 00:25:64:fd:0b:28 media: Ethernet autoselect (none) status: no carrier bce3: flags=3D8802 metric 0 mtu 1500 options=3Dc01bb ether 00:25:64:fd:0b:2a media: Ethernet autoselect (none) status: no carrier lo0: flags=3D8049 metric 0 mtu 16384 options=3D3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5=20 inet6 ::1 prefixlen 128=20 inet 127.0.0.1 netmask 0xff000000=20 nd6 options=3D3 vboxnet0: flags=3D8802 metric 0 mtu 1500 ether 0a:00:27:00:00:00 > * netstat -inbd (if desired, XXX out MACs) Name Mtu Network Address Ipkts Ierrs Idrop Ib= ytes Opkts Oerrs Obytes Coll Drop bce0 1500 00:25:64:fd:0b:24 14467627 0 0 634654= 9588 11846499 0 4646920777 0 0=20 bce0 1500 10.5.0.0/22 10.5.2.69 1987644 - - 37163= 5478 415087 - 74168123 - -=20 bce1* 1500 00:25:64:fd:0b:26 0 0 0 = 0 0 0 0 0 0=20 bce2* 1500 00:25:64:fd:0b:28 0 0 0 = 0 0 0 0 0 0=20 bce3* 1500 00:25:64:fd:0b:2a 0 0 0 = 0 0 0 0 0 0=20 lo0 16384 25561 0 0 4733= 8756 25561 0 47338756 0 0=20 lo0 16384 fe80:5::1/64 fe80:5::1 0 - - = 0 0 - 0 - -=20 lo0 16384 ::1/128 ::1 0 - - = 0 0 - 0 - -=20 lo0 16384 127.0.0.0/8 127.0.0.1 25561 - - 4733= 8756 25561 - 47338756 - -=20 vboxn 1500 0a:00:27:00:00:00 0 0 0 = 0 0 0 0 0 0=20 > * pciconf -lvc (only the bceX entry please) bce0@pci0:1:0:0: class=3D0x020000 card=3D0x02d41028 chip=3D0x163= 914e4 rev=3D0x20 hdr=3D0x00 vendor =3D 'Broadcom Corporation' device =3D 'NetXtreme II Gigabit Ethernet (BCM5709)' class =3D network subclass =3D ethernet cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 03[50] =3D VPD cap 05[58] =3D MSI supports 16 messages, 64 bit enabled with 1 mess= age cap 11[a0] =3D MSI-X supports 9 messages in map 0x10 cap 10[ac] =3D PCI-Express 2 endpoint max data 256(512) link x2(x4) =20 > Also check dmesg to see if there's any error messages that correlate > when the problem occurs. All quiet on that front. Thanks for the reply, Jeremy! -- Mahlon E. Smith =20 http://www.martini.nu/contact.html --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- iD8DBQFMhsup1bsjBDapbeMRAlMvAJ9WcgJ8TVjEOo5I6hdHUU4ZtNqKwQCgtz9r /v/BhP7d05P1DeLSpnwpHZI= =Wi9i -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND-- From owner-freebsd-stable@FreeBSD.ORG Wed Sep 8 00:29:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 175B410656C5 for ; Wed, 8 Sep 2010 00:29:38 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id D89428FC12 for ; Wed, 8 Sep 2010 00:29:37 +0000 (UTC) Received: by pwi8 with SMTP id 8so1916541pwi.13 for ; Tue, 07 Sep 2010 17:29:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:subject :message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=CJggxb6y3ErNnlRAE8uGChyCE/taY0L+2m1BQwHMY2Y=; b=ghP/+eD2U10IBhUd+KpHRPfo/s/Uf6DyQt1rNf26OLkWref9XilXO2hZpBiBOy18iM 48h62Z9qviqfZn7orfZDtb7MK9gPzPnYkV58VTl8JPuS5VKqyAsxwu0pwdOAmXYNlmly b9REvo9YC8O0v48R/iGbz8TlkZNm8qfPM40+4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=nOVbLP6dDcvaiHc0vQ+BLX65qMghIEhOKSYEyQ5mZpkZVt6Chbc7drJep4+0JTQvgy jyGYs3HgUAsfD9Oyh+joUBn/UatE+N5nqFaNQW0VmUVvoy3ujvHHKTA6+FFarJVtXeJO s4ocLJ8E9+E8DBp6ZyUbg9tmxieDRjA/rnOAw= Received: by 10.142.199.5 with SMTP id w5mr136951wff.299.1283905777210; Tue, 07 Sep 2010 17:29:37 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id n36sm6433832wfa.4.2010.09.07.17.29.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 07 Sep 2010 17:29:36 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 7 Sep 2010 17:29:17 -0700 From: Pyun YongHyeon Date: Tue, 7 Sep 2010 17:29:17 -0700 To: "Mahlon E. Smith" , Jeremy Chadwick , freebsd-stable@freebsd.org Message-ID: <20100908002917.GO1439@michelle.cdnetworks.com> References: <20100907210813.GI49065@martini.nu> <20100907222403.GA18595@icarus.home.lan> <20100907233257.GA94092@martini.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100907233257.GA94092@martini.nu> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: Network memory allocation failures X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 00:29:38 -0000 On Tue, Sep 07, 2010 at 04:32:57PM -0700, Mahlon E. Smith wrote: > On Tue, Sep 07, 2010, Jeremy Chadwick wrote: > > > > This could be a bce(4) bug, meaning the "failed to allocate memory" > > message could be indicating DMA failure or something else from the card, > > and not necessarily related to mbufs. > > > > There are also changes/fixes to bce(4) that are in RELENG_8 (8.1-STABLE) > > that aren't in 8.1-RELEASE, but I don't know if those are responsible > > for your problem. > > Hmm, well -- I'm definitely not opposed to jumping to -STABLE if it > might fix it. > > > > Please provide output from the following: > > > > * uname -a (if desired, XXX out hostname) > > FreeBSD jessage 8.1-RELEASE FreeBSD 8.1-RELEASE #2: Fri Aug 20 14:30:31 PDT 2010 root@jessage:/usr/src/sys/amd64/compile/R810 amd64 > > Custom kernel, with additions to GENERIC (nothing removed): > > device carp > device snp > options HZ=1000 > options DEVICE_POLLING bce(4) does not support polling(4) so you can completely remove configuration of HZ and DEVICE_POLLING. In fact, there is no reason to use polling(4) at all on intelligent controllers like bce(4). polling(4) is mainly for dumb controllers that lack efficient interrupt moderation. > options ALTQ > options ALTQ_CBQ > options ALTQ_PRIQ > options SC_DISABLE_REBOOT > options PANIC_REBOOT_WAIT_TIME=5 > > ALTQ and friends not actually active on the machine. I was fighting a > different battle when running GENERIC, so I can't honestly recall if this > problem existed then -- I'll make sure it is still happening under > GENERIC for a baseline, to eliminate any potential weirdness with > DEVICE_POLLING or the HZ timing. > > > > * vmstat -i > > interrupt total rate > irq19: ehci0 1547103 0 > irq21: uhci1 uhci3+ 29 0 > irq23: atapci0 35 0 > irq32: mfi0 68104468 43 > cpu0: timer 3093305346 1986 > irq256: bce0 46587008 29 > cpu19: timer 3103614834 1992 > cpu1: timer 3093298527 1986 > cpu4: timer 3093297557 1986 > cpu10: timer 3089824707 1983 > cpu12: timer 3097896788 1989 > cpu16: timer 3097897232 1989 > cpu22: timer 3103615267 1992 > cpu2: timer 3093297601 1986 > cpu5: timer 3093298349 1986 > cpu3: timer 3093298637 1986 > cpu6: timer 3089823402 1983 > cpu18: timer 3103614571 1992 > cpu13: timer 3097897961 1989 > cpu20: timer 3103615299 1992 > cpu23: timer 3103614783 1992 > cpu9: timer 3089821582 1983 > cpu17: timer 3097898138 1989 > cpu11: timer 3089821712 1983 > cpu14: timer 3097897190 1989 > cpu7: timer 3089821360 1983 > cpu21: timer 3103615012 1992 > cpu15: timer 3097898081 1989 > cpu8: timer 3089824487 1983 > Total 74424047066 47788 > > > > * ifconfig -a (if desired, XXX out IPs and MACs) > > bce0: flags=8943 metric 0 mtu 1500 > options=c01bb > ether 00:25:64:fd:0b:24 > inet 10.5.2.69 netmask 0xfffffc00 broadcast 10.5.3.255 > media: Ethernet autoselect (1000baseT ) > status: active > bce1: flags=8802 metric 0 mtu 1500 > options=c01bb > ether 00:25:64:fd:0b:26 > media: Ethernet autoselect (none) > status: no carrier > bce2: flags=8802 metric 0 mtu 1500 > options=c01bb > ether 00:25:64:fd:0b:28 > media: Ethernet autoselect (none) > status: no carrier > bce3: flags=8802 metric 0 mtu 1500 > options=c01bb > ether 00:25:64:fd:0b:2a > media: Ethernet autoselect (none) > status: no carrier > lo0: flags=8049 metric 0 mtu 16384 > options=3 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > nd6 options=3 > vboxnet0: flags=8802 metric 0 mtu 1500 > ether 0a:00:27:00:00:00 > > > > * netstat -inbd (if desired, XXX out MACs) > > Name Mtu Network Address Ipkts Ierrs Idrop Ibytes Opkts Oerrs Obytes Coll Drop > bce0 1500 00:25:64:fd:0b:24 14467627 0 0 6346549588 11846499 0 4646920777 0 0 > bce0 1500 10.5.0.0/22 10.5.2.69 1987644 - - 371635478 415087 - 74168123 - - > bce1* 1500 00:25:64:fd:0b:26 0 0 0 0 0 0 0 0 0 > bce2* 1500 00:25:64:fd:0b:28 0 0 0 0 0 0 0 0 0 > bce3* 1500 00:25:64:fd:0b:2a 0 0 0 0 0 0 0 0 0 > lo0 16384 25561 0 0 47338756 25561 0 47338756 0 0 > lo0 16384 fe80:5::1/64 fe80:5::1 0 - - 0 0 - 0 - - > lo0 16384 ::1/128 ::1 0 - - 0 0 - 0 - - > lo0 16384 127.0.0.0/8 127.0.0.1 25561 - - 47338756 25561 - 47338756 - - > vboxn 1500 0a:00:27:00:00:00 0 0 0 0 0 0 0 0 0 > > > > > * pciconf -lvc (only the bceX entry please) > > bce0@pci0:1:0:0: class=0x020000 card=0x02d41028 chip=0x163914e4 rev=0x20 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'NetXtreme II Gigabit Ethernet (BCM5709)' > class = network > subclass = ethernet > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 03[50] = VPD > cap 05[58] = MSI supports 16 messages, 64 bit enabled with 1 message > cap 11[a0] = MSI-X supports 9 messages in map 0x10 > cap 10[ac] = PCI-Express 2 endpoint max data 256(512) link x2(x4) > > > > Also check dmesg to see if there's any error messages that correlate > > when the problem occurs. > > All quiet on that front. > Based on your outputs, I don't see abnormal things in bce(4). Why do you think bce(4) is the cause of problem? You may see more detailed MAC statistics if controller saw some kind of memory related failure from the output of "sysctl dev.bce.0". From owner-freebsd-stable@FreeBSD.ORG Wed Sep 8 03:18:36 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B485910656D3; Wed, 8 Sep 2010 03:18:36 +0000 (UTC) (envelope-from vadim_nuclight@mail.ru) Received: from fallback4.mail.ru (fallback4.mail.ru [94.100.176.42]) by mx1.freebsd.org (Postfix) with ESMTP id 392218FC18; Wed, 8 Sep 2010 03:18:35 +0000 (UTC) Received: from smtp5.mail.ru (smtp5.mail.ru [94.100.176.47]) by fallback4.mail.ru (mPOP.Fallback_MX) with ESMTP id D5FA6304E04F; Wed, 8 Sep 2010 01:31:49 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=In-Reply-To:Message-ID:Content-Transfer-Encoding:MIME-Version:Content-Type:From:References:Subject:To:Date; bh=PBHkzXMDK7dZaTO1ZoDpS+Qw7jC38g8g4bbwA+NqDp4=; b=4FHDzgsBkg/E2xlCfN6kRwYjU/e8Cn568fTE5b458ghwFA6KnW2FV0AO+eSlk93SQsKsXqv7M0f/KTuL8mhcTnD37i8ukWKktZhiaUq9zRlm+G9O2hl4ZKqQCuYvP29P; Received: from [217.29.94.29] (port=35203 helo=nuclight) by smtp5.mail.ru with asmtp id 1Ot5lb-0005MV-00; Wed, 08 Sep 2010 01:31:48 +0400 Date: Wed, 08 Sep 2010 04:31:46 +0700 To: freebsd-stable@freebsd.org, freebsd-security@freebsd.org References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <201009011902.06538.hselasky@c2i.net> <4C8627A6.1090308@icyb.net.ua> From: "Vadim Goncharov" Organization: AVTF TPU Hostel Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <4C8627A6.1090308@icyb.net.ua> User-Agent: Opera M2/7.54 (Win32, build 3865) X-Mras: Ok Cc: Subject: Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 03:18:36 -0000 07.09.10 @ 18:53 Andriy Gapon wrote: > on 07/09/2010 13:38 Vadim Goncharov said the following: >>> Just to clarify things a little for those following it: >>> the original I4B code was removed ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (1) >>> for entirely practical reasons: it couldn't run without the Giant >>> lock, and support for the Giant lock over the network stack was >>> removed. >> >> But if it was used, removing a component just because of Giant lock is >> not >> practical and is purely ideologic, isn't it? > > Which part of "support for the Giant lock *over the network stack* was > removed" > [emphasis mine] do you not understand? No, component removed was (1), I've underlined. > The reason is performance for overall network stack, not ideology. For a practical reasons, "it works but slow" is better than "doesn't work at all (due to absence of code in the src tree)". "Make it work. Make it right. Make it fast. In that order", know this? Sacrificing "work" for "fast"?.. Hmm, if it is not ideology, then what is it?.. > BTW, there were advanced notices for users, request for volunteers, etc. > > So, if you didn't speak up at that time please keep silence now :-) You do not understand the problem. It is not in notices & volunteers, but rather in the Project's policy - delete something which could still work. Personally, I don't use ISDN, so didn't said anything that time, but now, there are more precedents of removing components from FreeBSD - so, for now, I must say that this policy is harmful. Though I doubt that one man's opinion could change Project's policy until it's too late... -- WBR, Vadim Goncharov From owner-freebsd-stable@FreeBSD.ORG Wed Sep 8 03:37:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43F4810656B0 for ; Wed, 8 Sep 2010 03:37:12 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id DDD038FC19 for ; Wed, 8 Sep 2010 03:37:11 +0000 (UTC) Received: (qmail 12643 invoked by uid 399); 8 Sep 2010 03:37:10 -0000 Received: from localhost (HELO ?192.168.0.142?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 8 Sep 2010 03:37:10 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C8704E3.5000408@FreeBSD.org> Date: Tue, 07 Sep 2010 20:37:07 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Vadim Goncharov References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <201009011902.06538.hselasky@c2i.net> <4C8627A6.1090308@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-security@freebsd.org, freebsd-stable@freebsd.org Subject: Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 03:37:12 -0000 On 09/07/2010 02:31 PM, Vadim Goncharov wrote: > 07.09.10 @ 18:53 Andriy Gapon wrote: > >> on 07/09/2010 13:38 Vadim Goncharov said the following: >>>> Just to clarify things a little for those following it: >>>> the original I4B code was removed > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (1) >>>> for entirely practical reasons: it couldn't run without the Giant >>>> lock, and support for the Giant lock over the network stack was >>>> removed. >>> >>> But if it was used, removing a component just because of Giant lock >>> is not >>> practical and is purely ideologic, isn't it? >> >> Which part of "support for the Giant lock *over the network stack* was >> removed" >> [emphasis mine] do you not understand? > > No, component removed was (1), I've underlined. > >> The reason is performance for overall network stack, not ideology. > > For a practical reasons, "it works but slow" is better than > "doesn't work at all (due to absence of code in the src tree)". I think you are misunderstanding the situation. It wasn't a case of, "It works but it's slow." The situation was that in order to take performance of the network stack as a whole up to the next level it was necessary to remove the Giant lock. Because the original I4B code didn't work without the Giant lock, and because no one stepped forward to fix that, the code had to be removed. >> BTW, there were advanced notices for users, request for volunteers, etc. >> >> So, if you didn't speak up at that time please keep silence now :-) > > You do not understand the problem. It is not in notices & volunteers, In this case it was 100% about the latter. In addition to the fact that without volunteers there is no project, period; the fact that no one steps forward to maintain/improve a given piece of code is generally a pretty good indicator that it's not widely used. > but rather in the Project's policy - delete something which could still > work. This was not the case here. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-stable@FreeBSD.ORG Wed Sep 8 04:38:36 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E28C10656DC for ; Wed, 8 Sep 2010 04:38:36 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id 525448FC08 for ; Wed, 8 Sep 2010 04:38:35 +0000 (UTC) Received: from omta09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by qmta06.emeryville.ca.mail.comcast.net with comcast id 3oub1f0090S2fkCA64ebXU; Wed, 08 Sep 2010 04:38:35 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta09.emeryville.ca.mail.comcast.net with comcast id 44ea1f00b3LrwQ28V4ebgE; Wed, 08 Sep 2010 04:38:35 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 8A71B9B423; Tue, 7 Sep 2010 21:38:34 -0700 (PDT) Date: Tue, 7 Sep 2010 21:38:34 -0700 From: Jeremy Chadwick To: Pyun YongHyeon Message-ID: <20100908043834.GA27124@icarus.home.lan> References: <20100907210813.GI49065@martini.nu> <20100907222403.GA18595@icarus.home.lan> <20100907233257.GA94092@martini.nu> <20100908002917.GO1439@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100908002917.GO1439@michelle.cdnetworks.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Network memory allocation failures X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 04:38:36 -0000 On Tue, Sep 07, 2010 at 05:29:17PM -0700, Pyun YongHyeon wrote: > On Tue, Sep 07, 2010 at 04:32:57PM -0700, Mahlon E. Smith wrote: > > On Tue, Sep 07, 2010, Jeremy Chadwick wrote: > > > > > > This could be a bce(4) bug, meaning the "failed to allocate memory" > > > message could be indicating DMA failure or something else from the card, > > > and not necessarily related to mbufs. > > > > > > There are also changes/fixes to bce(4) that are in RELENG_8 (8.1-STABLE) > > > that aren't in 8.1-RELEASE, but I don't know if those are responsible > > > for your problem. > > > > Hmm, well -- I'm definitely not opposed to jumping to -STABLE if it > > might fix it. > > > > > > > Please provide output from the following: > > > > > > * uname -a (if desired, XXX out hostname) > > > > FreeBSD jessage 8.1-RELEASE FreeBSD 8.1-RELEASE #2: Fri Aug 20 14:30:31 PDT 2010 root@jessage:/usr/src/sys/amd64/compile/R810 amd64 > > > > Custom kernel, with additions to GENERIC (nothing removed): > > > > device carp > > device snp > > options HZ=1000 > > options DEVICE_POLLING > > bce(4) does not support polling(4) so you can completely remove > configuration of HZ and DEVICE_POLLING. In fact, there is no reason > to use polling(4) at all on intelligent controllers like bce(4). > polling(4) is mainly for dumb controllers that lack efficient > interrupt moderation. > > > options ALTQ > > options ALTQ_CBQ > > options ALTQ_PRIQ > > options SC_DISABLE_REBOOT > > options PANIC_REBOOT_WAIT_TIME=5 > > > > ALTQ and friends not actually active on the machine. I was fighting a > > different battle when running GENERIC, so I can't honestly recall if this > > problem existed then -- I'll make sure it is still happening under > > GENERIC for a baseline, to eliminate any potential weirdness with > > DEVICE_POLLING or the HZ timing. > > > > > > > * vmstat -i > > > > interrupt total rate > > irq19: ehci0 1547103 0 > > irq21: uhci1 uhci3+ 29 0 > > irq23: atapci0 35 0 > > irq32: mfi0 68104468 43 > > cpu0: timer 3093305346 1986 > > irq256: bce0 46587008 29 > > cpu19: timer 3103614834 1992 > > cpu1: timer 3093298527 1986 > > cpu4: timer 3093297557 1986 > > cpu10: timer 3089824707 1983 > > cpu12: timer 3097896788 1989 > > cpu16: timer 3097897232 1989 > > cpu22: timer 3103615267 1992 > > cpu2: timer 3093297601 1986 > > cpu5: timer 3093298349 1986 > > cpu3: timer 3093298637 1986 > > cpu6: timer 3089823402 1983 > > cpu18: timer 3103614571 1992 > > cpu13: timer 3097897961 1989 > > cpu20: timer 3103615299 1992 > > cpu23: timer 3103614783 1992 > > cpu9: timer 3089821582 1983 > > cpu17: timer 3097898138 1989 > > cpu11: timer 3089821712 1983 > > cpu14: timer 3097897190 1989 > > cpu7: timer 3089821360 1983 > > cpu21: timer 3103615012 1992 > > cpu15: timer 3097898081 1989 > > cpu8: timer 3089824487 1983 > > Total 74424047066 47788 > > > > > > > * ifconfig -a (if desired, XXX out IPs and MACs) > > > > bce0: flags=8943 metric 0 mtu 1500 > > options=c01bb > > ether 00:25:64:fd:0b:24 > > inet 10.5.2.69 netmask 0xfffffc00 broadcast 10.5.3.255 > > media: Ethernet autoselect (1000baseT ) > > status: active > > bce1: flags=8802 metric 0 mtu 1500 > > options=c01bb > > ether 00:25:64:fd:0b:26 > > media: Ethernet autoselect (none) > > status: no carrier > > bce2: flags=8802 metric 0 mtu 1500 > > options=c01bb > > ether 00:25:64:fd:0b:28 > > media: Ethernet autoselect (none) > > status: no carrier > > bce3: flags=8802 metric 0 mtu 1500 > > options=c01bb > > ether 00:25:64:fd:0b:2a > > media: Ethernet autoselect (none) > > status: no carrier > > lo0: flags=8049 metric 0 mtu 16384 > > options=3 > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 > > inet6 ::1 prefixlen 128 > > inet 127.0.0.1 netmask 0xff000000 > > nd6 options=3 > > vboxnet0: flags=8802 metric 0 mtu 1500 > > ether 0a:00:27:00:00:00 > > > > > > > * netstat -inbd (if desired, XXX out MACs) > > > > Name Mtu Network Address Ipkts Ierrs Idrop Ibytes Opkts Oerrs Obytes Coll Drop > > bce0 1500 00:25:64:fd:0b:24 14467627 0 0 6346549588 11846499 0 4646920777 0 0 > > bce0 1500 10.5.0.0/22 10.5.2.69 1987644 - - 371635478 415087 - 74168123 - - > > bce1* 1500 00:25:64:fd:0b:26 0 0 0 0 0 0 0 0 0 > > bce2* 1500 00:25:64:fd:0b:28 0 0 0 0 0 0 0 0 0 > > bce3* 1500 00:25:64:fd:0b:2a 0 0 0 0 0 0 0 0 0 > > lo0 16384 25561 0 0 47338756 25561 0 47338756 0 0 > > lo0 16384 fe80:5::1/64 fe80:5::1 0 - - 0 0 - 0 - - > > lo0 16384 ::1/128 ::1 0 - - 0 0 - 0 - - > > lo0 16384 127.0.0.0/8 127.0.0.1 25561 - - 47338756 25561 - 47338756 - - > > vboxn 1500 0a:00:27:00:00:00 0 0 0 0 0 0 0 0 0 > > > > > > > > > * pciconf -lvc (only the bceX entry please) > > > > bce0@pci0:1:0:0: class=0x020000 card=0x02d41028 chip=0x163914e4 rev=0x20 hdr=0x00 > > vendor = 'Broadcom Corporation' > > device = 'NetXtreme II Gigabit Ethernet (BCM5709)' > > class = network > > subclass = ethernet > > cap 01[48] = powerspec 3 supports D0 D3 current D0 > > cap 03[50] = VPD > > cap 05[58] = MSI supports 16 messages, 64 bit enabled with 1 message > > cap 11[a0] = MSI-X supports 9 messages in map 0x10 > > cap 10[ac] = PCI-Express 2 endpoint max data 256(512) link x2(x4) > > > > > > > Also check dmesg to see if there's any error messages that correlate > > > when the problem occurs. > > > > All quiet on that front. > > > > Based on your outputs, I don't see abnormal things in bce(4). > Why do you think bce(4) is the cause of problem? > You may see more detailed MAC statistics if controller saw some > kind of memory related failure from the output of > "sysctl dev.bce.0". I figured there might memory exhaustion of sorts, possibly in the bce(4) driver itself, that could cause the OP's problem. bce(4) might not be the problem at all. But the OP's issue seems to only occur when transmitting data, not receiving: http://lists.freebsd.org/pipermail/freebsd-stable/2010-September/058708.html The 2nd-to-last paragraph there is worth noting, specifically how limiting maximum addressable memory to 32GB via loader.conf seems to work around the issue. There were other problems with the systems in question back in July, it seems. I assume these got hammered out somehow: http://www.mail-archive.com/freebsd-stable@freebsd.org/msg111408.html -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Sep 8 05:19:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92AC510656C8 for ; Wed, 8 Sep 2010 05:19:43 +0000 (UTC) (envelope-from vwe@freebsd.org) Received: from Mail.elbekies.net (mail.elbekies.net [217.6.211.146]) by mx1.freebsd.org (Postfix) with ESMTP id 010048FC24 for ; Wed, 8 Sep 2010 05:19:42 +0000 (UTC) Received: from bel.soho.vwsoft.com (p57A0D9BA.dip.t-dialin.net [87.160.217.186]) by Mail.elbekies.net (Postfix) with ESMTPA id 7C9F82E037; Wed, 8 Sep 2010 07:02:16 +0200 (CEST) Received: from [192.168.16.4] (dardanos.sz.vwsoft.com [192.168.16.4]) by bel.soho.vwsoft.com (Postfix) with ESMTP id 0C83533C7F; Wed, 8 Sep 2010 07:00:16 +0200 (CEST) Message-ID: <4C8718C3.3000804@freebsd.org> Date: Wed, 08 Sep 2010 07:01:55 +0200 From: vwe@freebsd.org User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.11) Gecko/20100811 Thunderbird/3.0.6 MIME-Version: 1.0 To: Vadim Goncharov References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <201009011902.06538.hselasky@c2i.net> <4C8627A6.1090308@icyb.net.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-VWSoft-MailScanner: Found to be clean X-MailScanner-ID: 7C9F82E037.A61E2 X-Elbekies-MailScanner: Found to be clean X-MailScanner-From: vwe@freebsd.org MailScanner-NULL-Check: 1284526936.86431@nzEhMBqknOrbVoaB7yJVzw Cc: freebsd-stable@freebsd.org Subject: Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 05:19:43 -0000 [removed security@ which is not nearly related to topic] On 09/07/10 23:31, Vadim Goncharov wrote: > 07.09.10 @ 18:53 Andriy Gapon wrote: >> The reason is performance for overall network stack, not ideology. > > For a practical reasons, "it works but slow" is better than > "doesn't work at all (due to absence of code in the src tree)". > > "Make it work. Make it right. Make it fast. In that order", know this? > Sacrificing "work" for "fast"?.. Hmm, if it is not ideology, then what > is it?.. > >> BTW, there were advanced notices for users, request for volunteers, etc. >> >> So, if you didn't speak up at that time please keep silence now :-) > > You do not understand the problem. It is not in notices & volunteers, > but rather in the Project's policy - delete something which could still > work. Personally, I don't use ISDN, so didn't said anything that time, > but now, there are more precedents of removing components from FreeBSD - > so, for now, I must say that this policy is harmful. Though I doubt that > one man's opinion could change Project's policy until it's too late... > Vadim, it (i4b) worked, nobody was maintaining it, nobody opted to maintain it, everybody was asked to maintain it, nobody wanted, everybody has been asked to speak up if the code will be axed out, nobody spoke up, it has been axed out ... 13 months ago and even then nobody complained about. Are _you_ willing to maintain it? From owner-freebsd-stable@FreeBSD.ORG Wed Sep 8 05:53:07 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0101010656AD; Wed, 8 Sep 2010 05:53:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id AEB158FC12; Wed, 8 Sep 2010 05:53:06 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o885r5tk096317; Wed, 8 Sep 2010 01:53:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o885r5bc096316; Wed, 8 Sep 2010 05:53:05 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 8 Sep 2010 05:53:05 GMT Message-Id: <201009080553.o885r5bc096316@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 05:53:07 -0000 TB --- 2010-09-08 05:46:32 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-08 05:46:32 - starting RELENG_8 tinderbox run for amd64/amd64 TB --- 2010-09-08 05:46:32 - cleaning the object tree TB --- 2010-09-08 05:47:43 - cvsupping the source tree TB --- 2010-09-08 05:47:43 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup18.freebsd.org /tinderbox/RELENG_8/amd64/amd64/supfile TB --- 2010-09-08 05:53:05 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-08 05:53:05 - ERROR: unable to cvsup the source tree TB --- 2010-09-08 05:53:05 - 2.20 user 45.20 system 393.43 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Wed Sep 8 07:48:30 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0477010656D7 for ; Wed, 8 Sep 2010 07:48:30 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id DD8798FC1E for ; Wed, 8 Sep 2010 07:48:29 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 3D3DF569A3; Wed, 8 Sep 2010 07:30:19 +0000 (UTC) Date: Wed, 8 Sep 2010 07:30:19 +0000 From: Mark Linimon To: vadim_nuclight@mail.ru Message-ID: <20100908073019.GA16493@lonesome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@FreeBSD.org Subject: Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 07:48:30 -0000 > > The reason is performance for overall network stack, not ideology. > For a practical reasons, "it works but slow" is better than > "doesn't work at all (due to absence of code in the src tree)". > "Make it work. Make it right. Make it fast. In that order", know this? > Sacrificing "work" for "fast"?.. Hmm, if it is not ideology, then what is > it?.. It wasn't "it works but slow". It was "it works, but networking throughput is limited on the modern hardware that the majority of our users employ". In particular, IIUC, 10GB network drivers were suffering under the old strategy. We simply were not competitive with other OSes, and we have many multiples more users interested in 10GBE than in ISDN. > You do not understand the problem. It is not in notices & volunteers, but > rather in the Project's policy - delete something which could still work. You do not understand how this was handled. The situation was: an announcement was made that "in X months, all network drivers need to be made to run Giant-free so that FreeBSD can drop Giant from the neworking stack to move forward." Within that period, most of the drivers were updated. Repeated postings were made to the mailing list that "the following drivers still have not been converted, and need to be updated or they will be dropped." They weren't; they were droppped. So while it could "still" work, it was slowing down progress. The fact of the matter is, FreeBSD is a big project with a finite number of developers. We try to keep as much coverage of systems as we can, but a reality of any large software engineering project is that older features sometimes have to be dropped to make progress. The code still exists in the repository for any interested party to pick up and modernize. mcl From owner-freebsd-stable@FreeBSD.ORG Wed Sep 8 08:58:58 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B971C10656D2 for ; Wed, 8 Sep 2010 08:58:58 +0000 (UTC) (envelope-from lordcow@lordcow.org) Received: from lordcow.org (lordcow.org [41.203.5.188]) by mx1.freebsd.org (Postfix) with ESMTP id DA17C8FC0A for ; Wed, 8 Sep 2010 08:58:57 +0000 (UTC) Received: from lordcow.org (localhost [127.0.0.1]) by lordcow.org (8.14.4/8.14.4) with ESMTP id o888Y7VM072507 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Wed, 8 Sep 2010 10:34:07 +0200 (SAST) (envelope-from lordcow@lordcow.org) Received: (from lordcow@localhost) by lordcow.org (8.14.4/8.14.4/Submit) id o888Y1aV072505 for stable@freebsd.org; Wed, 8 Sep 2010 10:34:01 +0200 (SAST) (envelope-from lordcow) Date: Wed, 8 Sep 2010 10:34:01 +0200 From: Gareth de Vaux To: stable@freebsd.org Message-ID: <20100908083401.GA68797@lordcow.org> References: <20100906155350.GA50151@lordcow.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lordcow.org Cc: Subject: Re: MSIX failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 08:58:58 -0000 On Tue 2010-09-07 (10:00), Jack Vogel wrote: > First off, this device was not supported in 8.0 REL, what were you running > that last worked? Hey, I was running 8.0 REL and it worked. I installed the system from the 8.0 .iso, but the onboard card didn't work. I added the PCI card and it worked. > Do you have MSI disabled on this system of yours, the reason for this message > is that both MSIX and MSI setup failed, your device should succeed with MSI. I didn't do anything to disable it I think. $ sysctl -a | grep msi hw.bce.msi_enable: 1 hw.pci.honor_msi_blacklist: 1 hw.pci.enable_msix: 1 hw.pci.enable_msi: 1 From owner-freebsd-stable@FreeBSD.ORG Wed Sep 8 09:41:05 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D5AB10656CC for ; Wed, 8 Sep 2010 09:41:05 +0000 (UTC) (envelope-from bsd@lordcow.org) Received: from lordcow.org (lordcow.org [41.203.5.188]) by mx1.freebsd.org (Postfix) with ESMTP id A482D8FC18 for ; Wed, 8 Sep 2010 09:41:04 +0000 (UTC) Received: from lordcow.org (localhost [127.0.0.1]) by lordcow.org (8.14.4/8.14.4) with ESMTP id o889eute075636 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Wed, 8 Sep 2010 11:40:56 +0200 (SAST) (envelope-from lordcow@lordcow.org) Received: (from lordcow@localhost) by lordcow.org (8.14.4/8.14.4/Submit) id o889epRG075635 for stable@freebsd.org; Wed, 8 Sep 2010 11:40:51 +0200 (SAST) (envelope-from lordcow) Date: Wed, 8 Sep 2010 11:40:50 +0200 From: Gareth de Vaux To: stable@freebsd.org Message-ID: <20100908094050.GA73841@lordcow.org> References: <20100906155350.GA50151@lordcow.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lordcow.org Cc: Subject: Re: MSIX failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 09:41:05 -0000 On Tue 2010-09-07 (13:25), Jack Vogel wrote: > I've looked at the code, this message was misleading, what really happens > is that the driver fails to be able to setup either MSIX OR MSI, when this > happens it will fall back and use a Legacy interrupt, so its non-fatal and > the device should work anyway. > > The only real reason you should see this is a) you used sysctl and turned > msi and msix off, or b) a real hardware problem in the chipset has caused > the failure. All devices em drives (as opposed to lem) are PCI Express and > so by definition they have MSI and MSIX available. Ok I think I got my cards mixed up - in my original mail em1 is the PCI card and em0 is the onboard, sorry. I guessed the numbering may not have been as expected while trying to fix the issue, but I might not have fully tested this at the time. So here's the situation after looking through older kernel logs: I installed 8.0-RELEASE, the onboard card didn't work - the kernel didn't even pick it up, and ifconfig only showed the lo0 device. I added the PCI Intel(R) PRO/1000 GT card (Gigabit Ethernet Controller (Copper) rev 5 (82541PI)) - this worked and came up as em0. Last week I moved to -STABLE, GENERIC kernel. The kernel now detects both cards, with the kernel messages in my original mail. Whether either works I'm not completely sure, I'll need to get to the machine physically and switch cables/cards/configurations first. I didn't turn off msi/msix with sysctl (except when debugging in my original mail). From owner-freebsd-stable@FreeBSD.ORG Wed Sep 8 10:10:16 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5C731065672 for ; Wed, 8 Sep 2010 10:10:16 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 33A068FC1B for ; Wed, 8 Sep 2010 10:10:15 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OtHbY-0007xX-OC for freebsd-stable@freebsd.org; Wed, 08 Sep 2010 12:10:12 +0200 Received: from nuclight.avtf.net ([217.29.94.29]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Sep 2010 12:10:12 +0200 Received: from vadim_nuclight by nuclight.avtf.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Sep 2010 12:10:12 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Vadim Goncharov Date: Wed, 8 Sep 2010 10:09:57 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 79 Message-ID: References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <201009011902.06538.hselasky@c2i.net> <4C8627A6.1090308@icyb.net.ua> <4C8718C3.3000804@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: nuclight.avtf.net X-Comment-To: vwe@freebsd.org User-Agent: slrn/0.9.9p1 (FreeBSD) Subject: Policy for removing working code (Was: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 10:10:16 -0000 Hi vwe@freebsd.org! On Wed, 08 Sep 2010 07:01:55 +0200; vwe@freebsd.org wrote about 'Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon': > On 09/07/10 23:31, Vadim Goncharov wrote: >> 07.09.10 @ 18:53 Andriy Gapon wrote: >>> The reason is performance for overall network stack, not ideology. >> >> For a practical reasons, "it works but slow" is better than >> "doesn't work at all (due to absence of code in the src tree)". >> >> "Make it work. Make it right. Make it fast. In that order", know this? >> Sacrificing "work" for "fast"?.. Hmm, if it is not ideology, then what >> is it?.. >> >>> BTW, there were advanced notices for users, request for volunteers, etc. >>> >>> So, if you didn't speak up at that time please keep silence now :-) >> >> You do not understand the problem. It is not in notices & volunteers, >> but rather in the Project's policy - delete something which could still >> work. Personally, I don't use ISDN, so didn't said anything that time, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> but now, there are more precedents of removing components from FreeBSD - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> so, for now, I must say that this policy is harmful. Though I doubt that >> one man's opinion could change Project's policy until it's too late... >> > Are _you_ willing to maintain it? Have you read carefuly? I don't use ISDN (and so won't maintain), but I consider this policy, as time goes by, could touch subsystems which now I will be interested in. Precedents that already happened, to give an idea, include (but not limited to) e.g. window(1) and pppd(8). > it (i4b) worked, nobody was maintaining it, nobody opted to maintain it, > everybody was asked to maintain it, nobody wanted, everybody has been > asked to speak up if the code will be axed out, nobody spoke up, it has > been axed out ... 13 months ago and even then nobody complained about. Hey, _everybody_ was asked? And nobody complained? But this is simply not true. So then why someone complains now? Answer is simple: because it wasn't everybody. Let's go to gmane and look to archives of announce@ for past 8 years. Exclude release and security announcements. Exclude conferences announcements. Exclude finance-related Foundation announcements and other DVD-like stuff. Then you left with actual Project info. Exclude announcements about new projects and status reports, as they tell about new fetutures only. What is left after? Not glamourous marketing but real info about events that could harm production systems: Mark Murray Perl5 is leaving the base system for 5.0 and after! 15 May 02 Kris Kennaway Ports scheduled for removal on Feb 2 03 Nov 03 Kris Kennaway Ports scheduled for removal in March and April 25 Feb 04 Kris Kennaway Ports scheduled for removal on August 20 22 Jun 04 Joe Marcus Clarke Updating guidelines for ports 13 Oct 04 Kris Kennaway Ports scheduled for removal 30 Jul 05 Kris Kennaway Volunteers needed to help maintain ports 25 May 06 Ken Smith Upcoming change in Daylight Savings Time 25 Feb 07 Kris Kennaway HEADS UP: xorg 7.2 update in progress 19 May 07 Doug Barton BIND 8 is EOL as of 27 August 2008 (fwd) 28 Aug 07 Joe Marcus Clarke HEADS UP: Ports support for 5.X is no more 02 Jun 08 Peter Wemm FreeBSD.org begins switch to Subversion 04 Jun 08 Only 12 letters for 8 years! And we see that _earlier_ Project actully did such announcements - individual ports could be viewed analogous to individual base system subsystems like ISDN or window, etc. Only 4 years ago. And these days Project began to turn to some another policy with not-so-good smell. Surely this is not coincidence. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-stable@FreeBSD.ORG Wed Sep 8 10:24:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85CBF106564A for ; Wed, 8 Sep 2010 10:24:24 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 0CDB08FC1A for ; Wed, 8 Sep 2010 10:24:23 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OtHpE-0006Sx-U5 for freebsd-stable@freebsd.org; Wed, 08 Sep 2010 12:24:20 +0200 Received: from nuclight.avtf.net ([217.29.94.29]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Sep 2010 12:24:20 +0200 Received: from vadim_nuclight by nuclight.avtf.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Sep 2010 12:24:20 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Vadim Goncharov Date: Wed, 8 Sep 2010 10:24:11 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 68 Message-ID: References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <201009011902.06538.hselasky@c2i.net> <4C8627A6.1090308@icyb.net.ua> <4C8704E3.5000408@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: nuclight.avtf.net X-Comment-To: Doug Barton User-Agent: slrn/0.9.9p1 (FreeBSD) Cc: freebsd-security@freebsd.org Subject: Policy for removing working code (Was: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 10:24:24 -0000 Hi Doug Barton! On Tue, 07 Sep 2010 20:37:07 -0700; Doug Barton wrote about 'Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon': > On 09/07/2010 02:31 PM, Vadim Goncharov wrote: >> 07.09.10 @ 18:53 Andriy Gapon wrote: >> >>> on 07/09/2010 13:38 Vadim Goncharov said the following: >>>>> Just to clarify things a little for those following it: >>>>> the original I4B code was removed >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (1) >>>>> for entirely practical reasons: it couldn't run without the Giant >>>>> lock, and support for the Giant lock over the network stack was >>>>> removed. >>>> >>>> But if it was used, removing a component just because of Giant lock >>>> is not >>>> practical and is purely ideologic, isn't it? >>> >>> Which part of "support for the Giant lock *over the network stack* was >>> removed" >>> [emphasis mine] do you not understand? >> >> No, component removed was (1), I've underlined. >> >>> The reason is performance for overall network stack, not ideology. >> >> For a practical reasons, "it works but slow" is better than >> "doesn't work at all (due to absence of code in the src tree)". > > I think you are misunderstanding the situation. It wasn't a case of, "It > works but it's slow." The situation was that in order to take > performance of the network stack as a whole up to the next level it was > necessary to remove the Giant lock. But definitely this IS that situation: "network stack with I4B/Giant works but it's slow" - you see, "It" = "stack w/ I4B". > Because the original I4B code didn't > work without the Giant lock, and because no one stepped forward to fix > that, the code had to be removed. No. The code needn't removal, the stack should be modified to be fast without I4B and slow for those who wish to compile it with I4B anf Giant. Then slowness is their problem, not of the Project. >>> BTW, there were advanced notices for users, request for volunteers, etc. >>> >>> So, if you didn't speak up at that time please keep silence now :-) >> >> You do not understand the problem. It is not in notices & volunteers, > > In this case it was 100% about the latter. In addition to the fact that > without volunteers there is no project, period; the fact that no one > steps forward to maintain/improve a given piece of code is generally a No, I've just described to vwe@ that there were no proper notices so wherefrom volunteers will appear?.. > pretty good indicator that it's not widely used. If code isn't widely used that is still not the reason to axe it out. If it is almost not used - then may be. Also, how widely it is used may be easily underestimated due to lack of announcements and surveys. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-stable@FreeBSD.ORG Wed Sep 8 10:44:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B324710656D5 for ; Wed, 8 Sep 2010 10:44:58 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 0E2188FC0A for ; Wed, 8 Sep 2010 10:44:57 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OtI97-0001lQ-4J for freebsd-stable@freebsd.org; Wed, 08 Sep 2010 12:44:53 +0200 Received: from nuclight.avtf.net ([217.29.94.29]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Sep 2010 12:44:53 +0200 Received: from vadim_nuclight by nuclight.avtf.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Sep 2010 12:44:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Vadim Goncharov Date: Wed, 8 Sep 2010 10:44:42 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 63 Message-ID: References: <20100908073019.GA16493@lonesome.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: nuclight.avtf.net X-Comment-To: Mark Linimon User-Agent: slrn/0.9.9p1 (FreeBSD) Subject: Policy for removing working code (Was: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 10:44:58 -0000 Hi Mark Linimon! On Wed, 8 Sep 2010 07:30:19 +0000; Mark Linimon wrote about 'Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon': >>> The reason is performance for overall network stack, not ideology. >> For a practical reasons, "it works but slow" is better than >> "doesn't work at all (due to absence of code in the src tree)". >> "Make it work. Make it right. Make it fast. In that order", know this? >> Sacrificing "work" for "fast"?.. Hmm, if it is not ideology, then what is >> it?.. > > It wasn't "it works but slow". It was "it works, but networking throughput > is limited on the modern hardware that the majority of our users employ". > In particular, IIUC, 10GB network drivers were suffering under the old > strategy. We simply were not competitive with other OSes, and we have > many multiples more users interested in 10GBE than in ISDN. I understand that we need to support modern fast hardware but that doesn't mean we should drop working features for that. And... >> You do not understand the problem. It is not in notices & volunteers, but >> rather in the Project's policy - delete something which could still work. > > You do not understand how this was handled. ...and how this is handled in other OSes to which we have compete, er? They all also do dropping features to frighten away old users? Are there no alternative ways to handle? Put network Giant code into bunch of #ifdef's, after all. > The situation was: an announcement was made that "in X months, all network > drivers need to be made to run Giant-free so that FreeBSD can drop Giant > from the neworking stack to move forward." Within that period, most of > the drivers were updated. Repeated postings were made to the mailing list > that "the following drivers still have not been converted, and need to be > updated or they will be dropped." They weren't; they were droppped. No. See my answer to vwe@ that there were no proper announcements. With them, for example, someone could get sponsored to update these drivers which were needed by those FreeBSD users who can't maintain code themselves. That's a last resort, more likely volunteers will come, but you get the idea. > So while it could "still" work, it was slowing down progress. If it is not ideology, then what is it?.. > The fact of the matter is, FreeBSD is a big project with a finite number > of developers. We try to keep as much coverage of systems as we can, but > a reality of any large software engineering project is that older features > sometimes have to be dropped to make progress. >From time to time such critical cases could possibly be handled by another ways, I've mentioned one possible above. > The code still exists in the repository for any interested party to pick > up and modernize. I hope that for this particular case alternative from ports will be enough. But policy is not tied to one particular case, alas. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-stable@FreeBSD.ORG Wed Sep 8 12:38:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1ACEE10656EE for ; Wed, 8 Sep 2010 12:38:50 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:140::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7EEDB8FC0C for ; Wed, 8 Sep 2010 12:38:49 +0000 (UTC) Received: from [10.0.0.10] (phenom.otrada.od.ua [10.0.0.10]) (authenticated bits=0) by otrada.od.ua (8.14.3/8.14.3) with ESMTP id o88Ccj4O095710 for ; Wed, 8 Sep 2010 15:38:45 +0300 (EEST) (envelope-from universite@ukr.net) X-Authentication-Warning: otrada.od.ua: Host phenom.otrada.od.ua [10.0.0.10] claimed to be [10.0.0.10] Message-ID: <4C8783D0.7040902@ukr.net> Date: Wed, 08 Sep 2010 15:38:40 +0300 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20100907210813.GI49065@martini.nu> <20100907222403.GA18595@icarus.home.lan> In-Reply-To: <20100907222403.GA18595@icarus.home.lan> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.7 required=5.0 tests=ALL_TRUSTED,AWL autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mary-teresa.otrada.od.ua X-Virus-Scanned: clamav-milter 0.95.3 at mary-teresa.otrada.od.ua X-Virus-Status: Clean Subject: Re: Network memory allocation failures X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 12:38:50 -0000 Please provide output from the following: netstat -m /etc/sysctl.conf 08.09.2010 1:24, Jeremy Chadwick wrote: > Please provide output from the following: > > * uname -a (if desired, XXX out hostname) > * vmstat -i > * ifconfig -a (if desired, XXX out IPs and MACs) > * netstat -inbd (if desired, XXX out MACs) > * pciconf -lvc (only the bceX entry please) > > Also check dmesg to see if there's any error messages that correlate > when the problem occurs. > > I'm also CC'ing Yong-Hyeon PYUN who might have some ideas. > From owner-freebsd-stable@FreeBSD.ORG Wed Sep 8 12:42:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A0D210656E1; Wed, 8 Sep 2010 12:42:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id EB82B8FC1F; Wed, 8 Sep 2010 12:42:36 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 902E646B8E; Wed, 8 Sep 2010 08:42:36 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A06AD8A050; Wed, 8 Sep 2010 08:42:34 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org, vadim_nuclight@mail.ru Date: Wed, 8 Sep 2010 08:42:28 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <4C8704E3.5000408@FreeBSD.org> In-Reply-To: MIME-Version: 1.0 Message-Id: <201009080842.28495.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 08 Sep 2010 08:42:35 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-security@freebsd.org Subject: Re: Policy for removing working code (Was: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 12:42:37 -0000 On Wednesday, September 08, 2010 6:24:11 am Vadim Goncharov wrote: > > Because the original I4B code didn't > > work without the Giant lock, and because no one stepped forward to fix > > that, the code had to be removed. > > No. The code needn't removal, the stack should be modified to be fast without > I4B and slow for those who wish to compile it with I4B anf Giant. Then slowness > is their problem, not of the Project. No, that would require maintaining two network stacks, not just one. The shims to allow unlocked code to run were not trivial. The choices were this: 1) Moving forward on work to allow the network stack to scale on SMP systems (e.g. modern x86 multi-core servers) and support higher rate protocols such as 10GB, 40GB, and 100GB. 2) Stop all progress on making the network stack scale on SMP. I'm sorry, but 2) just isn't feasible. Not if FreeBSD is to continue to be a modern, relevant system. Also, despite your claims to the contrary, there _was_ adequate notice: http://lists.freebsd.org/pipermail/freebsd-current/2007-June/072977.html This was also documented in the release notes for 7.0: http://www.freebsd.org/releases/7.0R/relnotes.html If you wish to help work on ISDN support, I suggest you offer to test hps@' ISDN stack. hps@ recently became a committer so I think there is a very good chance his code will be brought into the tree. We do have a policy for removing code in that it only gets removed if no one is able to maintain it and/or test patches for it. I locked several of the remaining NIC drivers during the push to remove Giant and a few of them were removed from the system because no one had the hardware around to test the patches to add locking (think of really old ISA NICs that only do 10Mbps). Even in that case, the code will always live on in the source code control repository's history. That means it can always be resurrected if someone shows up who will maintain it and keep it up to date. At this point I think this thread has reached the end of its usefulness. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Sep 8 14:01:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B0D710656F6 for ; Wed, 8 Sep 2010 14:01:33 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id A907A8FC1C for ; Wed, 8 Sep 2010 14:01:32 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OtLDP-0008E0-Tz for freebsd-stable@freebsd.org; Wed, 08 Sep 2010 16:01:31 +0200 Received: from nuclight.avtf.net ([217.29.94.29]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Sep 2010 16:01:31 +0200 Received: from vadim_nuclight by nuclight.avtf.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Sep 2010 16:01:31 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Vadim Goncharov Date: Wed, 8 Sep 2010 14:01:22 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 69 Message-ID: References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <4C8704E3.5000408@FreeBSD.org> <201009080842.28495.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: nuclight.avtf.net X-Comment-To: John Baldwin User-Agent: slrn/0.9.9p1 (FreeBSD) Cc: freebsd-security@freebsd.org Subject: Re: Policy for removing working code X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 14:01:33 -0000 Hi John Baldwin! On Wed, 8 Sep 2010 08:42:28 -0400; John Baldwin wrote about 'Re: Policy for removing working code (Was: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon)': > On Wednesday, September 08, 2010 6:24:11 am Vadim Goncharov wrote: >>> Because the original I4B code didn't >>> work without the Giant lock, and because no one stepped forward to fix >>> that, the code had to be removed. >> >> No. The code needn't removal, the stack should be modified to be fast without >> I4B and slow for those who wish to compile it with I4B anf Giant. Then slowness >> is their problem, not of the Project. > No, that would require maintaining two network stacks, not just one. The > shims to allow unlocked code to run were not trivial. The choices were this: > 1) Moving forward on work to allow the network stack to scale on SMP > systems (e.g. modern x86 multi-core servers) and support higher rate > protocols such as 10GB, 40GB, and 100GB. > 2) Stop all progress on making the network stack scale on SMP. > I'm sorry, but 2) just isn't feasible. Not if FreeBSD is to continue to be a > modern, relevant system. If it is the only variants, then I'll agree (but only on this part). Are there really no other variants? What do other OSes to which, as was said, we have to compete? E.g. Linux? > Also, despite your claims to the contrary, there _was_ adequate notice: > http://lists.freebsd.org/pipermail/freebsd-current/2007-June/072977.html > This was also documented in the release notes for 7.0: > http://www.freebsd.org/releases/7.0R/relnotes.html No, my claims were that there was no _adequate_ notice, and this links acknowledge this. 7.0 Release notes state about broken ISDN as an already happened fact, user can't do anything about it already. As I've shown in message to vwe@, it wasn't in announce@ and even in stable@. Number of users/subscribers of lists can be expressed as: # devel lists < # current@ < # stable@ < # announce@ < # of total FreeBSD users While we can't do anything with those who not subscribed even to announce@ (though should it be duplicated on www may be?), number of announce@ readers is still MUCH more than that of current@, not even mention devel lists. > If you wish to help work on ISDN support, I suggest you offer to test hps@' > ISDN stack. hps@ recently became a committer so I think there is a very good > chance his code will be brought into the tree. > We do have a policy for removing code in that it only gets removed if no one > is able to maintain it and/or test patches for it. I locked several of the > remaining NIC drivers during the push to remove Giant and a few of them were > removed from the system because no one had the hardware around to test the > patches to add locking (think of really old ISA NICs that only do 10Mbps). Big thanks for your work, but unfortunately, the problem itself is not ISDN or network stack, it is deeper. It is the policy or may be style of thought, discourse. Something like: progress dictates we need fix/maintainership to feature X & we have no resources to maintain feature X -> we announce theis need, but only to _limited_ audience, not wide circles -> nobody responds -> the X code is removed AND we think this logic chain is correct, thought we did not things this way even 5 years ago. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-stable@FreeBSD.ORG Wed Sep 8 14:13:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAF1D1065744 for ; Wed, 8 Sep 2010 14:13:32 +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 012A88FC1C for ; Wed, 8 Sep 2010 14:13:31 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA14679; Wed, 08 Sep 2010 17:13:29 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4C879A09.9080804@icyb.net.ua> Date: Wed, 08 Sep 2010 17:13:29 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100823 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: vadim_nuclight@mail.ru References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <4C8704E3.5000408@FreeBSD.org> <201009080842.28495.jhb@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Policy for removing working code X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 14:13:32 -0000 on 08/09/2010 17:01 Vadim Goncharov said the following: > Big thanks for your work, but unfortunately, the problem itself is not ISDN or > network stack, it is deeper. It is the policy or may be style of thought, > discourse. Something like: > progress dictates we need fix/maintainership to feature X > & we have no resources to maintain feature X > -> we announce theis need, but only to _limited_ audience, not wide circles > -> nobody responds > -> the X code is removed > AND we think this logic chain is correct, thought we did not things this way > even 5 years ago. So, get to work, become a committer, get elected to core and have a control over these procedures. [And maybe your perspectives will change along the way] Until then, please, let's stop wasting time on this issue. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Sep 8 14:22:00 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED39910656AA for ; Wed, 8 Sep 2010 14:22:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BA84B8FC16 for ; Wed, 8 Sep 2010 14:22:00 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 597E246BC0; Wed, 8 Sep 2010 10:22:00 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7E2F48A04F; Wed, 8 Sep 2010 10:21:59 -0400 (EDT) From: John Baldwin To: vadim_nuclight@mail.ru Date: Wed, 8 Sep 2010 10:21:47 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <201009080842.28495.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009081021.48077.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 08 Sep 2010 10:21:59 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: stable@freebsd.org Subject: Re: Policy for removing working code X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 14:22:01 -0000 [ Trimming cc's a bit ] On Wednesday, September 08, 2010 10:01:22 am Vadim Goncharov wrote: > Hi John Baldwin! > > On Wed, 8 Sep 2010 08:42:28 -0400; John Baldwin wrote about 'Re: Policy for removing working code (Was: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon)': > > > On Wednesday, September 08, 2010 6:24:11 am Vadim Goncharov wrote: > >>> Because the original I4B code didn't > >>> work without the Giant lock, and because no one stepped forward to fix > >>> that, the code had to be removed. > >> > >> No. The code needn't removal, the stack should be modified to be fast without > >> I4B and slow for those who wish to compile it with I4B anf Giant. Then slowness > >> is their problem, not of the Project. > > > No, that would require maintaining two network stacks, not just one. The > > shims to allow unlocked code to run were not trivial. The choices were this: > > > 1) Moving forward on work to allow the network stack to scale on SMP > > systems (e.g. modern x86 multi-core servers) and support higher rate > > protocols such as 10GB, 40GB, and 100GB. > > > 2) Stop all progress on making the network stack scale on SMP. > > > I'm sorry, but 2) just isn't feasible. Not if FreeBSD is to continue to be a > > modern, relevant system. > > If it is the only variants, then I'll agree (but only on this part). Are there > really no other variants? What do other OSes to which, as was said, we have to > compete? E.g. Linux? Yes, other OS's (Windows, Linux, Solaris) all are working on the multi-core problem. OS's that aren't working on this will soon be obsolete. Even modern embedded systems are multi-core (e.g. many MIPs chips now include multiple cores on a chip, even SMT similar to Intel's HyperThreading on RMI's MIPs SOCs). > > Also, despite your claims to the contrary, there _was_ adequate notice: > > http://lists.freebsd.org/pipermail/freebsd-current/2007-June/072977.html > > This was also documented in the release notes for 7.0: > > http://www.freebsd.org/releases/7.0R/relnotes.html > > No, my claims were that there was no _adequate_ notice, and this links > acknowledge this. 7.0 Release notes state about broken ISDN as an already > happened fact, user can't do anything about it already. As I've shown in > message to vwe@, it wasn't in announce@ and even in stable@. Number of > users/subscribers of lists can be expressed as: > > # devel lists < # current@ < # stable@ < # announce@ < # of total FreeBSD users > > While we can't do anything with those who not subscribed even to announce@ > (though should it be duplicated on www may be?), number of announce@ readers > is still MUCH more than that of current@, not even mention devel lists. We can't e-mail announce@ every time something is going to be removed. That would be way too much spam for that list. I do think stable@ is a good place to e-mail, and I did in fact mail my locking patches for the various NIC drivers to stable@. In some cases I did only find testers via stable@ and not via current@. I do think that the general rule is that stable@ should be on the list. It is true that that did not happen in this case (and probably should have), but it does happen in the typical case. I would chalk this up to a one-time slip-up, not a systemic problem. > > If you wish to help work on ISDN support, I suggest you offer to test hps@' > > ISDN stack. hps@ recently became a committer so I think there is a very good > > chance his code will be brought into the tree. > > We do have a policy for removing code in that it only gets removed if no one > > is able to maintain it and/or test patches for it. I locked several of the > > remaining NIC drivers during the push to remove Giant and a few of them were > > removed from the system because no one had the hardware around to test the > > patches to add locking (think of really old ISA NICs that only do 10Mbps). > > Big thanks for your work, but unfortunately, the problem itself is not ISDN or > network stack, it is deeper. It is the policy or may be style of thought, > discourse. Something like: > progress dictates we need fix/maintainership to feature X > & we have no resources to maintain feature X > -> we announce theis need, but only to _limited_ audience, not wide circles > -> nobody responds > -> the X code is removed > AND we think this logic chain is correct, thought we did not things this way > even 5 years ago. Actually, things have worked this way far longer than 5 years ago. For example, we lost a few SCSI HBA drivers during the transition to CAM (e.g. wds(4) was not present in 4.x but was eventually CAM-ified and reappeared in 5.0). I suspect there was far less notice given for those drivers than for ISDN (multiple notices to arch@ and current@ spread out across many months). -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Sep 8 14:34:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBBB71065694 for ; Wed, 8 Sep 2010 14:34:45 +0000 (UTC) (envelope-from mahlon@martini.nu) Received: from martini.nu (martini.nu [198.145.180.83]) by mx1.freebsd.org (Postfix) with SMTP id A96C08FC08 for ; Wed, 8 Sep 2010 14:34:45 +0000 (UTC) Received: (qmail 55879 invoked by uid 1000); 8 Sep 2010 14:34:45 -0000 Date: Wed, 8 Sep 2010 07:34:44 -0700 From: "Mahlon E. Smith" To: Jeremy Chadwick Message-ID: <20100908143444.GB27923@martini.nu> Mail-Followup-To: "Mahlon E. Smith" , Jeremy Chadwick , Pyun YongHyeon , freebsd-stable@freebsd.org References: <20100907210813.GI49065@martini.nu> <20100907222403.GA18595@icarus.home.lan> <20100907233257.GA94092@martini.nu> <20100908002917.GO1439@michelle.cdnetworks.com> <20100908043834.GA27124@icarus.home.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zx4FCpZtqtKETZ7O" Content-Disposition: inline In-Reply-To: <20100908043834.GA27124@icarus.home.lan> X-GPG-Fingerprint: 19B8 DDB3 0156 3A03 FA80 8278 C0BE 6BFB 3606 B267 X-Sysinfo: FreeBSD 7.0-RELEASE-p1 i386 User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Pyun YongHyeon , freebsd-stable@freebsd.org Subject: Re: Network memory allocation failures X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 14:34:46 -0000 --zx4FCpZtqtKETZ7O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 07, 2010, Jeremy Chadwick wrote: >=20 > I figured there might memory exhaustion of sorts, possibly in the bce(4) > driver itself, that could cause the OP's problem. bce(4) might not be > the problem at all. But the OP's issue seems to only occur when > transmitting data, not receiving: >=20 > http://lists.freebsd.org/pipermail/freebsd-stable/2010-September/058708.h= tml More information: Looks like 100M wasn't enough of a test burst to tickle the problem in my original message... 10G is, though. It's definitely happening in both directions. Upgraded to -STABLE on one of the two machines last night, running GENERIC. FreeBSD obb 8.1-STABLE FreeBSD 8.1-STABLE #0: Tue Sep 7 19:48:55 PDT 2010 = root@obb:/usr/obj/usr/src/sys/GENERIC amd64 Outgoing: obb# scp testfile root@holp:/usr/local/tmp/ testfile 8% 856MB 37.6MB/s 04:09 ETA Write failed: Cannot allocate memory lost connection obb# scp testfile root@holp:/usr/local/tmp/ testfile 0% 72MB 34.3MB/s 04:56 ETA Write failed: Cannot allocate memory lost connection Incoming: obb# scp root@holp:/usr/local/tmp/testfile . testfile 6% 670MB 31.9MB/s 04:59 ETA Write failed: Cannot allocate memory lost connection obb# scp root@holp:/usr/local/tmp/testfile . testfile 1% 118MB 39.3MB/s 04:17 ETA Write failed: Cannot allocate memory lost connection obb# scp root@holp:/usr/local/tmp/testfile . testfile 15% 1613MB 29.0MB/s 04:57 ETA Write failed: Cannot allocate memory lost connection > The 2nd-to-last paragraph there is worth noting, specifically how > limiting maximum addressable memory to 32GB via loader.conf seems to > work around the issue. I'd no longer consider this a coincidence, limiting the memory to 16G eliminates the issue completely. I'll retest with 32G today. Incoming: obb# scp root@holp:/usr/local/tmp/testfile testfile2 testfile 100% 10GB 17.8MB/s 09:35 obb# scp root@holp:/usr/local/tmp/testfile testfile2 testfile 100% 10GB 17.0MB/s 10:02 Outgoing: obb# scp testfile root@holp:/usr/local/tmp/testfile2 testfile 100% 10GB 35.7MB/s 04:47 obb# scp testfile root@holp:/usr/local/tmp/testfile2 testfile 100% 10GB 35.4MB/s 04:49 =20 > There were other problems with the systems in question back in July, it > seems. I assume these got hammered out somehow: >=20 > http://www.mail-archive.com/freebsd-stable@freebsd.org/msg111408.html To a degree -- the initial install and cpu count problems are all fixed up, thanks to help from the list. The Intel 10G panics were stifled with a newer driver from Intel's site, but I ran out of time to do any serious testing with it, and just ended up using the broadcoms to satisfy my time constraint. -- Mahlon E. Smith =20 http://www.martini.nu/contact.html --zx4FCpZtqtKETZ7O Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- iD8DBQFMh58E1bsjBDapbeMRAg7qAJ4pGqjom+X+D0G06KzaLqR/d7gn5ACglvjL LBf1URS7U4R1TcZ9O4PrBCE= =Nus7 -----END PGP SIGNATURE----- --zx4FCpZtqtKETZ7O-- From owner-freebsd-stable@FreeBSD.ORG Wed Sep 8 14:50:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3660810656EC for ; Wed, 8 Sep 2010 14:50:34 +0000 (UTC) (envelope-from mahlon@martini.nu) Received: from martini.nu (martini.nu [198.145.180.83]) by mx1.freebsd.org (Postfix) with SMTP id 091F38FC17 for ; Wed, 8 Sep 2010 14:50:33 +0000 (UTC) Received: (qmail 58611 invoked by uid 1000); 8 Sep 2010 14:50:34 -0000 Date: Wed, 8 Sep 2010 07:50:34 -0700 From: "Mahlon E. Smith" To: Pyun YongHyeon Message-ID: <20100908145034.GC27923@martini.nu> Mail-Followup-To: "Mahlon E. Smith" , Pyun YongHyeon , freebsd-stable@freebsd.org References: <20100907210813.GI49065@martini.nu> <20100907222403.GA18595@icarus.home.lan> <20100907233257.GA94092@martini.nu> <20100908002917.GO1439@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rQ2U398070+RC21q" Content-Disposition: inline In-Reply-To: <20100908002917.GO1439@michelle.cdnetworks.com> X-GPG-Fingerprint: 19B8 DDB3 0156 3A03 FA80 8278 C0BE 6BFB 3606 B267 X-Sysinfo: FreeBSD 7.0-RELEASE-p1 i386 User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-stable@freebsd.org Subject: Re: Network memory allocation failures X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 14:50:34 -0000 --rQ2U398070+RC21q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 07, 2010, Pyun YongHyeon wrote: >=20 > [...] >=20 > You may see more detailed MAC statistics if controller saw some kind > of memory related failure from the output of "sysctl dev.bce.0". Snagged that output immediately after an allocation error. I don't see anything "bad" here, but sending to the list for more eyes. obb# scp holp:/usr/local/tmp/testfile . testfile 11% 1157MB 28.5MB/s 05:18 ETA Write failed: Cannot allocate memory lost connection obb# sysctl dev.bce.0 | less dev.bce.0.%desc: Broadcom NetXtreme II BCM5709 1000Base-T (C0) dev.bce.0.%driver: bce dev.bce.0.%location: slot=3D0 function=3D0 dev.bce.0.%pnpinfo: vendor=3D0x14e4 device=3D0x1639 subvendor=3D0x1028 = subdevice=3D0x02d4 class=3D0x020000 dev.bce.0.%parent: pci1 dev.bce.0.l2fhdr_error_count: 0 dev.bce.0.mbuf_alloc_failed_count: 0 dev.bce.0.fragmented_mbuf_count: 0 dev.bce.0.dma_map_addr_rx_failed_count: 0 dev.bce.0.dma_map_addr_tx_failed_count: 0 dev.bce.0.unexpected_attention_count: 0 dev.bce.0.stat_IfHcInOctets: 9574840018 dev.bce.0.stat_IfHCInBadOctets: 33793 dev.bce.0.stat_IfHCOutOctets: 5227554926 dev.bce.0.stat_IfHCOutBadOctets: 0 dev.bce.0.stat_IfHCInUcastPkts: 13315747 dev.bce.0.stat_IfHCInMulticastPkts: 1677373 dev.bce.0.stat_IfHCInBroadcastPkts: 3170095 dev.bce.0.stat_IfHCOutUcastPkts: 14516907 dev.bce.0.stat_IfHCOutMulticastPkts: 3799 dev.bce.0.stat_IfHCOutBroadcastPkts: 2864 dev.bce.0.stat_emac_tx_stat_dot3statsinternalmactransmiterrors: 0 dev.bce.0.stat_Dot3StatsCarrierSenseErrors: 0 dev.bce.0.stat_Dot3StatsFCSErrors: 0 dev.bce.0.stat_Dot3StatsAlignmentErrors: 0 dev.bce.0.stat_Dot3StatsSingleCollisionFrames: 0 dev.bce.0.stat_Dot3StatsMultipleCollisionFrames: 0 dev.bce.0.stat_Dot3StatsDeferredTransmissions: 0 dev.bce.0.stat_Dot3StatsExcessiveCollisions: 0 dev.bce.0.stat_Dot3StatsLateCollisions: 0 dev.bce.0.stat_EtherStatsCollisions: 0 dev.bce.0.stat_EtherStatsFragments: 0 dev.bce.0.stat_EtherStatsJabbers: 0 dev.bce.0.stat_EtherStatsUndersizePkts: 0 dev.bce.0.stat_EtherStatsOversizePkts: 0 dev.bce.0.stat_EtherStatsPktsRx64Octets: 1837825 dev.bce.0.stat_EtherStatsPktsRx65Octetsto127Octets: 3654565 dev.bce.0.stat_EtherStatsPktsRx128Octetsto255Octets: 4448594 dev.bce.0.stat_EtherStatsPktsRx256Octetsto511Octets: 3353660 dev.bce.0.stat_EtherStatsPktsRx512Octetsto1023Octets: 516080 dev.bce.0.stat_EtherStatsPktsRx1024Octetsto1522Octets: 4352491 dev.bce.0.stat_EtherStatsPktsRx1523Octetsto9022Octets: 0 dev.bce.0.stat_EtherStatsPktsTx64Octets: 74155 dev.bce.0.stat_EtherStatsPktsTx65Octetsto127Octets: 5516618 dev.bce.0.stat_EtherStatsPktsTx128Octetsto255Octets: 1709976 dev.bce.0.stat_EtherStatsPktsTx256Octetsto511Octets: 5174458 dev.bce.0.stat_EtherStatsPktsTx512Octetsto1023Octets: 202881 dev.bce.0.stat_EtherStatsPktsTx1024Octetsto1522Octets: 1845482 dev.bce.0.stat_EtherStatsPktsTx1523Octetsto9022Octets: 0 dev.bce.0.stat_XonPauseFramesReceived: 0 dev.bce.0.stat_XoffPauseFramesReceived: 0 dev.bce.0.stat_OutXonSent: 0 dev.bce.0.stat_OutXoffSent: 0 dev.bce.0.stat_FlowControlDone: 0 dev.bce.0.stat_MacControlFramesReceived: 0 dev.bce.0.stat_XoffStateEntered: 0 dev.bce.0.stat_IfInFramesL2FilterDiscards: 238 dev.bce.0.stat_IfInRuleCheckerDiscards: 0 dev.bce.0.stat_IfInFTQDiscards: 0 dev.bce.0.stat_IfInMBUFDiscards: 0 dev.bce.0.stat_IfInRuleCheckerP4Hit: 4843765 dev.bce.0.stat_CatchupInRuleCheckerDiscards: 0 dev.bce.0.stat_CatchupInFTQDiscards: 0 dev.bce.0.stat_CatchupInMBUFDiscards: 0 dev.bce.0.stat_CatchupInRuleCheckerP4Hit: 0 dev.bce.0.com_no_buffers: 0 -- Mahlon E. Smith =20 http://www.martini.nu/contact.html --rQ2U398070+RC21q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- iD8DBQFMh6K61bsjBDapbeMRAlyNAJ0S2gXMjPFn88nhrxWSSBWrIBEnpwCgp2oz pbcKtrR0e9bXchzGHkUsENk= =Hyln -----END PGP SIGNATURE----- --rQ2U398070+RC21q-- From owner-freebsd-stable@FreeBSD.ORG Wed Sep 8 14:59:09 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A733710656D6 for ; Wed, 8 Sep 2010 14:59:09 +0000 (UTC) (envelope-from mark@exonetric.com) Received: from relay0.exonetric.net (relay0.exonetric.net [82.138.248.161]) by mx1.freebsd.org (Postfix) with ESMTP id 711398FC12 for ; Wed, 8 Sep 2010 14:59:09 +0000 (UTC) Received: from markimac.fairfx.local (unknown [62.244.179.66]) by relay0.exonetric.net (Postfix) with ESMTP id 9D81F5701F for ; Wed, 8 Sep 2010 15:31:13 +0100 (BST) Message-ID: <4C879E2F.6000107@exonetric.com> Date: Wed, 08 Sep 2010 15:31:11 +0100 From: Mark Blackman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.11) Gecko/20100701 SeaMonkey/2.0.6 MIME-Version: 1.0 To: stable@freebsd.org References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <201009080842.28495.jhb@freebsd.org> <201009081021.48077.jhb@freebsd.org> In-Reply-To: <201009081021.48077.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Policy for removing working code X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 14:59:09 -0000 John Baldwin wrote: > [ Trimming cc's a bit ] > > On Wednesday, September 08, 2010 10:01:22 am Vadim Goncharov wrote: >> Big thanks for your work, but unfortunately, the problem itself is not ISDN or >> network stack, it is deeper. It is the policy or may be style of thought, >> discourse. Something like: >> progress dictates we need fix/maintainership to feature X >> & we have no resources to maintain feature X >> -> we announce theis need, but only to _limited_ audience, not wide circles >> -> nobody responds >> -> the X code is removed >> AND we think this logic chain is correct, thought we did not things this way >> even 5 years ago. > > Actually, things have worked this way far longer than 5 years ago. For > example, we lost a few SCSI HBA drivers during the transition to CAM (e.g. > wds(4) was not present in 4.x but was eventually CAM-ified and reappeared > in 5.0). I suspect there was far less notice given for those drivers > than for ISDN (multiple notices to arch@ and current@ spread out across > many months). On top of which, I'd say that the general philosopy is always that you stick with the release that works for you. Surely the people who "need" those ISDN drivers, simply stay with the release that works for them. If they need new features as well as ISDN, they do a cost-benefit analysis on writing drivers to fit the new framework. - Mark From owner-freebsd-stable@FreeBSD.ORG Wed Sep 8 15:06:25 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7FC310656A7 for ; Wed, 8 Sep 2010 15:06:25 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp03.sth.basefarm.net (ch-smtp03.sth.basefarm.net [80.76.149.214]) by mx1.freebsd.org (Postfix) with ESMTP id 532F58FC08 for ; Wed, 8 Sep 2010 15:06:25 +0000 (UTC) Received: from c83-255-61-120.bredband.comhem.se ([83.255.61.120]:57544 helo=falcon.midgard.homeip.net) by ch-smtp03.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1OtME8-0001N2-Cc for stable@freebsd.org; Wed, 08 Sep 2010 17:06:23 +0200 Received: (qmail 7129 invoked from network); 8 Sep 2010 17:06:13 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 8 Sep 2010 17:06:13 +0200 Received: (qmail 10567 invoked by uid 1001); 8 Sep 2010 17:06:13 +0200 Date: Wed, 8 Sep 2010 17:06:13 +0200 From: Erik Trulsson To: Mark Blackman Message-ID: <20100908150613.GA10557@owl.midgard.homeip.net> References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <201009080842.28495.jhb@freebsd.org> <201009081021.48077.jhb@freebsd.org> <4C879E2F.6000107@exonetric.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C879E2F.6000107@exonetric.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Originating-IP: 83.255.61.120 X-Scan-Result: No virus found in message 1OtME8-0001N2-Cc. X-Scan-Signature: ch-smtp03.sth.basefarm.net 1OtME8-0001N2-Cc 6cafca0c5f5427ee8e86203aa8f591f7 Cc: stable@freebsd.org Subject: Re: Policy for removing working code X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 15:06:25 -0000 On Wed, Sep 08, 2010 at 03:31:11PM +0100, Mark Blackman wrote: > John Baldwin wrote: > > [ Trimming cc's a bit ] > > > > On Wednesday, September 08, 2010 10:01:22 am Vadim Goncharov wrote: > > >> Big thanks for your work, but unfortunately, the problem itself is not ISDN or > >> network stack, it is deeper. It is the policy or may be style of thought, > >> discourse. Something like: > >> progress dictates we need fix/maintainership to feature X > >> & we have no resources to maintain feature X > >> -> we announce theis need, but only to _limited_ audience, not wide circles > >> -> nobody responds > >> -> the X code is removed > >> AND we think this logic chain is correct, thought we did not things this way > >> even 5 years ago. > > > > Actually, things have worked this way far longer than 5 years ago. For > > example, we lost a few SCSI HBA drivers during the transition to CAM (e.g. > > wds(4) was not present in 4.x but was eventually CAM-ified and reappeared > > in 5.0). I suspect there was far less notice given for those drivers > > than for ISDN (multiple notices to arch@ and current@ spread out across > > many months). > > On top of which, I'd say that the general philosopy is always that > you stick with the release that works for you. Surely the people who > "need" those ISDN drivers, simply stay with the release that works for > them. If they need new features as well as ISDN, they do a cost-benefit > analysis on writing drivers to fit the new framework. Only problem with that is that eventually those old releases stop receiving security fixes at which point it might become downright dangerous to continue using the old release. I think that is exactly the situation now which started this discussion - the last release supporting ISDN was 6.4, which is to be EOL soon. -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-stable@FreeBSD.ORG Wed Sep 8 15:12:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3F9B106564A; Wed, 8 Sep 2010 15:12:27 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2-6.sentex.ca [IPv6:2607:f3e0:80:80::2]) by mx1.freebsd.org (Postfix) with ESMTP id 42D8D8FC08; Wed, 8 Sep 2010 15:12:27 +0000 (UTC) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.4/8.14.4) with ESMTP id o88FCJxe003090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Sep 2010 11:12:19 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o88FCIq8064280; Wed, 8 Sep 2010 11:12:18 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201009081512.o88FCIq8064280@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 08 Sep 2010 11:12:24 -0400 To: "Li, Qing" , From: Mike Tancsa In-Reply-To: References: <201008312102.o7VL2MJr000894@lava.sentex.ca> <201009012255.o81MtMXn009701@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.67 on 205.211.164.50 Cc: Subject: RE: if_rtdel: error 47 (netgraph or mpd issue?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 15:12:27 -0000 At 07:24 PM 9/1/2010, Li, Qing wrote: >http://svn.freebsd.org/viewvc/base/head/sys/netinet/in.c?r1=3D201811&r2=3D2= 0 >3401 > > Maybe related and something similar needs to be done for IPv6 ... Hi, Another 6 days and another crash. The=20 coredump seems to be in the same location as before h= ttp://lists.freebsd.org/pipermail/freebsd-stable/2010-August/058419.html=20 I didnt see any routing table corruption this=20 time, so perhaps thats a different issue that=20 just happened to be hit last time ? Fatal trap 12: page fault while in kernel mode cpuid =3D 1; apic id =3D 01 fault virtual address =3D 0x24 fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0xc5ef3e15 stack pointer =3D 0x28:0xc4fe4838 frame pointer =3D 0x28:0xc4fe484c code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 1000 (ng_queue1) trap number =3D 12 panic: page fault cpuid =3D 1 Uptime: 6d4h9m42s #1 0xc0681233 in boot (howto=3D260) at= /usr/src/sys/kern/kern_shutdown.c:416 #2 0xc0681499 in panic (fmt=3DVariable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:590 #3 0xc08ea3ec in trap_fatal (frame=3D0xc4fe47f8, eva=3D36) at /usr/src/sys/i386/i386/trap.c:938 #4 0xc08ea650 in trap_pfault (frame=3D0xc4fe47f8, usermode=3D0, eva=3D36) at /usr/src/sys/i386/i386/trap.c:851 #5 0xc08eaf19 in trap (frame=3D0xc4fe47f8) at= /usr/src/sys/i386/i386/trap.c:533 #6 0xc08cd4bc in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #7 0xc5ef3e15 in ng_address_hook (here=3D0x0, item=3D0xc5f03c40, hook=3D0xcb685980, retaddr=3D0) at= /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:3504 #8 0xc5f7ebfb in ng_tcpmss_rcvdata (hook=3D0xc6618300, item=3D0xc5f03c40) at= /usr/src/sys/modules/netgraph/tcpmss/../../../netgraph/ng_tcpmss.c:347 #9 0xc5ef57c4 in ng_apply_item (node=3D0xca955b00, item=3D0xc5f03c40, rw=3D= 0) at= /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #10 0xc5ef479f in ng_snd_item (item=3D0xc5f03c40,=20 flags=3DVariable "flags" is not available. ) at= /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2253 #11 0xc5f6dd30 in ng_ppp_proto_recv=20 (node=3D0xc6431300, item=3D0xc5f03c40, proto=3DVariable "proto" is not= available. ) at /usr/src/sys/modules/netgraph/ppp/../../../netgraph/ng_ppp.c:949 #12 0xc5f6ea25 in ng_ppp_rcvdata (hook=3D0xcb228a80, item=3D0xc5f03c40) at /usr/src/sys/modules/netgraph/ppp/../../../netgraph/ng_ppp.c:1524 #13 0xc5ef57c4 in ng_apply_item (node=3D0xc6431300, item=3D0xc5f03c40, rw=3D= 0) at= /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #14 0xc5ef479f in ng_snd_item (item=3D0xc5f03c40,=20 flags=3DVariable "flags" is not available. ) at= /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2253 #15 0xc5ef57c4 in ng_apply_item (node=3D0xcb375c80, item=3D0xc5f03c40, rw=3D= 0) at= /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #16 0xc5ef479f in ng_snd_item (item=3D0xc5f03c40,=20 flags=3DVariable "flags" is not available. ) at= /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2253 #17 0xc5ef57c4 in ng_apply_item (node=3D0xc6330100, item=3D0xc5f03c40, rw=3D= 0) at= /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #18 0xc5ef479f in ng_snd_item (item=3D0xc5f03c40,=20 flags=3DVariable "flags" is not available. ) at= /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2253 #19 0xc5f4db1c in ng_ksocket_incoming2 (node=3D0xc6431e00, hook=3D0x0, arg1=3D0xc63479a8, arg2=3D0) at=20 /usr/src/sys/modules/netgraph/ksocket/../../../netgraph/ng_ksocket.c:1153 #20 0xc5ef58f9 in ng_apply_item (node=3D0xc6431e00, item=3D0xc5f02780, rw=3D= 1) at= /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2407 #21 0xc5ef6a46 in ngthread (arg=3D0x0) at= /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:3351 #22 0xc0656cd1 in fork_exit (callout=3D0xc5ef68e0 , arg=3D0x0, frame=3D0xc4fe4d38) at /usr/src/sys/kern/kern_fork.c:844 #23 0xc08cd534 in fork_trampoline () at= /usr/src/sys/i386/i386/exception.s:273 (kgdb) up 7 #7 0xc5ef3e15 in ng_address_hook (here=3D0x0,=20 item=3D0xc5f03c40, hook=3D0xcb685980, retaddr=3D0) at= /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:3504 3504 if ((hook =3D=3D NULL) || (kgdb) list 3499 * Quick sanity check.. 3500 * Since a hook holds a reference on it's node, once we know 3501 * that the peer is still connected (even if invalid,) we= know 3502 * that the peer node is present, though maybe invalid. 3503 */ 3504 if ((hook =3D=3D NULL) || 3505 NG_HOOK_NOT_VALID(hook) || 3506 NG_HOOK_NOT_VALID(peer =3D NG_HOOK_PEER(hook)) || 3507 NG_NODE_NOT_VALID(peernode =3D NG_PEER_NODE(hook))) { 3508 NG_FREE_ITEM(item); (kgdb) (kgdb) p item $1 =3D 0xc5f03c40 (kgdb) p *item $2 =3D {el_flags =3D 5, el_next =3D {stqe_next =3D 0x0},=20 el_dest =3D 0x0, el_hook =3D 0x0, body =3D {da_m =3D 0xcaa71600, msg =3D { msg_msg =3D 0xcaa71600, msg_retaddr =3D 0}, fn=20 =3D {fn_fn =3D {fn_fn =3D 0xcaa71600, fn_fn2 =3D 0xcaa71600}, fn_arg1 =3D= 0x0, fn_arg2 =3D 0}}, apply =3D 0x0, depth =3D 4} (kgdb) p *hook $3 =3D {hk_name =3D "out", '\0' ,=20 hk_private =3D 0xc60dba00, hk_flags =3D 0, hk_type =3D 0, hk_peer =3D= 0xcae40480, hk_node =3D 0xca955b00, hk_hooks =3D {le_next =3D=20 0xc6618300, le_prev =3D 0xca955b34}, hk_rcvmsg =3D 0, hk_rcvdata =3D 0,= hk_refs =3D 2} (kgdb) p *peer $4 =3D {hk_name =3D "\b\000\000\000=20 \000\000\000\004\000\000\000\001\000\000\000\037>t\001\003=F6\0248cmd4\000\0= 00\000",=20 hk_private =3D 0x0, hk_flags =3D 0, hk_type =3D 0,=20 hk_peer =3D 0x0, hk_node =3D 0x0, hk_hooks =3D {le_next =3D 0x0, le_prev =3D= 0x355db}, hk_rcvmsg =3D 0x11a11376, hk_rcvdata =3D 0x1c7e8, hk_refs =3D 6432036} (kgdb) -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-stable@FreeBSD.ORG Wed Sep 8 15:25:04 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8B3610656EC for ; Wed, 8 Sep 2010 15:25:04 +0000 (UTC) (envelope-from mark@exonetric.com) Received: from relay0.exonetric.net (relay0.exonetric.net [82.138.248.161]) by mx1.freebsd.org (Postfix) with ESMTP id A17DF8FC17 for ; Wed, 8 Sep 2010 15:25:04 +0000 (UTC) Received: from markimac.fairfx.local (unknown [62.244.179.66]) by relay0.exonetric.net (Postfix) with ESMTP id C380F5701F; Wed, 8 Sep 2010 16:25:03 +0100 (BST) Message-ID: <4C87AACF.1060907@exonetric.com> Date: Wed, 08 Sep 2010 16:25:03 +0100 From: Mark Blackman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.11) Gecko/20100701 SeaMonkey/2.0.6 MIME-Version: 1.0 To: Erik Trulsson References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <201009080842.28495.jhb@freebsd.org> <201009081021.48077.jhb@freebsd.org> <4C879E2F.6000107@exonetric.com> <20100908150613.GA10557@owl.midgard.homeip.net> In-Reply-To: <20100908150613.GA10557@owl.midgard.homeip.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: Policy for removing working code X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 15:25:04 -0000 Erik Trulsson wrote: > On Wed, Sep 08, 2010 at 03:31:11PM +0100, Mark Blackman wrote: >> On top of which, I'd say that the general philosopy is always that >> you stick with the release that works for you. Surely the people who >> "need" those ISDN drivers, simply stay with the release that works for >> them. If they need new features as well as ISDN, they do a cost-benefit >> analysis on writing drivers to fit the new framework. > > > Only problem with that is that eventually those old releases stop > receiving security fixes at which point it might become downright > dangerous to continue using the old release. > I think that is exactly the situation now which started this discussion > - the last release supporting ISDN was 6.4, which is to be EOL soon. Fair point, although I'd say that's part of the cost-benefit analysis too, where features includes "up-to-date security fixes". Anyway, I finally reviewed the thread and an actual I4B user, Julian, seems to have concluded that investing a bit of time in the hps code is a net benefit, so all's well. :) - Mark From owner-freebsd-stable@FreeBSD.ORG Wed Sep 8 15:35:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B9AA10656AB for ; Wed, 8 Sep 2010 15:35:30 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2-6.sentex.ca [IPv6:2607:f3e0:80:80::2]) by mx1.freebsd.org (Postfix) with ESMTP id B55678FC2C for ; Wed, 8 Sep 2010 15:35:29 +0000 (UTC) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.4/8.14.4) with ESMTP id o88FZLBp005958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 8 Sep 2010 11:35:21 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o88FZKQS064396; Wed, 8 Sep 2010 11:35:20 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201009081535.o88FZKQS064396@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 08 Sep 2010 11:35:27 -0400 To: Vlad Galu From: Mike Tancsa In-Reply-To: References: <201008312102.o7VL2MJr000894@lava.sentex.ca> <201009012255.o81MtMXn009701@lava.sentex.ca> <201009081512.o88FCIq8064280@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.67 on 205.211.164.50 Cc: "Li, Qing" , freebsd-stable@freebsd.org Subject: Re: if_rtdel: error 47 (netgraph or mpd issue?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 15:35:30 -0000 At 11:30 AM 9/8/2010, Vlad Galu wrote: >On Wed, Sep 8, 2010 at 6:12 PM, Mike Tancsa wrote: >[...] > >FWIW, I've had a few crashes in if_rtdel() while playing with ECMP. No >Netgraph on that box. Unfortunately, the stack was too corrupted to be >able to see the outer frames. Hi, Actually, I dont have ECMP enabled on this box. Its basically GENERIC, minus < ident router --- > ident GENERIC 72,75c73,76 < #options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) < #options AUDIT # Security event auditing < #options MAC # TrustedBSD MAC Framework < #options FLOWTABLE # per-cpu routing cache --- > options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) > options AUDIT # Security event auditing > options MAC # TrustedBSD MAC Framework > options FLOWTABLE # per-cpu routing cache and device drivers that are unused ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-stable@FreeBSD.ORG Wed Sep 8 16:01:36 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F11CC10656B7 for ; Wed, 8 Sep 2010 16:01:36 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id B5E4C8FC12 for ; Wed, 8 Sep 2010 16:01:36 +0000 (UTC) Received: by gxk24 with SMTP id 24so125285gxk.13 for ; Wed, 08 Sep 2010 09:01:36 -0700 (PDT) Received: by 10.229.237.199 with SMTP id kp7mr14051qcb.8.1283959853202; Wed, 08 Sep 2010 08:30:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.38.83 with HTTP; Wed, 8 Sep 2010 08:30:13 -0700 (PDT) In-Reply-To: <201009081512.o88FCIq8064280@lava.sentex.ca> References: <201008312102.o7VL2MJr000894@lava.sentex.ca> <201009012255.o81MtMXn009701@lava.sentex.ca> <201009081512.o88FCIq8064280@lava.sentex.ca> From: Vlad Galu Date: Wed, 8 Sep 2010 18:30:13 +0300 Message-ID: To: Mike Tancsa Content-Type: text/plain; charset=ISO-8859-1 Cc: "Li, Qing" , freebsd-stable@freebsd.org Subject: Re: if_rtdel: error 47 (netgraph or mpd issue?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 16:01:37 -0000 On Wed, Sep 8, 2010 at 6:12 PM, Mike Tancsa wrote: [...] FWIW, I've had a few crashes in if_rtdel() while playing with ECMP. No Netgraph on that box. Unfortunately, the stack was too corrupted to be able to see the outer frames. -- Good, fast & cheap. Pick any two. From owner-freebsd-stable@FreeBSD.ORG Wed Sep 8 16:41:54 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 766BC1065679 for ; Wed, 8 Sep 2010 16:41:54 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id EF39D8FC19 for ; Wed, 8 Sep 2010 16:41:53 +0000 (UTC) Received: by eyx24 with SMTP id 24so254550eyx.13 for ; Wed, 08 Sep 2010 09:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=uVb4F7K8XJ50VghCSXYfamyjFhUcYGPcL4J8g6D5G4E=; b=ZFQ27nbHMVVN/fOBuSKC/Oh+YBRnNqALNbBOnQIML1LcmAFvzPpBXwBMVjcJZ1+mpJ uZKJhF/ZLQ5xIKtRBIbPWwZ+Cu/jJI/20VgK0LntHHR1O3LUeZqbh/ExdvZjHbHZFx/6 Eiw+ST1mJcuTqz0nkGVmNzGBl7X6IQFnHEnsc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cs065j1l8nKsuh8gv/gsKSGriC9bpMdvbNZ0J/xnQ2hSwNv27qGsA0eIL5HySjmB6b 7yNsTqEnjguEK1cN/XwJKLu453ML1LE8lfrVGbOrF0AtLJ1LY4nxPMafPTG8/KxTqawZ Yg7FtwXNu37jrHor8NYkNmvqrBNd04ooNVwEI= MIME-Version: 1.0 Received: by 10.216.59.131 with SMTP id s3mr1343923wec.71.1283964112313; Wed, 08 Sep 2010 09:41:52 -0700 (PDT) Received: by 10.216.49.78 with HTTP; Wed, 8 Sep 2010 09:41:51 -0700 (PDT) In-Reply-To: <20100908094050.GA73841@lordcow.org> References: <20100906155350.GA50151@lordcow.org> <20100908094050.GA73841@lordcow.org> Date: Wed, 8 Sep 2010 09:41:51 -0700 Message-ID: From: Jack Vogel To: Gareth de Vaux Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: stable@freebsd.org Subject: Re: MSIX failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 16:41:54 -0000 This is what'd I'd expect, the onboard is PCH chipset, support was not in 8.0, but as I said, in 8.1 (and hence stable/8) it is supported, and it should work. I do not know why you don't have MSI support, but it should still work with Legacy interrupts. Jack On Wed, Sep 8, 2010 at 2:40 AM, Gareth de Vaux wrote: > On Tue 2010-09-07 (13:25), Jack Vogel wrote: > > I've looked at the code, this message was misleading, what really happens > > is that the driver fails to be able to setup either MSIX OR MSI, when > this > > happens it will fall back and use a Legacy interrupt, so its non-fatal > and > > the device should work anyway. > > > > The only real reason you should see this is a) you used sysctl and turned > > msi and msix off, or b) a real hardware problem in the chipset has caused > > the failure. All devices em drives (as opposed to lem) are PCI Express > and > > so by definition they have MSI and MSIX available. > > Ok I think I got my cards mixed up - in my original mail em1 is the PCI > card and em0 is the onboard, sorry. I guessed the numbering may not have > been as expected while trying to fix the issue, but I might not have fully > tested this at the time. > > So here's the situation after looking through older kernel logs: > > I installed 8.0-RELEASE, the onboard card didn't work - the kernel didn't > even pick it up, and ifconfig only showed the lo0 device. > > I added the PCI Intel(R) PRO/1000 GT card (Gigabit Ethernet Controller > (Copper) rev 5 (82541PI)) - this worked and came up as em0. > > Last week I moved to -STABLE, GENERIC kernel. The kernel now detects both > cards, with the kernel messages in my original mail. Whether either works > I'm not completely sure, I'll need to get to the machine physically and > switch cables/cards/configurations first. > > I didn't turn off msi/msix with sysctl (except when debugging in my > original > mail). > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Wed Sep 8 16:52:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46B7210656C3 for ; Wed, 8 Sep 2010 16:52:25 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 126518FC1A for ; Wed, 8 Sep 2010 16:52:24 +0000 (UTC) Received: by pwi8 with SMTP id 8so160867pwi.13 for ; Wed, 08 Sep 2010 09:52:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:subject :message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=5kg7aBaossDUAvnbSWr/4t23TmC5u1tjVVou7UJ1ghM=; b=Ee5pRz6D68byVwJEA6+FdoukRkXs+qewSuI4WAxpi28ksYA5soOphHNiuU1SS/Ol9B YDyQkTRjgfisGeZfjsp8tw8TzoH3jXR9kqdyEZW2FGUgPPaX0mlsUV5PZdyESohYTleS 3Vr00QZMee+Xe7ra5DNxsmj/9hYWYXCo7W/RE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=ASFO3zAUsCH/Frw+wLkL3wfFrmCMwcZ8Ui+1U7Pm9FGY4JtUTz2HNr0CHZ3lurYyZx sZDSDOlZXnrpbxpIOpkb4KmfQw1VbjWQu7EL2eIXdODNVO16p2c8eQGHwZO1dDOtu8nT NrX9LudRqVnQLjSgOfp/8yVNJMNiOws2StjBg= Received: by 10.114.89.11 with SMTP id m11mr109559wab.23.1283964738557; Wed, 08 Sep 2010 09:52:18 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id q6sm371310waj.10.2010.09.08.09.52.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 08 Sep 2010 09:52:16 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 8 Sep 2010 09:51:58 -0700 From: Pyun YongHyeon Date: Wed, 8 Sep 2010 09:51:58 -0700 To: "Mahlon E. Smith" , Jeremy Chadwick , freebsd-stable@freebsd.org Message-ID: <20100908165158.GB7203@michelle.cdnetworks.com> References: <20100907210813.GI49065@martini.nu> <20100907222403.GA18595@icarus.home.lan> <20100907233257.GA94092@martini.nu> <20100908002917.GO1439@michelle.cdnetworks.com> <20100908043834.GA27124@icarus.home.lan> <20100908143444.GB27923@martini.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100908143444.GB27923@martini.nu> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: Network memory allocation failures X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 16:52:25 -0000 On Wed, Sep 08, 2010 at 07:34:44AM -0700, Mahlon E. Smith wrote: > On Tue, Sep 07, 2010, Jeremy Chadwick wrote: > > > > I figured there might memory exhaustion of sorts, possibly in the bce(4) > > driver itself, that could cause the OP's problem. bce(4) might not be > > the problem at all. But the OP's issue seems to only occur when > > transmitting data, not receiving: > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-September/058708.html > > More information: > > Looks like 100M wasn't enough of a test burst to tickle the problem in > my original message... 10G is, though. It's definitely happening in > both directions. > > Upgraded to -STABLE on one of the two machines last night, running > GENERIC. > > FreeBSD obb 8.1-STABLE FreeBSD 8.1-STABLE #0: Tue Sep 7 19:48:55 PDT 2010 root@obb:/usr/obj/usr/src/sys/GENERIC amd64 > > > Outgoing: > > obb# scp testfile root@holp:/usr/local/tmp/ > testfile 8% 856MB 37.6MB/s 04:09 ETA > Write failed: Cannot allocate memory > lost connection > obb# scp testfile root@holp:/usr/local/tmp/ > testfile 0% 72MB 34.3MB/s 04:56 ETA > Write failed: Cannot allocate memory > lost connection > > Incoming: > > obb# scp root@holp:/usr/local/tmp/testfile . > testfile 6% 670MB 31.9MB/s 04:59 ETA > Write failed: Cannot allocate memory > lost connection > obb# scp root@holp:/usr/local/tmp/testfile . > testfile 1% 118MB 39.3MB/s 04:17 ETA > Write failed: Cannot allocate memory > lost connection > obb# scp root@holp:/usr/local/tmp/testfile . > testfile 15% 1613MB 29.0MB/s 04:57 ETA > Write failed: Cannot allocate memory > lost connection > I think bce(4) may not be able to return ENOMEM to user land process so I guess it's not a bce(4) issue. To rule out possible driver issue, could you try other controller instead of bce(4)? > > > > The 2nd-to-last paragraph there is worth noting, specifically how > > limiting maximum addressable memory to 32GB via loader.conf seems to > > work around the issue. > > I'd no longer consider this a coincidence, limiting the memory to 16G > eliminates the issue completely. I'll retest with 32G today. > Again, this type of change has nothing to do with driver operation. bce(4) may have some issues on PAE but I don't think that would trigger problems on amd64 systems. > Incoming: > > obb# scp root@holp:/usr/local/tmp/testfile testfile2 > testfile 100% 10GB 17.8MB/s 09:35 > obb# scp root@holp:/usr/local/tmp/testfile testfile2 > testfile 100% 10GB 17.0MB/s 10:02 > > Outgoing: > > obb# scp testfile root@holp:/usr/local/tmp/testfile2 > testfile 100% 10GB 35.7MB/s 04:47 > obb# scp testfile root@holp:/usr/local/tmp/testfile2 > testfile 100% 10GB 35.4MB/s 04:49 > > > > There were other problems with the systems in question back in July, it > > seems. I assume these got hammered out somehow: > > > > http://www.mail-archive.com/freebsd-stable@freebsd.org/msg111408.html > > To a degree -- the initial install and cpu count problems are all fixed > up, thanks to help from the list. The Intel 10G panics were stifled > with a newer driver from Intel's site, but I ran out of time to do > any serious testing with it, and just ended up using the broadcoms to > satisfy my time constraint. > > -- > Mahlon E. Smith > http://www.martini.nu/contact.html From owner-freebsd-stable@FreeBSD.ORG Wed Sep 8 20:22:42 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB19210656A4 for ; Wed, 8 Sep 2010 20:22:42 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id A53A98FC0C for ; Wed, 8 Sep 2010 20:22:42 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 6E5331A3C3B; Wed, 8 Sep 2010 13:06:24 -0700 (PDT) Date: Wed, 8 Sep 2010 13:06:24 -0700 From: Alfred Perlstein To: "William D. Colburn (Schlake)" Message-ID: <20100908200624.GJ69795@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: My kernel panics suck X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 20:22:42 -0000 * William D. Colburn (Schlake) [100702 12:19] wrote: > I got my new 8-stable system up, and now I just have recurrent disk > controller failures. The machine can't stay more than about ten > minutes before it panics into a hung kernel, or simple reboots. > Unfortunately, I know the root cause of the panics. If my computer is > sitting on the table, then the kernel doesn't panic. If the computer > is sitting on the desk, then it panics like mad. The table is wooden, > the desk is metal. Of course, I'm also changing power too. On the > table, I use a wall outlet, while on the desk I use my Smart UPS. > Unfortunately, you can't really help me with this. I'm just writing > in out of the hope that I'll get some sympathy for this problem. Everyone knows the best place to run FreeBSD is under your desk: ~ % gcc -v Using built-in specs. Target: amd64-undermydesk-freebsd Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD] -Alfred From owner-freebsd-stable@FreeBSD.ORG Wed Sep 8 20:23:57 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B69B610656E0 for ; Wed, 8 Sep 2010 20:23:57 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 7FF5E8FC19 for ; Wed, 8 Sep 2010 20:23:57 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id o88KNtv6029585; Wed, 8 Sep 2010 13:23:55 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Sep 2010 13:23:35 -0700 Message-ID: In-Reply-To: <201009081535.o88FZKQS064396@lava.sentex.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: if_rtdel: error 47 (netgraph or mpd issue?) Thread-Index: ActPa3koIuS5KOhvQcCuYGpKJSKySwAKC8IA References: <201008312102.o7VL2MJr000894@lava.sentex.ca> <201009012255.o81MtMXn009701@lava.sentex.ca> <201009081512.o88FCIq8064280@lava.sentex.ca> <201009081535.o88FZKQS064396@lava.sentex.ca> From: "Li, Qing" To: "Mike Tancsa" , "Vlad Galu" Cc: freebsd-stable@freebsd.org Subject: RE: if_rtdel: error 47 (netgraph or mpd issue?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 20:23:57 -0000 I am working with Mike offline. -- Qing > -----Original Message----- > From: Mike Tancsa [mailto:mike@sentex.net] > Sent: Wednesday, September 08, 2010 8:35 AM > To: Vlad Galu > Cc: Li, Qing; freebsd-stable@freebsd.org > Subject: Re: if_rtdel: error 47 (netgraph or mpd issue?) >=20 > At 11:30 AM 9/8/2010, Vlad Galu wrote: > >On Wed, Sep 8, 2010 at 6:12 PM, Mike Tancsa wrote: > >[...] > > > >FWIW, I've had a few crashes in if_rtdel() while playing with ECMP. No > >Netgraph on that box. Unfortunately, the stack was too corrupted to be > >able to see the outer frames. >=20 > Hi, > Actually, I dont have ECMP enabled on this box. Its > basically GENERIC, minus >=20 > < ident router > --- > > ident GENERIC > 72,75c73,76 > < #options HWPMC_HOOKS # Necessary kernel hooks for > hwpmc(4) > < #options AUDIT # Security event auditing > < #options MAC # TrustedBSD MAC Framework > < #options FLOWTABLE # per-cpu routing cache > --- > > options HWPMC_HOOKS # Necessary kernel hooks for > hwpmc(4) > > options AUDIT # Security event auditing > > options MAC # TrustedBSD MAC Framework > > options FLOWTABLE # per-cpu routing cache >=20 > and device drivers that are unused >=20 > ---Mike >=20 >=20 > -------------------------------------------------------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet since 1994 www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 08:30:58 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9780F10656E7; Thu, 9 Sep 2010 08:30:58 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 73C378FC22; Thu, 9 Sep 2010 08:30:58 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id o898Uuvq072008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 9 Sep 2010 01:30:57 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id o898UuqP072007; Thu, 9 Sep 2010 01:30:56 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA08372; Thu, 9 Sep 10 01:26:41 PDT Date: Thu, 09 Sep 2010 01:22:22 -0700 From: perryh@pluto.rain.com To: jhb@freebsd.org, vadim_nuclight@mail.ru Message-Id: <4c88993e.MgMUYIGSfJIxECy9%perryh@pluto.rain.com> References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <201009080842.28495.jhb@freebsd.org> <201009081021.48077.jhb@freebsd.org> In-Reply-To: <201009081021.48077.jhb@freebsd.org> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: Policy for removing working code X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 08:30:58 -0000 John Baldwin wrote: > We can't e-mail announce@ every time something is going to > be removed. That would be way too much spam for that list. That may depend on how often something substantial is removed :) > I do think stable@ is a good place to e-mail ... Good, perhaps even "necessary", but is it "sufficient"? Those following a -STABLE branch are expected to read stable@, but what about those who are following a security branch? > I do think that the general rule is that stable@ should be on > the list. It is true that that did not happen in this case (and > probably should have), but it does happen in the typical case. > I would chalk this up to a one-time slip-up, not a systemic problem. In light of this slip-up having now resulted in at least one user having the rug yanked out from under him, perhaps the security officer should be approached WRT continuing support for 6.4 until ISDN is resurrected (which, to judge from other postings in this thread, seems unlikely to amount to "indefinitely"). > ... we lost a few SCSI HBA drivers during the transition to CAM > (e.g. wds(4) was not present in 4.x but was eventually CAM-ified > and reappeared in 5.0). I suspect there was far less notice given > for those drivers than for ISDN (multiple notices to arch@ and > current@ spread out across many months). But, as noted previously, not to any list that someone following a security branch would be expected to read. Beyond that, I suspect that dropping an HBA or three would have been far less burdensome on users of the hardware in question than dropping ISDN is on its users. One can always replace a no-longer-supported HBA with a supported one, or (worst case) replace the whole box. In contrast, someone located beyond DSL range may have no other viable option than ISDN. Perhaps it would be advisable to e-mail announce@ when something is to be removed _and_ there is no recommended migration path. That should reduce the frequency of such postings considerably compared with the strawman suggestion that > ... every time something is going to be removed would overload the list. From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 08:57:11 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6233110656AB for ; Thu, 9 Sep 2010 08:57:11 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp02.sth.basefarm.net (ch-smtp02.sth.basefarm.net [80.76.149.213]) by mx1.freebsd.org (Postfix) with ESMTP id E4BEB8FC12 for ; Thu, 9 Sep 2010 08:57:10 +0000 (UTC) Received: from c83-255-61-120.bredband.comhem.se ([83.255.61.120]:38850 helo=falcon.midgard.homeip.net) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1OtcwH-0000vb-7a for stable@freebsd.org; Thu, 09 Sep 2010 10:57:03 +0200 Received: (qmail 12853 invoked from network); 9 Sep 2010 10:56:58 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 9 Sep 2010 10:56:58 +0200 Received: (qmail 15558 invoked by uid 1001); 9 Sep 2010 10:56:58 +0200 Date: Thu, 9 Sep 2010 10:56:58 +0200 From: Erik Trulsson To: perryh@pluto.rain.com Message-ID: <20100909085658.GA15504@owl.midgard.homeip.net> References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <201009080842.28495.jhb@freebsd.org> <201009081021.48077.jhb@freebsd.org> <4c88993e.MgMUYIGSfJIxECy9%perryh@pluto.rain.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4c88993e.MgMUYIGSfJIxECy9%perryh@pluto.rain.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Originating-IP: 83.255.61.120 X-Scan-Result: No virus found in message 1OtcwH-0000vb-7a. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1OtcwH-0000vb-7a 3007927eb55882bf69c4d05b6dfd1222 Cc: vadim_nuclight@mail.ru, stable@freebsd.org, jhb@freebsd.org Subject: Re: Policy for removing working code X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 08:57:11 -0000 On Thu, Sep 09, 2010 at 01:22:22AM -0700, perryh@pluto.rain.com wrote: > John Baldwin wrote: > > > We can't e-mail announce@ every time something is going to > > be removed. That would be way too much spam for that list. > > That may depend on how often something substantial is removed :) If mails to announce@ were only sent at the point significant stuff actually is removed it might not be all that much traffic, but at that point it seems a bit late for people to protest against the removal since it has already happened. OTOH, if mails were sent to announce@ everytime something was proposed to be removed then there would probably be far too much traffic for that list. (Most discussions regarding removing stuff tend to end up with status quo being maintained.) > > > I do think stable@ is a good place to e-mail ... > > Good, perhaps even "necessary", but is it "sufficient"? Those > following a -STABLE branch are expected to read stable@, but > what about those who are following a security branch? That depends on what they want to know. If they are concerned about things affecting the branch they are following, then announce@ is probably sufficient since all security advisories are sent there and there are essentially no other changes made to a security branch. If, on the other hand, they are interested in what will be included/not included in future major releases, then current@ is pretty much a must-read. -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 09:42:19 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0745F10656C9; Thu, 9 Sep 2010 09:42:19 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 14DFF8FC08; Thu, 9 Sep 2010 09:42:17 +0000 (UTC) Received: by fxm4 with SMTP id 4so852721fxm.13 for ; Thu, 09 Sep 2010 02:42:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mAbmTjuzYlSQdOzOXotVkHNbCnxp7j6HptkqXg4U7t8=; b=EDrq3lnR5PJse/hDrRw+ONCbBf1EosLt4gFHkcwupOCKlDiShRSXFR9E3l6ifUBymN tZHLE1GUqde5sl03aIvFwdMMJaCe5/zED6QtD2rG/6LSHY9W9IwVpSXVLfDumJCIkhrs FbGt08kkFir7WUTl4tSV3P2tXL2hzqhXoM97w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ApVSTfFsdqz52ZEMMpiZ1BOpATuU727RZcI2VhDWpv1kbFoaoFAzOG8h6PImKBN2Ou NXya1WVYL8Cf9g0qToFbxfHWZHNb7Y6WG8vO2/OOQMuOgeMFPCE4tP5sAsM8oLnUA3Ol evqhZD8tS1VdKu8ORDmgteD3g/q9qsbATn4NE= MIME-Version: 1.0 Received: by 10.239.185.148 with SMTP id c20mr467468hbh.138.1284023932410; Thu, 09 Sep 2010 02:18:52 -0700 (PDT) Received: by 10.239.155.129 with HTTP; Thu, 9 Sep 2010 02:18:52 -0700 (PDT) In-Reply-To: <4c88993e.MgMUYIGSfJIxECy9%perryh@pluto.rain.com> References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <201009080842.28495.jhb@freebsd.org> <201009081021.48077.jhb@freebsd.org> <4c88993e.MgMUYIGSfJIxECy9%perryh@pluto.rain.com> Date: Thu, 9 Sep 2010 04:18:52 -0500 Message-ID: From: Scot Hetzel To: perryh@pluto.rain.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vadim_nuclight@mail.ru, stable@freebsd.org, jhb@freebsd.org Subject: Re: Policy for removing working code X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 09:42:19 -0000 On Thu, Sep 9, 2010 at 3:22 AM, wrote: > John Baldwin wrote: > >> We can't e-mail announce@ every time something is going to >> be removed. =A0That would be way too much spam for that list. > > That may depend on how often something substantial is removed :) > >> I do think stable@ is a good place to e-mail ... > > Good, perhaps even "necessary", but is it "sufficient"? =A0Those > following a -STABLE branch are expected to read stable@, but > what about those who are following a security branch? > If someone is following a RELENG_X (a.k.a -STABLE) or a RELENG_X_Y (a errata fix branch), then they should be reading the stable@ list. Scot From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 09:46:33 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42CFD10656B3 for ; Thu, 9 Sep 2010 09:46:33 +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 882758FC08 for ; Thu, 9 Sep 2010 09:46:32 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA28839; Thu, 09 Sep 2010 12:40:42 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OtdcX-0004US-PG; Thu, 09 Sep 2010 12:40:41 +0300 Message-ID: <4C88AB99.9030709@icyb.net.ua> Date: Thu, 09 Sep 2010 12:40:41 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: perryh@pluto.rain.com References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <201009080842.28495.jhb@freebsd.org> <201009081021.48077.jhb@freebsd.org> <4c88993e.MgMUYIGSfJIxECy9%perryh@pluto.rain.com> <4C88AA05.5050909@icyb.net.ua> In-Reply-To: <4C88AA05.5050909@icyb.net.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: Policy for removing nonworking code X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 09:46:33 -0000 on 09/09/2010 12:33 Andriy Gapon said the following: > People, who care, are expected to read current@ and stable@ even if they use > only releases and security branches. At the very least, to see what's cooking > up for them and what to expect. Not to mention isdn@ for this particular case. BTW, I changed the subject line, because the code in question became non-working when Giant support in network stack was dropped. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 09:46:34 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0EE810656E4 for ; Thu, 9 Sep 2010 09:46:34 +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 12C628FC21 for ; Thu, 9 Sep 2010 09:46:33 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA28751; Thu, 09 Sep 2010 12:33:58 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OtdW2-0004Tt-0p; Thu, 09 Sep 2010 12:33:58 +0300 Message-ID: <4C88AA05.5050909@icyb.net.ua> Date: Thu, 09 Sep 2010 12:33:57 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: perryh@pluto.rain.com References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <201009080842.28495.jhb@freebsd.org> <201009081021.48077.jhb@freebsd.org> <4c88993e.MgMUYIGSfJIxECy9%perryh@pluto.rain.com> In-Reply-To: <4c88993e.MgMUYIGSfJIxECy9%perryh@pluto.rain.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: Policy for removing working code X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 09:46:34 -0000 on 09/09/2010 11:22 perryh@pluto.rain.com said the following: > Good, perhaps even "necessary", but is it "sufficient"? Those > following a -STABLE branch are expected to read stable@, but > what about those who are following a security branch? People, who care, are expected to read current@ and stable@ even if they use only releases and security branches. At the very least, to see what's cooking up for them and what to expect. P.S. I am surprised that this thread isn't over yet and is being kept alive by people who do not seem to use the feature in question or offer any work on it. While people, who really need it, have already found a way forward for themselves. P.P.S. Please, please, let it go now. Watch current@, watch stable@ and speak up next time such an announcement is made. Do it on time, don't wait until a few years later :-) -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 11:33:39 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BFFA1065695 for ; Thu, 9 Sep 2010 11:33:39 +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 8A4348FC0C for ; Thu, 9 Sep 2010 11:33:38 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA00656; Thu, 09 Sep 2010 14:33:35 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OtfNn-0004e8-Ko; Thu, 09 Sep 2010 14:33:35 +0300 Message-ID: <4C88C60E.4020309@icyb.net.ua> Date: Thu, 09 Sep 2010 14:33:34 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: nickolasbug@gmail.com References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <201009080842.28495.jhb@freebsd.org> <201009081021.48077.jhb@freebsd.org> <4c88993e.MgMUYIGSfJIxECy9%perryh@pluto.rain.com> <4C88AA05.5050909@icyb.net.ua> <4C88AB99.9030709@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: Policy for removing nonworking code X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 11:33:39 -0000 on 09/09/2010 14:19 nickolasbug@gmail.com said the following: > 2010/9/9 Andriy Gapon : >> on 09/09/2010 12:33 Andriy Gapon said the following: >>> People, who care, are expected to read current@ and stable@ even if they use >>> only releases and security branches. At the very least, to see what's cooking >>> up for them and what to expect. >> >> Not to mention isdn@ for this particular case. >> BTW, I changed the subject line, because the code in question became non-working >> when Giant support in network stack was dropped. > > Please, stop this useless thread You first. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 11:46:45 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C245C10656D1 for ; Thu, 9 Sep 2010 11:46:45 +0000 (UTC) (envelope-from nickolasbug@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 7AAE88FC0A for ; Thu, 9 Sep 2010 11:46:45 +0000 (UTC) Received: by qyk31 with SMTP id 31so6288075qyk.13 for ; Thu, 09 Sep 2010 04:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=J5Gy3vK1lQ77s4XkpoMhZ9zKQzdewM0hD32WyWZj87o=; b=BdSVmDTzRfXB7xMC4YpJG5gYBkmlVdUZvg//9K3isQHZMsYZNDP8+P3nr/5R/vvtJF db5kBv6qediOrByfbrS0sYqZg4Yxp9+ObllGE9eHGjkdd33Kyar62wGrP2QyyUWgpCR/ Ye6u1ZvIDVKKshvivZYbkOTyTIsVBWUdVK5+M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=M2j6FiPUqPk63XrV9WYBN8oZY+ds1LvYcnBnP7aaNvNUnm+PIHfjScxKA1pylCI8SJ SaOLphz5EdOjGywBYdnjD3fSGJ/VbTMd7DDZONacIUEvB0t0awGF/SwabTLxJFgw43+I OGld9utYdBQfbBFO/sn9Cy960ywA48P+7N4n4= MIME-Version: 1.0 Received: by 10.229.86.69 with SMTP id r5mr1273232qcl.97.1284031143561; Thu, 09 Sep 2010 04:19:03 -0700 (PDT) Received: by 10.229.215.145 with HTTP; Thu, 9 Sep 2010 04:19:03 -0700 (PDT) In-Reply-To: <4C88AB99.9030709@icyb.net.ua> References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <201009080842.28495.jhb@freebsd.org> <201009081021.48077.jhb@freebsd.org> <4c88993e.MgMUYIGSfJIxECy9%perryh@pluto.rain.com> <4C88AA05.5050909@icyb.net.ua> <4C88AB99.9030709@icyb.net.ua> Date: Thu, 9 Sep 2010 14:19:03 +0300 Message-ID: From: nickolasbug@gmail.com To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org, perryh@pluto.rain.com Subject: Re: Policy for removing nonworking code X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 11:46:45 -0000 2010/9/9 Andriy Gapon : > on 09/09/2010 12:33 Andriy Gapon said the following: >> People, who care, are expected to read current@ and stable@ even if they= use >> only releases and security branches. =A0At the very least, to see what's= cooking >> up for them and what to expect. > > Not to mention isdn@ for this particular case. > BTW, I changed the subject line, because the code in question became non-= working > when Giant support in network stack was dropped. Please, stop this useless thread From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 12:54:15 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A36BF10656C9 for ; Thu, 9 Sep 2010 12:54:15 +0000 (UTC) (envelope-from bsd@lordcow.org) Received: from lordcow.org (lordcow.org [41.203.5.188]) by mx1.freebsd.org (Postfix) with ESMTP id C14FD8FC1E for ; Thu, 9 Sep 2010 12:54:14 +0000 (UTC) Received: from lordcow.org (localhost [127.0.0.1]) by lordcow.org (8.14.4/8.14.4) with ESMTP id o89Cs6Ka020877 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Thu, 9 Sep 2010 14:54:06 +0200 (SAST) (envelope-from lordcow@lordcow.org) Received: (from lordcow@localhost) by lordcow.org (8.14.4/8.14.4/Submit) id o89Cs1Cv020875 for stable@freebsd.org; Thu, 9 Sep 2010 14:54:01 +0200 (SAST) (envelope-from lordcow) Date: Thu, 9 Sep 2010 14:54:01 +0200 From: Gareth de Vaux To: stable@freebsd.org Message-ID: <20100909125400.GA18723@lordcow.org> References: <20100906155350.GA50151@lordcow.org> <20100908094050.GA73841@lordcow.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lordcow.org Cc: Subject: Re: MSIX failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 12:54:15 -0000 On Wed 2010-09-08 (09:41), Jack Vogel wrote: > This is what'd I'd expect, the onboard is PCH chipset, support was not in > 8.0, but as I said, in 8.1 (and hence stable/8) it is supported, and it should > work. I've just paid the machine a visit and yes, MSIX fails on the onboard but the device still works. The PCI card however doesn't work, whereas it did when using 8.0-RELEASE. (There is occasional activity from tcpdump). I'm able to use the onboard so I can survive, but FYI, the PCI card output: kernel: em1: port 0x1000-0x103f mem 0xe3120000-0xe313ffff,0xe3100000-0xe311ffff irq 9 at device 1.0 on pci5 kernel: em1: [FILTER] kernel: em1: Ethernet address: 00:1b:21:5b:f2:18 (no MSIX failure here, or in 8.0-RELEASE) $ ifconfig em1 em1: flags=8802 metric 0 mtu 1500 options=209b ether 00:1b:21:5b:f2:18 media: Ethernet autoselect status: no carrier pciconf -lv: em1@pci0:5:1:0: class=0x020000 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' class = network subclass = ethernet From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 13:13:43 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E9D710656D1 for ; Thu, 9 Sep 2010 13:13:43 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by mx1.freebsd.org (Postfix) with ESMTP id AC7BD8FC12 for ; Thu, 9 Sep 2010 13:13:42 +0000 (UTC) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta15.westchester.pa.mail.comcast.net with comcast id 4afV1f0031c6gX85FdDioH; Thu, 09 Sep 2010 13:13:42 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta23.westchester.pa.mail.comcast.net with comcast id 4dDh1f00Z3LrwQ23jdDiZ9; Thu, 09 Sep 2010 13:13:42 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 50EEB9B423; Thu, 9 Sep 2010 06:13:40 -0700 (PDT) Date: Thu, 9 Sep 2010 06:13:40 -0700 From: Jeremy Chadwick To: Gareth de Vaux Message-ID: <20100909131340.GA75829@icarus.home.lan> References: <20100906155350.GA50151@lordcow.org> <20100908094050.GA73841@lordcow.org> <20100909125400.GA18723@lordcow.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100909125400.GA18723@lordcow.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: stable@freebsd.org Subject: Re: MSIX failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 13:13:43 -0000 On Thu, Sep 09, 2010 at 02:54:01PM +0200, Gareth de Vaux wrote: > On Wed 2010-09-08 (09:41), Jack Vogel wrote: > > This is what'd I'd expect, the onboard is PCH chipset, support was not in > > 8.0, but as I said, in 8.1 (and hence stable/8) it is supported, and it should > > work. > > I've just paid the machine a visit and yes, MSIX fails on the onboard but > the device still works. > > The PCI card however doesn't work, whereas it did when using 8.0-RELEASE. > (There is occasional activity from tcpdump). I'm able to use the onboard > so I can survive, but FYI, the PCI card output: > > kernel: em1: port 0x1000-0x103f mem 0xe3120000-0xe313ffff,0xe3100000-0xe311ffff irq 9 at device 1.0 on pci5 > kernel: em1: [FILTER] > kernel: em1: Ethernet address: 00:1b:21:5b:f2:18 > > (no MSIX failure here, or in 8.0-RELEASE) > > $ ifconfig em1 > em1: flags=8802 metric 0 mtu 1500 > options=209b > ether 00:1b:21:5b:f2:18 > media: Ethernet autoselect > status: no carrier > > pciconf -lv: > > em1@pci0:5:1:0: class=0x020000 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' > class = network > subclass = ethernet Can you add the "-c" flag to your pciconf command? Thanks. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 13:25:32 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 715D810656C2 for ; Thu, 9 Sep 2010 13:25:32 +0000 (UTC) (envelope-from bsd@lordcow.org) Received: from lordcow.org (lordcow.org [41.203.5.188]) by mx1.freebsd.org (Postfix) with ESMTP id 8ED6B8FC1B for ; Thu, 9 Sep 2010 13:25:30 +0000 (UTC) Received: from lordcow.org (localhost [127.0.0.1]) by lordcow.org (8.14.4/8.14.4) with ESMTP id o89DPOhn022272 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Thu, 9 Sep 2010 15:25:24 +0200 (SAST) (envelope-from lordcow@lordcow.org) Received: (from lordcow@localhost) by lordcow.org (8.14.4/8.14.4/Submit) id o89DPJlf022271 for stable@freebsd.org; Thu, 9 Sep 2010 15:25:19 +0200 (SAST) (envelope-from lordcow) Date: Thu, 9 Sep 2010 15:25:19 +0200 From: Gareth de Vaux To: stable@freebsd.org Message-ID: <20100909132519.GB21535@lordcow.org> References: <20100906155350.GA50151@lordcow.org> <20100908094050.GA73841@lordcow.org> <20100909125400.GA18723@lordcow.org> <20100909131340.GA75829@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100909131340.GA75829@icarus.home.lan> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lordcow.org Cc: Subject: Re: MSIX failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 13:25:32 -0000 On Thu 2010-09-09 (06:13), Jeremy Chadwick wrote: > Can you add the "-c" flag to your pciconf command? Thanks. Forbidden? # pciconf -lvc pciconf: /dev/pci: Operation not permitted # pciconf -lc pciconf: /dev/pci: Operation not permitted # ls -l /dev/pci crw-r--r-- 1 root wheel 0, 9 Sep 9 11:55 /dev/pci From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 13:31:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC97A10656CB for ; Thu, 9 Sep 2010 13:31:53 +0000 (UTC) (envelope-from O.Seibert@cs.ru.nl) Received: from rustug.science.ru.nl (rustug.science.ru.nl [131.174.16.158]) by mx1.freebsd.org (Postfix) with ESMTP id 4FDA28FC1C for ; Thu, 9 Sep 2010 13:31:52 +0000 (UTC) Received: from kookpunt.science.ru.nl (kookpunt.science.ru.nl [131.174.30.61]) by rustug.science.ru.nl (8.13.7/5.31) with ESMTP id o89DAK3t015605 for ; Thu, 9 Sep 2010 15:10:20 +0200 (MEST) Received: from twoquid.cs.ru.nl (twoquid.cs.ru.nl [131.174.142.38]) by kookpunt.science.ru.nl (8.13.7/5.31) with ESMTP id o89DAHfA000284; Thu, 9 Sep 2010 15:10:17 +0200 (MEST) Received: by twoquid.cs.ru.nl (Postfix, from userid 4100) id CC0E52E04F; Thu, 9 Sep 2010 15:10:17 +0200 (CEST) Date: Thu, 9 Sep 2010 15:10:17 +0200 From: Olaf Seibert To: freebsd-stable@freebsd.org Message-ID: <20100909131017.GO4404@twoquid.cs.ru.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) X-Spam-Score: -1.799 () ALL_TRUSTED,BAYES_50 X-Scanned-By: MIMEDefang 2.63 on 131.174.30.61 Subject: mountd has resolving problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 13:31:53 -0000 I just upgraded a box from 8.0 to 8.1, and already when rebooting with the new kernel (i.e. before installing new userland), I got the following problem. Of course many of the messages scrolled off screen, but some were preserved in the syslog. Sep 9 14:26:51 fourquid mountd[839]: can't get address info for host XYZ Sep 9 14:26:51 fourquid mountd[839]: bad host XYZ in netgroup vbgroup, skipping Mountd was run and wanted to determine which hosts to export to. However, it could not resolve any of them. So, that suggests some network issue. However, I use a static IP address (no DHCP) and static info in /etc/resolv.conf, using one of the university's name servers. So resolving should always be available. Running /etc/rc.d/mountd restart so far always solved the export problem. I have also seen (presumably similar) issues with mounting NFS file systems, but that was deemed so fatal that the boot was aborted. A mount ``by hand'' of the affected file system also worked. Any ideas? Maybe with the new kernel the network interface is a bit slower in coming up, and not fully working by the time /etc/rc.d/mountd runs? In fact, I now notice this sequence of messages in /var/log/messages: Sep 9 14:26:51 fourquid mountd[839]: bad host XYZ in netgroup vbgroup, skipping Sep 9 14:26:51 fourquid mountd[839]: bad exports list line /xxxxxx Sep 9 14:26:54 fourquid kernel: fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 Sep 9 14:26:54 fourquid init: /bin/sh on /etc/rc terminated abnormally, going to single user mode Sep 9 14:26:55 fourquid kernel: nfe0: link state changed to UP so here the network interface takes a full 4 more seconds to come up, after it was already needed. I can try to put a 10 sec delay somewhere, but there should be a better solution... -Olaf. -- From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 13:40:35 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FDD010656B3 for ; Thu, 9 Sep 2010 13:40:35 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id C351E8FC1D for ; Thu, 9 Sep 2010 13:40:34 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OthMf-0005vt-49 for freebsd-stable@freebsd.org; Thu, 09 Sep 2010 15:40:33 +0200 Received: from nuclight.avtf.net ([217.29.94.29]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Sep 2010 15:40:33 +0200 Received: from vadim_nuclight by nuclight.avtf.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Sep 2010 15:40:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Vadim Goncharov Date: Thu, 9 Sep 2010 13:40:23 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 32 Message-ID: References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <4C8704E3.5000408@FreeBSD.org> <201009080842.28495.jhb@freebsd.org> <4C879A09.9080804@icyb.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: nuclight.avtf.net X-Comment-To: Andriy Gapon User-Agent: slrn/0.9.9p1 (FreeBSD) Subject: Re: Policy for removing working code X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 13:40:35 -0000 Hi Andriy Gapon! On Wed, 08 Sep 2010 17:13:29 +0300; Andriy Gapon wrote about 'Re: Policy for removing working code': >> network stack, it is deeper. It is the policy or may be style of thought, >> discourse. Something like: >> progress dictates we need fix/maintainership to feature X >> & we have no resources to maintain feature X >> -> we announce theis need, but only to _limited_ audience, not wide circles >> -> nobody responds >> -> the X code is removed >> AND we think this logic chain is correct, thought we did not things this way >> even 5 years ago. > So, get to work, become a committer, get elected to core and have a control over > these procedures. [And maybe your perspectives will change along the way] > Until then, please, let's stop wasting time on this issue. And, after several years for all of this, to see that FreeBSD have lost many old users? That's will be too late. You retort here ad hominem, while the policy quoted above is true. Nobody has to be core@ member to predict this policy will eventually harm FreeBSD userbase. Anybody could say that meal is bad, he don't need to be head-cook for this to taste and say. P.S. If I couldn't explain why you were wrong here, there is an article in another language that does this much better: http://lurkmore.ru//%D0%A1%D0%BF%D0%B5%D1%80%D0%B2%D0%B0_%D0%B4%D0%BE%D0%B1%D0%B5%D0%B9%D1%81%D1%8F -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 13:57:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF20210656BD for ; Thu, 9 Sep 2010 13:57:53 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 444A08FC1A for ; Thu, 9 Sep 2010 13:57:53 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OthdL-0000CA-Vn for freebsd-stable@freebsd.org; Thu, 09 Sep 2010 15:57:47 +0200 Received: from nuclight.avtf.net ([217.29.94.29]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Sep 2010 15:57:47 +0200 Received: from vadim_nuclight by nuclight.avtf.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Sep 2010 15:57:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Vadim Goncharov Date: Thu, 9 Sep 2010 13:57:38 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 106 Message-ID: References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <201009080842.28495.jhb@freebsd.org> <201009081021.48077.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: nuclight.avtf.net X-Comment-To: John Baldwin User-Agent: slrn/0.9.9p1 (FreeBSD) Subject: Re: Policy for removing working code X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 13:57:53 -0000 Hi John Baldwin! On Wed, 8 Sep 2010 10:21:47 -0400; John Baldwin wrote about 'Re: Policy for removing working code': >>> No, that would require maintaining two network stacks, not just one. The >>> shims to allow unlocked code to run were not trivial. The choices were this: >> >>> 1) Moving forward on work to allow the network stack to scale on SMP >>> systems (e.g. modern x86 multi-core servers) and support higher rate >>> protocols such as 10GB, 40GB, and 100GB. >> >>> 2) Stop all progress on making the network stack scale on SMP. >> >>> I'm sorry, but 2) just isn't feasible. Not if FreeBSD is to continue to be a >>> modern, relevant system. >> >> If it is the only variants, then I'll agree (but only on this part). Are there >> really no other variants? What do other OSes to which, as was said, we have to >> compete? E.g. Linux? > > Yes, other OS's (Windows, Linux, Solaris) all are working on the multi-core > problem. OS's that aren't working on this will soon be obsolete. Even modern > embedded systems are multi-core (e.g. many MIPs chips now include multiple > cores on a chip, even SMT similar to Intel's HyperThreading on RMI's MIPs > SOCs). My question is not quite the same as that to which you've answered. I agree that non-SMP OS's will be obsolete, but what that OSes do in such particular cases? >>> Also, despite your claims to the contrary, there _was_ adequate notice: >>> http://lists.freebsd.org/pipermail/freebsd-current/2007-June/072977.html >>> This was also documented in the release notes for 7.0: >>> http://www.freebsd.org/releases/7.0R/relnotes.html >> >> No, my claims were that there was no _adequate_ notice, and this links >> acknowledge this. 7.0 Release notes state about broken ISDN as an already >> happened fact, user can't do anything about it already. As I've shown in >> message to vwe@, it wasn't in announce@ and even in stable@. Number of >> users/subscribers of lists can be expressed as: >> >> # devel lists < # current@ < # stable@ < # announce@ < # of total FreeBSD users >> >> While we can't do anything with those who not subscribed even to announce@ >> (though should it be duplicated on www may be?), number of announce@ readers >> is still MUCH more than that of current@, not even mention devel lists. > We can't e-mail announce@ every time something is going to be removed. That > would be way too much spam for that list. No, not everytime and everything, of course. That will go to far to other end. I mean every major event, e.g. each ordinary driver is not worth noting (too much spam), but in this case there were TWO not drivers, but subsystems (ISDN and netatm). One symptom that could indicate this is major event, not minor, is call for volunteers. This is definitely happens not too often. > I do think stable@ is a good place > to e-mail, and I did in fact mail my locking patches for the various NIC > drivers to stable@. In some cases I did only find testers via stable@ and > not via current@. I do think that the general rule is that stable@ should be > on the list. It is true that that did not happen in this case (and probably > should have), but it does happen in the typical case. I would chalk this up > to a one-time slip-up, not a systemic problem. You said about testers, and testers are already involved somehow to the project, at least are subscribed to lists. But testers are in general for testing new features (positive), but not all FreeBSD users need new fetures that fast. They are more concerned about feature removal (negative). Such announcements need to be made at least for them to have migration plan - just like Security Officer informs about EoL before that happens, for people have time to plan maintenance and upgrade. >>> If you wish to help work on ISDN support, I suggest you offer to test hps@' >>> ISDN stack. hps@ recently became a committer so I think there is a very good >>> chance his code will be brought into the tree. >>> We do have a policy for removing code in that it only gets removed if no one >>> is able to maintain it and/or test patches for it. I locked several of the >>> remaining NIC drivers during the push to remove Giant and a few of them were >>> removed from the system because no one had the hardware around to test the >>> patches to add locking (think of really old ISA NICs that only do 10Mbps). >> >> Big thanks for your work, but unfortunately, the problem itself is not ISDN or >> network stack, it is deeper. It is the policy or may be style of thought, >> discourse. Something like: >> progress dictates we need fix/maintainership to feature X >> & we have no resources to maintain feature X >> -> we announce theis need, but only to _limited_ audience, not wide circles >> -> nobody responds >> -> the X code is removed >> AND we think this logic chain is correct, thought we did not things this way >> even 5 years ago. > Actually, things have worked this way far longer than 5 years ago. For > example, we lost a few SCSI HBA drivers during the transition to CAM (e.g. > wds(4) was not present in 4.x but was eventually CAM-ified and reappeared > in 5.0). I suspect there was far less notice given for those drivers > than for ISDN (multiple notices to arch@ and current@ spread out across > many months). Not entirely so. Individual drivers are more minor changes than major ones, and still 5 years ago there were messages to announce@ about such removals when there many-many of them, e.g. from Kris Kennaway. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 14:02:27 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47FDA10656C2 for ; Thu, 9 Sep 2010 14:02:27 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id 2A5018FC12 for ; Thu, 9 Sep 2010 14:02:26 +0000 (UTC) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta09.emeryville.ca.mail.comcast.net with comcast id 4czi1f0011u4NiLA9e2SK9; Thu, 09 Sep 2010 14:02:26 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta21.emeryville.ca.mail.comcast.net with comcast id 4e2Q1f00C3LrwQ28he2RbL; Thu, 09 Sep 2010 14:02:26 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id D93009B423; Thu, 9 Sep 2010 07:02:24 -0700 (PDT) Date: Thu, 9 Sep 2010 07:02:24 -0700 From: Jeremy Chadwick To: Gareth de Vaux Message-ID: <20100909140224.GA76889@icarus.home.lan> References: <20100906155350.GA50151@lordcow.org> <20100908094050.GA73841@lordcow.org> <20100909125400.GA18723@lordcow.org> <20100909131340.GA75829@icarus.home.lan> <20100909132519.GB21535@lordcow.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100909132519.GB21535@lordcow.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: stable@freebsd.org Subject: Re: MSIX failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 14:02:27 -0000 On Thu, Sep 09, 2010 at 03:25:19PM +0200, Gareth de Vaux wrote: > On Thu 2010-09-09 (06:13), Jeremy Chadwick wrote: > > Can you add the "-c" flag to your pciconf command? Thanks. > > Forbidden? > > # pciconf -lvc > pciconf: /dev/pci: Operation not permitted > # pciconf -lc > pciconf: /dev/pci: Operation not permitted > # ls -l /dev/pci > crw-r--r-- 1 root wheel 0, 9 Sep 9 11:55 /dev/pci You need to be root to use the -c flag. Despite your prompt, I don't think you're root. Reproduction: $ id uid=1000(jdc) gid=1000(users) groups=1000(users),0(wheel) $ pciconf -lv | wc -l 114 $ pciconf -lc pciconf: /dev/pci: Permission denied $ sudo -i box# id uid=0(root) gid=0(wheel) groups=0(wheel),5(operator) box# pciconf -lc | wc -l 73 -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 14:03:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E94DC1065696 for ; Thu, 9 Sep 2010 14:03:51 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 9D76B8FC08 for ; Thu, 9 Sep 2010 14:03:51 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OthjC-0003z8-6Y for freebsd-stable@freebsd.org; Thu, 09 Sep 2010 16:03:50 +0200 Received: from nuclight.avtf.net ([217.29.94.29]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Sep 2010 16:03:50 +0200 Received: from vadim_nuclight by nuclight.avtf.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Sep 2010 16:03:50 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Vadim Goncharov Date: Thu, 9 Sep 2010 14:03:33 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 27 Message-ID: References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <201009080842.28495.jhb@freebsd.org> <201009081021.48077.jhb@freebsd.org> <4c88993e.MgMUYIGSfJIxECy9%perryh@pluto.rain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: nuclight.avtf.net X-Comment-To: Scot Hetzel User-Agent: slrn/0.9.9p1 (FreeBSD) Subject: Re: Policy for removing working code X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 14:03:52 -0000 Hi Scot Hetzel! On Thu, 9 Sep 2010 04:18:52 -0500; Scot Hetzel wrote about 'Re: Policy for removing working code': >>> We can't e-mail announce@ every time something is going to >>> be removed. šThat would be way too much spam for that list. >> >> That may depend on how often something substantial is removed :) >> >>> I do think stable@ is a good place to e-mail ... >> >> Good, perhaps even "necessary", but is it "sufficient"? šThose >> following a -STABLE branch are expected to read stable@, but >> what about those who are following a security branch? >> > If someone is following a RELENG_X (a.k.a -STABLE) or a RELENG_X_Y (a > errata fix branch), then they should be reading the stable@ list. True for RELENG_X, but not for RELENG_X_Y. They shouldn't, because all information for security/errata fix branch go to announce@, they don't need to read all noise in stable@ just for this. And, what is more important, they in fact don't do. So announce@ is the only choice from purely practical means. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 14:05:31 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB59410656BB for ; Thu, 9 Sep 2010 14:05:31 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by mx1.freebsd.org (Postfix) with ESMTP id 918928FC21 for ; Thu, 9 Sep 2010 14:05:31 +0000 (UTC) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta15.emeryville.ca.mail.comcast.net with comcast id 4bSv1f0050QkzPwAFe5XaA; Thu, 09 Sep 2010 14:05:31 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta02.emeryville.ca.mail.comcast.net with comcast id 4e5V1f00L3LrwQ28Ne5WAT; Thu, 09 Sep 2010 14:05:30 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id C76689B423; Thu, 9 Sep 2010 07:05:29 -0700 (PDT) Date: Thu, 9 Sep 2010 07:05:29 -0700 From: Jeremy Chadwick To: Olaf Seibert Message-ID: <20100909140529.GB76889@icarus.home.lan> References: <20100909131017.GO4404@twoquid.cs.ru.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100909131017.GO4404@twoquid.cs.ru.nl> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: mountd has resolving problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 14:05:31 -0000 On Thu, Sep 09, 2010 at 03:10:17PM +0200, Olaf Seibert wrote: > I just upgraded a box from 8.0 to 8.1, and already when rebooting with > the new kernel (i.e. before installing new userland), I got the > following problem. > > Of course many of the messages scrolled off screen, but some were > preserved in the syslog. > > Sep 9 14:26:51 fourquid mountd[839]: can't get address info for host XYZ > Sep 9 14:26:51 fourquid mountd[839]: bad host XYZ in netgroup vbgroup, skipping > > Mountd was run and wanted to determine which hosts to export to. > However, it could not resolve any of them. So, that suggests some > network issue. > > However, I use a static IP address (no DHCP) and static info in > /etc/resolv.conf, using one of the university's name servers. So > resolving should always be available. > > Running /etc/rc.d/mountd restart so far always solved the export > problem. > > I have also seen (presumably similar) issues with mounting NFS file > systems, but that was deemed so fatal that the boot was aborted. A mount > ``by hand'' of the affected file system also worked. > > Any ideas? Maybe with the new kernel the network interface is a bit > slower in coming up, and not fully working by the time /etc/rc.d/mountd > runs? In fact, I now notice this sequence of messages in > /var/log/messages: > > Sep 9 14:26:51 fourquid mountd[839]: bad host XYZ in netgroup vbgroup, skipping > Sep 9 14:26:51 fourquid mountd[839]: bad exports list line /xxxxxx > Sep 9 14:26:54 fourquid kernel: fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 > Sep 9 14:26:54 fourquid init: /bin/sh on /etc/rc terminated abnormally, going to single user mode > Sep 9 14:26:55 fourquid kernel: nfe0: link state changed to UP > > so here the network interface takes a full 4 more seconds to come up, > after it was already needed. > > I can try to put a 10 sec delay somewhere, but there should be a better > solution... The problem is that the network isn't "truly" up and available by the time mountd runs, and therefore DNS resolution doesn't work. Please use my netwait script to solve this problem: http://jdc.parodius.com/freebsd/netwait Place it in /usr/local/etc/rc.d, make sure it's chmod'd to 755, then enable use of it by using /etc/rc.conf variables like so: netwait_enable="yes" netwait_ip="4.2.2.1 4.2.2.2" netwait_if="nfe0" For what the variables do, please see the script comments. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 14:10:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F18410656BC for ; Thu, 9 Sep 2010 14:10:05 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 391348FC1E for ; Thu, 9 Sep 2010 14:10:05 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OthpE-0007dH-5h for freebsd-stable@freebsd.org; Thu, 09 Sep 2010 16:10:04 +0200 Received: from nuclight.avtf.net ([217.29.94.29]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Sep 2010 16:10:04 +0200 Received: from vadim_nuclight by nuclight.avtf.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Sep 2010 16:10:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Vadim Goncharov Date: Thu, 9 Sep 2010 14:07:08 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 25 Message-ID: References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <201009080842.28495.jhb@freebsd.org> <201009081021.48077.jhb@freebsd.org> <4c88993e.MgMUYIGSfJIxECy9%perryh@pluto.rain.com> <4C88AA05.5050909@icyb.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: nuclight.avtf.net X-Comment-To: Andriy Gapon User-Agent: slrn/0.9.9p1 (FreeBSD) Subject: Re: Policy for removing working code X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 14:10:05 -0000 Hi Andriy Gapon! On Thu, 09 Sep 2010 12:33:57 +0300; Andriy Gapon wrote about 'Re: Policy for removing working code': >> Good, perhaps even "necessary", but is it "sufficient"? Those >> following a -STABLE branch are expected to read stable@, but >> what about those who are following a security branch? > People, who care, are expected to read current@ and stable@ even if they use > only releases and security branches. At the very least, to see what's cooking > up for them and what to expect. Hey, by whom expected? They are NOT expected to do this! Can you quote some official docs or statements for this? > P.S. I am surprised that this thread isn't over yet and is being kept alive by > people who do not seem to use the feature in question or offer any work on it. > While people, who really need it, have already found a way forward for themselves. Because this thread is not about this feature but about policy which will slowly bring FreeBSD project to troubles if nothing will be changed. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 14:17:04 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 901231065673 for ; Thu, 9 Sep 2010 14:17:04 +0000 (UTC) (envelope-from O.Seibert@cs.ru.nl) Received: from kookpunt.science.ru.nl (kookpunt.science.ru.nl [131.174.30.61]) by mx1.freebsd.org (Postfix) with ESMTP id 2B5248FC1C for ; Thu, 9 Sep 2010 14:17:03 +0000 (UTC) Received: from twoquid.cs.ru.nl (twoquid.cs.ru.nl [131.174.142.38]) by kookpunt.science.ru.nl (8.13.7/5.31) with ESMTP id o89EH2UY004003; Thu, 9 Sep 2010 16:17:02 +0200 (MEST) Received: by twoquid.cs.ru.nl (Postfix, from userid 4100) id 6C11E2E04F; Thu, 9 Sep 2010 16:17:02 +0200 (CEST) Date: Thu, 9 Sep 2010 16:17:02 +0200 From: Olaf Seibert To: freebsd-stable@freebsd.org Message-ID: <20100909141702.GP4404@twoquid.cs.ru.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) X-Spam-Score: -1.799 () ALL_TRUSTED,BAYES_50 X-Scanned-By: MIMEDefang 2.63 on 131.174.30.61 Subject: Can't build 8.1 GENERIC kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 14:17:04 -0000 I'm trying to build a custom kernel, and I got an error. So I tried GENERIC, in the perhaps old-fashioned way of # config GENERIC # cd ../compile/GENERIC # make depend # make and I get a complaint about a file named ``hack.So''. Here is what happens if I remove it again to get it re-made: $ sudo make :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=make sh ../../../conf/newvers.sh GENERIC cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I../../.. -I../../../contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror vers.c linking kernel.debug hack.So: could not read symbols: File in wrong format *** Error code 1 Stop in /usr/src/sys/amd64/compile/GENERIC. Am I the only one who is seeing this? ``file'' thinks this: $ file hack.So hack.So: ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically linked, not stripped -Olaf. -- From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 14:21:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8037A10656AA for ; Thu, 9 Sep 2010 14:21:00 +0000 (UTC) (envelope-from thomas@ronner.org) Received: from mail.knopje.net (unknown [IPv6:2001:470:1f15:a0::10]) by mx1.freebsd.org (Postfix) with ESMTP id 4301E8FC0A for ; Thu, 9 Sep 2010 14:21:00 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.knopje.net (Postfix) with ESMTP id 89DD438139 for ; Thu, 9 Sep 2010 16:20:59 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at knopje.net Received: from mail.knopje.net ([127.0.0.1]) by localhost (hal.knopje.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yH-rqgXYadA for ; Thu, 9 Sep 2010 16:20:56 +0200 (CEST) Received: from appelflap.local (cl-1815.ams-05.nl.sixxs.net [IPv6:2001:610:600:716::2]) by mail.knopje.net (Postfix) with ESMTPSA id DCD92380F2 for ; Thu, 9 Sep 2010 16:20:56 +0200 (CEST) Message-ID: <4C88ED48.7020204@ronner.org> Date: Thu, 09 Sep 2010 16:20:56 +0200 From: Thomas Ronner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20100909141702.GP4404@twoquid.cs.ru.nl> In-Reply-To: <20100909141702.GP4404@twoquid.cs.ru.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Can't build 8.1 GENERIC kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 14:21:00 -0000 Hi Olaf, On 09/09/2010 16:17, Olaf Seibert wrote: > I'm trying to build a custom kernel, and I got an error. So I tried > GENERIC, in the perhaps old-fashioned way of > > # config GENERIC > # cd ../compile/GENERIC > # make depend > # make > I don't know about the old-fashioned way, but the new way is: # cd /usr/src # make buildkernel KERNCONF=GENERIC # make installkernel KERNCONF=GENERIC The KERNCONF=GENERIC is redundant, because the GENERIC config is default. Thomas From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 14:22:40 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D67410656AA for ; Thu, 9 Sep 2010 14:22:40 +0000 (UTC) (envelope-from bsd@lordcow.org) Received: from lordcow.org (lordcow.org [41.203.5.188]) by mx1.freebsd.org (Postfix) with ESMTP id 614068FC1D for ; Thu, 9 Sep 2010 14:22:38 +0000 (UTC) Received: from lordcow.org (localhost [127.0.0.1]) by lordcow.org (8.14.4/8.14.4) with ESMTP id o89EMVDb025720 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Thu, 9 Sep 2010 16:22:31 +0200 (SAST) (envelope-from lordcow@lordcow.org) Received: (from lordcow@localhost) by lordcow.org (8.14.4/8.14.4/Submit) id o89EMQtb025719 for stable@freebsd.org; Thu, 9 Sep 2010 16:22:26 +0200 (SAST) (envelope-from lordcow) Date: Thu, 9 Sep 2010 16:22:26 +0200 From: Gareth de Vaux To: stable@freebsd.org Message-ID: <20100909142226.GA25370@lordcow.org> References: <20100906155350.GA50151@lordcow.org> <20100908094050.GA73841@lordcow.org> <20100909125400.GA18723@lordcow.org> <20100909131340.GA75829@icarus.home.lan> <20100909132519.GB21535@lordcow.org> <20100909140224.GA76889@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100909140224.GA76889@icarus.home.lan> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lordcow.org Cc: Subject: Re: MSIX failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 14:22:40 -0000 On Thu 2010-09-09 (07:02), Jeremy Chadwick wrote: > You need to be root to use the -c flag. Despite your prompt, I don't > think you're root. Reproduction: That was as root, # id uid=0(root) gid=0(wheel) groups=0(wheel),5(operator) # pciconf -lc pciconf: /dev/pci: Operation not permitted From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 14:24:57 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 542BA10656F1 for ; Thu, 9 Sep 2010 14:24:57 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by mx1.freebsd.org (Postfix) with ESMTP id 3784F8FC2E for ; Thu, 9 Sep 2010 14:24:57 +0000 (UTC) Received: from omta01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by qmta14.emeryville.ca.mail.comcast.net with comcast id 4cWe1f0020EPchoAEeQwM0; Thu, 09 Sep 2010 14:24:56 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta01.emeryville.ca.mail.comcast.net with comcast id 4eQw1f0013LrwQ28MeQwrC; Thu, 09 Sep 2010 14:24:56 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id ED63D9B423; Thu, 9 Sep 2010 07:24:55 -0700 (PDT) Date: Thu, 9 Sep 2010 07:24:55 -0700 From: Jeremy Chadwick To: Gareth de Vaux Message-ID: <20100909142455.GA77677@icarus.home.lan> References: <20100908094050.GA73841@lordcow.org> <20100909125400.GA18723@lordcow.org> <20100909131340.GA75829@icarus.home.lan> <20100909132519.GB21535@lordcow.org> <20100909140224.GA76889@icarus.home.lan> <20100909142226.GA25370@lordcow.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100909142226.GA25370@lordcow.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: stable@freebsd.org Subject: Re: MSIX failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 14:24:57 -0000 On Thu, Sep 09, 2010 at 04:22:26PM +0200, Gareth de Vaux wrote: > On Thu 2010-09-09 (07:02), Jeremy Chadwick wrote: > > You need to be root to use the -c flag. Despite your prompt, I don't > > think you're root. Reproduction: > > That was as root, > > # id > uid=0(root) gid=0(wheel) groups=0(wheel),5(operator) > # pciconf -lc > pciconf: /dev/pci: Operation not permitted Is this within a jail or something else along those lines? I can't reproduce the problem otherwise. Frustrating! Someone else on the list might have ideas as to what could cause this. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 14:29:41 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC22A10656A5 for ; Thu, 9 Sep 2010 14:29:41 +0000 (UTC) (envelope-from bsd@lordcow.org) Received: from lordcow.org (lordcow.org [41.203.5.188]) by mx1.freebsd.org (Postfix) with ESMTP id 186DB8FC08 for ; Thu, 9 Sep 2010 14:29:40 +0000 (UTC) Received: from lordcow.org (localhost [127.0.0.1]) by lordcow.org (8.14.4/8.14.4) with ESMTP id o89ETXjq026245 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Thu, 9 Sep 2010 16:29:33 +0200 (SAST) (envelope-from lordcow@lordcow.org) Received: (from lordcow@localhost) by lordcow.org (8.14.4/8.14.4/Submit) id o89ETSie026244 for stable@freebsd.org; Thu, 9 Sep 2010 16:29:28 +0200 (SAST) (envelope-from lordcow) Date: Thu, 9 Sep 2010 16:29:28 +0200 From: Gareth de Vaux To: stable@freebsd.org Message-ID: <20100909142928.GA25877@lordcow.org> References: <20100908094050.GA73841@lordcow.org> <20100909125400.GA18723@lordcow.org> <20100909131340.GA75829@icarus.home.lan> <20100909132519.GB21535@lordcow.org> <20100909140224.GA76889@icarus.home.lan> <20100909142226.GA25370@lordcow.org> <20100909142455.GA77677@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100909142455.GA77677@icarus.home.lan> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lordcow.org Cc: Subject: Re: MSIX failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 14:29:42 -0000 On Thu 2010-09-09 (07:24), Jeremy Chadwick wrote: > Is this within a jail or something else along those lines? I can't > reproduce the problem otherwise. Frustrating! Someone else on the list > might have ideas as to what could cause this. Nope, this's a normal host. I've got securelevel on 1, but doubt that would affect this? From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 14:33:56 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5A2610656C0 for ; Thu, 9 Sep 2010 14:33:56 +0000 (UTC) (envelope-from pi@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id 60A308FC0A for ; Thu, 9 Sep 2010 14:33:56 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OtiCL-000B0Z-GO; Thu, 09 Sep 2010 16:33:57 +0200 Date: Thu, 9 Sep 2010 16:33:57 +0200 From: Kurt Jaeger To: Gareth de Vaux Message-ID: <20100909143357.GG34314@home.opsec.eu> References: <20100908094050.GA73841@lordcow.org> <20100909125400.GA18723@lordcow.org> <20100909131340.GA75829@icarus.home.lan> <20100909132519.GB21535@lordcow.org> <20100909140224.GA76889@icarus.home.lan> <20100909142226.GA25370@lordcow.org> <20100909142455.GA77677@icarus.home.lan> <20100909142928.GA25877@lordcow.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100909142928.GA25877@lordcow.org> Cc: stable@freebsd.org Subject: Re: MSIX failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 14:33:56 -0000 Hi! > > Is this within a jail or something else along those lines? I can't > > reproduce the problem otherwise. Frustrating! Someone else on the list > > might have ideas as to what could cause this. > > Nope, this's a normal host. I've got securelevel on 1, but doubt that > would affect this? I assume it affects it. http://www.freebsd.org/doc/en/books/faq/security.html#SECURELEVEL Basically, when the securelevel is positive, the kernel restricts certain tasks; not even the superuser (i.e., root) is allowed to do them. There: # Write to kernel memory via /dev/mem and /dev/kmem. So I assume it also restricts reading /dev/kmem ? -- pi@opsec.eu +49 171 3101372 10 years to go ! From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 14:40:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E014810656A4 for ; Thu, 9 Sep 2010 14:40:38 +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 1BA758FC1B for ; Thu, 9 Sep 2010 14:40:37 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA03561; Thu, 09 Sep 2010 17:40:35 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4C88F1E3.7060106@icyb.net.ua> Date: Thu, 09 Sep 2010 17:40:35 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100909 Lightning/1.0b2 Thunderbird/3.1.3 MIME-Version: 1.0 To: vadim_nuclight@mail.ru References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <201009080842.28495.jhb@freebsd.org> <201009081021.48077.jhb@freebsd.org> <4c88993e.MgMUYIGSfJIxECy9%perryh@pluto.rain.com> <4C88AA05.5050909@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Policy for removing working code X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 14:40:39 -0000 on 09/09/2010 17:07 Vadim Goncharov said the following: > > Because this thread is not about this feature but about policy which will > slowly bring FreeBSD project to troubles if nothing will be changed. Your opinion is noted. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 14:48:13 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1D2C10656C3 for ; Thu, 9 Sep 2010 14:48:13 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 943DB8FC1A for ; Thu, 9 Sep 2010 14:48:13 +0000 (UTC) Received: by qwg5 with SMTP id 5so501551qwg.13 for ; Thu, 09 Sep 2010 07:48:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FG4g5HtYLGpXlaopQ5o/EGT1F/YaUWphHppPVHCQCyc=; b=x0C2K9yr+H9Yt2L5IqLMM5NNqN65JCJPMkgqUzefSjg1SMmhAxtRwJyZNHrzbni1YR zrJLQHhQzzh9hA6aZoGmOzHhdKfAuYSTP6OvMfNtVR/H6eIjg5cUHx39BNPpg25ATdpT 9skJZRmf6PWWHnvL/s89VYUFuxC4PHzakLpYk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=MMIpfVXdzTpV+WNk1Cf/l6wYwJewx8W5O+z2WdXoopCgQqzTHFn/MHsOjQ7nQBu10W MKvMEYYdhcFvfsaz2bna3Ev8pwl9X6VGwvqvZdQCndtx3njASRhiq6f/obV26+X4H992 Dod+J996k8o3pOHoW5dRPyjlJXHovv9rpj3LE= MIME-Version: 1.0 Received: by 10.224.11.131 with SMTP id t3mr187153qat.262.1284043691635; Thu, 09 Sep 2010 07:48:11 -0700 (PDT) Received: by 10.229.19.206 with HTTP; Thu, 9 Sep 2010 07:48:11 -0700 (PDT) In-Reply-To: <20100907145028.GF16902@felucia.tataz.chchile.org> References: <20100907145028.GF16902@felucia.tataz.chchile.org> Date: Thu, 9 Sep 2010 18:48:11 +0400 Message-ID: From: pluknet To: Jeremie Le Hen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Cannot install using serial console X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 14:48:14 -0000 On 7 September 2010 18:50, Jeremie Le Hen wrote: > Hi list, > > =3D> Please Cc: me when replying, as I am not subscribed. <=3D > > I tried to install FreeBSD (201008 -CURRENT snapshot, but I don't think > it's important here) in a KVM-backed virtual machine on a headless Linux > host, following section 2.12.1 of the handbook. > =A0 =A0 =A0 =A0http://www.freebsd.org/doc/handbook/install-advanced.html > > I've rebuilt the ISO image with the following lines in boot/loader.conf: > =A0 =A0 =A0 =A0console=3D"comconsole" > =A0 =A0 =A0 =A0beastie_disable=3D"YES" > > The kernel boots correctly (see output below) but the output invariably > stalls after the following lines: > =A0 =A0 =A0 =A0Trying to mount root from ufs:/dev/md0 > =A0 =A0 =A0 =A0/stand/sysinstal > > (Yes, only one `l'.) > > Any idea? > [strip] > WARNING: WITNESS option enabled, expect reduced performance. > Root mount waiting for: usbus0 > uhub0: 2 ports with 2 removable, self powered > Trying to mount root from ufs:/dev/md0 > As far as I know you need also to enable a serial terminal in /etc/ttys. --=20 wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 14:52:27 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 542C210656B2 for ; Thu, 9 Sep 2010 14:52:27 +0000 (UTC) (envelope-from jorgen.maas@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0ED558FC13 for ; Thu, 9 Sep 2010 14:52:26 +0000 (UTC) Received: by iwn34 with SMTP id 34so1375277iwn.13 for ; Thu, 09 Sep 2010 07:52:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Y6RZYTOzoczyvzbA7+qqn8yNzhqY3MdxOgeII5ooc0Q=; b=MwPote2yEOqsKAH7NxevdONzUPwYrJylfviUUBbDfwOFhzuakJgHRaMunK6flFfEj0 8XxsXbBaidCd3lT3bOSeCDit+FW12gqVvsySp+O7DpX1LmKyF93VuBG6OhyNgAP9rK8w tX4OSLHdeElW9eDZJnt+0nLlaOofOQW7roDxU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=U+fyuO81u0/K92qwvmtNVAJMgh7dC+FnOpQeG2ZugtmQ5hshYd43iVfZrlYbHwNUpb evpGYbYXRH6VlqeFK/MbBrEI1CJBJThmLS2rNaVL8Fh8Eo+llU61YLRwk5LIvN4SWqz5 IkTpaRP3MaI9yz4vjYyVE1YyvOKUV9qKCXVII= MIME-Version: 1.0 Received: by 10.231.146.136 with SMTP id h8mr11858187ibv.0.1284042431333; Thu, 09 Sep 2010 07:27:11 -0700 (PDT) Received: by 10.231.140.22 with HTTP; Thu, 9 Sep 2010 07:27:11 -0700 (PDT) In-Reply-To: <20100909142226.GA25370@lordcow.org> References: <20100906155350.GA50151@lordcow.org> <20100908094050.GA73841@lordcow.org> <20100909125400.GA18723@lordcow.org> <20100909131340.GA75829@icarus.home.lan> <20100909132519.GB21535@lordcow.org> <20100909140224.GA76889@icarus.home.lan> <20100909142226.GA25370@lordcow.org> Date: Thu, 9 Sep 2010 16:27:11 +0200 Message-ID: From: =?ISO-8859-1?Q?J=F6rgen_Maas?= To: Gareth de Vaux Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: stable@freebsd.org Subject: Re: MSIX failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 14:52:27 -0000 On Thu, Sep 9, 2010 at 4:22 PM, Gareth de Vaux wrote: > On Thu 2010-09-09 (07:02), Jeremy Chadwick wrote: > > You need to be root to use the -c flag. Despite your prompt, I don't > > think you're root. Reproduction: > > That was as root, > > # id > uid=0(root) gid=0(wheel) groups=0(wheel),5(operator) > # pciconf -lc > pciconf: /dev/pci: Operation not permitted > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > perhaps you should lower your kernel securelevel? From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 14:54:56 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1FA210656F6 for ; Thu, 9 Sep 2010 14:54:56 +0000 (UTC) (envelope-from pi@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id 919258FC26 for ; Thu, 9 Sep 2010 14:54:56 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OtiWf-000BLh-Ip; Thu, 09 Sep 2010 16:54:57 +0200 Date: Thu, 9 Sep 2010 16:54:57 +0200 From: Kurt Jaeger To: Gareth de Vaux Message-ID: <20100909145457.GH34314@home.opsec.eu> References: <20100908094050.GA73841@lordcow.org> <20100909125400.GA18723@lordcow.org> <20100909131340.GA75829@icarus.home.lan> <20100909132519.GB21535@lordcow.org> <20100909140224.GA76889@icarus.home.lan> <20100909142226.GA25370@lordcow.org> <20100909142455.GA77677@icarus.home.lan> <20100909142928.GA25877@lordcow.org> <20100909143357.GG34314@home.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100909143357.GG34314@home.opsec.eu> Cc: stable@freebsd.org Subject: Re: MSIX failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 14:54:57 -0000 Hi! > > > Is this within a jail or something else along those lines? I can't > > > reproduce the problem otherwise. Frustrating! Someone else on the list > > > might have ideas as to what could cause this. > > > > Nope, this's a normal host. I've got securelevel on 1, but doubt that > > would affect this? > > I assume it affects it. > > http://www.freebsd.org/doc/en/books/faq/security.html#SECURELEVEL > > Basically, when the securelevel is positive, the kernel restricts > certain tasks; not even the superuser (i.e., root) is allowed to > do them. > > There: > > # Write to kernel memory via /dev/mem and /dev/kmem. > > So I assume it also restricts reading /dev/kmem ? -c asks for pci device capabilities, which are read in /usr/src/usr.sbin/pciconf/pciconf.c:177 with O_RDWR I guess that's it. -- pi@opsec.eu +49 171 3101372 10 years to go ! From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 14:55:16 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2CE210656BC for ; Thu, 9 Sep 2010 14:55:16 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id 4CFC48FC16 for ; Thu, 9 Sep 2010 14:55:15 +0000 (UTC) Received: (qmail 13975 invoked from network); 9 Sep 2010 14:28:34 -0000 Received: from unknown (HELO ?10.0.0.124?) (spawk@128.238.64.31) by acm.poly.edu with AES256-SHA encrypted SMTP; 9 Sep 2010 14:28:34 -0000 Message-ID: <4C88EF0C.8090601@acm.poly.edu> Date: Thu, 09 Sep 2010 10:28:28 -0400 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.24 (X11/20100530) MIME-Version: 1.0 To: Jeremy Chadwick References: <20100908094050.GA73841@lordcow.org> <20100909125400.GA18723@lordcow.org> <20100909131340.GA75829@icarus.home.lan> <20100909132519.GB21535@lordcow.org> <20100909140224.GA76889@icarus.home.lan> <20100909142226.GA25370@lordcow.org> <20100909142455.GA77677@icarus.home.lan> In-Reply-To: <20100909142455.GA77677@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gareth de Vaux , stable@freebsd.org Subject: Re: MSIX failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 14:55:16 -0000 Jeremy Chadwick wrote: > On Thu, Sep 09, 2010 at 04:22:26PM +0200, Gareth de Vaux wrote: > >> On Thu 2010-09-09 (07:02), Jeremy Chadwick wrote: >> >>> You need to be root to use the -c flag. Despite your prompt, I don't >>> think you're root. Reproduction: >>> >> That was as root, >> >> # id >> uid=0(root) gid=0(wheel) groups=0(wheel),5(operator) >> # pciconf -lc >> pciconf: /dev/pci: Operation not permitted >> > > Is this within a jail or something else along those lines? I can't > reproduce the problem otherwise. Frustrating! Someone else on the list > might have ideas as to what could cause this. > > A kern.securelevel of 1 or higher would also cause this to happen. -Boris From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 15:00:28 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A08551065696 for ; Thu, 9 Sep 2010 15:00:28 +0000 (UTC) (envelope-from bsd@lordcow.org) Received: from lordcow.org (lordcow.org [41.203.5.188]) by mx1.freebsd.org (Postfix) with ESMTP id BBABF8FC13 for ; Thu, 9 Sep 2010 15:00:27 +0000 (UTC) Received: from lordcow.org (localhost [127.0.0.1]) by lordcow.org (8.14.4/8.14.4) with ESMTP id o89F0I0T027656 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Thu, 9 Sep 2010 17:00:18 +0200 (SAST) (envelope-from lordcow@lordcow.org) Received: (from lordcow@localhost) by lordcow.org (8.14.4/8.14.4/Submit) id o89F0DEF027654 for stable@freebsd.org; Thu, 9 Sep 2010 17:00:13 +0200 (SAST) (envelope-from lordcow) Date: Thu, 9 Sep 2010 17:00:12 +0200 From: Gareth de Vaux To: stable@freebsd.org Message-ID: <20100909150012.GA27370@lordcow.org> References: <20100909125400.GA18723@lordcow.org> <20100909131340.GA75829@icarus.home.lan> <20100909132519.GB21535@lordcow.org> <20100909140224.GA76889@icarus.home.lan> <20100909142226.GA25370@lordcow.org> <20100909142455.GA77677@icarus.home.lan> <20100909142928.GA25877@lordcow.org> <20100909143357.GG34314@home.opsec.eu> <20100909145457.GH34314@home.opsec.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100909145457.GH34314@home.opsec.eu> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lordcow.org Cc: Subject: Re: MSIX failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 15:00:28 -0000 On Thu 2010-09-09 (16:54), Kurt Jaeger wrote: > -c asks for pci device capabilities, which are read in > > /usr/src/usr.sbin/pciconf/pciconf.c:177 with O_RDWR Ah. I'll have to schedule a reboot then .. From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 15:24:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4CD010656B2 for ; Thu, 9 Sep 2010 15:24:02 +0000 (UTC) (envelope-from O.Seibert@cs.ru.nl) Received: from kookpunt.science.ru.nl (kookpunt.science.ru.nl [131.174.30.61]) by mx1.freebsd.org (Postfix) with ESMTP id 3F9AA8FC08 for ; Thu, 9 Sep 2010 15:24:01 +0000 (UTC) Received: from twoquid.cs.ru.nl (twoquid.cs.ru.nl [131.174.142.38]) by kookpunt.science.ru.nl (8.13.7/5.31) with ESMTP id o89FO02T007638; Thu, 9 Sep 2010 17:24:00 +0200 (MEST) Received: by twoquid.cs.ru.nl (Postfix, from userid 4100) id 726F42E04F; Thu, 9 Sep 2010 17:24:00 +0200 (CEST) Date: Thu, 9 Sep 2010 17:24:00 +0200 From: Olaf Seibert To: freebsd-stable@freebsd.org Message-ID: <20100909152400.GS4404@twoquid.cs.ru.nl> References: <20100909141702.GP4404@twoquid.cs.ru.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100909141702.GP4404@twoquid.cs.ru.nl> User-Agent: Mutt/1.5.19 (2009-01-05) X-Spam-Score: -0.8 () ALL_TRUSTED,BAYES_60 X-Scanned-By: MIMEDefang 2.63 on 131.174.30.61 Cc: Thomas Ronner Subject: Re: Can't build 8.1 GENERIC kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 15:24:02 -0000 Thomas Ronner wrote: > I don't know about the old-fashioned way, but the new way is: > > # cd /usr/src > # make buildkernel KERNCONF=GENERIC > # make installkernel KERNCONF=GENERIC Thank you, that worked. I wonder what the underlying difference is; probably something fairly subtle. The same hack.So file was generated (byte for byte identical). And something changed between 8.0 and 8.1, since previously, the old-fashioned method worked. -Olaf. -- From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 15:35:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17FBE10656F3 for ; Thu, 9 Sep 2010 15:35:33 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id B75BC8FC17 for ; Thu, 9 Sep 2010 15:35:31 +0000 (UTC) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta01.westchester.pa.mail.comcast.net with comcast id 4f1C1f00827AodY51fbYCc; Thu, 09 Sep 2010 15:35:32 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta19.westchester.pa.mail.comcast.net with comcast id 4fbX1f0073LrwQ23ffbXJJ; Thu, 09 Sep 2010 15:35:32 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id F14119B423; Thu, 9 Sep 2010 08:35:29 -0700 (PDT) Date: Thu, 9 Sep 2010 08:35:29 -0700 From: Jeremy Chadwick To: Olaf Seibert Message-ID: <20100909153529.GA79356@icarus.home.lan> References: <20100909141702.GP4404@twoquid.cs.ru.nl> <20100909152400.GS4404@twoquid.cs.ru.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100909152400.GS4404@twoquid.cs.ru.nl> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org, Thomas Ronner Subject: Re: Can't build 8.1 GENERIC kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 15:35:33 -0000 On Thu, Sep 09, 2010 at 05:24:00PM +0200, Olaf Seibert wrote: > Thomas Ronner wrote: > > > I don't know about the old-fashioned way, but the new way is: > > > > # cd /usr/src > > # make buildkernel KERNCONF=GENERIC > > # make installkernel KERNCONF=GENERIC > > Thank you, that worked. > > I wonder what the underlying difference is; probably something fairly > subtle. The same hack.So file was generated (byte for byte identical). > And something changed between 8.0 and 8.1, since previously, the > old-fashioned method worked. Not sure (it's been a long time since I configured a kernel the old way, dating back to 2.x), but possibly it has to do with the introduction of /usr/obj. Your "file" command doesn't indicate what your working directory was at the time. Regardless, when it comes to building world and kernel, you should follow the instructions in /usr/src/Makefile (there's 11 steps). Do not skip steps, and do not avoid steps (such as doing installkernel then skipping the boot-into-single-user step before doing installworld; this may work the majority of the time, but I've seen cases where /libexec binaries don't get updated without going into single-user, and the result is a system that breaks immediately). You should also build world before building kernel; as I understand it, the binaries built during buildworld will be used to build the kernel. There have been many situations in the past where not doing this has broken the build process (e.g. a new feature/flag/etc. being introduced which exists via the /usr/obj/usr/bin/whatever binary, but not /usr/bin/whatever). -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 15:39:16 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30A9310656C6 for ; Thu, 9 Sep 2010 15:39:16 +0000 (UTC) (envelope-from bsd@lordcow.org) Received: from lordcow.org (lordcow.org [41.203.5.188]) by mx1.freebsd.org (Postfix) with ESMTP id 58BEA8FC19 for ; Thu, 9 Sep 2010 15:39:14 +0000 (UTC) Received: from lordcow.org (localhost [127.0.0.1]) by lordcow.org (8.14.4/8.14.4) with ESMTP id o89Fd7Pr028830 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Thu, 9 Sep 2010 17:39:07 +0200 (SAST) (envelope-from lordcow@lordcow.org) Received: (from lordcow@localhost) by lordcow.org (8.14.4/8.14.4/Submit) id o89Fd25X028829 for stable@freebsd.org; Thu, 9 Sep 2010 17:39:02 +0200 (SAST) (envelope-from lordcow) Date: Thu, 9 Sep 2010 17:39:02 +0200 From: Gareth de Vaux To: stable@freebsd.org Message-ID: <20100909153902.GA28341@lordcow.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lordcow.org Cc: Subject: ipfw: Too many dynamic rules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 15:39:16 -0000 Hi again, I use some keep-state rules in ipfw, but get the following kernel message: kernel: ipfw: install_state: Too many dynamic rules when presumably my state table reaches its limit (and I effectively get DoS'd). netstat shows tons of connections in FIN_WAIT_2 state, mostly to my webserver. Consequently net.inet.ip.fw.dyn_count is large too. I can increase my net.inet.ip.fw.dyn_max but the new limit will simply be reached later on. I currently get around this with a cronjob that sets net.inet.ip.fw.dyn_keepalive to 0 for just less than 5 minutes every night. If I leave it at 0 for longer or indefinitely then idle ssh sessions and the like are dropped. This works fine for me but it looks like there's some bug with net.inet.ip.fw.dyn_keepalive=1? Or with Apache? I'm using 8.1-STABLE, GENERIC kernel. Experienced the same behaviour on 8.0-RELEASE, but not on 6.1-RELEASE where I had a similar setup. I have a KeepAliveTimeout of 4 in Apache (2.2.16). From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 16:20:12 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3071E10657C7 for ; Thu, 9 Sep 2010 16:20:12 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by mx1.freebsd.org (Postfix) with ESMTP id E1CD18FC13 for ; Thu, 9 Sep 2010 16:20:10 +0000 (UTC) Received: from omta09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by qmta10.emeryville.ca.mail.comcast.net with comcast id 4dm41f0020S2fkCAAgLADa; Thu, 09 Sep 2010 16:20:10 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta09.emeryville.ca.mail.comcast.net with comcast id 4gL91f00J3LrwQ28VgL92Q; Thu, 09 Sep 2010 16:20:10 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 5BABC9B423; Thu, 9 Sep 2010 09:20:09 -0700 (PDT) Date: Thu, 9 Sep 2010 09:20:09 -0700 From: Jeremy Chadwick To: Gareth de Vaux Message-ID: <20100909162009.GA80375@icarus.home.lan> References: <20100909153902.GA28341@lordcow.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100909153902.GA28341@lordcow.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: stable@freebsd.org Subject: Re: ipfw: Too many dynamic rules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 16:20:12 -0000 On Thu, Sep 09, 2010 at 05:39:02PM +0200, Gareth de Vaux wrote: > Hi again, I use some keep-state rules in ipfw, but get the following > kernel message: > > kernel: ipfw: install_state: Too many dynamic rules > > when presumably my state table reaches its limit (and I effectively > get DoS'd). > > netstat shows tons of connections in FIN_WAIT_2 state, mostly to > my webserver. Consequently net.inet.ip.fw.dyn_count is large too. > > I can increase my net.inet.ip.fw.dyn_max but the new limit will > simply be reached later on. > > I currently get around this with a cronjob that sets > net.inet.ip.fw.dyn_keepalive to 0 for just less than 5 minutes > every night. If I leave it at 0 for longer or indefinitely then > idle ssh sessions and the like are dropped. This works fine for > me but it looks like there's some bug with net.inet.ip.fw.dyn_keepalive=1? > Or with Apache? > > I'm using 8.1-STABLE, GENERIC kernel. Experienced the same behaviour > on 8.0-RELEASE, but not on 6.1-RELEASE where I had a similar setup. I > have a KeepAliveTimeout of 4 in Apache (2.2.16). Firstly, I'm not familiar with dynamic firewall rules in ipfw. I tend to use pf these days, with ALTQ for rate-limiting. pf offers a lot of improvements over ipfw. Secondly, I'm fairly certain HTTP KeepAlive (re: KeepAliveTimeout) are unrelated to TCP keepalives[1]. I mention this because you're focusing on netstat, which will give you indication of TCP session state, not HTTP protocol statefulness. Thirdly, if you feel FIN_WAIT2 is the cause of your problem, then you should consider adjusting the following sysctl: net.inet.tcp.finwait2_timeout Try something like 15000 (15 seconds) instead of the default (60000). Finally, why are you using dynamic firewall rules at all? For what purpose do you need these that, say, pf and its state tracking would not suffice? [1]: http://en.wikipedia.org/wiki/Keepalive -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 16:25:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAA561065693 for ; Thu, 9 Sep 2010 16:25:37 +0000 (UTC) (envelope-from O.Seibert@cs.ru.nl) Received: from kookpunt.science.ru.nl (kookpunt.science.ru.nl [131.174.30.61]) by mx1.freebsd.org (Postfix) with ESMTP id 6D0D98FC0C for ; Thu, 9 Sep 2010 16:25:37 +0000 (UTC) Received: from twoquid.cs.ru.nl (twoquid.cs.ru.nl [131.174.142.38]) by kookpunt.science.ru.nl (8.13.7/5.31) with ESMTP id o89GPXVG009965; Thu, 9 Sep 2010 18:25:33 +0200 (MEST) Received: by twoquid.cs.ru.nl (Postfix, from userid 4100) id A92512E04F; Thu, 9 Sep 2010 18:25:33 +0200 (CEST) Date: Thu, 9 Sep 2010 18:25:33 +0200 From: Olaf Seibert To: Jeremy Chadwick Message-ID: <20100909162533.GT4404@twoquid.cs.ru.nl> References: <20100909141702.GP4404@twoquid.cs.ru.nl> <20100909152400.GS4404@twoquid.cs.ru.nl> <20100909153529.GA79356@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100909153529.GA79356@icarus.home.lan> User-Agent: Mutt/1.5.19 (2009-01-05) X-Spam-Score: -1.799 () ALL_TRUSTED,BAYES_50 X-Scanned-By: MIMEDefang 2.63 on 131.174.30.61 Cc: freebsd-stable@freebsd.org, Olaf Seibert , Thomas Ronner Subject: Re: Can't build 8.1 GENERIC kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 16:25:37 -0000 On Thu 09 Sep 2010 at 08:35:29 -0700, Jeremy Chadwick wrote: > Regardless, when it comes to building world and kernel, you should > follow the instructions in /usr/src/Makefile (there's 11 steps). Do not > skip steps, and do not avoid steps (such as doing installkernel then > skipping the boot-into-single-user step before doing installworld; this > may work the majority of the time, but I've seen cases where /libexec > binaries don't get updated without going into single-user, and the > result is a system that breaks immediately). Fortunately, I was not upgrading anything, just reducing my kernel size a bit (well, almost by half) by eliminating support for hardware that isn't applicable. Sources and installed kernel and userland were the result of ``freebsd-update'' so they should all be up to date and in sync. I'm now trying a cross-build run, I'm curious how it compares with NetBSD. (NetBSD always builds (cross-) tools when building the world. In particular when building a major upgrade this is convenient, since then you can always be sure to be building with up-to-date tools) -Olaf. -- From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 16:41:52 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0D8910656AB for ; Thu, 9 Sep 2010 16:41:52 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2D94B8FC16 for ; Thu, 9 Sep 2010 16:41:51 +0000 (UTC) Received: by wwd20 with SMTP id 20so125645wwd.1 for ; Thu, 09 Sep 2010 09:41:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=6lKwIRaFAmBD4+qWY5N+ci7VxIP6aT0zGYYUg3r+DFs=; b=o/+WpqEmPWtXRoaqVg6Hb+7qZdl/N9WboHIwIQ5mp1NakrLEVTOH6wYpwe9jDnnIN9 pQzELSrfI5r4YJC0jOpcdMy/tWSQKgZdZPw1PF/wzCxGPWIm5lUaIbfxaxNYz3hmVhwO oc1yZnZ2pGLd6ADiG+/dVXHSPdUKhH1iwr20g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=scQHArfPrqBdsJbKR8bPU4JqKC5HWyiIQfQZ48v8efXcXFedqMo3gTrMhfRM8DIdCz v5YR6j+7aoWNCZKDXrRFNB/Ou/skRQN8gwiqKEBeye0ULOmybl563FZGlV1YmmyKhO8+ jfpadH+Srt3WpJNboGHe6OlaIzWPubaIGDPsg= MIME-Version: 1.0 Received: by 10.227.157.84 with SMTP id a20mr24885wbx.32.1284050468146; Thu, 09 Sep 2010 09:41:08 -0700 (PDT) Received: by 10.216.49.78 with HTTP; Thu, 9 Sep 2010 09:41:07 -0700 (PDT) In-Reply-To: <20100909143357.GG34314@home.opsec.eu> References: <20100908094050.GA73841@lordcow.org> <20100909125400.GA18723@lordcow.org> <20100909131340.GA75829@icarus.home.lan> <20100909132519.GB21535@lordcow.org> <20100909140224.GA76889@icarus.home.lan> <20100909142226.GA25370@lordcow.org> <20100909142455.GA77677@icarus.home.lan> <20100909142928.GA25877@lordcow.org> <20100909143357.GG34314@home.opsec.eu> Date: Thu, 9 Sep 2010 09:41:07 -0700 Message-ID: From: Jack Vogel To: Kurt Jaeger Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Gareth de Vaux , stable@freebsd.org Subject: Re: MSIX failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 16:41:52 -0000 On Thu, Sep 9, 2010 at 7:33 AM, Kurt Jaeger wrote: > Hi! > > > > Is this within a jail or something else along those lines? I can't > > > reproduce the problem otherwise. Frustrating! Someone else on the > list > > > might have ideas as to what could cause this. > > > > Nope, this's a normal host. I've got securelevel on 1, but doubt that > > would affect this? > > I assume it affects it. > > http://www.freebsd.org/doc/en/books/faq/security.html#SECURELEVEL > > Basically, when the securelevel is positive, the kernel restricts > certain tasks; not even the superuser (i.e., root) is allowed to > do them. > > There: > > # Write to kernel memory via /dev/mem and /dev/kmem. > > So I assume it also restricts reading /dev/kmem ? > > OH YUCK, another root isn't really root, so is it also possibly the reason for the MSIX failure?? Is this pile, er feature, on by default? Jack From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 16:44:13 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A44AA10656EA for ; Thu, 9 Sep 2010 16:44:13 +0000 (UTC) (envelope-from pi@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id 6175D8FC08 for ; Thu, 9 Sep 2010 16:44:13 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OtkEQ-000D4j-TG for stable@freebsd.org; Thu, 09 Sep 2010 18:44:14 +0200 Date: Thu, 9 Sep 2010 18:44:14 +0200 From: Kurt Jaeger To: stable@freebsd.org Message-ID: <20100909164414.GI34314@home.opsec.eu> References: <20100909125400.GA18723@lordcow.org> <20100909131340.GA75829@icarus.home.lan> <20100909132519.GB21535@lordcow.org> <20100909140224.GA76889@icarus.home.lan> <20100909142226.GA25370@lordcow.org> <20100909142455.GA77677@icarus.home.lan> <20100909142928.GA25877@lordcow.org> <20100909143357.GG34314@home.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: Subject: Re: MSIX failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 16:44:13 -0000 Hi! > > Basically, when the securelevel is positive, the kernel restricts > > certain tasks; not even the superuser (i.e., root) is allowed to > > do them. > OH YUCK, another root isn't really root, so is it also possibly > the reason for the MSIX failure?? Is this pile, er feature, on by default? No, not by default. -- pi@opsec.eu +49 171 3101372 10 years to go ! From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 16:51:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B406710656A8 for ; Thu, 9 Sep 2010 16:51:12 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 408C98FC12 for ; Thu, 9 Sep 2010 16:51:11 +0000 (UTC) Received: by wyb33 with SMTP id 33so1899170wyb.13 for ; Thu, 09 Sep 2010 09:51:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=+m1B89Asfz1BHfJZBGLFqMLEf/v6RFaL6lIlyfb2L/U=; b=sMJBXdpH3dmOJ0OhzcW024zpGZEFLC7Jn5ZS9vQ0E4t2cbVBedxUdjLQ+9s/F8cSvZ 4+0bdf0d2a/jLSJ7YKwJQyWtp6cutrYpbN7E39FiZpOhgdddY6ZwGIrY4Ny3yWEDaY/g prPf0Wnfst6b6V05/rTBhAfdy1c2EA7RMe75k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=pXf2W5lfiY+WiQ9voGz5sYsSSDDfIjNI/3D5reN1dWlHn6ji1+1DfH80dObNvvzi1g HCDtcMiH8Tz8W7eLMMVLmX8YtTA5nbhCFWxmjdb+6huS/NasQgUZHaeKUhSmADbk0V7q Meux5BRsDGcUBV1DdCtEzNPSZmMOlcK1fYVls= Received: by 10.227.146.147 with SMTP id h19mr2074wbv.222.1284051070950; Thu, 09 Sep 2010 09:51:10 -0700 (PDT) Received: from centel.dataix.local ([99.181.137.20]) by mx.google.com with ESMTPS id m25sm1294453wbc.19.2010.09.09.09.51.07 (version=SSLv3 cipher=RC4-MD5); Thu, 09 Sep 2010 09:51:08 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C89107A.6050802@DataIX.net> Date: Thu, 09 Sep 2010 12:51:06 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.9) Gecko/20100908 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: vadim_nuclight@mail.ru References: <20100908073019.GA16493@lonesome.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Policy for removing working code (Was: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 16:51:12 -0000 On 09/08/2010 06:44, Vadim Goncharov wrote: > Hi Mark Linimon! > > On Wed, 8 Sep 2010 07:30:19 +0000; Mark Linimon wrote about 'Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon': > >>>> The reason is performance for overall network stack, not ideology. > >>> For a practical reasons, "it works but slow" is better than >>> "doesn't work at all (due to absence of code in the src tree)". >>> "Make it work. Make it right. Make it fast. In that order", know this? >>> Sacrificing "work" for "fast"?.. Hmm, if it is not ideology, then what is >>> it?.. >> >> It wasn't "it works but slow". It was "it works, but networking throughput >> is limited on the modern hardware that the majority of our users employ". >> In particular, IIUC, 10GB network drivers were suffering under the old >> strategy. We simply were not competitive with other OSes, and we have >> many multiples more users interested in 10GBE than in ISDN. > > I understand that we need to support modern fast hardware but that doesn't mean > we should drop working features for that. And... > >>> You do not understand the problem. It is not in notices & volunteers, but >>> rather in the Project's policy - delete something which could still work. >> >> You do not understand how this was handled. > > ...and how this is handled in other OSes to which we have compete, er? They all > also do dropping features to frighten away old users? Are there no alternative > ways to handle? Put network Giant code into bunch of #ifdef's, after all. > >> The situation was: an announcement was made that "in X months, all network >> drivers need to be made to run Giant-free so that FreeBSD can drop Giant >> from the neworking stack to move forward." Within that period, most of >> the drivers were updated. Repeated postings were made to the mailing list >> that "the following drivers still have not been converted, and need to be >> updated or they will be dropped." They weren't; they were droppped. > > No. See my answer to vwe@ that there were no proper announcements. With them, > for example, someone could get sponsored to update these drivers which were > needed by those FreeBSD users who can't maintain code themselves. That's a last > resort, more likely volunteers will come, but you get the idea. > >> So while it could "still" work, it was slowing down progress. > > If it is not ideology, then what is it?.. > >> The fact of the matter is, FreeBSD is a big project with a finite number >> of developers. We try to keep as much coverage of systems as we can, but >> a reality of any large software engineering project is that older features >> sometimes have to be dropped to make progress. > >>From time to time such critical cases could possibly be handled by another > ways, I've mentioned one possible above. > >> The code still exists in the repository for any interested party to pick >> up and modernize. > > I hope that for this particular case alternative from ports will be enough. > But policy is not tied to one particular case, alas. > Would you please stop provoking a situation for which you are no more involved in other than running FreeBSD. Thank you. PS: The website in your signature is broke. This should give you enough to do for a while. -- jhell,v From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 17:18:21 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 480861065697 for ; Thu, 9 Sep 2010 17:18:21 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id BCA278FC0C for ; Thu, 9 Sep 2010 17:18:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o89HIHgB077358; Fri, 10 Sep 2010 03:18:17 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 10 Sep 2010 03:18:16 +1000 (EST) From: Ian Smith To: Gareth de Vaux In-Reply-To: <20100909153902.GA28341@lordcow.org> Message-ID: <20100910023132.E73353@sola.nimnet.asn.au> References: <20100909153902.GA28341@lordcow.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: stable@freebsd.org Subject: Re: ipfw: Too many dynamic rules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 17:18:21 -0000 On Thu, 9 Sep 2010, Gareth de Vaux wrote: > Hi again, I use some keep-state rules in ipfw, but get the following > kernel message: > > kernel: ipfw: install_state: Too many dynamic rules > > when presumably my state table reaches its limit (and I effectively > get DoS'd). > > netstat shows tons of connections in FIN_WAIT_2 state, mostly to > my webserver. Consequently net.inet.ip.fw.dyn_count is large too. > > I can increase my net.inet.ip.fw.dyn_max but the new limit will > simply be reached later on. Try using 'limit' rather than the unlimited 'keep-state' for inbound dynamic connections to your server/s. eg, derived from ipfw(8): ipfw add allow tcp from any to me 80 setup limit src-addr 4 ".. can be placed on a server to make sure that a single client does not use more than 4 simultaneous connections." You could add 'in recv $ext_if' to avoid limiting internal clients. > I currently get around this with a cronjob that sets > net.inet.ip.fw.dyn_keepalive to 0 for just less than 5 minutes > every night. If I leave it at 0 for longer or indefinitely then > idle ssh sessions and the like are dropped. This works fine for > me but it looks like there's some bug with net.inet.ip.fw.dyn_keepalive=1? > Or with Apache? Limiting the number of source connections per source address to what apache is happy to deal with, you mightn't need to fuss with that? cheers, Ian > I'm using 8.1-STABLE, GENERIC kernel. Experienced the same behaviour > on 8.0-RELEASE, but not on 6.1-RELEASE where I had a similar setup. I > have a KeepAliveTimeout of 4 in Apache (2.2.16). From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 17:32:32 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C3A410656BC for ; Thu, 9 Sep 2010 17:32:32 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 28C7D8FC08 for ; Thu, 9 Sep 2010 17:32:32 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o89HWVDr021208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 9 Sep 2010 10:32:31 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 1282D1CC3A; Thu, 9 Sep 2010 10:32:31 -0700 (PDT) To: Andriy Gapon In-reply-to: Your message of "Thu, 09 Sep 2010 12:33:57 +0300." <4C88AA05.5050909@icyb.net.ua> Date: Thu, 09 Sep 2010 10:32:31 -0700 From: "Kevin Oberman" Message-Id: <20100909173231.1282D1CC3A@ptavv.es.net> Cc: stable@freebsd.org, perryh@pluto.rain.com Subject: Re: Policy for removing working code X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 17:32:32 -0000 > Date: Thu, 09 Sep 2010 12:33:57 +0300 > From: Andriy Gapon > Sender: owner-freebsd-stable@freebsd.org > > on 09/09/2010 11:22 perryh@pluto.rain.com said the following: > > Good, perhaps even "necessary", but is it "sufficient"? Those > > following a -STABLE branch are expected to read stable@, but > > what about those who are following a security branch? > > People, who care, are expected to read current@ and stable@ even if > they use only releases and security branches. At the very least, to > see what's cooking up for them and what to expect. > > P.S. I am surprised that this thread isn't over yet and is being kept > alive by people who do not seem to use the feature in question or > offer any work on it. While people, who really need it, have already > found a way forward for themselves. > > P.P.S. Please, please, let it go now. Watch current@, watch stable@ > and speak up next time such an announcement is made. Do it on time, > don't wait until a few years later :-) The point is that people running release code and release+security are NOT expected to be reading either stable or current. They should be reading the release notes, but the dropping of ISDN support was only mentioned in the 7.0 release notes and it stated: "ISDN4BSD and netatm have been temporarily disconnected from the build. These modules all require the Giant kernel lock for their operation; disconnecting them allows the removal of the NET_NEEDS_GIANT compatability (sic) shim. It is planned to convert these modules to fine-grained kernel locking and re-connect them for FreeBSD 7.1-RELEASE." Even if you read this, (ignoring the spelling error) you would not expect them to be gone in 7.3 or 8.1. I must say that this was very poorly documented for the "typical" user who happens to need ISDN. Yes, the code needed removal, but when a major capability is removed, it really needs to be better noted. Since the 7.0 release notes said that ISDN4BSD would be back in 7.1, the 7.1 notes should have mentioned that it was not and might not be back. I also think that, once the decision to remove all devices that required GIANT and most of the dust had settled (i.e. jhb and others had converted most of the drivers to not use GIANT) and the plea went out for people to test/patch the remaining devices, it would have been appropriate to send a message to that effect to announce. Let's face it, the removal of GIANT from the network stack was a major change and it was likely to impact users of the sub-systems removed. If they did the "usual" and skipped the ".0" release, they never installed 7.0 and probably did not read the release notes. It was never mentioned in the announcements, either. While the removal was needed, it really needed to be better publicized. ISDN is still in use. We support it (not with FreeBSD) and, if it fails, the mail comes pouring in, usually from outside of the US and the often from places where other forms of broadband Internet are not readily available or from those using appliances that use ISDN for network connectivity. This is a volunteer effort. When we screw up, and we do, we should say "sorry" and try not to do it again, not spend time sending responses that the users are at fault. Leave that to the commercial operations who do it regularly. Personally, I think we screwed up. -- 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 From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 18:15:44 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E9F110656AB for ; Thu, 9 Sep 2010 18:15:44 +0000 (UTC) (envelope-from amarat@ksu.ru) Received: from mx7.ksu.ru (honey.ksu.ru [193.232.252.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5ECAC8FC15 for ; Thu, 9 Sep 2010 18:15:42 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.56,340,1280692800"; d="p7s'?scan'208";a="911749" Received: from mail.ksu.ru (HELO ruby.ksu.ru) ([193.232.252.56]) by iport2.ksu.ru with ESMTP; 09 Sep 2010 22:03:38 +0400 X-Pass-Through: Kazan State University Network Received: from zealot.ksu.ru ([194.85.245.161]) by ksu.ru (8.13.4/8.13.4) with ESMTP id o89I3YWB014552; Thu, 9 Sep 2010 18:03:35 GMT Received: from zealot.ksu.ru (localhost.lnet [127.0.0.1]) by zealot.ksu.ru (8.14.4/8.14.4) with ESMTP id o89I3At5008670; Thu, 9 Sep 2010 22:03:10 +0400 (MSD) (envelope-from amarat@ksu.ru) Message-ID: <4C89215E.7010203@ksu.ru> Date: Thu, 09 Sep 2010 22:03:10 +0400 From: "Marat N.Afanasyev" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.11) Gecko/20100724 SeaMonkey/2.0.6 MIME-Version: 1.0 To: Gareth de Vaux , stable@freebsd.org References: <20100909153902.GA28341@lordcow.org> In-Reply-To: <20100909153902.GA28341@lordcow.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060301070401010606060606" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: ipfw: Too many dynamic rules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 18:15:44 -0000 This is a cryptographically signed message in MIME format. --------------ms060301070401010606060606 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: quoted-printable Gareth de Vaux wrote: > Hi again, I use some keep-state rules in ipfw, but get the following > kernel message: > > kernel: ipfw: install_state: Too many dynamic rules > > when presumably my state table reaches its limit (and I effectively > get DoS'd). > > netstat shows tons of connections in FIN_WAIT_2 state, mostly to > my webserver. Consequently net.inet.ip.fw.dyn_count is large too. > > I can increase my net.inet.ip.fw.dyn_max but the new limit will > simply be reached later on. > > I currently get around this with a cronjob that sets > net.inet.ip.fw.dyn_keepalive to 0 for just less than 5 minutes > every night. If I leave it at 0 for longer or indefinitely then > idle ssh sessions and the like are dropped. This works fine for > me but it looks like there's some bug with net.inet.ip.fw.dyn_keepalive= =3D1? > Or with Apache? > > I'm using 8.1-STABLE, GENERIC kernel. Experienced the same behaviour > on 8.0-RELEASE, but not on 6.1-RELEASE where I had a similar setup. I > have a KeepAliveTimeout of 4 in Apache (2.2.16). > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.or= g" > I wonder, are these dynamic rules really necessary? let's see, a client=20 connects to your web-server and you immediately should create a new=20 dynamic rule, therefore you participate in this DoS attack as well as=20 attacker. ;) may be using ipfw add XXX allow tcp from me 80 to any would be enough? I usually use keep-state rules only for outgoing=20 connections and try to keep number of such rules as few as possible. if=20 you're afraid of somebody trying to attack your servers using unopened=20 connections you may filter out connections that aren't established. you can try to change, of course, net.inet.ip.fw.dyn_*_lifetime variables, but I think that using dynamic rules to filter out web-server = answers is not as good practice as it seems. --=20 SY, Marat --------------ms060301070401010606060606-- From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 19:04:29 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0D8E10656E9; Thu, 9 Sep 2010 19:04:29 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id F0EA08FC1B; Thu, 9 Sep 2010 19:04:28 +0000 (UTC) Received: by eyx24 with SMTP id 24so1366161eyx.13 for ; Thu, 09 Sep 2010 12:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=GEwtRxfGjQoeDdajr7HJLpemy4Bx7LmKeLGtJlzwREw=; b=vqwAtTv/326P9vqAZjSQpB5AJLn6WOz+AOew75gAU212JK7FEWO3otEQ3dxKIPRRHz ebFCPYjAyQlrEGBXit8nHJ+kRK0iyOX0g9nOuAlVlGcvwLMtKOVKtEZmiZwtvHqVdcVB 98h6v/auVIoLOSobOyab6kfphdSGtXVeatF6o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YVq+Ueq+SClnIVlByZ51k6U51rWJf0TXqZCslJXKndveOShEqPIFIWwZ2mnBa59xPS 1lho534rwD140OrcLn5oZCwILpzoLKBoQY8eqsb9aRTBZfNC+CgtzEQjBFlrcYdiqCf1 +mHn/PnVIAXeQIBARmyc+CKBc7fp0YYpk/VbI= MIME-Version: 1.0 Received: by 10.216.11.129 with SMTP id 1mr684383wex.90.1284059067566; Thu, 09 Sep 2010 12:04:27 -0700 (PDT) Received: by 10.216.49.78 with HTTP; Thu, 9 Sep 2010 12:04:27 -0700 (PDT) In-Reply-To: <201009091437.21563.jhb@freebsd.org> References: <20100909143357.GG34314@home.opsec.eu> <201009091437.21563.jhb@freebsd.org> Date: Thu, 9 Sep 2010 12:04:27 -0700 Message-ID: From: Jack Vogel To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Kurt Jaeger , Gareth de Vaux , freebsd-stable@freebsd.org, stable@freebsd.org Subject: Re: MSIX failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 19:04:29 -0000 On Thu, Sep 9, 2010 at 11:37 AM, John Baldwin wrote: > On Thursday, September 09, 2010 12:41:07 pm Jack Vogel wrote: > > On Thu, Sep 9, 2010 at 7:33 AM, Kurt Jaeger wrote: > > > > > Hi! > > > > > > > > Is this within a jail or something else along those lines? I can't > > > > > reproduce the problem otherwise. Frustrating! Someone else on the > > > list > > > > > might have ideas as to what could cause this. > > > > > > > > Nope, this's a normal host. I've got securelevel on 1, but doubt that > > > > would affect this? > > > > > > I assume it affects it. > > > > > > http://www.freebsd.org/doc/en/books/faq/security.html#SECURELEVEL > > > > > > Basically, when the securelevel is positive, the kernel restricts > > > certain tasks; not even the superuser (i.e., root) is allowed to > > > do them. > > > > > > There: > > > > > > # Write to kernel memory via /dev/mem and /dev/kmem. > > > > > > So I assume it also restricts reading /dev/kmem ? > > > > > > > > OH YUCK, another root isn't really root, so is it also possibly > > the reason for the MSIX failure?? Is this pile, er feature, on by > default? > > securelevel does not affect any of the MSI/MSI-X bits. > Well then there's something else funny going on with that hardware, as at least MSI should work with the chipset, I am not able to get that exact skew from what I am told. Jack From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 19:04:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0D8E10656E9; Thu, 9 Sep 2010 19:04:29 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id F0EA08FC1B; Thu, 9 Sep 2010 19:04:28 +0000 (UTC) Received: by eyx24 with SMTP id 24so1366161eyx.13 for ; Thu, 09 Sep 2010 12:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=GEwtRxfGjQoeDdajr7HJLpemy4Bx7LmKeLGtJlzwREw=; b=vqwAtTv/326P9vqAZjSQpB5AJLn6WOz+AOew75gAU212JK7FEWO3otEQ3dxKIPRRHz ebFCPYjAyQlrEGBXit8nHJ+kRK0iyOX0g9nOuAlVlGcvwLMtKOVKtEZmiZwtvHqVdcVB 98h6v/auVIoLOSobOyab6kfphdSGtXVeatF6o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YVq+Ueq+SClnIVlByZ51k6U51rWJf0TXqZCslJXKndveOShEqPIFIWwZ2mnBa59xPS 1lho534rwD140OrcLn5oZCwILpzoLKBoQY8eqsb9aRTBZfNC+CgtzEQjBFlrcYdiqCf1 +mHn/PnVIAXeQIBARmyc+CKBc7fp0YYpk/VbI= MIME-Version: 1.0 Received: by 10.216.11.129 with SMTP id 1mr684383wex.90.1284059067566; Thu, 09 Sep 2010 12:04:27 -0700 (PDT) Received: by 10.216.49.78 with HTTP; Thu, 9 Sep 2010 12:04:27 -0700 (PDT) In-Reply-To: <201009091437.21563.jhb@freebsd.org> References: <20100909143357.GG34314@home.opsec.eu> <201009091437.21563.jhb@freebsd.org> Date: Thu, 9 Sep 2010 12:04:27 -0700 Message-ID: From: Jack Vogel To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Kurt Jaeger , Gareth de Vaux , freebsd-stable@freebsd.org, stable@freebsd.org Subject: Re: MSIX failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 19:04:29 -0000 On Thu, Sep 9, 2010 at 11:37 AM, John Baldwin wrote: > On Thursday, September 09, 2010 12:41:07 pm Jack Vogel wrote: > > On Thu, Sep 9, 2010 at 7:33 AM, Kurt Jaeger wrote: > > > > > Hi! > > > > > > > > Is this within a jail or something else along those lines? I can't > > > > > reproduce the problem otherwise. Frustrating! Someone else on the > > > list > > > > > might have ideas as to what could cause this. > > > > > > > > Nope, this's a normal host. I've got securelevel on 1, but doubt that > > > > would affect this? > > > > > > I assume it affects it. > > > > > > http://www.freebsd.org/doc/en/books/faq/security.html#SECURELEVEL > > > > > > Basically, when the securelevel is positive, the kernel restricts > > > certain tasks; not even the superuser (i.e., root) is allowed to > > > do them. > > > > > > There: > > > > > > # Write to kernel memory via /dev/mem and /dev/kmem. > > > > > > So I assume it also restricts reading /dev/kmem ? > > > > > > > > OH YUCK, another root isn't really root, so is it also possibly > > the reason for the MSIX failure?? Is this pile, er feature, on by > default? > > securelevel does not affect any of the MSI/MSI-X bits. > Well then there's something else funny going on with that hardware, as at least MSI should work with the chipset, I am not able to get that exact skew from what I am told. Jack From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 20:48:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5CD110656C0; Thu, 9 Sep 2010 20:48:15 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 42A3C8FC19; Thu, 9 Sep 2010 20:48:14 +0000 (UTC) Received: by ewy4 with SMTP id 4so1477287ewy.13 for ; Thu, 09 Sep 2010 13:48:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=tj1eKYqnSsWEabaWx21PRXRNyjiKIZGNqAwXv58JgAw=; b=Dlvj38LqAsRbCbx53CtHUIEyQijrOQ97wGQbXt9sSTYQJPVd3mTdzlQ1WKIrHL+WiO 6sXbIVLPVIMzZe9PDX3otXtxyfUz/iGGeoBXPBUJrKiNtZyCr7366sPg4U/UQgsz+DtD 7GiUK89LPLoZaPDQMWjVmDU/1wA5Fk/pahaj0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qP35VOX4Kfshk+hhpeOs/yBYjErxaiLsnBRuZ60+rvysku2CoHP/AvdaFKfxvSpCfs dwvka+iW8UkJlpS4x4QmnBT9Mjkoep8AzZfKa6F9mOWC2gQa6LBVD+dQS2ar0nkUVNlO 6qq59mjnoB2BCSxt0u4f2SAcomqWo+vmQcUGo= MIME-Version: 1.0 Received: by 10.216.13.17 with SMTP id a17mr75635wea.46.1284065293787; Thu, 09 Sep 2010 13:48:13 -0700 (PDT) Received: by 10.216.49.78 with HTTP; Thu, 9 Sep 2010 13:48:13 -0700 (PDT) In-Reply-To: <201009091620.25299.jhb@freebsd.org> References: <201009091437.21563.jhb@freebsd.org> <201009091620.25299.jhb@freebsd.org> Date: Thu, 9 Sep 2010 13:48:13 -0700 Message-ID: From: Jack Vogel To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Kurt Jaeger , freebsd-stable@freebsd.org Subject: Re: MSIX failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 20:48:16 -0000 Gareth's email bouncing for anybody else or is it just me? Gareth, set hw.pci.honor_msi_blacklist=0, you'll have to do that at boot btw. Tell me more exactly the make/model of the hardware so I might try to get my hands on one? Jack On Thu, Sep 9, 2010 at 1:20 PM, John Baldwin wrote: > On Thursday, September 09, 2010 3:04:27 pm Jack Vogel wrote: > > On Thu, Sep 9, 2010 at 11:37 AM, John Baldwin wrote: > > > > > On Thursday, September 09, 2010 12:41:07 pm Jack Vogel wrote: > > > > On Thu, Sep 9, 2010 at 7:33 AM, Kurt Jaeger wrote: > > > > > > > > > Hi! > > > > > > > > > > > > Is this within a jail or something else along those lines? I > can't > > > > > > > reproduce the problem otherwise. Frustrating! Someone else on > the > > > > > list > > > > > > > might have ideas as to what could cause this. > > > > > > > > > > > > Nope, this's a normal host. I've got securelevel on 1, but doubt > that > > > > > > would affect this? > > > > > > > > > > I assume it affects it. > > > > > > > > > > http://www.freebsd.org/doc/en/books/faq/security.html#SECURELEVEL > > > > > > > > > > Basically, when the securelevel is positive, the kernel restricts > > > > > certain tasks; not even the superuser (i.e., root) is allowed to > > > > > do them. > > > > > > > > > > There: > > > > > > > > > > # Write to kernel memory via /dev/mem and /dev/kmem. > > > > > > > > > > So I assume it also restricts reading /dev/kmem ? > > > > > > > > > > > > > > OH YUCK, another root isn't really root, so is it also possibly > > > > the reason for the MSIX failure?? Is this pile, er feature, on by > > > default? > > > > > > securelevel does not affect any of the MSI/MSI-X bits. > > > > > > > Well then there's something else funny going on with that hardware, as at > > least MSI should work with the chipset, I am not able to get that exact > > skew from what I am told. > > I think the first would be to disable the MSI blacklists via a tunable to > see > if that enables MSI. > > -- > John Baldwin > From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 21:19:13 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34A0810656F9 for ; Thu, 9 Sep 2010 21:19:13 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1C12F8FC08 for ; Thu, 9 Sep 2010 21:19:13 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o89LJB1a016922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 9 Sep 2010 14:19:11 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 2EA991CC3A; Thu, 9 Sep 2010 14:19:11 -0700 (PDT) To: "Marat N.Afanasyev" In-reply-to: Your message of "Thu, 09 Sep 2010 22:03:10 +0400." <4C89215E.7010203@ksu.ru> Date: Thu, 09 Sep 2010 14:19:11 -0700 From: "Kevin Oberman" Message-Id: <20100909211911.2EA991CC3A@ptavv.es.net> Cc: Gareth de Vaux , stable@freebsd.org Subject: Re: ipfw: Too many dynamic rules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 21:19:13 -0000 > Date: Thu, 09 Sep 2010 22:03:10 +0400 > From: "Marat N.Afanasyev" > Sender: owner-freebsd-stable@freebsd.org > > Gareth de Vaux wrote: > > Hi again, I use some keep-state rules in ipfw, but get the following > > kernel message: > > > > kernel: ipfw: install_state: Too many dynamic rules > > > > when presumably my state table reaches its limit (and I effectively > > get DoS'd). > > > > netstat shows tons of connections in FIN_WAIT_2 state, mostly to > > my webserver. Consequently net.inet.ip.fw.dyn_count is large too. > > > > I can increase my net.inet.ip.fw.dyn_max but the new limit will > > simply be reached later on. > > > > I currently get around this with a cronjob that sets > > net.inet.ip.fw.dyn_keepalive to 0 for just less than 5 minutes > > every night. If I leave it at 0 for longer or indefinitely then > > idle ssh sessions and the like are dropped. This works fine for > > me but it looks like there's some bug with net.inet.ip.fw.dyn_keepalive=1? > > Or with Apache? > > > > I'm using 8.1-STABLE, GENERIC kernel. Experienced the same behaviour > > on 8.0-RELEASE, but not on 6.1-RELEASE where I had a similar setup. I > > have a KeepAliveTimeout of 4 in Apache (2.2.16). > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > > I wonder, are these dynamic rules really necessary? let's see, a client > connects to your web-server and you immediately should create a new > dynamic rule, therefore you participate in this DoS attack as well as > attacker. ;) I'll be more blunt...stateful firewalls should NEVER be placed in front of externally accessible services. Access filters are fine, but stateful firewalls are nothing but a denial of service waiting to happen. Security pros have always know this, but too many folks insist that there be a firewall in front of everything and that is simply an invitation to problems. Marat is right! Just don't even try. An attacker can ALWAYS overwhelm the state tables in a stateful firewall. It's just way too easy. There was a long discussion of this a while back on a network ops list I participate in and noobs kept claiming that you have to have a stateful firewall in front of everything while the real operational security folks (like those at Y! and Google) kept explaining that it just does not work. -- 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 From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 21:27:43 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 641A110656D6 for ; Thu, 9 Sep 2010 21:27:43 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 1F5818FC12 for ; Thu, 9 Sep 2010 21:27:42 +0000 (UTC) Received: by qyk31 with SMTP id 31so6963350qyk.13 for ; Thu, 09 Sep 2010 14:27:42 -0700 (PDT) Received: by 10.224.112.215 with SMTP id x23mr541486qap.37.1284065832626; Thu, 09 Sep 2010 13:57:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.38.83 with HTTP; Thu, 9 Sep 2010 13:56:29 -0700 (PDT) In-Reply-To: <4C89215E.7010203@ksu.ru> References: <20100909153902.GA28341@lordcow.org> <4C89215E.7010203@ksu.ru> From: Vlad Galu Date: Thu, 9 Sep 2010 23:56:29 +0300 Message-ID: To: "Marat N.Afanasyev" Content-Type: text/plain; charset=KOI8-R Cc: Gareth de Vaux , stable@freebsd.org Subject: Re: ipfw: Too many dynamic rules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 21:27:43 -0000 2010/9/9 Marat N.Afanasyev : > I wonder, are these dynamic rules really necessary? let's see, a client > connects to your web-server and you immediately should create a new dynamic > rule, therefore you participate in this DoS attack as well as attacker. ;) With a stateless firewall, you help the attacker even more. Because he's able to connect to your httpd/whatever daemon is listening directly and he can easily fill up the descriptor table of that process. Limiting the number of states/connections from the same host prevents that. Sure, those states eat up RAM, but so do the established connections. Having a slightly more aggressive state expiry policy always helps. Sure, there are accf_http(9), accf_data(9) and various forking workarounds, but they don't work unless your TCP server is specifically designed to use them. PF also allows you to tarpit malicious hosts based on how often they try to reconnect - you can dynamically add them to a table which you can refer to from ALTQ. -- Good, fast & cheap. Pick any two. From owner-freebsd-stable@FreeBSD.ORG Thu Sep 9 21:50:08 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61D5310656E5; Thu, 9 Sep 2010 21:50:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id E5E488FC0A; Thu, 9 Sep 2010 21:50:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id E7BEC41C7CB; Thu, 9 Sep 2010 23:50:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id jEkM7kYtFHz8; Thu, 9 Sep 2010 23:50:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id BE06641C7D0; Thu, 9 Sep 2010 23:50:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 021634448F3; Thu, 9 Sep 2010 21:48:40 +0000 (UTC) Date: Thu, 9 Sep 2010 21:48:40 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Kevin Oberman In-Reply-To: <20100909173231.1282D1CC3A@ptavv.es.net> Message-ID: <20100909211621.H31898@maildrop.int.zabbadoz.net> References: <20100909173231.1282D1CC3A@ptavv.es.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-isdn@FreeBSD.org, stable@freebsd.org Subject: Re: I4B: what happened, which options? [was: Policy for removing working code] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-isdn@FreeBSD.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 21:50:08 -0000 On Thu, 9 Sep 2010, Kevin Oberman wrote: Hey, I think I should try to summarize parts of the ISDN topic, which I have been disconnected from for more than 2 years now, to make this tail of a thread more helpful maybe. I agree that later release notes could have mentioned it but neither did they mention that it was back and I cannot remember anyone complaining about netatm not coming back either until now, nor can I remember many complaints after freebsd 7.0 which was more than 2 years ago. I am Cc:ing freebsd-isdn@ as that list exists and has been for years. Check the archives for the overwhelming interest. If ISDN is in any way interesting to you, respect the Reply-To: The temporary disconnect was announced there (which is where the plan to bring it back came from): http://lists.freebsd.org/pipermail/freebsd-isdn/2007-July/000711.html There was a call for help (also with GSoC): http://lists.freebsd.org/pipermail/freebsd-isdn/2008-March/000833.html There was a notice that the code will be removed: http://lists.freebsd.org/pipermail/freebsd-isdn/2008-May/000842.html And there was an UPDATING entry with the removal: http://svn.freebsd.org/viewvc/base?view=revision&revision=179315 There was probably more but those were the once I found again within five minutes. So what are the options and what is out there now and there are a few, depending on your needs: 1) the FreeBSD Foundation is sponsoring a project currently: "DAHDI FreeBSD driver port" http://www.freebsdfoundation.org/project%20announcements.shtml#Max 2) I am (was) still running C4B on amd64 on RELENG_8 with a privately hacked together capi call log, which is a hack without me even thinking about capi (specs) when doing it, but was doing the job for me for 7 and 8. Getting the last C4B compiled for 8/HEAD or amd64 isn't a lot of patching and I can probably provide patches to you, if you want to make it a port. The PRIV constants needed for this in the base system have been shiping for a while: http://svn.freebsd.org/viewvc/base?view=revision&revision=192577 3) HPSI4B exists and he seems to maintain it. If you need old drivers for cards he doesn't support, talk to him if you want to use or are using his stack with other cards. 4) The old I4B code is still here and could be brought back from Attic if someone was to invest the resources (time, coding or money, ...). People tried back then but failed for ETIME. It's not only locking. The device drivers and layers are written in a RELENG_4ish way and my conclusion was that it'll end in a partial re-write. I still have cards and I still have a machine with ISA slots to test things. If someone fixes the infrastructure and 1 driver I'll also happily ship them so (s)he can do the others as well and test and maintain things for the next couple of years. Pick your poison;-) HTH /bz -- Bjoern A. Zeeb Welcome a new stage of life. From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 02:36:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12707106566C for ; Fri, 10 Sep 2010 02:36:49 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8EBE78FC16 for ; Fri, 10 Sep 2010 02:36:48 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.44]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id o8A2aZNK039667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 10 Sep 2010 12:06:40 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: "Daniel O'Connor" Date: Fri, 10 Sep 2010 12:06:35 +0930 Content-Transfer-Encoding: quoted-printable Message-Id: To: freebsd-stable Stable X-Mailer: Apple Mail (2.1081) X-Spam-Score: -2.51 () ALL_TRUSTED,BAYES_00,T_RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: "John H. Baldwin" Subject: Enabling MCA causes system hangs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 02:36:49 -0000 Hi, I recently tried enabling MCA (ie w.mca.enabled=3D1 in loader.conf) on = an 8.0-STABLE system and found that it would cause the system to hang = after a few minutes of uptime. The screen would go black and the monitor would turn off (regardless of = wether it was in X or not) and only a hard reset would bring it back. Also I found that quite often I had to power cycle the whole PC or the = BIOS wouldn't detect the hard disks on boot(!) after a hang. uname is.. FreeBSD midget.dons.net.au 8.0-STABLE FreeBSD 8.0-STABLE #6 r202903M: = Sun Jan 24 13:45:11 CST 2010 = darius@midget.dons.net.au:/usr/obj/usr/src/sys/MIDGET amd64 The motherboard is a Gigabyte GA-MA785GM-US2H with an Athlon II X2 240 = CPU & 4Gb of RAM. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 02:55:51 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 632D5106566C; Fri, 10 Sep 2010 02:55:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 308618FC0A; Fri, 10 Sep 2010 02:55:51 +0000 (UTC) Received: from bigwig.baldwin.cx (unknown [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 67AA446C08; Thu, 9 Sep 2010 14:38:34 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 31A068A04E; Thu, 9 Sep 2010 14:37:47 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Thu, 9 Sep 2010 14:37:21 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20100909143357.GG34314@home.opsec.eu> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009091437.21563.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 09 Sep 2010 14:37:47 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Gareth de Vaux , stable@freebsd.org, Kurt Jaeger , Jack Vogel Subject: Re: MSIX failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 02:55:51 -0000 On Thursday, September 09, 2010 12:41:07 pm Jack Vogel wrote: > On Thu, Sep 9, 2010 at 7:33 AM, Kurt Jaeger wrote: > > > Hi! > > > > > > Is this within a jail or something else along those lines? I can't > > > > reproduce the problem otherwise. Frustrating! Someone else on the > > list > > > > might have ideas as to what could cause this. > > > > > > Nope, this's a normal host. I've got securelevel on 1, but doubt that > > > would affect this? > > > > I assume it affects it. > > > > http://www.freebsd.org/doc/en/books/faq/security.html#SECURELEVEL > > > > Basically, when the securelevel is positive, the kernel restricts > > certain tasks; not even the superuser (i.e., root) is allowed to > > do them. > > > > There: > > > > # Write to kernel memory via /dev/mem and /dev/kmem. > > > > So I assume it also restricts reading /dev/kmem ? > > > > > OH YUCK, another root isn't really root, so is it also possibly > the reason for the MSIX failure?? Is this pile, er feature, on by default? securelevel does not affect any of the MSI/MSI-X bits. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 02:55:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 632D5106566C; Fri, 10 Sep 2010 02:55:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 308618FC0A; Fri, 10 Sep 2010 02:55:51 +0000 (UTC) Received: from bigwig.baldwin.cx (unknown [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 67AA446C08; Thu, 9 Sep 2010 14:38:34 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 31A068A04E; Thu, 9 Sep 2010 14:37:47 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Thu, 9 Sep 2010 14:37:21 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20100909143357.GG34314@home.opsec.eu> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009091437.21563.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 09 Sep 2010 14:37:47 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Gareth de Vaux , stable@freebsd.org, Kurt Jaeger , Jack Vogel Subject: Re: MSIX failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 02:55:51 -0000 On Thursday, September 09, 2010 12:41:07 pm Jack Vogel wrote: > On Thu, Sep 9, 2010 at 7:33 AM, Kurt Jaeger wrote: > > > Hi! > > > > > > Is this within a jail or something else along those lines? I can't > > > > reproduce the problem otherwise. Frustrating! Someone else on the > > list > > > > might have ideas as to what could cause this. > > > > > > Nope, this's a normal host. I've got securelevel on 1, but doubt that > > > would affect this? > > > > I assume it affects it. > > > > http://www.freebsd.org/doc/en/books/faq/security.html#SECURELEVEL > > > > Basically, when the securelevel is positive, the kernel restricts > > certain tasks; not even the superuser (i.e., root) is allowed to > > do them. > > > > There: > > > > # Write to kernel memory via /dev/mem and /dev/kmem. > > > > So I assume it also restricts reading /dev/kmem ? > > > > > OH YUCK, another root isn't really root, so is it also possibly > the reason for the MSIX failure?? Is this pile, er feature, on by default? securelevel does not affect any of the MSI/MSI-X bits. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 03:00:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8321B1065675 for ; Fri, 10 Sep 2010 03:00:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 15FFA8FC14 for ; Fri, 10 Sep 2010 03:00:51 +0000 (UTC) Received: from bigwig.baldwin.cx (unknown [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 28F5446C25; Thu, 9 Sep 2010 16:25:41 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id EEF4E8A03C; Thu, 9 Sep 2010 16:24:31 -0400 (EDT) From: John Baldwin To: Jack Vogel Date: Thu, 9 Sep 2010 16:20:25 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201009091437.21563.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201009091620.25299.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 09 Sep 2010 16:24:31 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Kurt Jaeger , Gareth de Vaux , freebsd-stable@freebsd.org Subject: Re: MSIX failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 03:00:51 -0000 On Thursday, September 09, 2010 3:04:27 pm Jack Vogel wrote: > On Thu, Sep 9, 2010 at 11:37 AM, John Baldwin wrote: > > > On Thursday, September 09, 2010 12:41:07 pm Jack Vogel wrote: > > > On Thu, Sep 9, 2010 at 7:33 AM, Kurt Jaeger wrote: > > > > > > > Hi! > > > > > > > > > > Is this within a jail or something else along those lines? I can't > > > > > > reproduce the problem otherwise. Frustrating! Someone else on the > > > > list > > > > > > might have ideas as to what could cause this. > > > > > > > > > > Nope, this's a normal host. I've got securelevel on 1, but doubt that > > > > > would affect this? > > > > > > > > I assume it affects it. > > > > > > > > http://www.freebsd.org/doc/en/books/faq/security.html#SECURELEVEL > > > > > > > > Basically, when the securelevel is positive, the kernel restricts > > > > certain tasks; not even the superuser (i.e., root) is allowed to > > > > do them. > > > > > > > > There: > > > > > > > > # Write to kernel memory via /dev/mem and /dev/kmem. > > > > > > > > So I assume it also restricts reading /dev/kmem ? > > > > > > > > > > > OH YUCK, another root isn't really root, so is it also possibly > > > the reason for the MSIX failure?? Is this pile, er feature, on by > > default? > > > > securelevel does not affect any of the MSI/MSI-X bits. > > > > Well then there's something else funny going on with that hardware, as at > least MSI should work with the chipset, I am not able to get that exact > skew from what I am told. I think the first would be to disable the MSI blacklists via a tunable to see if that enables MSI. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 03:46:14 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4010C106564A for ; Fri, 10 Sep 2010 03:46:14 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id A31C78FC08 for ; Fri, 10 Sep 2010 03:46:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o8A3k4Yg010032; Fri, 10 Sep 2010 13:46:06 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 10 Sep 2010 13:46:03 +1000 (EST) From: Ian Smith To: Vlad Galu In-Reply-To: Message-ID: <20100910125714.Y73353@sola.nimnet.asn.au> References: <20100909153902.GA28341@lordcow.org> <4C89215E.7010203@ksu.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "Marat N.Afanasyev" , Gareth de Vaux , stable@freebsd.org Subject: Re: ipfw: Too many dynamic rules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 03:46:14 -0000 On Thu, 9 Sep 2010, Vlad Galu wrote: > 2010/9/9 Marat N.Afanasyev : > > I wonder, are these dynamic rules really necessary? let's see, a client > > connects to your web-server and you immediately should create a new dynamic > > rule, therefore you participate in this DoS attack as well as attacker. ;) > > With a stateless firewall, you help the attacker even more. Because > he's able to connect to your httpd/whatever daemon is listening > directly and he can easily fill up the descriptor table of that > process. Limiting the number of states/connections from the same host > prevents that. Sure, those states eat up RAM, but so do the > established connections. Having a slightly more aggressive state > expiry policy always helps. Sure, there are accf_http(9), accf_data(9) > and various forking workarounds, but they don't work unless your TCP > server is specifically designed to use them. Agreed. > PF also allows you to tarpit malicious hosts based on how often they > try to reconnect - you can dynamically add them to a table which you > can refer to from ALTQ. As mentioned, ipfw 'limit' rules accomplish effectively the same without needing an extra table; eg only allowing N simultaneous connections from any one address. If N were say 4, even a distributed attack by 20 hosts will only allow 80 concurrent connections, no big deal for the firewall and no need to bother trying to limit connections later at the server. That said, I've also tables blocking noted pests, including some recent distributed bots seeking eg blocklist='scripts/setup.php p=phpinfo();' which irritated me enough to knock up a script to knock them off :) BTW, Gareth: ... while talking to mail.lordcow.org.: >>> DATA <<< 550 5.1.1 ... User unknown 550 5.1.1 ... User unknown <<< 503 5.0.0 Need RCPT (recipient) cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 07:10:50 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F27AF1065675 for ; Fri, 10 Sep 2010 07:10:50 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id CBF698FC17 for ; Fri, 10 Sep 2010 07:10:50 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id o8A7AnpX040718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Sep 2010 00:10:49 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id o8A7An6r040717; Fri, 10 Sep 2010 00:10:49 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA12100; Fri, 10 Sep 10 00:06:21 PDT Date: Thu, 09 Sep 2010 23:55:15 -0700 From: perryh@pluto.rain.com To: bsd@lordcow.org Message-Id: <4c89d653.UyUz1Sv9zPckJnig%perryh@pluto.rain.com> References: <20100909125400.GA18723@lordcow.org> <20100909131340.GA75829@icarus.home.lan> <20100909132519.GB21535@lordcow.org> <20100909140224.GA76889@icarus.home.lan> <20100909142226.GA25370@lordcow.org> <20100909142455.GA77677@icarus.home.lan> <20100909142928.GA25877@lordcow.org> <20100909143357.GG34314@home.opsec.eu> <20100909145457.GH34314@home.opsec.eu> <20100909150012.GA27370@lordcow.org> In-Reply-To: <20100909150012.GA27370@lordcow.org> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: MSIX failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 07:10:51 -0000 Gareth de Vaux wrote: > On Thu 2010-09-09 (16:54), Kurt Jaeger wrote: > > -c asks for pci device capabilities, which are read in > > > > /usr/src/usr.sbin/pciconf/pciconf.c:177 with O_RDWR > > Ah. I'll have to schedule a reboot then .. or hack on pciconf.c to not request more permission than it needs. It is arguably a bug to open O_RDWR when only examining things. From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 07:29:04 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87EC21065670; Fri, 10 Sep 2010 07:29:04 +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 9EF988FC08; Fri, 10 Sep 2010 07:29:03 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA15913; Fri, 10 Sep 2010 10:28:51 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Oty2V-0008Fp-Ar; Fri, 10 Sep 2010 10:28:51 +0300 Message-ID: <4C89DE32.9050402@icyb.net.ua> Date: Fri, 10 Sep 2010 10:28:50 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Daniel O'Connor" References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable Stable , "John H. Baldwin" Subject: Re: Enabling MCA causes system hangs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 07:29:04 -0000 on 10/09/2010 05:36 Daniel O'Connor said the following: > Hi, I recently tried enabling MCA (ie w.mca.enabled=1 in loader.conf) on an > 8.0-STABLE system and found that it would cause the system to hang after a > few minutes of uptime. > > The screen would go black and the monitor would turn off (regardless of > wether it was in X or not) and only a hard reset would bring it back. > > Also I found that quite often I had to power cycle the whole PC or the BIOS > wouldn't detect the hard disks on boot(!) after a hang. > > uname is.. FreeBSD midget.dons.net.au 8.0-STABLE FreeBSD 8.0-STABLE #6 > r202903M: Sun Jan 24 13:45:11 CST 2010 > darius@midget.dons.net.au:/usr/obj/usr/src/sys/MIDGET amd64 > > The motherboard is a Gigabyte GA-MA785GM-US2H with an Athlon II X2 240 CPU & > 4Gb of RAM. Do you also have superpages enabled (vm.pmap.pg_ps_enabled)? If so, please try to turn them off and report back if that helps. If not, then it's a tougher situation. What you see looks like a consequence of HyperTransport sync flood, which is a way to handle certain errors detected by CPU. Essentially it means that all HyperTransport communications are frozen. A system just hangs. My impression is that consumer-type systems are often configured to produce sync flood to stop error propagation in situations where more 'serious' systems would report machine check exception (MCE), probably an uncorrectable one. NOTE: the following may hurt your system and your data! Please stop reading if you are unsure if you can handle that! You may try to investigate the sync flood situation further by checking the following bit in CPU configuration: F3x180 Extended NB MCA Configuration Register 21 SyncFloodOnCpuLeakErr: sync flood on CPU leak error enable. You can examine current value with a command like the following: $ pciconf -r pci0:0:24:3 0x180 Where pci0:0:24:3 is PCI handle that corresponds to the device reported as follows by pciconf -lv: '(Family 10h) Athlon64/Opteron/Sempron Miscellaneous Control' If the bit is set, you can try to flip it off (using pciconf -w) and see how your system behaves when the MCA condition strikes. Be careful and cautious. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 07:46:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A1B5106564A; Fri, 10 Sep 2010 07:46:47 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id A69DA8FC0C; Fri, 10 Sep 2010 07:46:46 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.44]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id o8A7kXvD063414 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 10 Sep 2010 17:16:38 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: <4C89DE32.9050402@icyb.net.ua> Date: Fri, 10 Sep 2010 17:16:33 +0930 Content-Transfer-Encoding: quoted-printable Message-Id: <2D9E9363-3F81-4288-8788-8429CBAF6E53@gsoft.com.au> References: <4C89DE32.9050402@icyb.net.ua> To: Andriy Gapon X-Mailer: Apple Mail (2.1081) X-Spam-Score: -2.51 () ALL_TRUSTED,BAYES_00,T_RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-stable Stable , "John H. Baldwin" Subject: Re: Enabling MCA causes system hangs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 07:46:47 -0000 On 10/09/2010, at 16:58, Andriy Gapon wrote: >> The motherboard is a Gigabyte GA-MA785GM-US2H with an Athlon II X2 = 240 CPU & >> 4Gb of RAM. >=20 > Do you also have superpages enabled (vm.pmap.pg_ps_enabled)? > If so, please try to turn them off and report back if that helps. Yes, they are - I will try without. > If not, then it's a tougher situation. > What you see looks like a consequence of HyperTransport sync flood, = which is a > way to handle certain errors detected by CPU. Essentially it means = that all > HyperTransport communications are frozen. A system just hangs. >=20 > My impression is that consumer-type systems are often configured to = produce sync > flood to stop error propagation in situations where more 'serious' = systems would > report machine check exception (MCE), probably an uncorrectable one. Ahh.. The system does seem to operate normally without MCA and I haven't = noticed any data corruption issues. FWIW I am using ZFS on this box and = haven't seen any complaints about corrupt files. > NOTE: the following may hurt your system and your data! > Please stop reading if you are unsure if you can handle that! Woooh, sounds fun :) > You may try to investigate the sync flood situation further by = checking the > following bit in CPU configuration: >=20 > F3x180 Extended NB MCA Configuration Register > 21 SyncFloodOnCpuLeakErr: sync flood on CPU leak error enable. >=20 > You can examine current value with a command like the following: > $ pciconf -r pci0:0:24:3 0x180 >=20 > Where pci0:0:24:3 is PCI handle that corresponds to the device = reported as > follows by pciconf -lv: > '(Family 10h) Athlon64/Opteron/Sempron Miscellaneous Control' >=20 > If the bit is set, you can try to flip it off (using pciconf -w) and = see how > your system behaves when the MCA condition strikes. It does look like it is set: hostb4@pci0:0:24:3: class=3D0x060000 card=3D0x00000000 = chip=3D0x12031022 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D '(Family 10h) Athlon64/Opteron/Sempron Miscellaneous = Control' class =3D bridge subclass =3D HOST-PCI [midget 17:09] /usr/src/sys >sudo pciconf -r pci0:0:24:3 0x180 00f003e2=20 Which is.. 0 0 f 0 0 3 e 2 0000 0000 1111 0000 0000 0011 1110 0010 | | | | | | | | | 31 27 23 19 15 11 7 3 0 > Be careful and cautious. Thanks, I'll let you know how I go! -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 08:30:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6C3D1065670 for ; Fri, 10 Sep 2010 08:30:25 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 50A738FC15 for ; Fri, 10 Sep 2010 08:30:25 +0000 (UTC) Received: by fxm4 with SMTP id 4so1813424fxm.13 for ; Fri, 10 Sep 2010 01:30:24 -0700 (PDT) Received: by 10.223.103.82 with SMTP id j18mr98621fao.98.1284107424139; Fri, 10 Sep 2010 01:30:24 -0700 (PDT) Received: from jessie.localnet (p5B0E3D6C.dip0.t-ipconnect.de [91.14.61.108]) by mx.google.com with ESMTPS id r4sm1207552faa.43.2010.09.10.01.30.22 (version=SSLv3 cipher=RC4-MD5); Fri, 10 Sep 2010 01:30:22 -0700 (PDT) From: Bernhard Schmidt To: Dominic Fandrey Date: Fri, 10 Sep 2010 10:30:20 +0200 User-Agent: KMail/1.13.2 (Linux/2.6.32-24-generic; KDE/4.4.2; i686; ; ) References: <4C716382.3040605@bsdforen.de> <4C85E638.4070403@bsdforen.de> <201009070918.42959.bschmidt@techwires.net> In-Reply-To: <201009070918.42959.bschmidt@techwires.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201009101030.20856.bschmidt@techwires.net> Cc: freebsd-stable@freebsd.org Subject: Re: wpa_supplicant does not create pidfile X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 08:30:25 -0000 On Tuesday, September 07, 2010 09:18:42 Bernhard Schmidt wrote: > On Tuesday, September 07, 2010 09:14:00 Dominic Fandrey wrote: > > On 07/09/2010 09:09, Bernhard Schmidt wrote: > > > On Tuesday, September 07, 2010 09:01:18 Dominic Fandrey wrote: > > >> On 07/09/2010 08:50, Bernhard Schmidt wrote: > > >>> On Friday, August 27, 2010 09:42:30 Bernhard Schmidt wrote: > > >>>> On Fri, Aug 27, 2010 at 09:36, Dominic Fandrey > > >>>> > > > > > > wrote: > > >>>>> On 27/08/2010 09:28, Bernhard Schmidt wrote: > > >>>>>> On Sun, Aug 22, 2010 at 19:50, Dominic Fandrey > > >>>>>> > > >>> > > >>> wrote: > > >>>>>>> wpa_supplicant doesn't create the pidfile if the target directory > > >>>>>>> does not exist. Because /var/run is wiped with every boot I added > > >>>>>>> the following line to my rc.local to workaround this issue: > > >>>>>>> > > >>>>>>> /bin/mkdir -p /var/run/wpa_supplicant > > >>>>>>> > > >>>>>>> I'm running RELENG_8. > > >>>>>> > > >>>>>> How about this? > > >>>>>> > > >>>>>> Index: etc/mtree/BSD.var.dist > > >>>>>> ================================================================== > > >>>>>> = --- etc/mtree/BSD.var.dist>.....(revision 211568) > > >>>>>> +++ etc/mtree/BSD.var.dist>.....(working copy) > > >>>>>> @@ -64,6 +64,8 @@ > > >>>>>> > > >>>>>> .. > > >>>>>> ppp gname=network mode=0770 > > >>>>>> .. > > >>>>>> > > >>>>>> + wpa_supplicant > > >>>>>> + .. > > >>>>>> > > >>>>>> .. > > >>>>>> rwho gname=daemon mode=0775 > > >>>>>> .. I committed this change, as it seems to the correct solution. > > >>>>> Is the mtree built every time the system boots? Because my /var/run > > >>>>> is a tmpfs. And even if it wasn't, I think it's wiped every boot > > >>>>> any way. > > >>>> > > >>>> Not build but, according to /etc/rc.d/var mtree is run on every > > >>>> boot. I actually tried that and it works just fine. > > >>> > > >>> Did you have a chance to try this? Given positive feedback I'd like > > >>> to commit it. > > >> > > >> No, doesn't work. The named and ppp directories also don't exist. > > >> > > >> Sorry about the delay. > > > > > > Ok, thanks. > > > > > > Is it only /var/run/* that is wiped for you, or /var/* itself? I just > > > checked > > > > > > rc.d/var and it looks like this: > > > if [ -d /var/run -a -d /var/db -a -d /var/empty ] ; then > > > > > > true > > > > > > elif [ -x /usr/sbin/mtree ] ; then > > > > > > populate_var > > > > > > So.. if var/run does exist, populate_var isn't run. > > > > Only /var/run and /var/log are tmpfs (notebook, reduce HD access > > to allow HD spindown). I wouldn't wipe my /var/db every boot. > > Ah, ok, that explains it. Try with populate_var=YES in rc.conf and it > should create all directories under var/run. Were you able to give this a shot? -- Bernhard From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 08:41:34 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA13A1065675 for ; Fri, 10 Sep 2010 08:41:34 +0000 (UTC) (envelope-from bsd@lordcow.org) Received: from lordcow.org (lordcow.org [41.203.5.188]) by mx1.freebsd.org (Postfix) with ESMTP id DC55A8FC24 for ; Fri, 10 Sep 2010 08:41:33 +0000 (UTC) Received: from lordcow.org (localhost [127.0.0.1]) by lordcow.org (8.14.4/8.14.4) with ESMTP id o8A8fPpO048076 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Fri, 10 Sep 2010 10:41:25 +0200 (SAST) (envelope-from lordcow@lordcow.org) Received: (from lordcow@localhost) by lordcow.org (8.14.4/8.14.4/Submit) id o8A8fKV4048075 for stable@freebsd.org; Fri, 10 Sep 2010 10:41:20 +0200 (SAST) (envelope-from lordcow) Date: Fri, 10 Sep 2010 10:41:20 +0200 From: Gareth de Vaux To: stable@freebsd.org Message-ID: <20100910084120.GA46966@lordcow.org> References: <201009091437.21563.jhb@freebsd.org> <201009091620.25299.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lordcow.org Cc: Subject: Re: MSIX failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 08:41:34 -0000 On Thu 2010-09-09 (13:48), Jack Vogel wrote: > Gareth's email bouncing for anybody else or is it just me? Yes sorry I disabled this alias after picking up years of spam on the mailman archives. I assumed people would primarily reply to the list. I've re-enabled it for now. > Gareth, set hw.pci.honor_msi_blacklist=0, you'll have to do that at boot > btw. Ok, I'll have to get back to you in a day or 2 when I reboot. > Tell me more exactly the make/model of the hardware so I might try to get > my hands on one? I can't tell much more from here, the card came from the datacentre's reserve when I was fighting with the onboard. The larger lettering on the card itself was just 'Intel(R) PRO/1000 GT Desktop Adapter'. I didn't note down the smaller model-type numbers. Is this http://lists.freebsd.org/pipermail/freebsd-stable/2010-September/058748.html not enough? From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 08:51:33 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97FDE1065695 for ; Fri, 10 Sep 2010 08:51:33 +0000 (UTC) (envelope-from bsd@lordcow.org) Received: from lordcow.org (lordcow.org [41.203.5.188]) by mx1.freebsd.org (Postfix) with ESMTP id B90CA8FC1E for ; Fri, 10 Sep 2010 08:51:32 +0000 (UTC) Received: from lordcow.org (localhost [127.0.0.1]) by lordcow.org (8.14.4/8.14.4) with ESMTP id o8A8pPfJ048500 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Fri, 10 Sep 2010 10:51:25 +0200 (SAST) (envelope-from lordcow@lordcow.org) Received: (from lordcow@localhost) by lordcow.org (8.14.4/8.14.4/Submit) id o8A8pKs7048499 for stable@freebsd.org; Fri, 10 Sep 2010 10:51:20 +0200 (SAST) (envelope-from lordcow) Date: Fri, 10 Sep 2010 10:51:20 +0200 From: Gareth de Vaux To: stable@freebsd.org Message-ID: <20100910085120.GB46966@lordcow.org> References: <201009091437.21563.jhb@freebsd.org> <201009091620.25299.jhb@freebsd.org> <20100910084120.GA46966@lordcow.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100910084120.GA46966@lordcow.org> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lordcow.org Cc: Subject: Re: MSIX failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 08:51:33 -0000 On Fri 2010-09-10 (10:41), Gareth de Vaux wrote: > http://lists.freebsd.org/pipermail/freebsd-stable/2010-September/058748.html Just to reiterate - those are the specs of the PCI card that doesn't work. The PCI card doesn't come up with MSIX failures. The onboard has the MSIX failures but continues to work as you say. These are the comparative specs for the onboard: kernel: em0: port 0x3040-0x305f mem 0xe3200000-0xe321ffff,0xe3220000-0xe3220fff irq 10 at device 25.0 on pci0 kernel: em0: Setup MSIX failure kernel: em0: [FILTER] kernel: em0: Ethernet address: 00:27:0e:1e:5e:e3 $ ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=219b ether 00:27:0e:1e:5e:e3 inet XXXXXXXX media: Ethernet autoselect (100baseTX ) status: active pciconf -lv: em0@pci0:0:25:0: class=0x020000 card=0x00008086 chip=0x10f08086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 09:04:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67A8F1065670 for ; Fri, 10 Sep 2010 09:04:07 +0000 (UTC) (envelope-from free.bsd@webstyle.ch) Received: from zimbra.webstyle.ch (zimbra.webstyle.ch [212.103.68.7]) by mx1.freebsd.org (Postfix) with ESMTP id F128F8FC19 for ; Fri, 10 Sep 2010 09:04:06 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.webstyle.ch (Postfix) with ESMTP id 6F63910C00B8 for ; Fri, 10 Sep 2010 10:45:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.webstyle.ch Received: from zimbra.webstyle.ch ([127.0.0.1]) by localhost (zimbra.webstyle.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4s6O290OkokI; Fri, 10 Sep 2010 10:45:11 +0200 (CEST) Received: from [192.168.1.128] (unknown [212.60.63.146]) by zimbra.webstyle.ch (Postfix) with ESMTPA id 154F710C00A1; Fri, 10 Sep 2010 10:45:11 +0200 (CEST) Message-ID: <4C89F014.1050601@webstyle.ch> Date: Fri, 10 Sep 2010 10:45:08 +0200 From: freebsd User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: strange problem with FreeBSD 7.3 64bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 09:04:07 -0000 hi list, we upgraded some 20 boxes from 7.1 and 7.2 to 7.3-RELEASE-p2 (all amd64) and now are experiencing some weird behaviour on 6 of them with rsnapshot: after a few days/several weeks (seems to be completely random), rsnapshot reports that it can't start due it's lockfile and process still being present. on such boxes either a zombie rm or find process (which presumably were launched by rsnapshot) can be found. if the backup was done to a separate partition (physical disks or RAIDs) any access (ls, stat, fsck, etc) to the partition would kill the current SSH session, creating a new zombie of the process one just started. unmounting the affected partition would render the server completely unresponsive and required a hardware reset. when trying to restart, the machines wouldn't even shut down completely but hanged somewhere after syncing buffers, only a hardware reset worked. after the reboot, those partitions were unmounted and fscked. after which the backups would work again until the next error happened again. the hardware of affected and unaffected system are: HP ProLiant DL380 G4 HP ProLiant DL380 G5 HP ProLiant DL360 G5 there is no visible pattern between affected and unaffected boxes. also those machines were upgraded the exact same way, running identical kernels (more or less GENERIC, with QUOTA activated). we upgraded the most critical boxes which showed that behaviour on a daily interval to 8.0-RELEASE and ever since this behavior has disappeared since nearly 3 months now. we installed a debug-kernel on an affected box, but the machine wouldn't panic when the error occured. when trying to unmount the affected partition it just went completely unresponsive, as mentioned above. before trying to unmount procstat -ak showed some processes with VOP_LOCK1_APV: 55396 100135 find - mi_switch sleepq_switch sleepq_wait _sleep acquire _lockmgr ffs_lock VOP_LOCK1_APV _vn_lock vget cache_lookup vfs_cache_lookup VOP_LOOKUP_APV lookup namei kern_lstat lstat syscall 70923 100146 rsync - mi_switch sleepq_switch sleepq_wait _sleep acquire _lockmgr ffs_lock VOP_LOCK1_APV _vn_lock vget vfs_hash_get ffs_vgetf ufs_lookup_ vfs_cache_lookup OP_LOOKUP_APV lookup namei kern_lstat since this hardware has been working before 7.3 and -- as we assume -- would work again with 8.*, we would be grateful for any hints what could be the cause of all this. kind regards Flo From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 09:20:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 750A31065694 for ; Fri, 10 Sep 2010 09:20:39 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id B22DF8FC15 for ; Fri, 10 Sep 2010 09:20:36 +0000 (UTC) Received: from park.js.berklix.net (p549A7BE7.dip.t-dialin.net [84.154.123.231]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o8A9KPdS029426 for ; Fri, 10 Sep 2010 09:20:30 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o8A9KF1A033216 for ; Fri, 10 Sep 2010 11:20:15 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o8A9KAAp030811 for ; Fri, 10 Sep 2010 11:20:15 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201009100920.o8A9KAAp030811@fire.js.berklix.net> to: freebsd-stable@freebsd.org From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Thu, 09 Sep 2010 14:03:33 -0000." Date: Fri, 10 Sep 2010 11:20:10 +0200 Sender: jhs@berklix.com Subject: Re: Policy for removing working code X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 09:20:39 -0000 Vadim Goncharov wrote: > Hi Scot Hetzel! > > On Thu, 9 Sep 2010 04:18:52 -0500; Scot Hetzel wrote about 'Re: Policy for removing working code': > > >>> We can't e-mail announce@ every time something is going to > >>> be removed. šThat would be way too much spam for that list. > >> > >> That may depend on how often something substantial is removed :) > >> > >>> I do think stable@ is a good place to e-mail ... > >> > >> Good, perhaps even "necessary", but is it "sufficient"? šThose > >> following a -STABLE branch are expected to read stable@, but > >> what about those who are following a security branch? > >> > > If someone is following a RELENG_X (a.k.a -STABLE) or a RELENG_X_Y (a > > errata fix branch), then they should be reading the stable@ list. > > True for RELENG_X, but not for RELENG_X_Y. They shouldn't, because all > information for security/errata fix branch go to announce@, they don't > need to read all noise in stable@ just for this. And, what is more important, > they in fact don't do. So announce@ is the only choice from purely practical > means. One option could be a new list perhaps called eg one of features@ advisories@ notifications@ feature-notifications@ to carry heads up notification of future feature changes / removals. Its would be more traffic than announce@ but much lower traffic than stable@ FreeBSD already has the precedent of security-notifications@ Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text, Not HTML, quoted-printable & base 64 dumped with spam. Avoid top posting, It cripples itemised cumulative responses. From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 09:22:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FAEA106566B for ; Fri, 10 Sep 2010 09:22:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 398868FC13 for ; Fri, 10 Sep 2010 09:22:22 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o8A9LqK0062244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Sep 2010 12:21:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o8A9LpHB077680; Fri, 10 Sep 2010 12:21:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o8A9LpkH077679; Fri, 10 Sep 2010 12:21:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 10 Sep 2010 12:21:51 +0300 From: Kostik Belousov To: freebsd Message-ID: <20100910092151.GO2465@deviant.kiev.zoral.com.ua> References: <4C89F014.1050601@webstyle.ch> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WoqaC9TUMqqIOlla" Content-Disposition: inline In-Reply-To: <4C89F014.1050601@webstyle.ch> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-stable@freebsd.org Subject: Re: strange problem with FreeBSD 7.3 64bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 09:22:23 -0000 --WoqaC9TUMqqIOlla Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 10, 2010 at 10:45:08AM +0200, freebsd wrote: > hi list, >=20 > we upgraded some 20 boxes from 7.1 and 7.2 to 7.3-RELEASE-p2 (all amd64)= =20 > and now are experiencing some weird behaviour on 6 of them with rsnapshot: >=20 > after a few days/several weeks (seems to be completely random),=20 > rsnapshot reports that it can't start due it's lockfile and process=20 > still being present. on such boxes either a zombie rm or find process=20 > (which presumably were launched by rsnapshot) can be found. > if the backup was done to a separate partition (physical disks or RAIDs)= =20 > any access (ls, stat, fsck, etc) to the partition would kill the current= =20 > SSH session, creating a new zombie of the process one just started.=20 > unmounting the affected partition would render the server completely=20 > unresponsive and required a hardware reset. >=20 > when trying to restart, the machines wouldn't even shut down completely= =20 > but hanged somewhere after syncing buffers, only a hardware reset=20 > worked. after the reboot, those partitions were unmounted and fscked.=20 > after which the backups would work again until the next error happened=20 > again. >=20 > the hardware of affected and unaffected system are: >=20 > HP ProLiant DL380 G4 > HP ProLiant DL380 G5 > HP ProLiant DL360 G5 >=20 > there is no visible pattern between affected and unaffected boxes. also= =20 > those machines were upgraded the exact same way, running identical=20 > kernels (more or less GENERIC, with QUOTA activated). >=20 > we upgraded the most critical boxes which showed that behaviour on a=20 > daily interval to 8.0-RELEASE and ever since this behavior has=20 > disappeared since nearly 3 months now. >=20 > we installed a debug-kernel on an affected box, but the machine wouldn't= =20 > panic when the error occured. when trying to unmount the affected=20 > partition it just went completely unresponsive, as mentioned above. >=20 > before trying to unmount procstat -ak showed some processes with=20 > VOP_LOCK1_APV: >=20 > 55396 100135 find - mi_switch sleepq_switch sleepq_wait _sleep acquire=20 > _lockmgr ffs_lock VOP_LOCK1_APV _vn_lock vget cache_lookup=20 > vfs_cache_lookup VOP_LOOKUP_APV lookup namei kern_lstat lstat syscall > 70923 100146 rsync - mi_switch sleepq_switch sleepq_wait _sleep acquire= =20 > _lockmgr ffs_lock VOP_LOCK1_APV _vn_lock vget vfs_hash_get ffs_vgetf=20 > ufs_lookup_ vfs_cache_lookup OP_LOOKUP_APV lookup namei kern_lstat >=20 > since this hardware has been working before 7.3 and -- as we assume --=20 > would work again with 8.*, we would be grateful for any hints what could= =20 > be the cause of all this. It sounds like a deadlock, but the cause cannot be identified without further diagnostic. It might be driver (ciss I assume), but may be quota code, or even something else. Please follow the http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kernel= debug-deadlocks.html to obtain the required information. --WoqaC9TUMqqIOlla Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkyJ+K4ACgkQC3+MBN1Mb4hoJgCcCUB2l/kM45sCbzBk/czEKrUB CrsAoM0ZaXnPW90d4+s5xOemTp/S4kMD =DZNb -----END PGP SIGNATURE----- --WoqaC9TUMqqIOlla-- From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 10:04:56 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD65D106566C for ; Fri, 10 Sep 2010 10:04:56 +0000 (UTC) (envelope-from free.bsd@webstyle.ch) Received: from zimbra.webstyle.ch (zimbra.webstyle.ch [212.103.68.7]) by mx1.freebsd.org (Postfix) with ESMTP id 9B0478FC0C for ; Fri, 10 Sep 2010 10:04:56 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.webstyle.ch (Postfix) with ESMTP id B237810C00A2; Fri, 10 Sep 2010 12:04:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.webstyle.ch Received: from zimbra.webstyle.ch ([127.0.0.1]) by localhost (zimbra.webstyle.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ov+B3HuXqQ5; Fri, 10 Sep 2010 12:04:52 +0200 (CEST) Received: from [192.168.1.128] (unknown [212.60.63.146]) by zimbra.webstyle.ch (Postfix) with ESMTPA id 955BA10C00A0; Fri, 10 Sep 2010 12:04:52 +0200 (CEST) Message-ID: <4C8A02C2.9060704@webstyle.ch> Date: Fri, 10 Sep 2010 12:04:50 +0200 From: freebsd User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Kostik Belousov References: <4C89F014.1050601@webstyle.ch> <20100910092151.GO2465@deviant.kiev.zoral.com.ua> In-Reply-To: <20100910092151.GO2465@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: strange problem with FreeBSD 7.3 64bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 10:04:56 -0000 Am 10.09.2010 11:21, schrieb Kostik Belousov: > On Fri, Sep 10, 2010 at 10:45:08AM +0200, freebsd wrote: > It sounds like a deadlock, but the cause cannot be identified without > further diagnostic. It might be driver (ciss I assume), but may be quota > code, or even something else. > > Please follow the > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html > to obtain the required information. thanks for the quick answer. we've added the additional options to debug deadlocks. we'll have the required information in the timeframe of 1-2 weeks, since the testbox isn't that fast at generating the error. QUOTA most likely isn't the culprit, since 2 of the affected 6 boxes were running GENERIC w/o any modifications. From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 10:23:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69593106564A for ; Fri, 10 Sep 2010 10:23:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id D71388FC0A for ; Fri, 10 Sep 2010 10:23:40 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o8AANbFM067365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Sep 2010 13:23:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o8AANaoL087534; Fri, 10 Sep 2010 13:23:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o8AANadt087533; Fri, 10 Sep 2010 13:23:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 10 Sep 2010 13:23:36 +0300 From: Kostik Belousov To: freebsd Message-ID: <20100910102336.GP2465@deviant.kiev.zoral.com.ua> References: <4C89F014.1050601@webstyle.ch> <20100910092151.GO2465@deviant.kiev.zoral.com.ua> <4C8A02C2.9060704@webstyle.ch> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0UhZIN3Sa23/ILEd" Content-Disposition: inline In-Reply-To: <4C8A02C2.9060704@webstyle.ch> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_05, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-stable@freebsd.org Subject: Re: strange problem with FreeBSD 7.3 64bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 10:23:41 -0000 --0UhZIN3Sa23/ILEd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 10, 2010 at 12:04:50PM +0200, freebsd wrote: > Am 10.09.2010 11:21, schrieb Kostik Belousov: > >On Fri, Sep 10, 2010 at 10:45:08AM +0200, freebsd wrote: > >It sounds like a deadlock, but the cause cannot be identified without > >further diagnostic. It might be driver (ciss I assume), but may be quota > >code, or even something else. > > > >Please follow the > >http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ker= neldebug-deadlocks.html > >to obtain the required information. >=20 > thanks for the quick answer. > we've added the additional options to debug deadlocks. we'll have the=20 > required information in the timeframe of 1-2 weeks, since the testbox=20 > isn't that fast at generating the error. >=20 > QUOTA most likely isn't the culprit, since 2 of the affected 6 boxes=20 > were running GENERIC w/o any modifications. Ah. Then, the ciss(4) is the main suspect, but I cannot help with it. --0UhZIN3Sa23/ILEd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkyKBygACgkQC3+MBN1Mb4jEvACff3M7J2VzZfo0Rfc1VintAjqo xFkAnjZUcNxEArWEfRg0WQ2en60un4d+ =rMar -----END PGP SIGNATURE----- --0UhZIN3Sa23/ILEd-- From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 10:36:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58A8A106566B for ; Fri, 10 Sep 2010 10:36:54 +0000 (UTC) (envelope-from beezarliu@yahoo.com.cn) Received: from nm23-vm0.bullet.mail.ac4.yahoo.com (nm23-vm0.bullet.mail.ac4.yahoo.com [98.139.53.220]) by mx1.freebsd.org (Postfix) with SMTP id B97458FC12 for ; Fri, 10 Sep 2010 10:36:53 +0000 (UTC) Received: from [98.139.52.196] by nm23.bullet.mail.ac4.yahoo.com with NNFMP; 10 Sep 2010 10:24:08 -0000 Received: from [74.6.228.36] by tm9.bullet.mail.ac4.yahoo.com with NNFMP; 10 Sep 2010 10:24:08 -0000 Received: from [127.0.0.1] by smtp105.mail.ac4.yahoo.com with NNFMP; 10 Sep 2010 10:24:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.cn; s=s1024; t=1284114248; bh=cJWmRM2QiHBl9uobpIg2CYaBf5p2pfR1oAXweh7j0OE=; h=X-Yahoo-Newman-Id:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Date:From:To:Cc:Subject:Message-ID:X-mailer:Mime-Version:Content-Type; b=2BuDUpf3W7+v3h5xZiwGOyD6v6BE4FbzeF1W4p4uNcSpcRykLjMDGmUOpNNGoUjBorBeBJVU18L+H3/agU/Wjyuxg+96va3mNN5ZTvpLSezaC1wq1PA4buun6v9UGSl/M2t3zx1UgAIvhNPujarnEAk7LtsxIsE1pRmCsLXyGXE= X-Yahoo-Newman-Id: 548180.61002.bm@smtp105.mail.ac4.yahoo.com Received: from china (beezarliu@124.207.251.123 with login) by smtp105.mail.ac4.yahoo.com with SMTP; 10 Sep 2010 03:24:06 -0700 PDT X-Yahoo-SMTP: YP5UPy2swBBHZGZlvbmOrntlD3fotw-- X-YMail-OSG: .t5xC94VM1kGZlUN4eODpXZi26uqcv3Id0IDA6dqPDORmza uhncWwdAWoSbXdn7f71OJqoTjuhNr63KuG8jQNY9di325OxYEdex5pk1bpbO Q7F1f0bhXout.Mf74PzKzj4.7XOqrsOW.tZKMS0.avOH34Pa77z09O__uw6J ALl1mAiZ7B6UprXWpP72gmeDlL7Im8CJBNmhNWaX0n3XPY0rLGF3DWSnKfnR 4fjseGt1XNaxabAn._Ag3ruwRb.lp X-Yahoo-Newman-Property: ymail-3 Date: Fri, 10 Sep 2010 18:24:04 +0800 From: "beezarliu" To: "freebsd-stable" Message-ID: <201009101823570620798@yahoo.com.cn> X-mailer: Foxmail 6, 10, 201, 20 [cn] Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====001_Dragon734515843444_=====" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Jack Vogel Subject: e1000 receive queue handling X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 10:36:54 -0000 This is a multi-part message in MIME format. --=====001_Dragon734515843444_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Hi, I found em's receiving queue handling will have the following problems if system mbuf is used up. 1. NIC will hang because receive ring's tail pointer will not be updated (in em_rxeof). 2. "ifconfig up/down" may cause system panic because em_setup_receive_ring will free already-freed mbufs. So I made some changes: 1. NIC's recieve ring's head/tail pointer is updated according to rxr's next_to_check/next_to_refresh. So, on the position of next_to_refresh, no need to fill free mbuf because datasheet says "When the head pointer(s) is equal to the tail pointer(s), the queue(s) is empty. Hardware stops storing packets in system memory until software advances the tail pointer(s), making more receive buffers available." And (next_to_refresh + 1) % num_rx_desc == next_to_check means ring queue is full. 2. no need to reallocate the mbufs on receive queue when em re-initialize. 3. The mbufs on the queue are also freed according to these two indexs. 4. If ring queue is empty, em_refresh_mbufs is also called even if it doesn't handle any packet. Any comment? Thanks 2010-09-10 beezarliu --=====001_Dragon734515843444_===== Content-Type: application/octet-stream; name="if_em.c.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="if_em.c.patch" SW5kZXg6IGlmX2VtLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gaWZfZW0uYwkocmV2aXNpb24gMjEyNDA1KQor KysgaWZfZW0uYwkod29ya2luZyBjb3B5KQpAQCAtMzY3MSwxMSArMzY3MSwxMyBAQAogCWJ1c19k bWFfc2VnbWVudF90CXNlZ3NbMV07CiAJYnVzX2RtYW1hcF90CQltYXA7CiAJc3RydWN0IGVtX2J1 ZmZlcgkqcnhidWY7Ci0JaW50CQkJaSwgZXJyb3IsIG5zZWdzLCBjbGVhbmVkOworCWludAkJCWks IGosIGVycm9yLCBuc2VncywgY2xlYW5lZDsKIAotCWkgPSByeHItPm5leHRfdG9fcmVmcmVzaDsK KwlpID0gaiA9IHJ4ci0+bmV4dF90b19yZWZyZXNoOwogCWNsZWFuZWQgPSAtMTsKLQl3aGlsZSAo aSAhPSBsaW1pdCkgeworCWlmICgrK2ogPT0gYWRhcHRlci0+bnVtX3J4X2Rlc2MpCisJCWogPSAw OworCXdoaWxlIChqICE9IGxpbWl0KSB7CiAJCW0gPSBtX2dldGNsKE1fRE9OVFdBSVQsIE1UX0RB VEEsIE1fUEtUSERSKTsKIAkJaWYgKG0gPT0gTlVMTCkKIAkJCWdvdG8gdXBkYXRlOwpAQCAtMzcx MSw5ICszNzEzLDEwIEBACiAJCXJ4ci0+cnhfYmFzZVtpXS5idWZmZXJfYWRkciA9IGh0b2xlNjQo c2Vnc1swXS5kc19hZGRyKTsKIAogCQljbGVhbmVkID0gaTsKKwkJaSA9IGo7CiAJCS8qIENhbGN1 bGF0ZSBuZXh0IGluZGV4ICovCi0JCWlmICgrK2kgPT0gYWRhcHRlci0+bnVtX3J4X2Rlc2MpCi0J CQlpID0gMDsKKwkJaWYgKCsraiA9PSBhZGFwdGVyLT5udW1fcnhfZGVzYykKKwkJCWogPSAwOwog CQkvKiBUaGlzIGlzIHRoZSB3b3JrIG1hcmtlciBmb3IgcmVmcmVzaCAqLwogCQlyeHItPm5leHRf dG9fcmVmcmVzaCA9IGk7CiAJfQpAQCAtMzcyMiw3ICszNzI1LDcgQEAKIAkgICAgQlVTX0RNQVNZ TkNfUFJFUkVBRCB8IEJVU19ETUFTWU5DX1BSRVdSSVRFKTsKIAlpZiAoY2xlYW5lZCAhPSAtMSkg LyogVXBkYXRlIHRhaWwgaW5kZXggKi8KIAkJRTEwMDBfV1JJVEVfUkVHKCZhZGFwdGVyLT5odywK LQkJICAgIEUxMDAwX1JEVChyeHItPm1lKSwgY2xlYW5lZCk7CisJCSAgICBFMTAwMF9SRFQocnhy LT5tZSksIHJ4ci0+bmV4dF90b19yZWZyZXNoKTsKIAogCXJldHVybjsKIH0KQEAgLTM4MDksMzIg KzM4MTIsMjIgQEAKIAlzdHJ1Y3QJYWRhcHRlciAJKmFkYXB0ZXIgPSByeHItPmFkYXB0ZXI7CiAJ c3RydWN0IGVtX2J1ZmZlcgkqcnhidWY7CiAJYnVzX2RtYV9zZWdtZW50X3QJc2VnWzFdOwotCWlu dAkJCXJzaXplLCBuc2VncywgZXJyb3I7CisJaW50CQkJaSwgaiwgbnNlZ3MsIGVycm9yOwogCiAK IAkvKiBDbGVhciB0aGUgcmluZyBjb250ZW50cyAqLwogCUVNX1JYX0xPQ0socnhyKTsKLQlyc2l6 ZSA9IHJvdW5kdXAyKGFkYXB0ZXItPm51bV9yeF9kZXNjICoKLQkgICAgc2l6ZW9mKHN0cnVjdCBl MTAwMF9yeF9kZXNjKSwgRU1fREJBX0FMSUdOKTsKLQliemVybygodm9pZCAqKXJ4ci0+cnhfYmFz ZSwgcnNpemUpOwotCi0JLyoKLQkqKiBGcmVlIGN1cnJlbnQgUlggYnVmZmVyIHN0cnVjdHMgYW5k IHRoZWlyIG1idWZzCi0JKi8KLQlmb3IgKGludCBpID0gMDsgaSA8IGFkYXB0ZXItPm51bV9yeF9k ZXNjOyBpKyspIHsKLQkJcnhidWYgPSAmcnhyLT5yeF9idWZmZXJzW2ldOwotCQlpZiAocnhidWYt Pm1faGVhZCAhPSBOVUxMKSB7Ci0JCQlidXNfZG1hbWFwX3N5bmMocnhyLT5yeHRhZywgcnhidWYt Pm1hcCwKLQkJCSAgICBCVVNfRE1BU1lOQ19QT1NUUkVBRCk7Ci0JCQlidXNfZG1hbWFwX3VubG9h ZChyeHItPnJ4dGFnLCByeGJ1Zi0+bWFwKTsKLQkJCW1fZnJlZW0ocnhidWYtPm1faGVhZCk7Ci0J CX0KKwlmb3IgKGkgPSAwOyBpIDwgYWRhcHRlci0+bnVtX3J4X2Rlc2M7IGkrKykgeworCQlzdHJ1 Y3QgZTEwMDBfcnhfZGVzYyogY3VyOworCQljdXIgPSAmcnhyLT5yeF9iYXNlW2ldOworCQljdXIt PnN0YXR1cyA9IDA7CiAJfQogCi0JLyogTm93IHJlcGxlbmlzaCB0aGUgbWJ1ZnMgKi8KLQlmb3Ig KGludCBqID0gMDsgaiAhPSBhZGFwdGVyLT5udW1fcnhfZGVzYzsgKytqKSB7Ci0KLQkJcnhidWYg PSAmcnhyLT5yeF9idWZmZXJzW2pdOworCWkgPSBqID0gcnhyLT5uZXh0X3RvX3JlZnJlc2g7CisJ aWYgKCsraiA9PSBhZGFwdGVyLT5udW1fcnhfZGVzYykKKwkJaiA9IDA7CisJd2hpbGUoaiAhPSBy eHItPm5leHRfdG9fY2hlY2spIHsKKwkJcnhidWYgPSAmcnhyLT5yeF9idWZmZXJzW2ldOwogCQly eGJ1Zi0+bV9oZWFkID0gbV9nZXRjbChNX0RPTlRXQUlULCBNVF9EQVRBLCBNX1BLVEhEUik7CiAJ CWlmIChyeGJ1Zi0+bV9oZWFkID09IE5VTEwpCiAJCQlwYW5pYygiUlggcmluZyBoZHIgaW5pdGlh bGl6YXRpb24gZmFpbGVkIVxuIik7CkBAIC0zODUyLDEzICszODQ1LDE0IEBACiAJCSAgICByeGJ1 Zi0+bWFwLCBCVVNfRE1BU1lOQ19QUkVSRUFEKTsKIAogCQkvKiBVcGRhdGUgZGVzY3JpcHRvciAq LwotCQlyeHItPnJ4X2Jhc2Vbal0uYnVmZmVyX2FkZHIgPSBodG9sZTY0KHNlZ1swXS5kc19hZGRy KTsKKwkJcnhyLT5yeF9iYXNlW2ldLmJ1ZmZlcl9hZGRyID0gaHRvbGU2NChzZWdbMF0uZHNfYWRk cik7CisJCWkgPSBqOworCQlpZiAoKytqID09IGFkYXB0ZXItPm51bV9yeF9kZXNjKQorCQkJaiA9 IDA7CiAJfQogCi0KIAkvKiBTZXR1cCBvdXIgZGVzY3JpcHRvciBpbmRpY2VzICovCi0JcnhyLT5u ZXh0X3RvX2NoZWNrID0gMDsKLQlyeHItPm5leHRfdG9fcmVmcmVzaCA9IDA7CisJcnhyLT5uZXh0 X3RvX3JlZnJlc2ggPSBpOwogCiAJYnVzX2RtYW1hcF9zeW5jKHJ4ci0+cnhkbWEuZG1hX3RhZywg cnhyLT5yeGRtYS5kbWFfbWFwLAogCSAgICBCVVNfRE1BU1lOQ19QUkVSRUFEIHwgQlVTX0RNQVNZ TkNfUFJFV1JJVEUpOwpAQCAtMzkzOCw2ICszOTMyLDcgQEAKIHsKIAlzdHJ1Y3QgYWRhcHRlcgkJ KmFkYXB0ZXIgPSByeHItPmFkYXB0ZXI7CiAJc3RydWN0IGVtX2J1ZmZlcgkqcnhidWYgPSBOVUxM OworCWludCAJCQlpOwogCiAJSU5JVF9ERUJVR09VVCgiZnJlZV9yZWNlaXZlX2J1ZmZlcnM6IGJl Z2luIik7CiAKQEAgLTM5NDcsNyArMzk0Miw4IEBACiAJfQogCiAJaWYgKHJ4ci0+cnhfYnVmZmVy cyAhPSBOVUxMKSB7Ci0JCWZvciAoaW50IGkgPSAwOyBpIDwgYWRhcHRlci0+bnVtX3J4X2Rlc2M7 IGkrKykgeworCQlpID0gcnhyLT5uZXh0X3RvX2NoZWNrOworCQl3aGlsZShpICE9IHJ4ci0+bmV4 dF90b19yZWZyZXNoKSB7CiAJCQlyeGJ1ZiA9ICZyeHItPnJ4X2J1ZmZlcnNbaV07CiAJCQlpZiAo cnhidWYtPm1hcCAhPSBOVUxMKSB7CiAJCQkJYnVzX2RtYW1hcF9zeW5jKHJ4ci0+cnh0YWcsIHJ4 YnVmLT5tYXAsCkBAIC0zOTU5LDYgKzM5NTUsOCBAQAogCQkJCW1fZnJlZW0ocnhidWYtPm1faGVh ZCk7CiAJCQkJcnhidWYtPm1faGVhZCA9IE5VTEw7CiAJCQl9CisJCQlpZiAoKytpID09IGFkYXB0 ZXItPm51bV9yeF9kZXNjKQorCQkJCWkgPSAwOwkJCQogCQl9CiAJCWZyZWUocnhyLT5yeF9idWZm ZXJzLCBNX0RFVkJVRik7CiAJCXJ4ci0+cnhfYnVmZmVycyA9IE5VTEw7CkBAIC00MDQ0LDggKzQw NDIsOCBAQAogCQlFMTAwMF9XUklURV9SRUcoaHcsIEUxMDAwX1JEQkFIKGkpLCAodTMyKShidXNf YWRkciA+PiAzMikpOwogCQlFMTAwMF9XUklURV9SRUcoaHcsIEUxMDAwX1JEQkFMKGkpLCAodTMy KWJ1c19hZGRyKTsKIAkJLyogU2V0dXAgdGhlIEhlYWQgYW5kIFRhaWwgRGVzY3JpcHRvciBQb2lu dGVycyAqLwotCQlFMTAwMF9XUklURV9SRUcoaHcsIEUxMDAwX1JESChpKSwgMCk7Ci0JCUUxMDAw X1dSSVRFX1JFRyhodywgRTEwMDBfUkRUKGkpLCBhZGFwdGVyLT5udW1fcnhfZGVzYyAtIDEpOwor CQlFMTAwMF9XUklURV9SRUcoaHcsIEUxMDAwX1JESChpKSwgcnhyLT5uZXh0X3RvX2NoZWNrKTsK KwkJRTEwMDBfV1JJVEVfUkVHKGh3LCBFMTAwMF9SRFQoaSksIHJ4ci0+bmV4dF90b19yZWZyZXNo KTsKIAl9CiAKIAkvKiBTZXR1cCB0aGUgUmVjZWl2ZSBDb250cm9sIFJlZ2lzdGVyICovCkBAIC00 MjA2LDcgKzQyMDQsNyBAQAogCX0KIAogCS8qIENhdGNoIGFueSByZW1haW5pbmcgcmVmcmVzaCB3 b3JrICovCi0JaWYgKHByb2Nlc3NlZCAhPSAwKSB7CisJaWYgKHByb2Nlc3NlZCAhPSAwIHx8IGkg PT0gcnhyLT5uZXh0X3RvX3JlZnJlc2gpIHsKIAkJZW1fcmVmcmVzaF9tYnVmcyhyeHIsIGkpOwog CQlwcm9jZXNzZWQgPSAwOwogCX0K --=====001_Dragon734515843444_=====-- __________________________________________________ ¸Ï¿ì×¢²áÑÅ»¢³¬´óÈÝÁ¿Ãâ·ÑÓÊÏä? http://cn.mail.yahoo.com From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 11:14:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 107A11065672 for ; Fri, 10 Sep 2010 11:14:45 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by mx1.freebsd.org (Postfix) with ESMTP id 475108FC0A for ; Fri, 10 Sep 2010 11:14:42 +0000 (UTC) Received: from endor.tataz.chchile.org (unknown [82.233.239.98]) by smtp5-g21.free.fr (Postfix) with ESMTP id DB59BD4814A; Fri, 10 Sep 2010 13:14:35 +0200 (CEST) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id AE1A733CDC; Fri, 10 Sep 2010 11:14:34 +0000 (UTC) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id 944C8A1153; Fri, 10 Sep 2010 11:14:34 +0000 (UTC) Date: Fri, 10 Sep 2010 13:14:34 +0200 From: Jeremie Le Hen To: pluknet Message-ID: <20100910111434.GU16902@felucia.tataz.chchile.org> References: <20100907145028.GF16902@felucia.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org, Jeremie Le Hen Subject: Re: Cannot install using serial console X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 11:14:45 -0000 Hi, On Thu, Sep 09, 2010 at 06:48:11PM +0400, pluknet wrote: > On 7 September 2010 18:50, Jeremie Le Hen wrote: > > Hi list, > > > > => Please Cc: me when replying, as I am not subscribed. <= > > > > I tried to install FreeBSD (201008 -CURRENT snapshot, but I don't think > > it's important here) in a KVM-backed virtual machine on a headless Linux > > host, following section 2.12.1 of the handbook. > >        http://www.freebsd.org/doc/handbook/install-advanced.html > > > > I've rebuilt the ISO image with the following lines in boot/loader.conf: > >        console="comconsole" > >        beastie_disable="YES" > > > > The kernel boots correctly (see output below) but the output invariably > > stalls after the following lines: > >        Trying to mount root from ufs:/dev/md0 > >        /stand/sysinstal > > > > (Yes, only one `l'.) > > > > Any idea? > > > [strip] > > WARNING: WITNESS option enabled, expect reduced performance. > > Root mount waiting for: usbus0 > > uhub0: 2 ports with 2 removable, self powered > > Trying to mount root from ufs:/dev/md0 > > > > As far as I know you need also to enable a serial terminal in /etc/ttys. Yeah, this came to my mind too but I check on the installation CD, there is no /etc/ttys. -- Jeremie Le Hen Humans are born free and equal. But some are more equal than others. Coluche From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 11:16:47 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D40BA10656CE for ; Fri, 10 Sep 2010 11:16:47 +0000 (UTC) (envelope-from amarat@ksu.ru) Received: from mx7.ksu.ru (honey.ksu.ru [193.232.252.54]) by mx1.freebsd.org (Postfix) with ESMTP id A2E778FC27 for ; Fri, 10 Sep 2010 11:16:46 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.56,345,1280692800"; d="p7s'?scan'208";a="916993" Received: from mail.ksu.ru (HELO ruby.ksu.ru) ([193.232.252.56]) by iport2.ksu.ru with ESMTP; 10 Sep 2010 15:16:43 +0400 X-Pass-Through: Kazan State University Network Received: from zealot.ksu.ru ([194.85.245.161]) by ksu.ru (8.13.4/8.13.4) with ESMTP id o8ABFDAE014280; Fri, 10 Sep 2010 11:15:13 GMT Received: from zealot.ksu.ru (localhost.lnet [127.0.0.1]) by zealot.ksu.ru (8.14.4/8.14.4) with ESMTP id o8ABEmJX015993; Fri, 10 Sep 2010 15:14:48 +0400 (MSD) (envelope-from amarat@ksu.ru) Message-ID: <4C8A1328.6010508@ksu.ru> Date: Fri, 10 Sep 2010 15:14:48 +0400 From: "Marat N.Afanasyev" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.11) Gecko/20100724 SeaMonkey/2.0.6 MIME-Version: 1.0 To: Ian Smith References: <20100909153902.GA28341@lordcow.org> <4C89215E.7010203@ksu.ru> <20100910125714.Y73353@sola.nimnet.asn.au> In-Reply-To: <20100910125714.Y73353@sola.nimnet.asn.au> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040401010206020101000606" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Gareth de Vaux , Vlad Galu , stable@freebsd.org Subject: Re: ipfw: Too many dynamic rules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 11:16:47 -0000 This is a cryptographically signed message in MIME format. --------------ms040401010206020101000606 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: quoted-printable Ian Smith wrote: > On Thu, 9 Sep 2010, Vlad Galu wrote: > > 2010/9/9 Marat N.Afanasyev: > > > I wonder, are these dynamic rules really necessary? let's see, = a client > > > connects to your web-server and you immediately should create a= new dynamic > > > rule, therefore you participate in this DoS attack as well as a= ttacker. ;) > > > > With a stateless firewall, you help the attacker even more. Becaus= e > > he's able to connect to your httpd/whatever daemon is listening > > directly and he can easily fill up the descriptor table of that > > process. Limiting the number of states/connections from the same h= ost > > prevents that. Sure, those states eat up RAM, but so do the > > established connections. Having a slightly more aggressive state > > expiry policy always helps. Sure, there are accf_http(9), accf_dat= a(9) > > and various forking workarounds, but they don't work unless your T= CP > > server is specifically designed to use them. > > Agreed. stateful firewall does not limits numbers of states/connections. it just = add a new layer which can be overfulled easily. if you experience a DDoS = attack it's better to block attackers addresses, e.g, adding them to=20 some ipfw table using external methods. did you try to use lighweight and FAST frontend web-server as proxy?=20 e.g. www/nginx or www/zerowait-httpd? > > PF also allows you to tarpit malicious hosts based on how often th= ey > > try to reconnect - you can dynamically add them to a table which y= ou > > can refer to from ALTQ. > > As mentioned, ipfw 'limit' rules accomplish effectively the same withou= t > needing an extra table; eg only allowing N simultaneous connections fro= m > any one address. If N were say 4, even a distributed attack by 20 host= s > will only allow 80 concurrent connections, no big deal for the firewall= > and no need to bother trying to limit connections later at the server. I can say that 4 connection limit is extremely low limit, because if you = use a somewhat "distributed" web site (css, images, etc. in different=20 files) client software may open DOZENS of connections simultaneously,=20 and you will deny absolutely rightful connections. btw, real DDoS is=20 often uses thousands, tens of thousands and even hundreds of thousands=20 botware hosts. I've rarely seen millions, may be 2 or three times at=20 all, while 50-80 thousands hosts is average. > That said, I've also tables blocking noted pests, including some recent= > distributed bots seeking eg blocklist=3D'scripts/setup.php p=3Dphpinfo(= );' > which irritated me enough to knock up a script to knock them off :) yes, this is one of the best looking solutions. -- SY, Marat --------------ms040401010206020101000606-- From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 11:27:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FA501065675 for ; Fri, 10 Sep 2010 11:27:29 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by mx1.freebsd.org (Postfix) with ESMTP id 1A33B8FC28 for ; Fri, 10 Sep 2010 11:27:28 +0000 (UTC) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta13.westchester.pa.mail.comcast.net with comcast id 4yhh1f0041ap0As5DzTV6Y; Fri, 10 Sep 2010 11:27:29 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta22.westchester.pa.mail.comcast.net with comcast id 4zTU1f0013LrwQ23izTUT2; Fri, 10 Sep 2010 11:27:29 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id B2E249B423; Fri, 10 Sep 2010 04:27:26 -0700 (PDT) Date: Fri, 10 Sep 2010 04:27:26 -0700 From: Jeremy Chadwick To: Jeremie Le Hen Message-ID: <20100910112726.GA9262@icarus.home.lan> References: <20100907145028.GF16902@felucia.tataz.chchile.org> <20100910111434.GU16902@felucia.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100910111434.GU16902@felucia.tataz.chchile.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: pluknet , freebsd-stable@freebsd.org Subject: Re: Cannot install using serial console X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 11:27:29 -0000 On Fri, Sep 10, 2010 at 01:14:34PM +0200, Jeremie Le Hen wrote: > On Thu, Sep 09, 2010 at 06:48:11PM +0400, pluknet wrote: > > On 7 September 2010 18:50, Jeremie Le Hen wrote: > > > Hi list, > > > > > > => Please Cc: me when replying, as I am not subscribed. <= > > > > > > I tried to install FreeBSD (201008 -CURRENT snapshot, but I don't think > > > it's important here) in a KVM-backed virtual machine on a headless Linux > > > host, following section 2.12.1 of the handbook. > > >        http://www.freebsd.org/doc/handbook/install-advanced.html > > > > > > I've rebuilt the ISO image with the following lines in boot/loader.conf: > > >        console="comconsole" > > >        beastie_disable="YES" > > > > > > The kernel boots correctly (see output below) but the output invariably > > > stalls after the following lines: > > >        Trying to mount root from ufs:/dev/md0 > > >        /stand/sysinstal > > > > > > (Yes, only one `l'.) > > > > > > Any idea? > > > > > [strip] > > > WARNING: WITNESS option enabled, expect reduced performance. > > > Root mount waiting for: usbus0 > > > uhub0: 2 ports with 2 removable, self powered > > > Trying to mount root from ufs:/dev/md0 > > > > > > > As far as I know you need also to enable a serial terminal in /etc/ttys. > > Yeah, this came to my mind too but I check on the installation CD, there > is no /etc/ttys. This is normal. Can you try hacking up a solution for yourself based on what I've documented with regards to PXE booting? There will be pieces which obviously don't apply to you because you're booting from physical media, but some of the adjustments (to the bootloader, etc.) you can try. http://jdc.parodius.com/freebsd/pxeboot_serial_install_8.html One thing worth pointing out is that you stated the system that you're trying to use serial console on is actually running under a VM on Linux: > I tried to install FreeBSD (201008 -CURRENT snapshot, but I don't think > it's important here) in a KVM-backed virtual machine on a headless Linux > host, following section 2.12.1 of the handbook. Can you provide a full dmesg prior to the "/stand/sysinstal" output happening? You don't need to boot verbose (yet), but it would help with regards to determining what the kernel is seeing device-wise. Yes it matters. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 11:49:23 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CED5A1065694 for ; Fri, 10 Sep 2010 11:49:23 +0000 (UTC) (envelope-from bsd@lordcow.org) Received: from lordcow.org (lordcow.org [41.203.5.188]) by mx1.freebsd.org (Postfix) with ESMTP id F2F078FC13 for ; Fri, 10 Sep 2010 11:49:22 +0000 (UTC) Received: from lordcow.org (localhost [127.0.0.1]) by lordcow.org (8.14.4/8.14.4) with ESMTP id o8ABnEb6057228 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Fri, 10 Sep 2010 13:49:14 +0200 (SAST) (envelope-from lordcow@lordcow.org) Received: (from lordcow@localhost) by lordcow.org (8.14.4/8.14.4/Submit) id o8ABn9lR057227 for stable@freebsd.org; Fri, 10 Sep 2010 13:49:09 +0200 (SAST) (envelope-from lordcow) Date: Fri, 10 Sep 2010 13:49:08 +0200 From: Gareth de Vaux To: stable@freebsd.org Message-ID: <20100910114908.GA55978@lordcow.org> References: <20100909153902.GA28341@lordcow.org> <20100909162009.GA80375@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100909162009.GA80375@icarus.home.lan> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lordcow.org Cc: Subject: Re: ipfw: Too many dynamic rules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 11:49:23 -0000 On Thu 2010-09-09 (09:20), Jeremy Chadwick wrote: > Secondly, I'm fairly certain HTTP KeepAlive (re: KeepAliveTimeout) are > unrelated to TCP keepalives[1]. I mention this because you're focusing > on netstat, which will give you indication of TCP session state, not > HTTP protocol statefulness. Gotcha > Thirdly, if you feel FIN_WAIT2 is the cause of your problem, then you > should consider adjusting the following sysctl: > > net.inet.tcp.finwait2_timeout > > Try something like 15000 (15 seconds) instead of the default (60000). Ok that seems to be doing something. Will report back later. > Finally, why are you using dynamic firewall rules at all? So that I can identify legitimate(ish) traffic and drop the rest. > For what purpose do you need these that, say, pf and its state > tracking would not suffice? I haven't used pf. I started with ipfw and its done the trick so far. What's the difference between pf and ipfw's state tracking in this respect? From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 12:00:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D76721065794 for ; Fri, 10 Sep 2010 12:00:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A497C8FC33 for ; Fri, 10 Sep 2010 12:00:27 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0F9AC46BA7; Fri, 10 Sep 2010 08:00:27 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 107E98A04F; Fri, 10 Sep 2010 08:00:26 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Fri, 10 Sep 2010 07:57:49 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20100909150012.GA27370@lordcow.org> <4c89d653.UyUz1Sv9zPckJnig%perryh@pluto.rain.com> In-Reply-To: <4c89d653.UyUz1Sv9zPckJnig%perryh@pluto.rain.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009100757.49777.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 10 Sep 2010 08:00:26 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: bsd@lordcow.org, perryh@pluto.rain.com Subject: Re: MSIX failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 12:00:27 -0000 On Friday, September 10, 2010 2:55:15 am perryh@pluto.rain.com wrote: > Gareth de Vaux wrote: > > > On Thu 2010-09-09 (16:54), Kurt Jaeger wrote: > > > -c asks for pci device capabilities, which are read in > > > > > > /usr/src/usr.sbin/pciconf/pciconf.c:177 with O_RDWR > > > > Ah. I'll have to schedule a reboot then .. > > or hack on pciconf.c to not request more permission than it needs. > It is arguably a bug to open O_RDWR when only examining things. You have to have RDWR permission to issue the ioctl to read config registers which pciconf does when examining capabilities. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 12:08:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40BC0106564A for ; Fri, 10 Sep 2010 12:08:20 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id EF41F8FC08 for ; Fri, 10 Sep 2010 12:08:19 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Ou2Ou-0001HB-4Q for freebsd-stable@freebsd.org; Fri, 10 Sep 2010 14:08:16 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 10 Sep 2010 14:08:16 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 10 Sep 2010 14:08:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Fri, 10 Sep 2010 14:08:06 +0200 Lines: 30 Message-ID: References: <20100909153902.GA28341@lordcow.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100518 Thunderbird/3.0.4 In-Reply-To: <20100909153902.GA28341@lordcow.org> X-Enigmail-Version: 1.0.1 Subject: Re: ipfw: Too many dynamic rules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 12:08:20 -0000 On 09/09/10 17:39, Gareth de Vaux wrote: > Hi again, I use some keep-state rules in ipfw, but get the following > kernel message: > > kernel: ipfw: install_state: Too many dynamic rules > > when presumably my state table reaches its limit (and I effectively > get DoS'd). > > netstat shows tons of connections in FIN_WAIT_2 state, mostly to > my webserver. Consequently net.inet.ip.fw.dyn_count is large too. > > I can increase my net.inet.ip.fw.dyn_max but the new limit will > simply be reached later on. For what it's worth, here's what I've been running: net.inet.ip.fw.dyn_buckets=1024 net.inet.ip.fw.dyn_max=8192 net.inet.ip.fw.dyn_ack_lifetime=60 If in a tight spot, I might reduce dyn_ack_lifetime to 10. There is no way this machine would service 8192 legitimate simultaneous connections so this works for me. If you have the memory I think you can increase dyn_max practically arbitrarily. If under a DDoS attack, you might run out of some other resource, like ephemeral TCP ports for the server side of connections, before running out of ipfw entries. From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 12:35:43 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B26F2106564A for ; Fri, 10 Sep 2010 12:35:43 +0000 (UTC) (envelope-from bsd@lordcow.org) Received: from lordcow.org (lordcow.org [41.203.5.188]) by mx1.freebsd.org (Postfix) with ESMTP id D56B48FC08 for ; Fri, 10 Sep 2010 12:35:42 +0000 (UTC) Received: from lordcow.org (localhost [127.0.0.1]) by lordcow.org (8.14.4/8.14.4) with ESMTP id o8ACZXRV059704 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Fri, 10 Sep 2010 14:35:33 +0200 (SAST) (envelope-from lordcow@lordcow.org) Received: (from lordcow@localhost) by lordcow.org (8.14.4/8.14.4/Submit) id o8ACZRTd059702 for stable@freebsd.org; Fri, 10 Sep 2010 14:35:27 +0200 (SAST) (envelope-from lordcow) Date: Fri, 10 Sep 2010 14:35:27 +0200 From: Gareth de Vaux To: stable@freebsd.org Message-ID: <20100910123527.GB55978@lordcow.org> References: <20100909153902.GA28341@lordcow.org> <20100910023132.E73353@sola.nimnet.asn.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100910023132.E73353@sola.nimnet.asn.au> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lordcow.org Cc: Subject: Re: ipfw: Too many dynamic rules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 12:35:43 -0000 On Fri 2010-09-10 (03:18), Ian Smith wrote: > Try using 'limit' rather than the unlimited 'keep-state' for inbound > dynamic connections to your server/s. eg, derived from ipfw(8): These are mostly legitimate connections though, they just aren't being closed properly. So if limit were to have an affect in my scenario, it would just prevent legitimate users from reconnecting. From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 12:57:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C282C1065670 for ; Fri, 10 Sep 2010 12:57:49 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id A4E7D8FC1B for ; Fri, 10 Sep 2010 12:57:49 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1Ou3Aq-0002QG-FT for freebsd-stable@freebsd.org; Fri, 10 Sep 2010 05:57:48 -0700 Message-ID: <29676538.post@talk.nabble.com> Date: Fri, 10 Sep 2010 05:57:48 -0700 (PDT) From: Jakub Lach To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: jakub_lach@mailplus.pl Subject: Intel(R) ICH9 Family SMBus Controller description error (?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 12:57:49 -0000 Hello. System is 8.1-STABLE #0 r212325, I assume there is minor problem with description of SMBus Controller. e.g.: $ pciconf -lv | grep 'Intel(R)' device = 'Intel(R) ICH9 Family SMBus Controller working fine with http://download.cnet.com/Chipset-Driver-Inte (8086)' I doubt such description was intended. Best regards, and many thanks for hard work. -Jakub Lach -- View this message in context: http://old.nabble.com/Intel%28R%29-ICH9-Family-SMBus-Controller-description-error-%28-%29-tp29676538p29676538.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 14:11:54 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDADC106564A for ; Fri, 10 Sep 2010 14:11:54 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from vergina.eng.auth.gr (vergina.eng.auth.gr [155.207.18.1]) by mx1.freebsd.org (Postfix) with ESMTP id 4D7768FC1C for ; Fri, 10 Sep 2010 14:11:53 +0000 (UTC) Received: from mamalacation.ee.auth.gr (mamalacation.ee.auth.gr [155.207.33.29]) by vergina.eng.auth.gr (8.14.3/8.14.1) with ESMTP id o8ADWYtF064738 for ; Fri, 10 Sep 2010 16:32:34 +0300 (EEST) (envelope-from mamalos@eng.auth.gr) Message-ID: <4C8A336D.9080302@eng.auth.gr> Date: Fri, 10 Sep 2010 16:32:29 +0300 From: George Mamalakis User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100821 Thunderbird/3.1.2 MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: AoE driver for FBSD8 or later? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 14:11:55 -0000 Hi everybody, we have a coraid device with 15x1GB disks on it, and would like to use it with fbsd8 (zfs, etc). The http://support.coraid.com/support/freebsd/ is really outdated, and the port that creates the kernel module does not compile on FBSD8 (obviously!). Is there any effort on migrating the driver onto fbsd8 or should I plug the coraid on a linux system and use it from there? Thank you all in advance. -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 14:32:09 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4496D106564A; Fri, 10 Sep 2010 14:32:09 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 597B68FC19; Fri, 10 Sep 2010 14:32:08 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA21514; Fri, 10 Sep 2010 17:31:54 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Ou2kg-0008Z3-8B; Fri, 10 Sep 2010 15:30:46 +0300 Message-ID: <4C8A24F5.7040100@freebsd.org> Date: Fri, 10 Sep 2010 15:30:45 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Daniel O'Connor" References: <4C89DE32.9050402@icyb.net.ua> In-Reply-To: <4C89DE32.9050402@icyb.net.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable Stable , "John H. Baldwin" Subject: Re: Enabling MCA causes system hangs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 14:32:09 -0000 on 10/09/2010 10:28 Andriy Gapon said the following: > on 10/09/2010 05:36 Daniel O'Connor said the following: >> Hi, I recently tried enabling MCA (ie w.mca.enabled=1 in loader.conf) on an >> 8.0-STABLE system and found that it would cause the system to hang after a >> few minutes of uptime. >> >> The screen would go black and the monitor would turn off (regardless of >> wether it was in X or not) and only a hard reset would bring it back. >> >> Also I found that quite often I had to power cycle the whole PC or the BIOS >> wouldn't detect the hard disks on boot(!) after a hang. >> >> uname is.. FreeBSD midget.dons.net.au 8.0-STABLE FreeBSD 8.0-STABLE #6 >> r202903M: Sun Jan 24 13:45:11 CST 2010 >> darius@midget.dons.net.au:/usr/obj/usr/src/sys/MIDGET amd64 Oh, I should have payed attention to the version. I think that this is a known and resolved problem. There is a hardware bug in AMD 10h processors that is triggered by combination of enabled MCA and FreeBSD superpages. So, you either have to disable one of them or upgrade to a more recent version. The version you need is r206183. The latest stable/8 would do, obviously. >> The motherboard is a Gigabyte GA-MA785GM-US2H with an Athlon II X2 240 CPU & >> 4Gb of RAM. > > Do you also have superpages enabled (vm.pmap.pg_ps_enabled)? > If so, please try to turn them off and report back if that helps. > -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 15:18:10 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23C15106567A for ; Fri, 10 Sep 2010 15:18:10 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by mx1.freebsd.org (Postfix) with ESMTP id 9CEC08FC08 for ; Fri, 10 Sep 2010 15:18:07 +0000 (UTC) Received: from endor.tataz.chchile.org (unknown [82.233.239.98]) by smtp5-g21.free.fr (Postfix) with ESMTP id 920F4D481A0; Fri, 10 Sep 2010 17:18:01 +0200 (CEST) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id 742F433CDC; Fri, 10 Sep 2010 15:18:00 +0000 (UTC) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id 5390DA1153; Fri, 10 Sep 2010 15:18:00 +0000 (UTC) Date: Fri, 10 Sep 2010 17:18:00 +0200 From: Jeremie Le Hen To: Jeremy Chadwick Message-ID: <20100910151800.GX16902@felucia.tataz.chchile.org> References: <20100907145028.GF16902@felucia.tataz.chchile.org> <20100910111434.GU16902@felucia.tataz.chchile.org> <20100910112726.GA9262@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100910112726.GA9262@icarus.home.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org, pluknet , Jeremie Le Hen Subject: Re: Cannot install using serial console X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 15:18:10 -0000 Hi Jeremy, On Fri, Sep 10, 2010 at 04:27:26AM -0700, Jeremy Chadwick wrote: > > > As far as I know you need also to enable a serial terminal in /etc/ttys. > > > > Yeah, this came to my mind too but I check on the installation CD, there > > is no /etc/ttys. > > This is normal. > > Can you try hacking up a solution for yourself based on what I've > documented with regards to PXE booting? There will be pieces which > obviously don't apply to you because you're booting from physical media, > but some of the adjustments (to the bootloader, etc.) you can try. > > http://jdc.parodius.com/freebsd/pxeboot_serial_install_8.html But as far as I understand the handbook, this is not required to perform the installation through sysinstall(8) on a serial console. Modifying /boot/loader.conf on the installation media is enough according to chapter 2.12.1. Am I wrong? > One thing worth pointing out is that you stated the system that you're > trying to use serial console on is actually running under a VM on Linux: > > > I tried to install FreeBSD (201008 -CURRENT snapshot, but I don't think > > it's important here) in a KVM-backed virtual machine on a headless Linux > > host, following section 2.12.1 of the handbook. > > Can you provide a full dmesg prior to the "/stand/sysinstal" output > happening? You don't need to boot verbose (yet), but it would help with > regards to determining what the kernel is seeing device-wise. Yes it > matters. Yes, I've actually already posted it in my original message: http://lists.freebsd.org/pipermail/freebsd-stable/2010-September/058703.html Thanks for you attention. Regards, -- Jeremie Le Hen Humans are born free and equal. But some are more equal than others. Coluche From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 15:38:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2C69106567A for ; Fri, 10 Sep 2010 15:38:32 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id B6DCB8FC16 for ; Fri, 10 Sep 2010 15:38:32 +0000 (UTC) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta04.emeryville.ca.mail.comcast.net with comcast id 51r71f0021afHeLA43eXoD; Fri, 10 Sep 2010 15:38:31 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta17.emeryville.ca.mail.comcast.net with comcast id 53eW1f0073LrwQ28d3eWNo; Fri, 10 Sep 2010 15:38:31 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 4A54F9B423; Fri, 10 Sep 2010 08:38:30 -0700 (PDT) Date: Fri, 10 Sep 2010 08:38:30 -0700 From: Jeremy Chadwick To: Jeremie Le Hen Message-ID: <20100910153830.GA15012@icarus.home.lan> References: <20100907145028.GF16902@felucia.tataz.chchile.org> <20100910111434.GU16902@felucia.tataz.chchile.org> <20100910112726.GA9262@icarus.home.lan> <20100910151800.GX16902@felucia.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100910151800.GX16902@felucia.tataz.chchile.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: pluknet , freebsd-stable@freebsd.org Subject: Re: Cannot install using serial console X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 15:38:33 -0000 On Fri, Sep 10, 2010 at 05:18:00PM +0200, Jeremie Le Hen wrote: > On Fri, Sep 10, 2010 at 04:27:26AM -0700, Jeremy Chadwick wrote: > > > > As far as I know you need also to enable a serial terminal in /etc/ttys. > > > > > > Yeah, this came to my mind too but I check on the installation CD, there > > > is no /etc/ttys. > > > > This is normal. > > > > Can you try hacking up a solution for yourself based on what I've > > documented with regards to PXE booting? There will be pieces which > > obviously don't apply to you because you're booting from physical media, > > but some of the adjustments (to the bootloader, etc.) you can try. > > > > http://jdc.parodius.com/freebsd/pxeboot_serial_install_8.html > > But as far as I understand the handbook, this is not required to perform > the installation through sysinstall(8) on a serial console. Modifying > /boot/loader.conf on the installation media is enough according to > chapter 2.12.1. Am I wrong? Nah you're not wrong -- I'm just not sure what the VM might be doing with/to the serial port. I don't know what KVM you're using on Linux, but does the VM machine have a BIOS? If so, does it offer something like serial console redirect capability? If so, and it's enabled, it could/might be conflicting with the OS. The reason I mention this: on some x86 systems that offer BIOS-level console redirection capability, the kernel (confirmed on both FreeBSD and Linux) can, depending on circumstances I'm not sure of, lock up the OS hard. If the VM offers such a feature and you're not using it, try it (and remove the comconsole stuff from your loader.conf). You might end up with VGA-over-serial that way, and it might suffice. I imagine some form of getty(8) must be in use under the FreeBSD installation environment, because you can switch virtual consoles via Alt- as I'm sure you know. > > One thing worth pointing out is that you stated the system that you're > > trying to use serial console on is actually running under a VM on Linux: > > > > > I tried to install FreeBSD (201008 -CURRENT snapshot, but I don't think > > > it's important here) in a KVM-backed virtual machine on a headless Linux > > > host, following section 2.12.1 of the handbook. > > > > Can you provide a full dmesg prior to the "/stand/sysinstal" output > > happening? You don't need to boot verbose (yet), but it would help with > > regards to determining what the kernel is seeing device-wise. Yes it > > matters. > > Yes, I've actually already posted it in my original message: > http://lists.freebsd.org/pipermail/freebsd-stable/2010-September/058703.html Thanks much -- for some reason that part of the Email is missing for me. uart0: port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart0: console (9600,n,8,1) It sure looks like it's console, but I'm not sure if there are implications/bugs that might stop serial I/O from working past a certain point for this type of chip, especially when under a VM. Only other things I can think of trying, one at a time: - Explicitly set a serial port speed using comconsole_speed in loader.conf - Adding boot_serial="yes" to loader.conf - Try booting with ACPI disabled. I'm not sure this will work under a VM, but worth a shot I guess -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 15:58:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7389B1065672 for ; Fri, 10 Sep 2010 15:58:32 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id 1D69B8FC16 for ; Fri, 10 Sep 2010 15:58:31 +0000 (UTC) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta01.westchester.pa.mail.comcast.net with comcast id 4z1y1f0051YDfWL513yYty; Fri, 10 Sep 2010 15:58:32 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta20.westchester.pa.mail.comcast.net with comcast id 53yW1f00a3LrwQ23g3yXoi; Fri, 10 Sep 2010 15:58:32 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 9ED469B423; Fri, 10 Sep 2010 08:58:29 -0700 (PDT) Date: Fri, 10 Sep 2010 08:58:29 -0700 From: Jeremy Chadwick To: Jeremie Le Hen Message-ID: <20100910155829.GA15704@icarus.home.lan> References: <20100907145028.GF16902@felucia.tataz.chchile.org> <20100910111434.GU16902@felucia.tataz.chchile.org> <20100910112726.GA9262@icarus.home.lan> <20100910151800.GX16902@felucia.tataz.chchile.org> <20100910153830.GA15012@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100910153830.GA15012@icarus.home.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: pluknet , freebsd-stable@freebsd.org Subject: Re: Cannot install using serial console X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 15:58:32 -0000 On Fri, Sep 10, 2010 at 08:38:30AM -0700, Jeremy Chadwick wrote: > On Fri, Sep 10, 2010 at 05:18:00PM +0200, Jeremie Le Hen wrote: > > On Fri, Sep 10, 2010 at 04:27:26AM -0700, Jeremy Chadwick wrote: > > > > > As far as I know you need also to enable a serial terminal in /etc/ttys. > > > > > > > > Yeah, this came to my mind too but I check on the installation CD, there > > > > is no /etc/ttys. > > > > > > This is normal. > > > > > > Can you try hacking up a solution for yourself based on what I've > > > documented with regards to PXE booting? There will be pieces which > > > obviously don't apply to you because you're booting from physical media, > > > but some of the adjustments (to the bootloader, etc.) you can try. > > > > > > http://jdc.parodius.com/freebsd/pxeboot_serial_install_8.html > > > > But as far as I understand the handbook, this is not required to perform > > the installation through sysinstall(8) on a serial console. Modifying > > /boot/loader.conf on the installation media is enough according to > > chapter 2.12.1. Am I wrong? > > Nah you're not wrong -- I'm just not sure what the VM might be doing > with/to the serial port. I don't know what KVM you're using on Linux, > but does the VM machine have a BIOS? If so, does it offer something > like serial console redirect capability? If so, and it's enabled, it > could/might be conflicting with the OS. > > The reason I mention this: on some x86 systems that offer BIOS-level > console redirection capability, the kernel (confirmed on both FreeBSD > and Linux) can, depending on circumstances I'm not sure of, lock up the > OS hard. > > If the VM offers such a feature and you're not using it, try it (and > remove the comconsole stuff from your loader.conf). You might end up > with VGA-over-serial that way, and it might suffice. > > I imagine some form of getty(8) must be in use under the FreeBSD > installation environment, because you can switch virtual consoles via > Alt- as I'm sure you know. > > > > One thing worth pointing out is that you stated the system that you're > > > trying to use serial console on is actually running under a VM on Linux: > > > > > > > I tried to install FreeBSD (201008 -CURRENT snapshot, but I don't think > > > > it's important here) in a KVM-backed virtual machine on a headless Linux > > > > host, following section 2.12.1 of the handbook. > > > > > > Can you provide a full dmesg prior to the "/stand/sysinstal" output > > > happening? You don't need to boot verbose (yet), but it would help with > > > regards to determining what the kernel is seeing device-wise. Yes it > > > matters. > > > > Yes, I've actually already posted it in my original message: > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-September/058703.html > > Thanks much -- for some reason that part of the Email is missing for me. > > uart0: port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > uart0: [FILTER] > uart0: console (9600,n,8,1) > > It sure looks like it's console, but I'm not sure if there are > implications/bugs that might stop serial I/O from working past a certain > point for this type of chip, especially when under a VM. > > Only other things I can think of trying, one at a time: > > - Explicitly set a serial port speed using comconsole_speed in > loader.conf > - Adding boot_serial="yes" to loader.conf > - Try booting with ACPI disabled. I'm not sure this will work under a > VM, but worth a shot I guess Some other things that occurred to me: 1) Is the kernel built with SMP support? I imagine that the stock "out-of-the-box" images have SMP in use. I don't know what happens on FreeBSD if "options SMP" is present on a system which appears to lack SMP (your dmesg output indicates only one CPU). 2) Does this problem happen with RELENG_8 (e.g. 8.1-RELEASE or an 8.1-STABLE snapshot)? 3) Can you try booting a livefs CD image (with loader.conf adjusted to contain console="comconsole") and see if the behaviour is the same? I'm trying to figure out if it's something sysinstall somehow induces (I imagine there's a little delay between the console output and when the sysinstall binary has actually started), or if the kernel is doing something. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 16:28:25 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0972106566B for ; Fri, 10 Sep 2010 16:28:25 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 617328FC1A for ; Fri, 10 Sep 2010 16:28:25 +0000 (UTC) Received: by qyk31 with SMTP id 31so7953818qyk.13 for ; Fri, 10 Sep 2010 09:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=+8VO+RMVRdujJMsQZl03b0XIcsqhPowIfaWKDztaXPo=; b=DVHEcf6+kw1a+6C4/jrWzOtB2P6LZjbRB0H8DNdnpWvm0ZeSfHre8zKbKIFkcRbfCt FQiBaXRRrz8+RoMhUCBBAlK9iuhrbig+NIY9ZrIkM+lUnwzFibl5zBOQnn8YYbFHZG2L 3tDq9L0PvrbtLps4x+AHy3HEDzYdOT6468LS0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=iSSZN9AB8hM0t2GoJTRpG6eTE2nFPZpukkfPZ/XSzclu+mTSiAQ0hCyQOl35CPA5rD xE28rRTts5qKyOuKE/Qm3YSJ5gpgdF+LDaZt5RhArH/6BnfajkAEvugi586Ilf7g47sn EimYHq39iQL6UJdzp3UGrKxIzNgoF0+EnAtH4= MIME-Version: 1.0 Received: by 10.229.185.7 with SMTP id cm7mr695484qcb.7.1284134757704; Fri, 10 Sep 2010 09:05:57 -0700 (PDT) Received: by 10.229.19.206 with HTTP; Fri, 10 Sep 2010 09:05:57 -0700 (PDT) In-Reply-To: <4C8A336D.9080302@eng.auth.gr> References: <4C8A336D.9080302@eng.auth.gr> Date: Fri, 10 Sep 2010 20:05:57 +0400 Message-ID: From: pluknet To: George Mamalakis Content-Type: multipart/mixed; boundary=0016e6509e4213a492048fe9eca1 Cc: stable@freebsd.org Subject: Re: AoE driver for FBSD8 or later? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 16:28:25 -0000 --0016e6509e4213a492048fe9eca1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 10 September 2010 17:32, George Mamalakis wrote: > =A0Hi everybody, > > we have a coraid device with 15x1GB disks on it, and would like to use it > with fbsd8 (zfs, etc). The http://support.coraid.com/support/freebsd/ is > really outdated, and the port that creates the kernel module does not > compile on FBSD8 (obviously!). Is there any effort on migrating the drive= r > onto fbsd8 or should I plug the coraid on a linux system and use it from > there? > This change below looks obvious to me. Not sure if this is enough to make it work though. There are also might be issues with those interfaces which announce itself as IFT_ETHER, but have NULL if_input. # cat files/patch-dev-aoe-aoenet.c --- aoenet.c.orig 2006-05-25 16:10:11.000000000 +0000 +++ aoenet.c 2010-09-10 15:03:01.000000000 +0000 @@ -77,8 +77,11 @@ #define NECODES (sizeof(aoe_errlist) / sizeof(char *) - 1) #if (__FreeBSD_version < 600000) #define IFPADDR(ifp) (((struct arpcom *) (ifp))->ac_enaddr) +#elif (__FreeBSD_version < 700000) +#define IFPADDR(ifp) IFP2ENADDR(ifp) #else -#define IFPADDR(ifp) IFP2ENADDR(ifp) +#include +#define IFPADDR(ifp) IF_LLADDR(ifp) #endif #define IFLISTSZ 1024 @@ -223,7 +226,11 @@ m1->m_ext.ref_cnt =3D NULL; MEXTADD(m1, f->f_data, len, nilfn, +#if (__FreeBSD_version < 800000) NULL, 0, EXT_NET_DRV); +#else + f->f_data, NULL, 0, EXT_NET_DRV); +#endif m1->m_len =3D len; m1->m_next =3D NULL; } --=20 wbr, pluknet --0016e6509e4213a492048fe9eca1 Content-Type: application/octet-stream; name="patch-dev-aoe-aoenet.c" Content-Disposition: attachment; filename="patch-dev-aoe-aoenet.c" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gdx8kek00 LS0tIGFvZW5ldC5jLm9yaWcJMjAwNi0wNS0yNSAxNjoxMDoxMS4wMDAwMDAwMDAgKzAwMDAKKysr IGFvZW5ldC5jCTIwMTAtMDktMTAgMTU6MDM6MDEuMDAwMDAwMDAwICswMDAwCkBAIC03Nyw4ICs3 NywxMSBAQAogI2RlZmluZSBORUNPREVTIChzaXplb2YoYW9lX2Vycmxpc3QpIC8gIHNpemVvZihj aGFyICopIC0gMSkKICNpZiAoX19GcmVlQlNEX3ZlcnNpb24gPCA2MDAwMDApCiAjZGVmaW5lIElG UEFERFIoaWZwKSAoKChzdHJ1Y3QgYXJwY29tICopIChpZnApKS0+YWNfZW5hZGRyKQorI2VsaWYg KF9fRnJlZUJTRF92ZXJzaW9uIDwgNzAwMDAwKQorI2RlZmluZSBJRlBBRERSKGlmcCkgSUZQMkVO QUREUihpZnApCiAjZWxzZQotI2RlZmluZSBJRlBBRERSKGlmcCkgSUZQMkVOQUREUihpZnApIAor I2luY2x1ZGUgPG5ldC9pZl9kbC5oPgorI2RlZmluZSBJRlBBRERSKGlmcCkgSUZfTExBRERSKGlm cCkKICNlbmRpZgogI2RlZmluZSBJRkxJU1RTWiAxMDI0CiAKQEAgLTIyMyw3ICsyMjYsMTEgQEAK IAogCQltMS0+bV9leHQucmVmX2NudCA9IE5VTEw7CiAJCU1FWFRBREQobTEsIGYtPmZfZGF0YSwg bGVuLCBuaWxmbiwgCisjaWYgKF9fRnJlZUJTRF92ZXJzaW9uIDwgODAwMDAwKQogCQkJTlVMTCwg MCwgRVhUX05FVF9EUlYpOworI2Vsc2UKKwkJCWYtPmZfZGF0YSwgTlVMTCwgMCwgRVhUX05FVF9E UlYpOworI2VuZGlmCiAJCW0xLT5tX2xlbiA9IGxlbjsKIAkJbTEtPm1fbmV4dCA9IE5VTEw7CiAg ICAgICAgIH0K --0016e6509e4213a492048fe9eca1-- From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 16:51:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 641E1106564A; Fri, 10 Sep 2010 16:51:17 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2-6.sentex.ca [IPv6:2607:f3e0:80:80::2]) by mx1.freebsd.org (Postfix) with ESMTP id DEA058FC08; Fri, 10 Sep 2010 16:51:16 +0000 (UTC) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.4/8.14.4) with ESMTP id o8AGp9Ih054812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Sep 2010 12:51:09 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o8AGp8uU080952; Fri, 10 Sep 2010 12:51:08 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201009101651.o8AGp8uU080952@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 10 Sep 2010 12:51:01 -0400 To: "Li, Qing" From: Mike Tancsa In-Reply-To: References: <201008312102.o7VL2MJr000894@lava.sentex.ca> <201009012255.o81MtMXn009701@lava.sentex.ca> <201009081512.o88FCIq8064280@lava.sentex.ca> <201009081535.o88FZKQS064396@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.67 on 205.211.164.50 Cc: freebsd-stable@freebsd.org Subject: RE: if_rtdel: error 47 (netgraph or mpd issue?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 16:51:17 -0000 FYI, I enabled witness in the kernel and am seeing the following uma_zalloc_arg: zone "128" with the following non-sleepable locks held: exclusive rw ifnet_rw (ifnet_rw) r = 0 (0xc0b56ec4) locked @ /usr/src/sys/net/if.c:419 KDB: stack backtrace: db_trace_self_wrapper(c09195da,e7cb18f0,c06ac725,1a3,2,...) at db_trace_self_wrapper+0x26 kdb_backtrace(1a3,2,ffffffff,c0b29b74,e7cb1928,...) at kdb_backtrace+0x29 _witness_debugger(c091ad10,e7cb193c,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0930a90,c091543a,c06ad2f6,...) at witness_warn+0x1fe uma_zalloc_arg(c158b380,0,102,80,c56bfc00,...) at uma_zalloc_arg+0x34 malloc(80,c09a9a14,102,10,c56bfc00,...) at malloc+0x4e if_grow(c0b56ec4,c0921741,1a3,1a3,35000101,...) at if_grow+0x35 if_alloc(35,c65900e0,101,c65901a0,0,...) at if_alloc+0xd3 ng_iface_constructor(c65b7a80,e7cb1a88,c60b9080,c65cc700,e7cb1a98,...) at ng_iface_constructor+0x3b ng_make_node(c65cc738,e7cb1a88,0,0,0,...) at ng_make_node+0x5b ng_apply_item(c60b90c8,0,1,e7cb1ab8,c60b9080,...) at ng_apply_item+0x3ea ng_snd_item(c64d3340,0,c564d490,0,28a4ff40,...) at ng_snd_item+0x28f ngc_send(c63289a8,0,c5e27000,c56fb820,0,...) at ngc_send+0x1c2 sosend_generic(c63289a8,c56fb820,e7cb1bec,0,0,...) at sosend_generic+0x50d sosend(c63289a8,c56fb820,e7cb1bec,0,0,...) at sosend+0x3f kern_sendit(c6569a00,5,e7cb1c60,0,0,...) at kern_sendit+0x107 sendit(0,c56fb820,5,e7cb1c7c,1,...) at sendit+0xb1 sendto(c6569a00,e7cb1cf8,c093d225,c091bd41,282,...) at sendto+0x48 syscall(e7cb1d38) at syscall+0x1da Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (133, FreeBSD ELF32, sendto), eip = 0x284b13c7, esp = 0xbf3f88cc, ebp = 0xbf3f88f8 --- uma_zalloc_arg: zone "256" with the following non-sleepable locks held: exclusive rw ifnet_rw (ifnet_rw) r = 0 (0xc0b56ec4) locked @ /usr/src/sys/net/if.c:419 KDB: stack backtrace: db_trace_self_wrapper(c09195da,e7cb18f0,c06ac725,1a3,2,...) at db_trace_self_wrapper+0x26 kdb_backtrace(1a3,2,ffffffff,c0b29c24,e7cb1928,...) at kdb_backtrace+0x29 _witness_debugger(c091ad10,e7cb193c,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0930a90,c091543e,c06ad2f6,...) at witness_warn+0x1fe uma_zalloc_arg(c158b700,0,102,100,c56a7400,...) at uma_zalloc_arg+0x34 malloc(100,c09a9a14,102,20,c56a7400,...) at malloc+0x4e if_grow(c0b56ec4,c0921741,1a3,1a3,35000101,...) at if_grow+0x35 if_alloc(35,c65900e0,101,c65901a0,0,...) at if_alloc+0xd3 ng_iface_constructor(c660e680,e7cb1a88,c60b9080,c65aba00,e7cb1a98,...) at ng_iface_constructor+0x3b ng_make_node(c65aba38,e7cb1a88,0,0,0,...) at ng_make_node+0x5b ng_apply_item(c60b90c8,0,1,e7cb1ab8,c60b9080,...) at ng_apply_item+0x3ea ng_snd_item(c64d4d40,0,c56fb630,0,2882ff40,...) at ng_snd_item+0x28f ngc_send(c63289a8,0,c61eeb00,c589f9d0,0,...) at ngc_send+0x1c2 sosend_generic(c63289a8,c589f9d0,e7cb1bec,0,0,...) at sosend_generic+0x50d sosend(c63289a8,c589f9d0,e7cb1bec,0,0,...) at sosend+0x3f kern_sendit(c6404a00,5,e7cb1c60,0,0,...) at kern_sendit+0x107 sendit(0,c589f9d0,5,e7cb1c7c,1,...) at sendit+0xb1 sendto(c6404a00,e7cb1cf8,c,c,282,...) at sendto+0x48 syscall(e7cb1d38) at syscall+0x1da Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (133, FreeBSD ELF32, sendto), eip = 0x284b13c7, esp = 0xbf7fc8cc, ebp = 0xbf7fc8f8 --- >-- Qing > > > > -----Original Message----- > > From: Mike Tancsa [mailto:mike@sentex.net] > > Sent: Wednesday, September 08, 2010 8:35 AM > > To: Vlad Galu > > Cc: Li, Qing; freebsd-stable@freebsd.org > > Subject: Re: if_rtdel: error 47 (netgraph or mpd issue?) > > > > At 11:30 AM 9/8/2010, Vlad Galu wrote: > > >On Wed, Sep 8, 2010 at 6:12 PM, Mike Tancsa wrote: > > >[...] > > > > > >FWIW, I've had a few crashes in if_rtdel() while playing with ECMP. >No > > >Netgraph on that box. Unfortunately, the stack was too corrupted to >be > > >able to see the outer frames. > > > > Hi, > > Actually, I dont have ECMP enabled on this box. Its > > basically GENERIC, minus > > > > < ident router > > --- > > > ident GENERIC > > 72,75c73,76 > > < #options HWPMC_HOOKS # Necessary kernel hooks for > > hwpmc(4) > > < #options AUDIT # Security event auditing > > < #options MAC # TrustedBSD MAC Framework > > < #options FLOWTABLE # per-cpu routing >cache > > --- > > > options HWPMC_HOOKS # Necessary kernel hooks for > > hwpmc(4) > > > options AUDIT # Security event auditing > > > options MAC # TrustedBSD MAC Framework > > > options FLOWTABLE # per-cpu routing cache > > > > and device drivers that are unused > > > > ---Mike > > > > > > -------------------------------------------------------------------- > > Mike Tancsa, tel +1 519 651 3400 > > Sentex Communications, mike@sentex.net > > Providing Internet since 1994 www.sentex.net > > Cambridge, Ontario Canada www.sentex.net/mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 17:12:23 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FA4C106566C for ; Fri, 10 Sep 2010 17:12:23 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from vergina.eng.auth.gr (vergina.eng.auth.gr [155.207.18.1]) by mx1.freebsd.org (Postfix) with ESMTP id 174158FC18 for ; Fri, 10 Sep 2010 17:12:22 +0000 (UTC) Received: from mamalacation.ee.auth.gr (mamalacation.ee.auth.gr [155.207.33.29]) by vergina.eng.auth.gr (8.14.3/8.14.1) with ESMTP id o8AHCLxH027393; Fri, 10 Sep 2010 20:12:21 +0300 (EEST) (envelope-from mamalos@eng.auth.gr) Message-ID: <4C8A66EE.4090705@eng.auth.gr> Date: Fri, 10 Sep 2010 20:12:14 +0300 From: George Mamalakis User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100821 Thunderbird/3.1.2 MIME-Version: 1.0 To: pluknet References: <4C8A336D.9080302@eng.auth.gr> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: AoE driver for FBSD8 or later? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 17:12:23 -0000 On 10/09/2010 19:05, pluknet wrote: > On 10 September 2010 17:32, George Mamalakis wrote: >> Hi everybody, >> >> we have a coraid device with 15x1GB disks on it, and would like to use it >> with fbsd8 (zfs, etc). The http://support.coraid.com/support/freebsd/ is >> really outdated, and the port that creates the kernel module does not >> compile on FBSD8 (obviously!). Is there any effort on migrating the driver >> onto fbsd8 or should I plug the coraid on a linux system and use it from >> there? >> > This change below looks obvious to me. > Not sure if this is enough to make it work though. > There are also might be issues with those interfaces which announce > itself as IFT_ETHER, but have NULL if_input. > > # cat files/patch-dev-aoe-aoenet.c > --- aoenet.c.orig 2006-05-25 16:10:11.000000000 +0000 > +++ aoenet.c 2010-09-10 15:03:01.000000000 +0000 > @@ -77,8 +77,11 @@ > #define NECODES (sizeof(aoe_errlist) / sizeof(char *) - 1) > #if (__FreeBSD_version< 600000) > #define IFPADDR(ifp) (((struct arpcom *) (ifp))->ac_enaddr) > +#elif (__FreeBSD_version< 700000) > +#define IFPADDR(ifp) IFP2ENADDR(ifp) > #else > -#define IFPADDR(ifp) IFP2ENADDR(ifp) > +#include > +#define IFPADDR(ifp) IF_LLADDR(ifp) > #endif > #define IFLISTSZ 1024 > > @@ -223,7 +226,11 @@ > > m1->m_ext.ref_cnt = NULL; > MEXTADD(m1, f->f_data, len, nilfn, > +#if (__FreeBSD_version< 800000) > NULL, 0, EXT_NET_DRV); > +#else > + f->f_data, NULL, 0, EXT_NET_DRV); > +#endif > m1->m_len = len; > m1->m_next = NULL; > } > > Hi, and thanx for your quick reply. I patched my workdir on /usr/ports/net/aoe/work/dev/aoe but got the following output, which probably suggests that we may be talking about a different version you and me: [root]# patch -p0 < patch-dev-aoe-aoenet.c Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- aoenet.c.orig 2006-05-25 16:10:11.000000000 +0000 |+++ aoenet.c 2010-09-10 15:03:01.000000000 +0000 -------------------------- Patching file aoenet.c using Plan A... Hunk #1 failed at 77. Hunk #2 failed at 226. 2 out of 2 hunks failed--saving rejects to aoenet.c.rej Hmm... Ignoring the trailing garbage. done After cd'ing into /usr/ports/net/aoe and giving make I got: [root]# make ===> Configuring for aoe-1.2.0_1 ===> Building for aoe-1.2.0_1 ..... ..... aoenet.c:226:24: error: macro "MEXTADD" requires 8 arguments, but only 7 given aoenet.c: In function 'frame_mbufinit': aoenet.c:225: error: 'MEXTADD' undeclared (first use in this function) aoenet.c:225: error: (Each undeclared identifier is reported only once aoenet.c:225: error: for each function it appears in.) cc1: warnings being treated as errors aoenet.c: In function 'aoenet_xmitbcast': aoenet.c:278: warning: implicit declaration of function 'IFP2ENADDR' aoenet.c:278: warning: nested extern declaration of 'IFP2ENADDR' aoenet.c:278: warning: passing argument 2 of 'memcpy' makes pointer from integer without a cast aoenet.c: In function 'aoenet_enaddr': aoenet.c:294: warning: return makes pointer from integer without a cast *** Error code 1 Stop in /usr/ports/net/aoe/work/dev/aoe. *** Error code 1 Stop in /usr/ports/net/aoe. Which was pretty obvious, since not much had been patched... I didn't include the whole output; the missing part is correct compilation parts. Thanx again for your help, and if you could point me into the right source code (or port, whatsoever), I could try your patch and see whether the driver would be built. cheers, mamalos -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 17:43:04 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 028D71065696 for ; Fri, 10 Sep 2010 17:43:04 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 85A968FC16 for ; Fri, 10 Sep 2010 17:43:03 +0000 (UTC) Received: by eyx24 with SMTP id 24so2206619eyx.13 for ; Fri, 10 Sep 2010 10:43:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=AqwtKcq1bDIMjjKPquTi4dOXCqMxkwPZpCMaiIJdYzs=; b=sBo4LqpYh8HTDhlaQGjJHqfhWHuSJ4FdzGsDiKQ1KY9qFxbXG8edOAWcfBqJbZryIK D0g1A32XxMbd7MXdheDPgRhcBeOJRYAJkyRueMB0RHGto5I7rfS1IySmF4b/GgIDcA90 fSXvlXM9Zetv4suC6NQSK6dTu7LhFG3vid9ds= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BqCeyMmdbQyXQGkPQOQAe97zOAcu1V58gNx/EC+cN5I7Dt8fK3Z3mcb+w4JSYCmuHl EN3jh0uJBR3azn87+rs5iwmQoEU+MEd6no0BMtx764867BDfDxUyOv4rIABIr0qozJk3 Ocs7ZZQYfGA6ZqVqKYifrD8zMTU+0+XD4lkZ0= MIME-Version: 1.0 Received: by 10.216.188.1 with SMTP id z1mr1204068wem.57.1284140582151; Fri, 10 Sep 2010 10:43:02 -0700 (PDT) Received: by 10.216.49.78 with HTTP; Fri, 10 Sep 2010 10:43:01 -0700 (PDT) In-Reply-To: <20100910084120.GA46966@lordcow.org> References: <201009091437.21563.jhb@freebsd.org> <201009091620.25299.jhb@freebsd.org> <20100910084120.GA46966@lordcow.org> Date: Fri, 10 Sep 2010 10:43:01 -0700 Message-ID: From: Jack Vogel To: Gareth de Vaux Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: stable@freebsd.org Subject: Re: MSIX failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 17:43:04 -0000 On Fri, Sep 10, 2010 at 1:41 AM, Gareth de Vaux wrote: > On Thu 2010-09-09 (13:48), Jack Vogel wrote: > > Gareth's email bouncing for anybody else or is it just me? > > Yes sorry I disabled this alias after picking up years of spam on the > mailman archives. I assumed people would primarily reply to the list. > I've re-enabled it for now. > > > Gareth, set hw.pci.honor_msi_blacklist=0, you'll have to do that at boot > > btw. > > Ok, I'll have to get back to you in a day or 2 when I reboot. > > > Tell me more exactly the make/model of the hardware so I might try to get > > my hands on one? > > I can't tell much more from here, the card came from the datacentre's > reserve when I was fighting with the onboard. The larger lettering on > the card itself was just 'Intel(R) PRO/1000 GT Desktop Adapter'. I didn't > note down the smaller model-type numbers. Is this > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-September/058748.html > not enough? > > No, not the add-on adapter, i have no trouble finding those, what I want to know about is the details about the system that has em0 LOM, only way to check on that is to have the whole enchilada :) Jack From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 18:24:08 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3CA91065675 for ; Fri, 10 Sep 2010 18:24:08 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 345D78FC13 for ; Fri, 10 Sep 2010 18:24:07 +0000 (UTC) Received: (qmail 7184 invoked by uid 399); 10 Sep 2010 18:24:07 -0000 Received: from localhost (HELO ?192.168.0.142?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 10 Sep 2010 18:24:07 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C8A77C9.70009@FreeBSD.org> Date: Fri, 10 Sep 2010 11:24:09 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org References: <201009100920.o8A9KAAp030811@fire.js.berklix.net> In-Reply-To: <201009100920.o8A9KAAp030811@fire.js.berklix.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Policy for removing working code X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 18:24:08 -0000 On 9/10/2010 2:20 AM, Julian H. Stacey wrote: > One option could be a new list Just send these notices to -announce. The removal of stuff like this doesn't happen often, and as long as we're careful with the frequency and content of the messages I can't imagine people would complain too much. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-stable@FreeBSD.ORG Sat Sep 11 08:11:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00C1D106566C; Sat, 11 Sep 2010 08:11:02 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id A2AA78FC13; Sat, 11 Sep 2010 08:11:01 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id o8B8B09X051008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 11 Sep 2010 01:11:00 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id o8B8B070051007; Sat, 11 Sep 2010 01:11:00 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA16208; Sat, 11 Sep 10 01:05:37 PDT Date: Sat, 11 Sep 2010 01:01:59 -0700 From: perryh@pluto.rain.com To: jhb@freebsd.org Message-Id: <4c8b3777.A5l69BLBx5dsBnNl%perryh@pluto.rain.com> References: <20100909150012.GA27370@lordcow.org> <4c89d653.UyUz1Sv9zPckJnig%perryh@pluto.rain.com> <201009100757.49777.jhb@freebsd.org> In-Reply-To: <201009100757.49777.jhb@freebsd.org> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: MSIX failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Sep 2010 08:11:02 -0000 John Baldwin wrote: > On Friday, September 10, 2010 2:55:15 am perryh@pluto.rain.com wrote: > > ... > > It is arguably a bug to open O_RDWR when only examining things. > > You have to have RDWR permission to issue the ioctl to read config > registers which pciconf does when examining capabilities. So much for avoiding a reboot for (or whatever the correct address is -- that one bounced), but now it is beginning to look as if there may be a POLA violation at a lower level. Unless there are devices out there whose state can be changed by merely _reading_ (not writing) their configuration registers, I would not expect to need RDWR permission just to read them. From owner-freebsd-stable@FreeBSD.ORG Sat Sep 11 11:36:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1B4B1065675 for ; Sat, 11 Sep 2010 11:36:30 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [203.58.93.36]) by mx1.freebsd.org (Postfix) with ESMTP id 2F5B38FC0A for ; Sat, 11 Sep 2010 11:36:29 +0000 (UTC) Received: from rwpc12.mby.riverwillow.net.au (rwpc12.mby.riverwillow.net.au [172.25.24.193]) (authenticated bits=0) by mail1.riverwillow.net.au (8.14.4/8.14.4) with ESMTP id o8BBLCn5092559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 11 Sep 2010 21:21:13 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=m1001; t=1284204073; bh=bBW4rmYNakreTldZ9YAw4ZQyomMycGlC4E0brFAPwLw=; h=Date:From:To:Cc:Subject:Message-ID:Mime-Version:Content-Type; b=fN6Cjew32Fq70ZtGLOdVSrcgbNWcw/uCR9Nb4XZiJI7XIU4CRFNb+k7elAPv5f3LY 2waP7BSbI5bOkTSfublcwnJNAsELVzEhHadU/PBOnWfZQO5Y0t4ioiPTYXbQC5CBj8 /djAQTlpZxsx0mkAb39CkOC/3ZimLCFgrq+ESE+8= Received: from rwpc12.mby.riverwillow.net.au (localhost [127.0.0.1]) by rwpc12.mby.riverwillow.net.au (8.14.4/8.14.4) with ESMTP id o8BBLCeA017320; Sat, 11 Sep 2010 21:21:12 +1000 (AEST) (envelope-from john.marshall@riverwillow.com.au) Received: (from john@localhost) by rwpc12.mby.riverwillow.net.au (8.14.4/8.14.4/Submit) id o8BBLA7l017319; Sat, 11 Sep 2010 21:21:10 +1000 (AEST) (envelope-from john) Date: Sat, 11 Sep 2010 21:21:10 +1000 From: John Marshall To: freebsd-stable@freebsd.org Message-ID: <20100911112109.GN16882@rwpc12.mby.riverwillow.net.au> Mail-Followup-To: freebsd-stable@freebsd.org, marck@rinet.ru Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d01dLTUuW90fS44H" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i OpenPGP: id=A29A84A2 Cc: marck@rinet.ru Subject: Re: csup in repomirror mode dumps core @ stable/8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Sep 2010 11:36:30 -0000 --d01dLTUuW90fS44H Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 02, 2010, Dmitry Morozovsky wrote: > On Thu, Sep 02, 2010 at 03:59:07AM +0400, Dmitry Morozovsky wrote: > >=20 > > some 2 days ago my repo mirror (stable/8 at amd64) starts dumping core = on copying=20 > > repo: > >=20 > > ... > > SetAttrs CVSROOT-src/Emptydir > > Edit CVSROOT-src/access,v > > Segmentation fault (core dumped) > BTW, I can confirm moving away access,v file helps avoiding core. I saw the same thing with csup. I switched my local mirror client back to using cvsup. cvsup complains about the same file but it handles it OK: =20 ... Rsync CVSROOT-src/access Edit CVSROOT-src/access,v CVSROOT-src/access,v: Invalid RCS file: 16249: "String" expected -- will tr= ansfer entire file ... Applying fixups for collection cvs-all/cvs Fixup CVSROOT-src/access,v --=20 John Marshall --d01dLTUuW90fS44H Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkyLZiUACgkQw/tAaKKahKJU2gCgqfm1b088PvQDdVI5ndH8sZ+B u/sAmgKeYYN6jTA1Y0MRFmvkThiwcYw3 =8Liy -----END PGP SIGNATURE----- --d01dLTUuW90fS44H-- From owner-freebsd-stable@FreeBSD.ORG Sat Sep 11 11:55:48 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D7C8106564A for ; Sat, 11 Sep 2010 11:55:48 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4D3CA8FC0A for ; Sat, 11 Sep 2010 11:55:48 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id DBE7946B37; Sat, 11 Sep 2010 07:55:47 -0400 (EDT) Received: from John-Baldwins-Macbook-Pro.local (c-68-45-19-154.hsd1.nj.comcast.net [68.45.19.154]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5DA468A03C; Sat, 11 Sep 2010 07:55:36 -0400 (EDT) Message-ID: <4C8B6E38.7030303@FreeBSD.org> Date: Sat, 11 Sep 2010 07:55:36 -0400 From: John Baldwin User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: perryh@pluto.rain.com References: <20100909150012.GA27370@lordcow.org> <4c89d653.UyUz1Sv9zPckJnig%perryh@pluto.rain.com> <201009100757.49777.jhb@freebsd.org> <4c8b3777.A5l69BLBx5dsBnNl%perryh@pluto.rain.com> In-Reply-To: <4c8b3777.A5l69BLBx5dsBnNl%perryh@pluto.rain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Sat, 11 Sep 2010 07:55:36 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-stable@freebsd.org Subject: Re: MSIX failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Sep 2010 11:55:48 -0000 perryh@pluto.rain.com wrote: > John Baldwin wrote: >> On Friday, September 10, 2010 2:55:15 am perryh@pluto.rain.com wrote: >>> ... >>> It is arguably a bug to open O_RDWR when only examining things. >> You have to have RDWR permission to issue the ioctl to read config >> registers which pciconf does when examining capabilities. > > So much for avoiding a reboot for (or whatever the > correct address is -- that one bounced), but now it is beginning to > look as if there may be a POLA violation at a lower level. Unless > there are devices out there whose state can be changed by merely > _reading_ (not writing) their configuration registers, I would not > expect to need RDWR permission just to read them. Umm, not all config registers are standardized and devices are free to define device-specific registers with device-specific behavior (many do). Given that, it is quite possible for a device to implement a register that takes action when read (e.g. resets to 0 or clears status bits, etc.). pciconf -l itself does not require RDWR permissions, only -c which does a good bit more work. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Sat Sep 11 22:56:42 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06D7D1065672 for ; Sat, 11 Sep 2010 22:56:42 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id BD2638FC08 for ; Sat, 11 Sep 2010 22:56:41 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:6cd1:b429:8966:7e53] (unknown [IPv6:2001:7b8:3a7:0:6cd1:b429:8966:7e53]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id DC01F5C62; Sun, 12 Sep 2010 00:56:40 +0200 (CEST) Message-ID: <4C8C092D.7060306@FreeBSD.org> Date: Sun, 12 Sep 2010 00:56:45 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.10pre) Gecko/20100910 Lanikai/3.1.4pre MIME-Version: 1.0 To: freebsd-stable@freebsd.org, marck@rinet.ru References: <20100911112109.GN16882@rwpc12.mby.riverwillow.net.au> In-Reply-To: <20100911112109.GN16882@rwpc12.mby.riverwillow.net.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: csup in repomirror mode dumps core @ stable/8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Sep 2010 22:56:42 -0000 On 2010-09-11 13:21, John Marshall wrote: >>> some 2 days ago my repo mirror (stable/8 at amd64) starts dumping core on copying >>> repo: >>> >>> ... >>> SetAttrs CVSROOT-src/Emptydir >>> Edit CVSROOT-src/access,v >>> Segmentation fault (core dumped) > >> BTW, I can confirm moving away access,v file helps avoiding core. > > I saw the same thing with csup. I switched my local mirror client back > to using cvsup. cvsup complains about the same file but it handles it The CVSROOT-src/access,v on the master cvsup mirror is still truncated, unfortunately. Apparently cvsup handles 'corrupt' RCS files better than csup. :)