From owner-freebsd-current@FreeBSD.ORG Sun May 1 12:51:38 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AACF7106566B; Sun, 1 May 2011 12:51:38 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [46.28.110.116]) by mx1.freebsd.org (Postfix) with ESMTP id 5A76B8FC12; Sun, 1 May 2011 12:51:37 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id 4EBA37F3938; Sun, 1 May 2011 14:51:36 +0200 (CEST) Date: Sun, 1 May 2011 14:51:36 +0200 From: Roman Divacky To: Hans Petter Selasky Message-ID: <20110501125136.GA62418@freebsd.org> References: <72378267@bb.ipt.ru> <20110430094616.GA86210@freebsd.org> <201104301146.28225.hselasky@c2i.net> <201104301153.30356.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201104301153.30356.hselasky@c2i.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-multimedia@freebsd.org, Boris Samorodov , freebsd-current@freebsd.org, current@freebsd.org Subject: Re: webcamd-0.1.26: does not build with clang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 12:51:38 -0000 This is a bug in llvm integrated assembler. I filed a bug for it http://llvm.org/bugs/show_bug.cgi?id=9822 webcamd compiles/links just fine with clang + gnu as. On Sat, Apr 30, 2011 at 11:53:30AM +0200, Hans Petter Selasky wrote: > On Saturday 30 April 2011 11:46:28 Hans Petter Selasky wrote: > > linux_init_mod/linux_exit_mod. > > These two symbols are so-called sections. At least the GCC will resolve these, > I.E. when there is an __attribute__((__section__("linux_init_mod"))), then > also extern linux_init_mod resolves. > > --HPS > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun May 1 13:10:57 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01067106566B for ; Sun, 1 May 2011 13:10:57 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [46.28.110.116]) by mx1.freebsd.org (Postfix) with ESMTP id B3D438FC13 for ; Sun, 1 May 2011 13:10:56 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id 4EBA37F3938; Sun, 1 May 2011 14:51:36 +0200 (CEST) Date: Sun, 1 May 2011 14:51:36 +0200 From: Roman Divacky To: Hans Petter Selasky Message-ID: <20110501125136.GA62418@freebsd.org> References: <72378267@bb.ipt.ru> <20110430094616.GA86210@freebsd.org> <201104301146.28225.hselasky@c2i.net> <201104301153.30356.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201104301153.30356.hselasky@c2i.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-multimedia@freebsd.org, Boris Samorodov , freebsd-current@freebsd.org, current@freebsd.org Subject: Re: webcamd-0.1.26: does not build with clang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 13:10:57 -0000 This is a bug in llvm integrated assembler. I filed a bug for it http://llvm.org/bugs/show_bug.cgi?id=9822 webcamd compiles/links just fine with clang + gnu as. On Sat, Apr 30, 2011 at 11:53:30AM +0200, Hans Petter Selasky wrote: > On Saturday 30 April 2011 11:46:28 Hans Petter Selasky wrote: > > linux_init_mod/linux_exit_mod. > > These two symbols are so-called sections. At least the GCC will resolve these, > I.E. when there is an __attribute__((__section__("linux_init_mod"))), then > also extern linux_init_mod resolves. > > --HPS > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun May 1 17:15:39 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29A07106568F; Sun, 1 May 2011 17:15: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 C60A48FC0C; Sun, 1 May 2011 17:15:38 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p41HFb2Q060568; Sun, 1 May 2011 13:15:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p41HFbMk060501; Sun, 1 May 2011 17:15:37 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 1 May 2011 17:15:37 GMT Message-Id: <201105011715.p41HFbMk060501@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: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 17:15:39 -0000 TB --- 2011-05-01 16:10:46 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-01 16:10:46 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-05-01 16:10:46 - cleaning the object tree TB --- 2011-05-01 16:10:58 - cvsupping the source tree TB --- 2011-05-01 16:10:58 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-05-01 16:11:50 - building world TB --- 2011-05-01 16:11:50 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-01 16:11:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-01 16:11:50 - TARGET=sparc64 TB --- 2011-05-01 16:11:50 - TARGET_ARCH=sparc64 TB --- 2011-05-01 16:11:50 - TZ=UTC TB --- 2011-05-01 16:11:50 - __MAKE_CONF=/dev/null TB --- 2011-05-01 16:11:50 - cd /src TB --- 2011-05-01 16:11:50 - /usr/bin/make -B buildworld >>> World build started on Sun May 1 16:11:51 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun May 1 17:15:36 UTC 2011 TB --- 2011-05-01 17:15:36 - generating LINT kernel config TB --- 2011-05-01 17:15:36 - cd /src/sys/sparc64/conf TB --- 2011-05-01 17:15:36 - /usr/bin/make -B LINT TB --- 2011-05-01 17:15:37 - building LINT kernel TB --- 2011-05-01 17:15:37 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-01 17:15:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-01 17:15:37 - TARGET=sparc64 TB --- 2011-05-01 17:15:37 - TARGET_ARCH=sparc64 TB --- 2011-05-01 17:15:37 - TZ=UTC TB --- 2011-05-01 17:15:37 - __MAKE_CONF=/dev/null TB --- 2011-05-01 17:15:37 - cd /src TB --- 2011-05-01 17:15:37 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun May 1 17:15:37 UTC 2011 >>> stage 1: configuring the kernel [...] WARNING: duplicate option `SUNKBD_EMULATE_ATKBD' encountered. WARNING: kernel contains GPL contaminated emu10kx headers WARNING: kernel contains GPL contaminated emu10kx headers WARNING: kernel contains GPL contaminated emu10kx headers WARNING: kernel contains GPL contaminated ReiserFS filesystem WARNING: kernel contains GPL contaminated xfs filesystem config: Error: device "wpi" is unknown config: 1 errors *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-05-01 17:15:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-05-01 17:15:37 - ERROR: failed to build lint kernel TB --- 2011-05-01 17:15:37 - 2872.52 user 625.77 system 3890.98 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sun May 1 17:32:19 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD5661065675; Sun, 1 May 2011 17:32:19 +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 81DD08FC18; Sun, 1 May 2011 17:32:19 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p41HWIlJ065953; Sun, 1 May 2011 13:32:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p41HWI65065948; Sun, 1 May 2011 17:32:18 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 1 May 2011 17:32:18 GMT Message-Id: <201105011732.p41HWI65065948@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: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 17:32:20 -0000 TB --- 2011-05-01 15:58:18 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-01 15:58:18 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-05-01 15:58:18 - cleaning the object tree TB --- 2011-05-01 15:58:39 - cvsupping the source tree TB --- 2011-05-01 15:58:39 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-05-01 15:58:54 - building world TB --- 2011-05-01 15:58:54 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-01 15:58:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-01 15:58:54 - TARGET=powerpc TB --- 2011-05-01 15:58:54 - TARGET_ARCH=powerpc64 TB --- 2011-05-01 15:58:54 - TZ=UTC TB --- 2011-05-01 15:58:54 - __MAKE_CONF=/dev/null TB --- 2011-05-01 15:58:54 - cd /src TB --- 2011-05-01 15:58:54 - /usr/bin/make -B buildworld >>> World build started on Sun May 1 15:58:54 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sun May 1 17:32:17 UTC 2011 TB --- 2011-05-01 17:32:18 - generating LINT kernel config TB --- 2011-05-01 17:32:18 - cd /src/sys/powerpc/conf TB --- 2011-05-01 17:32:18 - /usr/bin/make -B LINT TB --- 2011-05-01 17:32:18 - building LINT kernel TB --- 2011-05-01 17:32:18 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-01 17:32:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-01 17:32:18 - TARGET=powerpc TB --- 2011-05-01 17:32:18 - TARGET_ARCH=powerpc64 TB --- 2011-05-01 17:32:18 - TZ=UTC TB --- 2011-05-01 17:32:18 - __MAKE_CONF=/dev/null TB --- 2011-05-01 17:32:18 - cd /src TB --- 2011-05-01 17:32:18 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun May 1 17:32:18 UTC 2011 >>> stage 1: configuring the kernel [...] WARNING: kernel contains GPL contaminated emu10kx headers WARNING: kernel contains GPL contaminated emu10kx headers WARNING: kernel contains GPL contaminated emu10kx headers WARNING: kernel contains GPL contaminated maestro3 headers WARNING: kernel contains GPL contaminated ReiserFS filesystem WARNING: kernel contains GPL contaminated xfs filesystem config: Error: device "wpi" is unknown config: 1 errors *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-05-01 17:32:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-05-01 17:32:18 - ERROR: failed to build lint kernel TB --- 2011-05-01 17:32:18 - 4334.75 user 943.71 system 5639.58 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun May 1 17:38:23 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1E871065670; Sun, 1 May 2011 17:38:23 +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 6BBC78FC0C; Sun, 1 May 2011 17:38:23 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p41HcMDP092785; Sun, 1 May 2011 13:38:22 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p41HcMie092784; Sun, 1 May 2011 17:38:22 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 1 May 2011 17:38:22 GMT Message-Id: <201105011738.p41HcMie092784@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: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 17:38:23 -0000 TB --- 2011-05-01 15:54:11 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-01 15:54:11 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-05-01 15:54:11 - cleaning the object tree TB --- 2011-05-01 15:54:24 - cvsupping the source tree TB --- 2011-05-01 15:54:24 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-05-01 15:54:39 - building world TB --- 2011-05-01 15:54:39 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-01 15:54:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-01 15:54:39 - TARGET=powerpc TB --- 2011-05-01 15:54:39 - TARGET_ARCH=powerpc TB --- 2011-05-01 15:54:39 - TZ=UTC TB --- 2011-05-01 15:54:39 - __MAKE_CONF=/dev/null TB --- 2011-05-01 15:54:39 - cd /src TB --- 2011-05-01 15:54:39 - /usr/bin/make -B buildworld >>> World build started on Sun May 1 15:54:41 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun May 1 17:38:22 UTC 2011 TB --- 2011-05-01 17:38:22 - generating LINT kernel config TB --- 2011-05-01 17:38:22 - cd /src/sys/powerpc/conf TB --- 2011-05-01 17:38:22 - /usr/bin/make -B LINT TB --- 2011-05-01 17:38:22 - building LINT kernel TB --- 2011-05-01 17:38:22 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-01 17:38:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-01 17:38:22 - TARGET=powerpc TB --- 2011-05-01 17:38:22 - TARGET_ARCH=powerpc TB --- 2011-05-01 17:38:22 - TZ=UTC TB --- 2011-05-01 17:38:22 - __MAKE_CONF=/dev/null TB --- 2011-05-01 17:38:22 - cd /src TB --- 2011-05-01 17:38:22 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun May 1 17:38:22 UTC 2011 >>> stage 1: configuring the kernel [...] WARNING: kernel contains GPL contaminated emu10kx headers WARNING: kernel contains GPL contaminated emu10kx headers WARNING: kernel contains GPL contaminated emu10kx headers WARNING: kernel contains GPL contaminated maestro3 headers WARNING: kernel contains GPL contaminated ReiserFS filesystem WARNING: kernel contains GPL contaminated xfs filesystem config: Error: device "wpi" is unknown config: 1 errors *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-05-01 17:38:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-05-01 17:38:22 - ERROR: failed to build lint kernel TB --- 2011-05-01 17:38:22 - 5114.35 user 845.69 system 6251.22 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun May 1 17:44:29 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4370B1065670; Sun, 1 May 2011 17:44:29 +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 D9C3D8FC0A; Sun, 1 May 2011 17:44:28 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p41HiS3F004043; Sun, 1 May 2011 13:44:28 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p41HiRbf004042; Sun, 1 May 2011 17:44:27 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 1 May 2011 17:44:27 GMT Message-Id: <201105011744.p41HiRbf004042@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: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 17:44:29 -0000 TB --- 2011-05-01 16:44:34 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-01 16:44:34 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2011-05-01 16:44:34 - cleaning the object tree TB --- 2011-05-01 16:44:45 - cvsupping the source tree TB --- 2011-05-01 16:44:45 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2011-05-01 16:44:58 - building world TB --- 2011-05-01 16:44:58 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-01 16:44:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-01 16:44:58 - TARGET=sun4v TB --- 2011-05-01 16:44:58 - TARGET_ARCH=sparc64 TB --- 2011-05-01 16:44:58 - TZ=UTC TB --- 2011-05-01 16:44:58 - __MAKE_CONF=/dev/null TB --- 2011-05-01 16:44:58 - cd /src TB --- 2011-05-01 16:44:58 - /usr/bin/make -B buildworld >>> World build started on Sun May 1 16:44:59 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun May 1 17:44:27 UTC 2011 TB --- 2011-05-01 17:44:27 - generating LINT kernel config TB --- 2011-05-01 17:44:27 - cd /src/sys/sun4v/conf TB --- 2011-05-01 17:44:27 - /usr/bin/make -B LINT TB --- 2011-05-01 17:44:27 - building LINT kernel TB --- 2011-05-01 17:44:27 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-01 17:44:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-01 17:44:27 - TARGET=sun4v TB --- 2011-05-01 17:44:27 - TARGET_ARCH=sparc64 TB --- 2011-05-01 17:44:27 - TZ=UTC TB --- 2011-05-01 17:44:27 - __MAKE_CONF=/dev/null TB --- 2011-05-01 17:44:27 - cd /src TB --- 2011-05-01 17:44:27 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun May 1 17:44:27 UTC 2011 >>> stage 1: configuring the kernel [...] WARNING: duplicate option `GEOM_PART_BSD' encountered. WARNING: duplicate option `GEOM_PART_VTOC8' encountered. WARNING: duplicate option `DEV_MEM' encountered. WARNING: duplicate device `mem' encountered. WARNING: kernel contains GPL contaminated ReiserFS filesystem WARNING: kernel contains GPL contaminated xfs filesystem config: Error: device "wpi" is unknown config: 1 errors *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-05-01 17:44:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-05-01 17:44:27 - ERROR: failed to build lint kernel TB --- 2011-05-01 17:44:27 - 2823.28 user 603.73 system 3593.44 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sun May 1 19:43:39 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC223106566C; Sun, 1 May 2011 19:43: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 769DE8FC16; Sun, 1 May 2011 19:43:39 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p41JhcKG098181; Sun, 1 May 2011 15:43:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p41JhcY6098169; Sun, 1 May 2011 19:43:38 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 1 May 2011 19:43:38 GMT Message-Id: <201105011943.p41JhcY6098169@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: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 19:43:39 -0000 TB --- 2011-05-01 17:50:01 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-01 17:50:01 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-05-01 17:50:01 - cleaning the object tree TB --- 2011-05-01 17:50:23 - cvsupping the source tree TB --- 2011-05-01 17:50:23 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-05-01 17:50:39 - building world TB --- 2011-05-01 17:50:39 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-01 17:50:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-01 17:50:39 - TARGET=pc98 TB --- 2011-05-01 17:50:39 - TARGET_ARCH=i386 TB --- 2011-05-01 17:50:39 - TZ=UTC TB --- 2011-05-01 17:50:39 - __MAKE_CONF=/dev/null TB --- 2011-05-01 17:50:39 - cd /src TB --- 2011-05-01 17:50:39 - /usr/bin/make -B buildworld >>> World build started on Sun May 1 17:50:40 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun May 1 19:43:37 UTC 2011 TB --- 2011-05-01 19:43:37 - generating LINT kernel config TB --- 2011-05-01 19:43:37 - cd /src/sys/pc98/conf TB --- 2011-05-01 19:43:37 - /usr/bin/make -B LINT TB --- 2011-05-01 19:43:37 - building LINT kernel TB --- 2011-05-01 19:43:37 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-01 19:43:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-01 19:43:37 - TARGET=pc98 TB --- 2011-05-01 19:43:37 - TARGET_ARCH=i386 TB --- 2011-05-01 19:43:37 - TZ=UTC TB --- 2011-05-01 19:43:37 - __MAKE_CONF=/dev/null TB --- 2011-05-01 19:43:37 - cd /src TB --- 2011-05-01 19:43:37 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun May 1 19:43:37 UTC 2011 >>> stage 1: configuring the kernel [...] WARNING: kernel contains GPL contaminated emu10kx headers WARNING: kernel contains GPL contaminated emu10kx headers WARNING: kernel contains GPL contaminated maestro3 headers WARNING: kernel contains GPL contaminated ReiserFS filesystem WARNING: kernel contains GPL contaminated xfs filesystem WARNING: COMPAT_SVR4 is broken and should be avoided config: Error: device "wpi" is unknown config: 1 errors *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-05-01 19:43:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-05-01 19:43:38 - ERROR: failed to build lint kernel TB --- 2011-05-01 19:43:38 - 5511.39 user 921.90 system 6817.12 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sun May 1 20:38:25 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4612106566B; Sun, 1 May 2011 20:38: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 75DBA8FC15; Sun, 1 May 2011 20:38:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p41KcOEw048407; Sun, 1 May 2011 16:38:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p41KcOFP048390; Sun, 1 May 2011 20:38:24 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 1 May 2011 20:38:24 GMT Message-Id: <201105012038.p41KcOFP048390@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: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 20:38:25 -0000 TB --- 2011-05-01 17:50:01 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-01 17:50:01 - starting HEAD tinderbox run for i386/i386 TB --- 2011-05-01 17:50:01 - cleaning the object tree TB --- 2011-05-01 17:50:28 - cvsupping the source tree TB --- 2011-05-01 17:50:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-05-01 17:50:42 - building world TB --- 2011-05-01 17:50:42 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-01 17:50:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-01 17:50:42 - TARGET=i386 TB --- 2011-05-01 17:50:42 - TARGET_ARCH=i386 TB --- 2011-05-01 17:50:42 - TZ=UTC TB --- 2011-05-01 17:50:42 - __MAKE_CONF=/dev/null TB --- 2011-05-01 17:50:42 - cd /src TB --- 2011-05-01 17:50:42 - /usr/bin/make -B buildworld >>> World build started on Sun May 1 17:50:46 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun May 1 19:44:25 UTC 2011 TB --- 2011-05-01 19:44:25 - generating LINT kernel config TB --- 2011-05-01 19:44:25 - cd /src/sys/i386/conf TB --- 2011-05-01 19:44:25 - /usr/bin/make -B LINT TB --- 2011-05-01 19:44:25 - building LINT kernel TB --- 2011-05-01 19:44:25 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-01 19:44:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-01 19:44:25 - TARGET=i386 TB --- 2011-05-01 19:44:25 - TARGET_ARCH=i386 TB --- 2011-05-01 19:44:25 - TZ=UTC TB --- 2011-05-01 19:44:25 - __MAKE_CONF=/dev/null TB --- 2011-05-01 19:44:25 - cd /src TB --- 2011-05-01 19:44:25 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun May 1 19:44:25 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sun May 1 20:13:39 UTC 2011 TB --- 2011-05-01 20:13:40 - cd /src/sys/i386/conf TB --- 2011-05-01 20:13:40 - /usr/sbin/config -m GENERIC TB --- 2011-05-01 20:13:40 - building GENERIC kernel TB --- 2011-05-01 20:13:40 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-01 20:13:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-01 20:13:40 - TARGET=i386 TB --- 2011-05-01 20:13:40 - TARGET_ARCH=i386 TB --- 2011-05-01 20:13:40 - TZ=UTC TB --- 2011-05-01 20:13:40 - __MAKE_CONF=/dev/null TB --- 2011-05-01 20:13:40 - cd /src TB --- 2011-05-01 20:13:40 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun May 1 20:13:40 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sun May 1 20:36:11 UTC 2011 TB --- 2011-05-01 20:36:11 - cd /src/sys/i386/conf TB --- 2011-05-01 20:36:11 - /usr/sbin/config -m PAE TB --- 2011-05-01 20:36:11 - building PAE kernel TB --- 2011-05-01 20:36:11 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-01 20:36:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-01 20:36:11 - TARGET=i386 TB --- 2011-05-01 20:36:11 - TARGET_ARCH=i386 TB --- 2011-05-01 20:36:11 - TZ=UTC TB --- 2011-05-01 20:36:11 - __MAKE_CONF=/dev/null TB --- 2011-05-01 20:36:11 - cd /src TB --- 2011-05-01 20:36:11 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Sun May 1 20:36:11 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/lge/if_lge.c cc -c -O -pipe -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/malo/if_malo.c cc -c -O -pipe -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/malo/if_malohal.c cc -c -O -pipe -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/malo/if_malo_pci.c cc1: warnings being treated as errors /src/sys/dev/malo/if_malo_pci.c: In function 'malo_pci_attach': /src/sys/dev/malo/if_malo_pci.c:232: warning: large integer implicitly truncated to unsigned type /src/sys/dev/malo/if_malo_pci.c:232: warning: large integer implicitly truncated to unsigned type *** Error code 1 Stop in /obj/i386.i386/src/sys/PAE. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-05-01 20:38:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-05-01 20:38:23 - ERROR: failed to build PAE kernel TB --- 2011-05-01 20:38:23 - 8147.54 user 1347.48 system 10102.89 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sun May 1 21:01:14 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2015A1065670; Sun, 1 May 2011 21:01:14 +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 BC5F48FC0C; Sun, 1 May 2011 21:01:13 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p41L1DiN025613; Sun, 1 May 2011 17:01:13 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p41L1CPm025596; Sun, 1 May 2011 21:01:12 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 1 May 2011 21:01:12 GMT Message-Id: <201105012101.p41L1CPm025596@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: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 21:01:14 -0000 TB --- 2011-05-01 19:36:02 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-01 19:36:02 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-05-01 19:36:02 - cleaning the object tree TB --- 2011-05-01 19:36:14 - cvsupping the source tree TB --- 2011-05-01 19:36:14 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-05-01 19:36:35 - building world TB --- 2011-05-01 19:36:35 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-01 19:36:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-01 19:36:35 - TARGET=ia64 TB --- 2011-05-01 19:36:35 - TARGET_ARCH=ia64 TB --- 2011-05-01 19:36:35 - TZ=UTC TB --- 2011-05-01 19:36:35 - __MAKE_CONF=/dev/null TB --- 2011-05-01 19:36:35 - cd /src TB --- 2011-05-01 19:36:35 - /usr/bin/make -B buildworld >>> World build started on Sun May 1 19:36:35 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun May 1 21:01:12 UTC 2011 TB --- 2011-05-01 21:01:12 - generating LINT kernel config TB --- 2011-05-01 21:01:12 - cd /src/sys/ia64/conf TB --- 2011-05-01 21:01:12 - /usr/bin/make -B LINT TB --- 2011-05-01 21:01:12 - building LINT kernel TB --- 2011-05-01 21:01:12 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-01 21:01:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-01 21:01:12 - TARGET=ia64 TB --- 2011-05-01 21:01:12 - TARGET_ARCH=ia64 TB --- 2011-05-01 21:01:12 - TZ=UTC TB --- 2011-05-01 21:01:12 - __MAKE_CONF=/dev/null TB --- 2011-05-01 21:01:12 - cd /src TB --- 2011-05-01 21:01:12 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun May 1 21:01:12 UTC 2011 >>> stage 1: configuring the kernel [...] WARNING: kernel contains GPL contaminated emu10kx headers WARNING: kernel contains GPL contaminated emu10kx headers WARNING: kernel contains GPL contaminated emu10kx headers WARNING: kernel contains GPL contaminated maestro3 headers WARNING: kernel contains GPL contaminated ReiserFS filesystem WARNING: kernel contains GPL contaminated xfs filesystem config: Error: device "wpi" is unknown config: 1 errors *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-05-01 21:01:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-05-01 21:01:12 - ERROR: failed to build lint kernel TB --- 2011-05-01 21:01:12 - 4084.59 user 722.87 system 5109.77 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sun May 1 21:22:13 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35139106566B for ; Sun, 1 May 2011 21:22:13 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id DF1FE8FC0C for ; Sun, 1 May 2011 21:22:12 +0000 (UTC) Received: by vws18 with SMTP id 18so5131816vws.13 for ; Sun, 01 May 2011 14:22:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=sUnmH39YRBsKdxORYMbyWHv6DKAKsibpsw/rFEg+4ds=; b=FLJRjHZ3F4hTfFVKl8wI9M/6ky+kzu4WodD0WyLZNu5ODOF6Bp+Yngszn6ocvWB/0y bJ0UP4xPLqsKd8YoKJXtxgEWJlVXriBpWiz91xiA+bDu7xGp9wBXLGugaoKY37/focLh 5uQLZAIQdZLGO9sAg4DDLIu65/HdCpBfIPWec= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=bRy82INi3NBr1KAHo8Kv7SOr47CKBN656JGuT9Y2vajkI74i0BJlOBviM3Iwbttzy1 vidFTAccnFy1UgiUclJLulgp3oW3bcM8w94QXJoR7LqeOnHUtiw0HI6uVPGiX20yOIAn HXk3+7df7UvWd/o90wdPt34mSdGGdQMRZjR4k= MIME-Version: 1.0 Received: by 10.220.189.70 with SMTP id dd6mr2130553vcb.116.1304284931878; Sun, 01 May 2011 14:22:11 -0700 (PDT) Received: by 10.220.199.130 with HTTP; Sun, 1 May 2011 14:22:11 -0700 (PDT) Date: Sun, 1 May 2011 14:22:11 -0700 Message-ID: From: Garrett Cooper To: Rick Macklem Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current Subject: "RPC: program not registered" with new NFS server? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 21:22:13 -0000 Hi Rick, et all, I upgraded to a later kernel on two of my machines and am running into issues starting up the nfs kernel. Every time I try mounting like so: # mount -t nfs localhost:/scratch/ /mnt/ or like so: # mount -t oldnfs localhost:/scratch/ /mnt/ I run into this error: [tcp] localhost:/scratch: RPCPROG_NFS: RPC: Program not registered [tcp6] localhost:/scratch: RPCPROG_NFS: RPC: Program not registered I kldloaded nfsd, and then could start the mountd and nfsd services (this made some of my problems go away, in particular showmount -e looks sane), but things aren't sane. I know that nfs client capability works because I can mount remote NFS shares via amd and raw nfs mounts with another machine that I haven't upgraded and things are fine, but the server appears to be completely broken on my machines. Here is the configuration: $ grep NFS /root/FALLOUT #options NFSCL #options NFSCLIENT # Network Filesystem Client #options NFSSERVER # Network Filesystem Server #options NFSLOCKD # Network Lock Manager #options NFS_ROOT # NFS usable as /, requires NFSCLIENT $ grep nfs /etc/src.conf MODULES_OVERRIDE+= krpc nfscommon nfscl nfsclient nfsd nfslockd nfsserver # rc.conf snippet... rpcbind_enable="YES" mountd_enable="YES" rpc_lockd_enable="YES" rpc_statd_enable="YES" nfsd_enable="YES" If someone can provide me with sane details about how to setup either v3 or v4 and get things going again with NFS, that would be awesome, as this will block me from doing other tasks tomorrow at $WORK unless I downgrade to an earlier version of CURRENT (in particular I know that my directions differ from what's suggested in the handbook, and the handbook directions don't work with my setup shown above). Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sun May 1 21:37:55 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97FAA1065672 for ; Sun, 1 May 2011 21:37:55 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 51FD18FC1E for ; Sun, 1 May 2011 21:37:54 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEACLSvU2DaFvO/2dsb2JhbACEUaJDiHGoaY9HgSqDVYEBBI55jj4 X-IronPort-AV: E=Sophos;i="4.64,299,1301889600"; d="scan'208";a="119252416" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 01 May 2011 17:37:53 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 9A740B3F98; Sun, 1 May 2011 17:37:53 -0400 (EDT) Date: Sun, 1 May 2011 17:37:53 -0400 (EDT) From: Rick Macklem To: Garrett Cooper Message-ID: <1964919189.836346.1304285873572.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: FreeBSD Current Subject: Re: "RPC: program not registered" with new NFS server? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 21:37:55 -0000 > Hi Rick, et all, > I upgraded to a later kernel on two of my machines and am running > into issues starting up the nfs kernel. Every time I try mounting like > so: > > # mount -t nfs localhost:/scratch/ /mnt/ > > or like so: > > # mount -t oldnfs localhost:/scratch/ /mnt/ > > I run into this error: > > [tcp] localhost:/scratch: RPCPROG_NFS: RPC: Program not registered > [tcp6] localhost:/scratch: RPCPROG_NFS: RPC: Program not registered > > I kldloaded nfsd, and then could start the mountd and nfsd > services (this made some of my problems go away, in particular > showmount -e looks sane), but things aren't sane. I know that nfs > client capability works because I can mount remote NFS shares via amd > and raw nfs mounts with another machine that I haven't upgraded and > things are fine, but the server appears to be completely broken on my > machines. > Here is the configuration: > > $ grep NFS /root/FALLOUT > #options NFSCL > #options NFSCLIENT # Network Filesystem Client > #options NFSSERVER # Network Filesystem Server > #options NFSLOCKD # Network Lock Manager > #options NFS_ROOT # NFS usable as /, requires NFSCLIENT > $ grep nfs /etc/src.conf > MODULES_OVERRIDE+= krpc nfscommon nfscl nfsclient nfsd nfslockd > nfsserver > > # rc.conf snippet... > > rpcbind_enable="YES" > mountd_enable="YES" > rpc_lockd_enable="YES" > rpc_statd_enable="YES" > nfsd_enable="YES" > Well, I think the rc variable has always been: nfs_server_enable="YES" which still works for the new one as well as old one. The only other thing I can think of is if you are pre-r220510 you need to create an empty stablerestart file before the new nfs server will start. Take a look to see if the nfsd is running via "ps axHl" or similar and check /var/log/messages for nfsd/mountd related errors. If you need to create the stable restart file, just do the following on the server: # install -o root -g wheel -m 600 /dev/null /var/db/nfs-stablerestart (This shouldn't be necessary for post r220510 systems and pre-r220510 systems shouldn't try and run the new server by default, so this shouldn't be your problem. Just "ls -l /var/db" to see if the file is there.) rick From owner-freebsd-current@FreeBSD.ORG Sun May 1 19:47:34 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 585A5106566B for ; Sun, 1 May 2011 19:47:34 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 0501B8FC17 for ; Sun, 1 May 2011 19:47:33 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1QGcc8-0001VB-J7>; Sun, 01 May 2011 21:47:32 +0200 Received: from e178024038.adsl.alicedsl.de ([85.178.24.38] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1QGcc8-0003MV-Ey>; Sun, 01 May 2011 21:47:32 +0200 Message-ID: <4DBDB8D4.6050102@mail.zedat.fu-berlin.de> Date: Sun, 01 May 2011 21:47:32 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.24.38 X-Mailman-Approved-At: Sun, 01 May 2011 23:08:22 +0000 Subject: Building FreeBSD 9.0-CUR/amd64 with CLANG fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 19:47:34 -0000 Well, I tried the first time building FreeBSD 9.0-CURRENT/amd64 (sources from today's latest svn) and it failed (taken the /etc/make.conf addition from the wiki), giving the below showed error. Is this a well known issue and FreeBSD isn't building correctly at the moment or did I miss something (not mentioned on the wiki's page)? clang: warning: argument unused during compilation: '-finhibit-size-directive' clang: warning: argument unused during compilation: '-fno-toplevel-reorder' sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtbegin.o /usr/obj/usr/src/lib32/usr/lib32/crtbegin.o sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtend.o /usr/obj/usr/src/lib32/usr/lib32/crtend.o sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtbeginT.o /usr/obj/usr/src/lib32/usr/lib32/crtbeginT.o sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtbegin.So /usr/obj/usr/src/lib32/usr/lib32/crtbeginS.o sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtend.So /usr/obj/usr/src/lib32/usr/lib32/crtendS.o ===> lib/csu/i386-elf (obj,depend,all,install) rm -f .depend CC='clang' mkdep -f .depend -a -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include /usr/src/lib/csu/i386-elf/crti.S /usr/src/lib/csu/i386-elf/crtn.S clang -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -std=gnu99 -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/lib/csu/i386-elf/crti.S clang -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -std=gnu99 -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/lib/csu/i386-elf/crtn.S clang -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -std=gnu99 -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -DGCRT -S -o gcrt1_c.s /usr/src/lib/csu/i386-elf/crt1_c.c sed -i "" -e '/\.note\.ABI-tag/s/progbits/note/' gcrt1_c.s clang -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -std=gnu99 -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c -o gcrt1_c.o gcrt1_c.s clang: warning: argument unused during compilation: '-I /usr/src/lib/csu/i386-elf/../common' clang: warning: argument unused during compilation: '-I /usr/src/lib/csu/i386-elf/../../libc/include' clang: warning: argument unused during compilation: '-std=gnu99' clang: warning: argument unused during compilation: '-Wsystem-headers' clang: warning: argument unused during compilation: '-Wall' clang: warning: argument unused during compilation: '-Wno-format-y2k' clang: warning: argument unused during compilation: '-W' clang: warning: argument unused during compilation: '-Wno-unused-parameter' clang: warning: argument unused during compilation: '-Wstrict-prototypes' clang: warning: argument unused during compilation: '-Wmissing-prototypes' clang: warning: argument unused during compilation: '-Wpointer-arith' clang: warning: argument unused during compilation: '-Wreturn-type' clang: warning: argument unused during compilation: '-Wcast-qual' clang: warning: argument unused during compilation: '-Wwrite-strings' clang: warning: argument unused during compilation: '-Wswitch' clang: warning: argument unused during compilation: '-Wshadow' clang: warning: argument unused during compilation: '-Wunused-parameter' clang: warning: argument unused during compilation: '-Wcast-align' clang: warning: argument unused during compilation: '-Wchar-subscripts' clang: warning: argument unused during compilation: '-Winline' clang: warning: argument unused during compilation: '-Wnested-externs' clang: warning: argument unused during compilation: '-Wredundant-decls' clang: warning: argument unused during compilation: '-Wold-style-definition' clang: warning: argument unused during compilation: '-Wno-pointer-sign' clang -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -std=gnu99 -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/lib/csu/i386-elf/crt1_s.S ld -m elf_i386_fbsd -Y P,/usr/obj/usr/src/lib32/usr/lib32 -o gcrt1.o -r crt1_s.o gcrt1_c.o ld: Relocatable linking with relocations from format elf64-x86-64-freebsd (crt1_s.o) to format elf32-i386-freebsd (gcrt1.o) is not supported *** Error code 1 Stop in /usr/src/lib/csu/i386-elf. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 From owner-freebsd-current@FreeBSD.ORG Mon May 2 01:57:32 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBA60106564A; Mon, 2 May 2011 01:57:32 +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 C02148FC0A; Mon, 2 May 2011 01:57:32 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p421vVl2032098; Sun, 1 May 2011 21:57:31 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p421vVbq032061; Mon, 2 May 2011 01:57:31 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 May 2011 01:57:31 GMT Message-Id: <201105020157.p421vVbq032061@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: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 01:57:33 -0000 TB --- 2011-05-01 23:10:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-01 23:10:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-05-01 23:10:00 - cleaning the object tree TB --- 2011-05-01 23:10:18 - cvsupping the source tree TB --- 2011-05-01 23:10:18 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-05-01 23:10:39 - building world TB --- 2011-05-01 23:10:39 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-01 23:10:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-01 23:10:39 - TARGET=i386 TB --- 2011-05-01 23:10:39 - TARGET_ARCH=i386 TB --- 2011-05-01 23:10:39 - TZ=UTC TB --- 2011-05-01 23:10:39 - __MAKE_CONF=/dev/null TB --- 2011-05-01 23:10:39 - cd /src TB --- 2011-05-01 23:10:39 - /usr/bin/make -B buildworld >>> World build started on Sun May 1 23:10:40 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon May 2 01:03:23 UTC 2011 TB --- 2011-05-02 01:03:24 - generating LINT kernel config TB --- 2011-05-02 01:03:24 - cd /src/sys/i386/conf TB --- 2011-05-02 01:03:24 - /usr/bin/make -B LINT TB --- 2011-05-02 01:03:24 - building LINT kernel TB --- 2011-05-02 01:03:24 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-02 01:03:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-02 01:03:24 - TARGET=i386 TB --- 2011-05-02 01:03:24 - TARGET_ARCH=i386 TB --- 2011-05-02 01:03:24 - TZ=UTC TB --- 2011-05-02 01:03:24 - __MAKE_CONF=/dev/null TB --- 2011-05-02 01:03:24 - cd /src TB --- 2011-05-02 01:03:24 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon May 2 01:03:24 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Mon May 2 01:32:48 UTC 2011 TB --- 2011-05-02 01:32:48 - cd /src/sys/i386/conf TB --- 2011-05-02 01:32:48 - /usr/sbin/config -m GENERIC TB --- 2011-05-02 01:32:48 - building GENERIC kernel TB --- 2011-05-02 01:32:48 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-02 01:32:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-02 01:32:48 - TARGET=i386 TB --- 2011-05-02 01:32:48 - TARGET_ARCH=i386 TB --- 2011-05-02 01:32:48 - TZ=UTC TB --- 2011-05-02 01:32:48 - __MAKE_CONF=/dev/null TB --- 2011-05-02 01:32:48 - cd /src TB --- 2011-05-02 01:32:48 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon May 2 01:32:48 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Mon May 2 01:55:20 UTC 2011 TB --- 2011-05-02 01:55:20 - cd /src/sys/i386/conf TB --- 2011-05-02 01:55:20 - /usr/sbin/config -m PAE TB --- 2011-05-02 01:55:20 - building PAE kernel TB --- 2011-05-02 01:55:20 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-02 01:55:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-02 01:55:20 - TARGET=i386 TB --- 2011-05-02 01:55:20 - TARGET_ARCH=i386 TB --- 2011-05-02 01:55:20 - TZ=UTC TB --- 2011-05-02 01:55:20 - __MAKE_CONF=/dev/null TB --- 2011-05-02 01:55:20 - cd /src TB --- 2011-05-02 01:55:20 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Mon May 2 01:55:20 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/lge/if_lge.c cc -c -O -pipe -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/malo/if_malo.c cc -c -O -pipe -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/malo/if_malohal.c cc -c -O -pipe -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/malo/if_malo_pci.c cc1: warnings being treated as errors /src/sys/dev/malo/if_malo_pci.c: In function 'malo_pci_attach': /src/sys/dev/malo/if_malo_pci.c:232: warning: large integer implicitly truncated to unsigned type /src/sys/dev/malo/if_malo_pci.c:232: warning: large integer implicitly truncated to unsigned type *** Error code 1 Stop in /obj/i386.i386/src/sys/PAE. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-05-02 01:57:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-05-02 01:57:31 - ERROR: failed to build PAE kernel TB --- 2011-05-02 01:57:31 - 8085.73 user 1326.99 system 10050.77 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Mon May 2 03:50:40 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE546106566B for ; Mon, 2 May 2011 03:50:40 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 846318FC0C for ; Mon, 2 May 2011 03:50:40 +0000 (UTC) Received: by vxc34 with SMTP id 34so5327487vxc.13 for ; Sun, 01 May 2011 20:50:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ICMczoBBYcEHtGN2LUOzXpahnLODBUzU3Re04SgL/fc=; b=QyBtxxlkNAewP5lCsNu+s4xJK4fbPqMMhbGgEM5G3DlAFCzKfu1sxDgVC35H1rTmKy Xcxvxl3Kwyyp/ThmbMoy9pWg9wxp62A6Dfc5+80sGIUfB2Tx5yMXYfm4mKBJczxfcXa7 kQ5hbv2COMxF8o6qqIuQo7lklKAX3ev84wwHc= 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=k8vyD8g98azYi7O09KKo3L6c4PxsFsuw02ilyjR55vxKZdoOxHrDNQzg8rVIzzf43b JZWcY8vMVsclmVY9vtdYxWvYQ3EWVtokM1BqokRKpmAlvw1ITkbsJueWG8byjZzbmY+D mlpVLw2eFKHdOwCSiWjy8mSFLXvDluYACHX/k= MIME-Version: 1.0 Received: by 10.220.203.13 with SMTP id fg13mr2222261vcb.11.1304308239470; Sun, 01 May 2011 20:50:39 -0700 (PDT) Received: by 10.220.199.130 with HTTP; Sun, 1 May 2011 20:50:39 -0700 (PDT) In-Reply-To: <1964919189.836346.1304285873572.JavaMail.root@erie.cs.uoguelph.ca> References: <1964919189.836346.1304285873572.JavaMail.root@erie.cs.uoguelph.ca> Date: Sun, 1 May 2011 20:50:39 -0700 Message-ID: From: Garrett Cooper To: Rick Macklem Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: "RPC: program not registered" with new NFS server? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 03:50:40 -0000 On Sun, May 1, 2011 at 2:37 PM, Rick Macklem wrote: >> Hi Rick, et all, >> I upgraded to a later kernel on two of my machines and am running >> into issues starting up the nfs kernel. Every time I try mounting like >> so: >> >> # mount -t nfs localhost:/scratch/ /mnt/ >> >> or like so: >> >> # mount -t oldnfs localhost:/scratch/ /mnt/ >> >> I run into this error: >> >> [tcp] localhost:/scratch: RPCPROG_NFS: RPC: Program not registered >> [tcp6] localhost:/scratch: RPCPROG_NFS: RPC: Program not registered >> >> I kldloaded nfsd, and then could start the mountd and nfsd >> services (this made some of my problems go away, in particular >> showmount -e looks sane), but things aren't sane. I know that nfs >> client capability works because I can mount remote NFS shares via amd >> and raw nfs mounts with another machine that I haven't upgraded and >> things are fine, but the server appears to be completely broken on my >> machines. >> Here is the configuration: >> >> $ grep NFS /root/FALLOUT >> #options NFSCL >> #options NFSCLIENT # Network Filesystem Client >> #options NFSSERVER # Network Filesystem Server >> #options NFSLOCKD # Network Lock Manager >> #options NFS_ROOT # NFS usable as /, requires NFSCLIENT >> $ grep nfs /etc/src.conf >> MODULES_OVERRIDE+=3D krpc nfscommon nfscl nfsclient nfsd nfslockd >> nfsserver >> >> # rc.conf snippet... >> >> rpcbind_enable=3D"YES" >> mountd_enable=3D"YES" >> rpc_lockd_enable=3D"YES" >> rpc_statd_enable=3D"YES" >> nfsd_enable=3D"YES" >> > Well, I think the rc variable has always been: > nfs_server_enable=3D"YES" > > which still works for the new one as well as old one. > > The only other thing I can think of is if you are > pre-r220510 you need to create an empty stablerestart > file before the new nfs server will start. > > Take a > look to see if the nfsd is running via "ps axHl" > or similar and check /var/log/messages for nfsd/mountd > related errors. > > If you need to create the stable restart file, just do > the following on the server: > # install -o root -g wheel -m 600 /dev/null /var/db/nfs-stablerestart > (This shouldn't be necessary for post r220510 systems and pre-r220510 > =A0systems shouldn't try and run the new server by default, so this > =A0shouldn't be your problem. Just "ls -l /var/db" to see if the file > =A0is there.) Ok, I finally go things going. Here's what I did: 1. Added the following modules to MODULES_OVERRIDE: # grep nfs /etc/src.conf MODULES_OVERRIDE+=3D krpc nfscl nfscommon nfs_common nfsclient nfsd nfslock nfslockd nfsserver nfssvc Note that there are a lot more nfs services listed here. 2. Commented out everything sans nfs_server_enable and nfs_client_enable -- so now everything NFS is run from the kernel instead of userland minus, nfsd. Now the NFS server and client are working fine via V3 and V4. It's important to note this because the module list is less in the old NFS server/client setup to get things fully functional. Example: Old: $ kldstat -v | egrep 'nfs|krpc' 162 nfssvc 164 krpc 161 nfsserver 158 nfs_common 163 nfslockd 160 nfs 159 nfslock New: # kldstat -v | egrep 'nfs|krpc' 11 1 0xffffffff80e19000 1aab0 nfsclient.ko (/boot/kernel/nfsclient.ko= ) 232 oldnfs 12 7 0xffffffff80e34000 13c88 krpc.ko (/boot/kernel/krpc.ko) 229 krpc 13 2 0xffffffff80e48000 d7e nfs_common.ko (/boot/kernel/nfs_common.= ko) 230 nfs_common 14 5 0xffffffff80e49000 f52 nfslock.ko (/boot/kernel/nfslock.ko) 231 nfslock 15 1 0xffffffff80e4a000 1b8f4 nfsserver.ko (/boot/kernel/nfsserver.ko= ) 234 nfsserver 16 5 0xffffffff80e66000 422 nfssvc.ko (/boot/kernel/nfssvc.ko) 233 nfssvc 17 1 0xffffffff80e67000 30887 nfsd.ko (/boot/kernel/nfsd.ko) 237 nfsd 18 3 0xffffffff80e98000 10a03 nfscommon.ko (/boot/kernel/nfscommon.ko= ) 235 nfscommon 19 1 0xffffffff80ea9000 d94a nfslockd.ko (/boot/kernel/nfslockd.ko) 236 nfslockd 20 1 0xffffffff80eb7000 35500 nfscl.ko (/boot/kernel/nfscl.ko) 239 nfs 238 nfscl Now the question I have is -- why are nfs_common and nfscommon not the same module (I know the sources are different, and the functionality is different, so this is more a rhetorical question than anything else)? Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Mon May 2 04:06:46 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67A0F106564A for ; Mon, 2 May 2011 04:06:46 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 180B28FC15 for ; Mon, 2 May 2011 04:06:45 +0000 (UTC) Received: by vws18 with SMTP id 18so5290064vws.13 for ; Sun, 01 May 2011 21:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EFhL3IRMNE26o6ZxA1yrsHl/ZDW3AH9bFPhy2KgqOi4=; b=flG2Mj0UPQeo3NIZIimD9V8V/ev/Rd95rUFW3KFRD3bi+2ydNyIMlsZd1kEo7pltQf o5XbEZAY5rmlbl6Xpdv/h/z923n7k5e9TvO4N5lZpdGqtgSRT/Wad5BzN2XW+nZTVQzB uwO2hqIWhWjMpB9czXqxDu1YDUa2Bf7DZPqZk= 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=VKMblC+rdrcHiajuDTTFX8er3iCicYnhenWNAfDYMfhgbEGTwvgRkRX8nvsNFu41h1 CfYqkqSD1TJAkM9AEVjHhGkhfF8DkP+ixMw5tIHVwObbqvC5N7BcxlNXe+jO9lBtldcZ C57cnJABKLylGRJQYmHKGdZyG+ffEaII2i6gQ= MIME-Version: 1.0 Received: by 10.220.112.138 with SMTP id w10mr1526705vcp.46.1304309205015; Sun, 01 May 2011 21:06:45 -0700 (PDT) Received: by 10.220.199.130 with HTTP; Sun, 1 May 2011 21:06:44 -0700 (PDT) In-Reply-To: References: <1964919189.836346.1304285873572.JavaMail.root@erie.cs.uoguelph.ca> Date: Sun, 1 May 2011 21:06:44 -0700 Message-ID: From: Garrett Cooper To: Rick Macklem Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: "RPC: program not registered" with new NFS server? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 04:06:46 -0000 On Sun, May 1, 2011 at 8:50 PM, Garrett Cooper wrote: > On Sun, May 1, 2011 at 2:37 PM, Rick Macklem wrote= : >>> Hi Rick, et all, >>> I upgraded to a later kernel on two of my machines and am running >>> into issues starting up the nfs kernel. Every time I try mounting like >>> so: >>> >>> # mount -t nfs localhost:/scratch/ /mnt/ >>> >>> or like so: >>> >>> # mount -t oldnfs localhost:/scratch/ /mnt/ >>> >>> I run into this error: >>> >>> [tcp] localhost:/scratch: RPCPROG_NFS: RPC: Program not registered >>> [tcp6] localhost:/scratch: RPCPROG_NFS: RPC: Program not registered >>> >>> I kldloaded nfsd, and then could start the mountd and nfsd >>> services (this made some of my problems go away, in particular >>> showmount -e looks sane), but things aren't sane. I know that nfs >>> client capability works because I can mount remote NFS shares via amd >>> and raw nfs mounts with another machine that I haven't upgraded and >>> things are fine, but the server appears to be completely broken on my >>> machines. >>> Here is the configuration: >>> >>> $ grep NFS /root/FALLOUT >>> #options NFSCL >>> #options NFSCLIENT # Network Filesystem Client >>> #options NFSSERVER # Network Filesystem Server >>> #options NFSLOCKD # Network Lock Manager >>> #options NFS_ROOT # NFS usable as /, requires NFSCLIENT >>> $ grep nfs /etc/src.conf >>> MODULES_OVERRIDE+=3D krpc nfscommon nfscl nfsclient nfsd nfslockd >>> nfsserver >>> >>> # rc.conf snippet... >>> >>> rpcbind_enable=3D"YES" >>> mountd_enable=3D"YES" >>> rpc_lockd_enable=3D"YES" >>> rpc_statd_enable=3D"YES" >>> nfsd_enable=3D"YES" >>> >> Well, I think the rc variable has always been: >> nfs_server_enable=3D"YES" >> >> which still works for the new one as well as old one. >> >> The only other thing I can think of is if you are >> pre-r220510 you need to create an empty stablerestart >> file before the new nfs server will start. >> >> Take a >> look to see if the nfsd is running via "ps axHl" >> or similar and check /var/log/messages for nfsd/mountd >> related errors. >> >> If you need to create the stable restart file, just do >> the following on the server: >> # install -o root -g wheel -m 600 /dev/null /var/db/nfs-stablerestart >> (This shouldn't be necessary for post r220510 systems and pre-r220510 >> =A0systems shouldn't try and run the new server by default, so this >> =A0shouldn't be your problem. Just "ls -l /var/db" to see if the file >> =A0is there.) > > Ok, I finally go things going. Here's what I did: > > 1. Added the following modules to MODULES_OVERRIDE: > > # grep nfs /etc/src.conf > MODULES_OVERRIDE+=3D =A0 =A0 =A0krpc nfscl nfscommon nfs_common nfsclient= nfsd > nfslock nfslockd nfsserver nfssvc > > Note that there are a lot more nfs services listed here. > > 2. Commented out everything sans nfs_server_enable and > nfs_client_enable -- so now everything NFS is run from the kernel > instead of userland minus, nfsd. > > Now the NFS server and client are working fine via V3 and V4. It's > important to note this because the module list is less in the old NFS > server/client setup to get things fully functional. Example: > > Old: > > $ kldstat -v | egrep 'nfs|krpc' > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0162 nfssvc > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0164 krpc > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0161 nfsserver > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0158 nfs_common > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0163 nfslockd > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0160 nfs > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0159 nfslock > > New: > > # kldstat -v | egrep 'nfs|krpc' > 11 =A0 =A01 0xffffffff80e19000 1aab0 =A0 =A0nfsclient.ko (/boot/kernel/nf= sclient.ko) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0232 oldnfs > 12 =A0 =A07 0xffffffff80e34000 13c88 =A0 =A0krpc.ko (/boot/kernel/krpc.ko= ) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0229 krpc > 13 =A0 =A02 0xffffffff80e48000 d7e =A0 =A0 =A0nfs_common.ko (/boot/kernel= /nfs_common.ko) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0230 nfs_common > 14 =A0 =A05 0xffffffff80e49000 f52 =A0 =A0 =A0nfslock.ko (/boot/kernel/nf= slock.ko) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0231 nfslock > 15 =A0 =A01 0xffffffff80e4a000 1b8f4 =A0 =A0nfsserver.ko (/boot/kernel/nf= sserver.ko) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0234 nfsserver > 16 =A0 =A05 0xffffffff80e66000 422 =A0 =A0 =A0nfssvc.ko (/boot/kernel/nfs= svc.ko) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0233 nfssvc > 17 =A0 =A01 0xffffffff80e67000 30887 =A0 =A0nfsd.ko (/boot/kernel/nfsd.ko= ) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0237 nfsd > 18 =A0 =A03 0xffffffff80e98000 10a03 =A0 =A0nfscommon.ko (/boot/kernel/nf= scommon.ko) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0235 nfscommon > 19 =A0 =A01 0xffffffff80ea9000 d94a =A0 =A0 nfslockd.ko (/boot/kernel/nfs= lockd.ko) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0236 nfslockd > 20 =A0 =A01 0xffffffff80eb7000 35500 =A0 =A0nfscl.ko (/boot/kernel/nfscl.= ko) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0239 nfs > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0238 nfscl > > =A0 =A0Now the question I have is -- why are nfs_common and nfscommon not > the same module (I know the sources are different, and the > functionality is different, so this is more a rhetorical question than > anything else)? And one last parting note for now: I had to whack all of my saved kernels because it was trying to load mismatched modules, so something was wonky there with kldload(2), etc. I have a trivial installkernel script that tacks on the svn tag to $INSTKERNNAME and I swap the /boot/kernel symlink pointer to test things out from time to time with different kernels. Not so much nowadays, but back a year ago I did this frequently because of stability issues. Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Mon May 2 07:48:12 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA375106566C; Mon, 2 May 2011 07:48: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 78B518FC14; Mon, 2 May 2011 07:48:12 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p427mB2X004110; Mon, 2 May 2011 03:48:11 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p427mBRP004105; Mon, 2 May 2011 07:48:11 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 May 2011 07:48:11 GMT Message-Id: <201105020748.p427mBRP004105@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: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 07:48:12 -0000 TB --- 2011-05-02 05:00:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-02 05:00:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-05-02 05:00:00 - cleaning the object tree TB --- 2011-05-02 05:00:24 - cvsupping the source tree TB --- 2011-05-02 05:00:24 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-05-02 05:00:50 - building world TB --- 2011-05-02 05:00:50 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-02 05:00:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-02 05:00:50 - TARGET=i386 TB --- 2011-05-02 05:00:50 - TARGET_ARCH=i386 TB --- 2011-05-02 05:00:50 - TZ=UTC TB --- 2011-05-02 05:00:50 - __MAKE_CONF=/dev/null TB --- 2011-05-02 05:00:50 - cd /src TB --- 2011-05-02 05:00:50 - /usr/bin/make -B buildworld >>> World build started on Mon May 2 05:00:50 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon May 2 06:53:39 UTC 2011 TB --- 2011-05-02 06:53:39 - generating LINT kernel config TB --- 2011-05-02 06:53:39 - cd /src/sys/i386/conf TB --- 2011-05-02 06:53:39 - /usr/bin/make -B LINT TB --- 2011-05-02 06:53:39 - building LINT kernel TB --- 2011-05-02 06:53:39 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-02 06:53:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-02 06:53:39 - TARGET=i386 TB --- 2011-05-02 06:53:39 - TARGET_ARCH=i386 TB --- 2011-05-02 06:53:39 - TZ=UTC TB --- 2011-05-02 06:53:39 - __MAKE_CONF=/dev/null TB --- 2011-05-02 06:53:39 - cd /src TB --- 2011-05-02 06:53:39 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon May 2 06:53:39 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Mon May 2 07:23:11 UTC 2011 TB --- 2011-05-02 07:23:11 - cd /src/sys/i386/conf TB --- 2011-05-02 07:23:11 - /usr/sbin/config -m GENERIC TB --- 2011-05-02 07:23:11 - building GENERIC kernel TB --- 2011-05-02 07:23:11 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-02 07:23:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-02 07:23:11 - TARGET=i386 TB --- 2011-05-02 07:23:11 - TARGET_ARCH=i386 TB --- 2011-05-02 07:23:11 - TZ=UTC TB --- 2011-05-02 07:23:11 - __MAKE_CONF=/dev/null TB --- 2011-05-02 07:23:11 - cd /src TB --- 2011-05-02 07:23:11 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon May 2 07:23:11 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Mon May 2 07:45:59 UTC 2011 TB --- 2011-05-02 07:45:59 - cd /src/sys/i386/conf TB --- 2011-05-02 07:45:59 - /usr/sbin/config -m PAE TB --- 2011-05-02 07:45:59 - building PAE kernel TB --- 2011-05-02 07:45:59 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-02 07:45:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-02 07:45:59 - TARGET=i386 TB --- 2011-05-02 07:45:59 - TARGET_ARCH=i386 TB --- 2011-05-02 07:45:59 - TZ=UTC TB --- 2011-05-02 07:45:59 - __MAKE_CONF=/dev/null TB --- 2011-05-02 07:45:59 - cd /src TB --- 2011-05-02 07:45:59 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Mon May 2 07:46:00 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/lge/if_lge.c cc -c -O -pipe -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/malo/if_malo.c cc -c -O -pipe -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/malo/if_malohal.c cc -c -O -pipe -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/malo/if_malo_pci.c cc1: warnings being treated as errors /src/sys/dev/malo/if_malo_pci.c: In function 'malo_pci_attach': /src/sys/dev/malo/if_malo_pci.c:232: warning: large integer implicitly truncated to unsigned type /src/sys/dev/malo/if_malo_pci.c:232: warning: large integer implicitly truncated to unsigned type *** Error code 1 Stop in /obj/i386.i386/src/sys/PAE. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-05-02 07:48:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-05-02 07:48:11 - ERROR: failed to build PAE kernel TB --- 2011-05-02 07:48:11 - 8120.49 user 1324.13 system 10090.18 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Mon May 2 10:09:10 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92639106566C for ; Mon, 2 May 2011 10:09:10 +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 1C35B8FC08 for ; Mon, 2 May 2011 10:09:10 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:a950:cfe0:24ac:52fd] (unknown [IPv6:2001:7b8:3a7:0:a950:cfe0:24ac:52fd]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 2B13F5C59; Mon, 2 May 2011 12:09:08 +0200 (CEST) Message-ID: <4DBE82C2.1030205@FreeBSD.org> Date: Mon, 02 May 2011 12:09:06 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110415 Lanikai/3.1.11pre MIME-Version: 1.0 To: "O. Hartmann" References: <4DBDB8D4.6050102@mail.zedat.fu-berlin.de> In-Reply-To: <4DBDB8D4.6050102@mail.zedat.fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Building FreeBSD 9.0-CUR/amd64 with CLANG fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 10:09:10 -0000 On 2011-05-01 21:47, O. Hartmann wrote: > I tried the first time building FreeBSD 9.0-CURRENT/amd64 (sources from > today's latest svn) and it failed (taken the /etc/make.conf addition > from the wiki), giving the below showed error. What is the full contents of your make.conf? From owner-freebsd-current@FreeBSD.ORG Mon May 2 12:06:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7B581065670 for ; Mon, 2 May 2011 12:06:41 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 9200B8FC14 for ; Mon, 2 May 2011 12:06:41 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAAmevk2DaFvO/2dsb2JhbACEUaJCiHGnG493gSqDVYEBBI55jj4 X-IronPort-AV: E=Sophos;i="4.64,302,1301889600"; d="scan'208";a="119290840" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 02 May 2011 08:06:28 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id AC09EB3F29; Mon, 2 May 2011 08:06:28 -0400 (EDT) Date: Mon, 2 May 2011 08:06:28 -0400 (EDT) From: Rick Macklem To: Garrett Cooper Message-ID: <139204952.849331.1304337988638.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: FreeBSD Current Subject: Re: "RPC: program not registered" with new NFS server? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 12:06:41 -0000 > > Now the NFS server and client are working fine via V3 and V4. It's > important to note this because the module list is less in the old NFS > server/client setup to get things fully functional. Example: > > Old: > > $ kldstat -v | egrep 'nfs|krpc' > 162 nfssvc > 164 krpc > 161 nfsserver > 158 nfs_common > 163 nfslockd > 160 nfs > 159 nfslock > > New: > > # kldstat -v | egrep 'nfs|krpc' > 11 1 0xffffffff80e19000 1aab0 nfsclient.ko (/boot/kernel/nfsclient.ko) > 232 oldnfs > 12 7 0xffffffff80e34000 13c88 krpc.ko (/boot/kernel/krpc.ko) > 229 krpc > 13 2 0xffffffff80e48000 d7e nfs_common.ko (/boot/kernel/nfs_common.ko) > 230 nfs_common > 14 5 0xffffffff80e49000 f52 nfslock.ko (/boot/kernel/nfslock.ko) > 231 nfslock > 15 1 0xffffffff80e4a000 1b8f4 nfsserver.ko (/boot/kernel/nfsserver.ko) > 234 nfsserver > 16 5 0xffffffff80e66000 422 nfssvc.ko (/boot/kernel/nfssvc.ko) > 233 nfssvc > 17 1 0xffffffff80e67000 30887 nfsd.ko (/boot/kernel/nfsd.ko) > 237 nfsd > 18 3 0xffffffff80e98000 10a03 nfscommon.ko (/boot/kernel/nfscommon.ko) > 235 nfscommon > 19 1 0xffffffff80ea9000 d94a nfslockd.ko (/boot/kernel/nfslockd.ko) > 236 nfslockd > 20 1 0xffffffff80eb7000 35500 nfscl.ko (/boot/kernel/nfscl.ko) > 239 nfs > 238 nfscl > > Now the question I have is -- why are nfs_common and nfscommon not > the same module (I know the sources are different, and the > functionality is different, so this is more a rhetorical question than > anything else)? > nfscommon - is the part of the new NFS subsystem shared by the client and server nfs_common - is the part of the old NFS subsystem shared by the old client and old server (It appeared fairly recently, when someone created it for some code that, previous to that point, was duplicated in the old client and old server.) If you are only running the new stuff, you shouldn't need: - nfs_common, nfsclient, nfsserver However, I think these will end up loaded by the rc.d scripts until they are fixed up. At the top of my to-do list. I'll try a config with no NFS kernel options again, to see if I have any problems w.r.t. the right modules loading. rick From owner-freebsd-current@FreeBSD.ORG Mon May 2 12:46:11 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FED11065673 for ; Mon, 2 May 2011 12:46:11 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id E59268FC15 for ; Mon, 2 May 2011 12:46:10 +0000 (UTC) Received: by pvg11 with SMTP id 11so4166556pvg.13 for ; Mon, 02 May 2011 05:46:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.35.228 with SMTP id l4mr9127066pbj.5.1304338770256; Mon, 02 May 2011 05:19:30 -0700 (PDT) Received: by 10.68.40.4 with HTTP; Mon, 2 May 2011 05:19:30 -0700 (PDT) In-Reply-To: <4DBDB8D4.6050102@mail.zedat.fu-berlin.de> References: <4DBDB8D4.6050102@mail.zedat.fu-berlin.de> Date: Mon, 2 May 2011 14:19:30 +0200 Message-ID: From: Olivier Smedts To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Building FreeBSD 9.0-CUR/amd64 with CLANG fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 12:46:11 -0000 2011/5/1 O. Hartmann : > Well, > I tried the first time building FreeBSD 9.0-CURRENT/amd64 (sources from > today's latest svn) and it failed (taken the /etc/make.conf addition from > the wiki), giving the below showed error. Did you follow the instructions on the wiki ? Do you have the following lines in your /etc/make.conf ? NO_WERROR=3D WERROR=3D > Is this a well known issue and FreeBSD isn't building correctly at the > moment or did I miss something (not mentioned on the wiki's page)? > > > > clang: warning: argument unused during compilation: > '-finhibit-size-directive' > clang: warning: argument unused during compilation: '-fno-toplevel-reorde= r' > sh /usr/src/tools/install.sh -o root -g wheel -m 444 =A0crtbegin.o > /usr/obj/usr/src/lib32/usr/lib32/crtbegin.o > sh /usr/src/tools/install.sh -o root -g wheel -m 444 =A0crtend.o > /usr/obj/usr/src/lib32/usr/lib32/crtend.o > sh /usr/src/tools/install.sh -o root -g wheel -m 444 =A0crtbeginT.o > /usr/obj/usr/src/lib32/usr/lib32/crtbeginT.o > sh /usr/src/tools/install.sh -o root -g wheel -m 444 =A0crtbegin.So > /usr/obj/usr/src/lib32/usr/lib32/crtbeginS.o > sh /usr/src/tools/install.sh -o root -g wheel -m 444 =A0crtend.So > /usr/obj/usr/src/lib32/usr/lib32/crtendS.o > =3D=3D=3D> lib/csu/i386-elf (obj,depend,all,install) > rm -f .depend > CC=3D'clang' mkdep -f .depend -a =A0 =A0-I/usr/src/lib/csu/i386-elf/../co= mmon > -I/usr/src/lib/csu/i386-elf/../../libc/include > /usr/src/lib/csu/i386-elf/crti.S /usr/src/lib/csu/i386-elf/crtn.S > clang -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common > -I/usr/src/lib/csu/i386-elf/../../libc/include -std=3Dgnu99 -Wsystem-head= ers > -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual > -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align > -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls > -Wold-style-definition -Wno-pointer-sign =A0-c > /usr/src/lib/csu/i386-elf/crti.S > clang -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common > -I/usr/src/lib/csu/i386-elf/../../libc/include -std=3Dgnu99 -Wsystem-head= ers > -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual > -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align > -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls > -Wold-style-definition -Wno-pointer-sign =A0-c > /usr/src/lib/csu/i386-elf/crtn.S > clang -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common > -I/usr/src/lib/csu/i386-elf/../../libc/include -std=3Dgnu99 -Wsystem-head= ers > -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual > -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align > -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls > -Wold-style-definition -Wno-pointer-sign -DGCRT -S -o gcrt1_c.s > /usr/src/lib/csu/i386-elf/crt1_c.c > sed -i "" -e '/\.note\.ABI-tag/s/progbits/note/' gcrt1_c.s > clang -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common > -I/usr/src/lib/csu/i386-elf/../../libc/include -std=3Dgnu99 -Wsystem-head= ers > -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual > -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align > -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls > -Wold-style-definition -Wno-pointer-sign -c -o gcrt1_c.o gcrt1_c.s > clang: warning: argument unused during compilation: '-I > /usr/src/lib/csu/i386-elf/../common' > clang: warning: argument unused during compilation: '-I > /usr/src/lib/csu/i386-elf/../../libc/include' > clang: warning: argument unused during compilation: '-std=3Dgnu99' > clang: warning: argument unused during compilation: '-Wsystem-headers' > clang: warning: argument unused during compilation: '-Wall' > clang: warning: argument unused during compilation: '-Wno-format-y2k' > clang: warning: argument unused during compilation: '-W' > clang: warning: argument unused during compilation: '-Wno-unused-paramete= r' > clang: warning: argument unused during compilation: '-Wstrict-prototypes' > clang: warning: argument unused during compilation: '-Wmissing-prototypes= ' > clang: warning: argument unused during compilation: '-Wpointer-arith' > clang: warning: argument unused during compilation: '-Wreturn-type' > clang: warning: argument unused during compilation: '-Wcast-qual' > clang: warning: argument unused during compilation: '-Wwrite-strings' > clang: warning: argument unused during compilation: '-Wswitch' > clang: warning: argument unused during compilation: '-Wshadow' > clang: warning: argument unused during compilation: '-Wunused-parameter' > clang: warning: argument unused during compilation: '-Wcast-align' > clang: warning: argument unused during compilation: '-Wchar-subscripts' > clang: warning: argument unused during compilation: '-Winline' > clang: warning: argument unused during compilation: '-Wnested-externs' > clang: warning: argument unused during compilation: '-Wredundant-decls' > clang: warning: argument unused during compilation: '-Wold-style-definiti= on' > clang: warning: argument unused during compilation: '-Wno-pointer-sign' > clang -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common > -I/usr/src/lib/csu/i386-elf/../../libc/include -std=3Dgnu99 -Wsystem-head= ers > -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual > -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align > -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls > -Wold-style-definition -Wno-pointer-sign =A0-c > /usr/src/lib/csu/i386-elf/crt1_s.S > ld -m elf_i386_fbsd -Y P,/usr/obj/usr/src/lib32/usr/lib32 =A0-o gcrt1.o -= r > crt1_s.o gcrt1_c.o > ld: Relocatable linking with relocations from format elf64-x86-64-freebsd > (crt1_s.o) to format elf32-i386-freebsd (gcrt1.o) is not supported > *** Error code 1 > > Stop in /usr/src/lib/csu/i386-elf. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > _______________________________________________ > 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-current@FreeBSD.ORG Mon May 2 12:51:09 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 769011065670 for ; Mon, 2 May 2011 12:51:09 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 2058D8FC13 for ; Mon, 2 May 2011 12:51:09 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1QGsai-0003cJ-9v>; Mon, 02 May 2011 14:51:08 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1QGsai-0001MH-60>; Mon, 02 May 2011 14:51:08 +0200 Message-ID: <4DBEA8BB.7010901@zedat.fu-berlin.de> Date: Mon, 02 May 2011 14:51:07 +0200 From: "O. Hartmann" Organization: Freie =?ISO-8859-1?Q?Universit=E4t_Berlin?= User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: Olivier Smedts References: <4DBDB8D4.6050102@mail.zedat.fu-berlin.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: freebsd-current@freebsd.org Subject: Re: Building FreeBSD 9.0-CUR/amd64 with CLANG fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 12:51:09 -0000 On 05/02/11 14:19, Olivier Smedts wrote: > 2011/5/1 O. Hartmann: >> Well, >> I tried the first time building FreeBSD 9.0-CURRENT/amd64 (sources from >> today's latest svn) and it failed (taken the /etc/make.conf addition from >> the wiki), giving the below showed error. > > Did you follow the instructions on the wiki ? Do you have the > following lines in your /etc/make.conf ? > NO_WERROR= > WERROR= > >> Is this a well known issue and FreeBSD isn't building correctly at the >> moment or did I miss something (not mentioned on the wiki's page)? >> >> >> >> clang: warning: argument unused during compilation: >> '-finhibit-size-directive' >> clang: warning: argument unused during compilation: '-fno-toplevel-reorder' >> sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtbegin.o >> /usr/obj/usr/src/lib32/usr/lib32/crtbegin.o >> sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtend.o >> /usr/obj/usr/src/lib32/usr/lib32/crtend.o >> sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtbeginT.o >> /usr/obj/usr/src/lib32/usr/lib32/crtbeginT.o >> sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtbegin.So >> /usr/obj/usr/src/lib32/usr/lib32/crtbeginS.o >> sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtend.So >> /usr/obj/usr/src/lib32/usr/lib32/crtendS.o >> ===> lib/csu/i386-elf (obj,depend,all,install) >> rm -f .depend >> CC='clang' mkdep -f .depend -a -I/usr/src/lib/csu/i386-elf/../common >> -I/usr/src/lib/csu/i386-elf/../../libc/include >> /usr/src/lib/csu/i386-elf/crti.S /usr/src/lib/csu/i386-elf/crtn.S >> clang -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common >> -I/usr/src/lib/csu/i386-elf/../../libc/include -std=gnu99 -Wsystem-headers >> -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes >> -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual >> -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align >> -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls >> -Wold-style-definition -Wno-pointer-sign -c >> /usr/src/lib/csu/i386-elf/crti.S >> clang -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common >> -I/usr/src/lib/csu/i386-elf/../../libc/include -std=gnu99 -Wsystem-headers >> -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes >> -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual >> -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align >> -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls >> -Wold-style-definition -Wno-pointer-sign -c >> /usr/src/lib/csu/i386-elf/crtn.S >> clang -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common >> -I/usr/src/lib/csu/i386-elf/../../libc/include -std=gnu99 -Wsystem-headers >> -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes >> -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual >> -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align >> -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls >> -Wold-style-definition -Wno-pointer-sign -DGCRT -S -o gcrt1_c.s >> /usr/src/lib/csu/i386-elf/crt1_c.c >> sed -i "" -e '/\.note\.ABI-tag/s/progbits/note/' gcrt1_c.s >> clang -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common >> -I/usr/src/lib/csu/i386-elf/../../libc/include -std=gnu99 -Wsystem-headers >> -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes >> -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual >> -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align >> -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls >> -Wold-style-definition -Wno-pointer-sign -c -o gcrt1_c.o gcrt1_c.s >> clang: warning: argument unused during compilation: '-I >> /usr/src/lib/csu/i386-elf/../common' >> clang: warning: argument unused during compilation: '-I >> /usr/src/lib/csu/i386-elf/../../libc/include' >> clang: warning: argument unused during compilation: '-std=gnu99' >> clang: warning: argument unused during compilation: '-Wsystem-headers' >> clang: warning: argument unused during compilation: '-Wall' >> clang: warning: argument unused during compilation: '-Wno-format-y2k' >> clang: warning: argument unused during compilation: '-W' >> clang: warning: argument unused during compilation: '-Wno-unused-parameter' >> clang: warning: argument unused during compilation: '-Wstrict-prototypes' >> clang: warning: argument unused during compilation: '-Wmissing-prototypes' >> clang: warning: argument unused during compilation: '-Wpointer-arith' >> clang: warning: argument unused during compilation: '-Wreturn-type' >> clang: warning: argument unused during compilation: '-Wcast-qual' >> clang: warning: argument unused during compilation: '-Wwrite-strings' >> clang: warning: argument unused during compilation: '-Wswitch' >> clang: warning: argument unused during compilation: '-Wshadow' >> clang: warning: argument unused during compilation: '-Wunused-parameter' >> clang: warning: argument unused during compilation: '-Wcast-align' >> clang: warning: argument unused during compilation: '-Wchar-subscripts' >> clang: warning: argument unused during compilation: '-Winline' >> clang: warning: argument unused during compilation: '-Wnested-externs' >> clang: warning: argument unused during compilation: '-Wredundant-decls' >> clang: warning: argument unused during compilation: '-Wold-style-definition' >> clang: warning: argument unused during compilation: '-Wno-pointer-sign' >> clang -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common >> -I/usr/src/lib/csu/i386-elf/../../libc/include -std=gnu99 -Wsystem-headers >> -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes >> -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual >> -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align >> -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls >> -Wold-style-definition -Wno-pointer-sign -c >> /usr/src/lib/csu/i386-elf/crt1_s.S >> ld -m elf_i386_fbsd -Y P,/usr/obj/usr/src/lib32/usr/lib32 -o gcrt1.o -r >> crt1_s.o gcrt1_c.o >> ld: Relocatable linking with relocations from format elf64-x86-64-freebsd >> (crt1_s.o) to format elf32-i386-freebsd (gcrt1.o) is not supported >> *** Error code 1 >> >> Stop in /usr/src/lib/csu/i386-elf. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 >> _______________________________________________ >> 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" >> > > > yes, I followed exactly the instructions shown in the wiki. From owner-freebsd-current@FreeBSD.ORG Mon May 2 13:00:43 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 401511065672 for ; Mon, 2 May 2011 13:00:43 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id B37F78FC1A for ; Mon, 2 May 2011 13:00:42 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 7782D25D3899 for ; Mon, 2 May 2011 13:00:41 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id CF20915991D0 for ; Mon, 2 May 2011 13:00:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id vpSdd+SIXARw for ; Mon, 2 May 2011 13:00:39 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 32C3815991D9 for ; Mon, 2 May 2011 13:00:39 +0000 (UTC) Date: Mon, 2 May 2011 13:00:39 +0000 (UTC) From: "Bjoern A. Zeeb" To: freebsd-current@freebsd.org Message-ID: X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: panic: ino 0xfffffe0073403300(0xC8201) 22668877, 22669287 != 22689623 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 13:00:43 -0000 Hi, I got the following panic while in the progress of updating my machine from mid-February (19th) HEAD to now. Not sure, could be fixed in the mean time by Jeff's, Kirk's and Kib's commits since? panic: ino 0xfffffe0073403300(0xC8201) 22668877, 22669287 != 22689623 It's a UFS+J on a non-default block size of 4k. I don't have neither a dump and nor much debugging information, which apart from the backtrace might be useless... panic: ino 0xfffffe0073403300(0xC8201) 22668877, 22669287 != 22689623 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x187 softdep_disk_io_initiation() at softdep_disk_io_initiation+0xd65 ffs_geom_strategy() at ffs_geom_strategy+0x17f bufwrite() at bufwrite+0x13d vfs_bio_awrite() at vfs_bio_awrite+0x69 vop_stdfsync() at vop_stdfsync+0x1d0 devfs_fsync() at devfs_fsync+0x98 VOP_FSYNC_APV() at VOP_FSYNC_APV+0x4a sync_vnode() at sync_vnode+0x15e sched_sync() at sched_sync+0x1d1 fork_exit() at fork_exit+0x11b fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff812068ad00, rbp = 0 --- db> show lockedvn Locked vnodes 0xfffffe00108eb780: tag devfs, type VCHR usecount 1, writecount 0, refcount 422 mountedhere 0xfffffe0006e0b200 flags () v_object 0xfffffe001093f870 ref 0 pages 14770 lock type devfs: EXCL by thread 0xfffffe0006b9d460 (pid 21) dev ada0....p3 db> show lockedbufs buf at 0xffffff80f3f09f60 b_flags = 0xa0020024 b_error = 0, b_bufsize = 16384, b_bcount = 16384, b_resid = 0 b_bufobj = (0xfffffe00108eb8a0), b_data = 0xffffff80f87c8000, b_blkno = 386355424, b_dep = 0 b_npages = 4, pages(OBJ, IDX, PA): (0xfffffe001093f870, 0x2e0ea1c, 0x3ed3e000),(0xfffffe001093f870, 0x2e0ea1d, 0x3ed3f000),(0xfffffe001093f870, 0x2e0ea1e, 0x13aaf0000),(0xfffffe001093f870, 0x2e0ea1f, 0x13aaf1000) db> show allpcpu Current CPU: 0 cpuid = 0 dynamic pcpu = 0x23e8100 curthread = 0xfffffe0006b9d460: pid 21 "syncer" curpcb = 0xffffff812068ad10 fpcurthread = none idlethread = 0xfffffe0004a82460: tid 100006 "idle: cpu0" curpmap = 0xffffffff80c644b0 tssp = 0xffffffff80cbc9e0 commontssp = 0xffffffff80cbc9e0 rsp0 = 0xffffff812068ad10 gs32p = 0xffffffff80cbb838 ldt = 0xffffffff80cbb878 tss = 0xffffffff80cbb868 cpuid = 1 dynamic pcpu = 0xffffff807f3d5100 curthread = 0xfffffe0004a828c0: pid 11 "idle: cpu1" curpcb = 0xffffff800003dd10 fpcurthread = none idlethread = 0xfffffe0004a828c0: tid 100005 "idle: cpu1" curpmap = 0xffffffff80c644b0 tssp = 0xffffffff80cbca48 commontssp = 0xffffffff80cbca48 rsp0 = 0xffffff800003dd10 gs32p = 0xffffffff80cbb8a0 ldt = 0xffffffff80cbb8e0 tss = 0xffffffff80cbb8d0 cpuid = 2 dynamic pcpu = 0xffffff807f3dc100 curthread = 0xfffffe0004a78000: pid 11 "idle: cpu2" curpcb = 0xffffff8000038d10 fpcurthread = none idlethread = 0xfffffe0004a78000: tid 100004 "idle: cpu2" curpmap = 0xffffffff80c644b0 tssp = 0xffffffff80cbcab0 commontssp = 0xffffffff80cbcab0 rsp0 = 0xffffff8000038d10 gs32p = 0xffffffff80cbb908 ldt = 0xffffffff80cbb948 tss = 0xffffffff80cbb938 cpuid = 3 dynamic pcpu = 0xffffff807f3e3100 curthread = 0xfffffe0004a8c460: pid 3 "g_up" curpcb = 0xffffff800006ad10 fpcurthread = none idlethread = 0xfffffe0004a78460: tid 100003 "idle: cpu3" curpmap = 0xffffffff80c644b0 tssp = 0xffffffff80cbcb18 commontssp = 0xffffffff80cbcb18 rsp0 = 0xffffff800006ad10 gs32p = 0xffffffff80cbb970 ldt = 0xffffffff80cbb9b0 tss = 0xffffffff80cbb9a0 -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-current@FreeBSD.ORG Mon May 2 13:37:59 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C19B106566B; Mon, 2 May 2011 13:37:59 +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 492728FC15; Mon, 2 May 2011 13:37:59 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p42DbwUC080626; Mon, 2 May 2011 09:37:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p42DbwDb080513; Mon, 2 May 2011 13:37:58 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 May 2011 13:37:58 GMT Message-Id: <201105021337.p42DbwDb080513@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: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 13:37:59 -0000 TB --- 2011-05-02 10:50:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-02 10:50:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-05-02 10:50:00 - cleaning the object tree TB --- 2011-05-02 10:50:19 - cvsupping the source tree TB --- 2011-05-02 10:50:19 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-05-02 10:50:45 - building world TB --- 2011-05-02 10:50:45 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-02 10:50:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-02 10:50:45 - TARGET=i386 TB --- 2011-05-02 10:50:45 - TARGET_ARCH=i386 TB --- 2011-05-02 10:50:45 - TZ=UTC TB --- 2011-05-02 10:50:45 - __MAKE_CONF=/dev/null TB --- 2011-05-02 10:50:45 - cd /src TB --- 2011-05-02 10:50:45 - /usr/bin/make -B buildworld >>> World build started on Mon May 2 10:50:46 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon May 2 12:43:31 UTC 2011 TB --- 2011-05-02 12:43:31 - generating LINT kernel config TB --- 2011-05-02 12:43:31 - cd /src/sys/i386/conf TB --- 2011-05-02 12:43:31 - /usr/bin/make -B LINT TB --- 2011-05-02 12:43:31 - building LINT kernel TB --- 2011-05-02 12:43:31 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-02 12:43:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-02 12:43:31 - TARGET=i386 TB --- 2011-05-02 12:43:31 - TARGET_ARCH=i386 TB --- 2011-05-02 12:43:31 - TZ=UTC TB --- 2011-05-02 12:43:31 - __MAKE_CONF=/dev/null TB --- 2011-05-02 12:43:31 - cd /src TB --- 2011-05-02 12:43:31 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon May 2 12:43:31 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Mon May 2 13:13:12 UTC 2011 TB --- 2011-05-02 13:13:12 - cd /src/sys/i386/conf TB --- 2011-05-02 13:13:12 - /usr/sbin/config -m GENERIC TB --- 2011-05-02 13:13:12 - building GENERIC kernel TB --- 2011-05-02 13:13:12 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-02 13:13:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-02 13:13:12 - TARGET=i386 TB --- 2011-05-02 13:13:12 - TARGET_ARCH=i386 TB --- 2011-05-02 13:13:12 - TZ=UTC TB --- 2011-05-02 13:13:12 - __MAKE_CONF=/dev/null TB --- 2011-05-02 13:13:12 - cd /src TB --- 2011-05-02 13:13:12 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon May 2 13:13:12 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Mon May 2 13:35:46 UTC 2011 TB --- 2011-05-02 13:35:46 - cd /src/sys/i386/conf TB --- 2011-05-02 13:35:46 - /usr/sbin/config -m PAE TB --- 2011-05-02 13:35:46 - building PAE kernel TB --- 2011-05-02 13:35:46 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-02 13:35:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-02 13:35:46 - TARGET=i386 TB --- 2011-05-02 13:35:46 - TARGET_ARCH=i386 TB --- 2011-05-02 13:35:46 - TZ=UTC TB --- 2011-05-02 13:35:46 - __MAKE_CONF=/dev/null TB --- 2011-05-02 13:35:46 - cd /src TB --- 2011-05-02 13:35:46 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Mon May 2 13:35:46 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/lge/if_lge.c cc -c -O -pipe -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/malo/if_malo.c cc -c -O -pipe -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/malo/if_malohal.c cc -c -O -pipe -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/malo/if_malo_pci.c cc1: warnings being treated as errors /src/sys/dev/malo/if_malo_pci.c: In function 'malo_pci_attach': /src/sys/dev/malo/if_malo_pci.c:232: warning: large integer implicitly truncated to unsigned type /src/sys/dev/malo/if_malo_pci.c:232: warning: large integer implicitly truncated to unsigned type *** Error code 1 Stop in /obj/i386.i386/src/sys/PAE. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-05-02 13:37:57 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-05-02 13:37:57 - ERROR: failed to build PAE kernel TB --- 2011-05-02 13:37:57 - 8093.86 user 1338.57 system 10076.93 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Mon May 2 16:19:25 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5D84106566B; Mon, 2 May 2011 16:19:25 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 64D678FC0A; Mon, 2 May 2011 16:19:24 +0000 (UTC) Received: by vws18 with SMTP id 18so5759088vws.13 for ; Mon, 02 May 2011 09:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vNSl1WipaBpWUfxOLWA1kB5iOSA7kUs6TTsxC9KwTes=; b=aXhD52gyG5C7IUwr2sdfysn/8xMYYM68zcNRTxJFdaCmfHKuThyzZKyDXvPFKyUoe1 Z2E0D/zbU1eg/EbQkFbetZenadDAI358ucwBbfKt96suECRW2LHRWd8cVi+NJqpYoJEx 5iqDiS9iAE6wYfxBitRKo/oYvPTPHXMXhsWjw= 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=t8WEMSSwAZKSj4DU/xhq+m1pm9fwdWq/SRG91DwsTnso3VtrZwDToE0YI+nCJWc7lz zThGFBSKgDXVHlTNm/cduIuDgtgdDQIs/6uR3PUOfwIXtzOHEO4yChbqx2KuiPUfi5AO DjFL8O29p6opRACck7IFLolCASO520MfB9JpA= MIME-Version: 1.0 Received: by 10.220.112.138 with SMTP id w10mr1710906vcp.46.1304351670757; Mon, 02 May 2011 08:54:30 -0700 (PDT) Received: by 10.220.199.130 with HTTP; Mon, 2 May 2011 08:54:30 -0700 (PDT) In-Reply-To: <201105020748.p427mBRP004105@freebsd-current.sentex.ca> References: <201105020748.p427mBRP004105@freebsd-current.sentex.ca> Date: Mon, 2 May 2011 08:54:30 -0700 Message-ID: From: Garrett Cooper To: FreeBSD Tinderbox Content-Type: multipart/mixed; boundary=0016e6471744ff6a8804a24d09fa Cc: freebsd-hackers@freebsd.org, current@freebsd.org, i386@freebsd.org Subject: Re: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 16:19:26 -0000 --0016e6471744ff6a8804a24d09fa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, May 2, 2011 at 12:48 AM, FreeBSD Tinderbox wrote: [...] > cc -c -O -pipe =A0-std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs = -Wstrict-prototypes =A0-Wmissing-prototypes -Wpointer-arith -Winline -Wcast= -qual =A0-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc =A0-I. -I/= src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -inc= lude opt_global.h -fno-common -finline-limit=3D8000 --param inline-unit-gro= wth=3D100 --param large-function-growth=3D1000 =A0-mno-align-long-strings -= mpreferred-stack-boundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-s= se3 -msoft-float -ffreestanding -fstack-protector -Werror =A0/src/sys/dev/l= ge/if_lge.c > cc -c -O -pipe =A0-std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs = -Wstrict-prototypes =A0-Wmissing-prototypes -Wpointer-arith -Winline -Wcast= -qual =A0-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc =A0-I. -I/= src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -inc= lude opt_global.h -fno-common -finline-limit=3D8000 --param inline-unit-gro= wth=3D100 --param large-function-growth=3D1000 =A0-mno-align-long-strings -= mpreferred-stack-boundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-s= se3 -msoft-float -ffreestanding -fstack-protector -Werror =A0/src/sys/dev/m= alo/if_malo.c > cc -c -O -pipe =A0-std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs = -Wstrict-prototypes =A0-Wmissing-prototypes -Wpointer-arith -Winline -Wcast= -qual =A0-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc =A0-I. -I/= src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -inc= lude opt_global.h -fno-common -finline-limit=3D8000 --param inline-unit-gro= wth=3D100 --param large-function-growth=3D1000 =A0-mno-align-long-strings -= mpreferred-stack-boundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-s= se3 -msoft-float -ffreestanding -fstack-protector -Werror =A0/src/sys/dev/m= alo/if_malohal.c > cc -c -O -pipe =A0-std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs = -Wstrict-prototypes =A0-Wmissing-prototypes -Wpointer-arith -Winline -Wcast= -qual =A0-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc =A0-I. -I/= src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -inc= lude opt_global.h -fno-common -finline-limit=3D8000 --param inline-unit-gro= wth=3D100 --param large-function-growth=3D1000 =A0-mno-align-long-strings -= mpreferred-stack-boundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-s= se3 -msoft-float -ffreestanding -fstack-protector -Werror =A0/src/sys/dev/m= alo/if_malo_pci.c > cc1: warnings being treated as errors > /src/sys/dev/malo/if_malo_pci.c: In function 'malo_pci_attach': > /src/sys/dev/malo/if_malo_pci.c:232: warning: large integer implicitly tr= uncated to unsigned type > /src/sys/dev/malo/if_malo_pci.c:232: warning: large integer implicitly tr= uncated to unsigned type > *** Error code 1 > > Stop in /obj/i386.i386/src/sys/PAE. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. Tinderbox has been whining about malo for the last day or so on i386 because of this issue. Could someone please commit the following patch to fix it? It's correct according to the printf(3) manpage combined with the fields in the malo_hal structure. FWIW I'm a bit confused too because it's listed in the WITHOUT_MODULES group for several i386 kernel compiles based on my looking at the make universe output, but it's still barfing on the module with tinderbox (and not with my local make universe), but it the results might be tainted by my environment somehow. Thanks! -Garrett --0016e6471744ff6a8804a24d09fa Content-Type: text/x-patch; charset=US-ASCII; name="fix-sys-dev-if-malo-format-string.patch" Content-Disposition: attachment; filename="fix-sys-dev-if-malo-format-string.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gn7bwhqy1 SW5kZXg6IHN5cy9kZXYvbWFsby9pZl9tYWxvLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2Rldi9tYWxv L2lmX21hbG8uYwkocmV2aXNpb24gMjIxMjE5KQorKysgc3lzL2Rldi9tYWxvL2lmX21hbG8uYwko d29ya2luZyBjb3B5KQpAQCAtMjI0LDkgKzIyNCw5IEBACiAJfQogCiAJRFBSSU5URihzYywgTUFM T19ERUJVR19GVywKLQkgICAgIm1hbG9faGFsX2dldGh3c3BlY3M6IGh3dmVyc2lvbiAweCV4IGhv c3RpZiAweCV4IgotCSAgICAibWF4bnVtX3djYiAweCV4IG1heG51bV9tY2FkZHIgMHgleCBtYXhu dW1fdHhfd2NiIDB4JXgiCi0JICAgICJyZWdpb25jb2RlIDB4JXggbnVtX2FudGVubmEgMHgleCBm d19yZWxlYXNlbnVtIDB4JXgiCisJICAgICJtYWxvX2hhbF9nZXRod3NwZWNzOiBod3ZlcnNpb24g MHglaGh4IGhvc3RpZiAweCVoaHgiCisJICAgICJtYXhudW1fd2NiIDB4JWh4IG1heG51bV9tY2Fk ZHIgMHglaHggbWF4bnVtX3R4X3djYiAweCVoeCIKKwkgICAgInJlZ2lvbmNvZGUgMHglaHggbnVt X2FudGVubmEgMHglaHggZndfcmVsZWFzZW51bSAweCV4IgogCSAgICAid2NiYmFzZTAgMHgleCBy eGRlc2NfcmVhZCAweCV4IHJ4ZGVzY193cml0ZSAweCV4IgogCSAgICAidWxfZndfYXdha2Vjb29r aWUgMHgleCB3WzRdID0gJXggJXggJXggJXgiLAogCSAgICBzYy0+bWFsb19od3NwZWNzLmh3dmVy c2lvbiwKQEAgLTE5MzEsNyArMTkzMSw4IEBACiB7CiAJc3RydWN0IGlmbmV0ICppZnAgPSBzYy0+ bWFsb19pZnA7CiAKLQlpZl9wcmludGYoaWZwLCAidmVyc2lvbnMgW2h3ICVkIGZ3ICVkLiVkLiVk LiVkXSAocmVnaW9uY29kZSAlZClcbiIsCisJaWZfcHJpbnRmKGlmcCwKKwkJInZlcnNpb25zIFto dyAweCVoaHggZncgJWQuJWQuJWQuJWRdIChyZWdpb25jb2RlIDB4JWh4KVxuIiwKIAkJc2MtPm1h bG9faHdzcGVjcy5od3ZlcnNpb24sCiAJCShzYy0+bWFsb19od3NwZWNzLmZ3X3JlbGVhc2VudW0g Pj4gMjQpICYgMHhmZiwKIAkJKHNjLT5tYWxvX2h3c3BlY3MuZndfcmVsZWFzZW51bSA+PiAxNikg JiAweGZmLAo= --0016e6471744ff6a8804a24d09fa-- From owner-freebsd-current@FreeBSD.ORG Mon May 2 19:26:32 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAA5B1065676; Mon, 2 May 2011 19:26:32 +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 8A98F8FC08; Mon, 2 May 2011 19:26:32 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p42JQV9o048954; Mon, 2 May 2011 15:26:31 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p42JQVAs048927; Mon, 2 May 2011 19:26:31 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 May 2011 19:26:31 GMT Message-Id: <201105021926.p42JQVAs048927@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: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 19:26:32 -0000 TB --- 2011-05-02 16:40:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-02 16:40:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-05-02 16:40:00 - cleaning the object tree TB --- 2011-05-02 16:40:21 - cvsupping the source tree TB --- 2011-05-02 16:40:21 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-05-02 16:40:46 - building world TB --- 2011-05-02 16:40:46 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-02 16:40:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-02 16:40:46 - TARGET=i386 TB --- 2011-05-02 16:40:46 - TARGET_ARCH=i386 TB --- 2011-05-02 16:40:46 - TZ=UTC TB --- 2011-05-02 16:40:46 - __MAKE_CONF=/dev/null TB --- 2011-05-02 16:40:46 - cd /src TB --- 2011-05-02 16:40:46 - /usr/bin/make -B buildworld >>> World build started on Mon May 2 16:40:47 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon May 2 18:33:55 UTC 2011 TB --- 2011-05-02 18:33:55 - generating LINT kernel config TB --- 2011-05-02 18:33:55 - cd /src/sys/i386/conf TB --- 2011-05-02 18:33:55 - /usr/bin/make -B LINT TB --- 2011-05-02 18:33:55 - building LINT kernel TB --- 2011-05-02 18:33:55 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-02 18:33:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-02 18:33:55 - TARGET=i386 TB --- 2011-05-02 18:33:55 - TARGET_ARCH=i386 TB --- 2011-05-02 18:33:55 - TZ=UTC TB --- 2011-05-02 18:33:55 - __MAKE_CONF=/dev/null TB --- 2011-05-02 18:33:55 - cd /src TB --- 2011-05-02 18:33:55 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon May 2 18:33:55 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Mon May 2 19:02:28 UTC 2011 TB --- 2011-05-02 19:02:28 - cd /src/sys/i386/conf TB --- 2011-05-02 19:02:28 - /usr/sbin/config -m GENERIC TB --- 2011-05-02 19:02:28 - building GENERIC kernel TB --- 2011-05-02 19:02:28 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-02 19:02:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-02 19:02:28 - TARGET=i386 TB --- 2011-05-02 19:02:28 - TARGET_ARCH=i386 TB --- 2011-05-02 19:02:28 - TZ=UTC TB --- 2011-05-02 19:02:28 - __MAKE_CONF=/dev/null TB --- 2011-05-02 19:02:28 - cd /src TB --- 2011-05-02 19:02:28 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon May 2 19:02:28 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Mon May 2 19:24:19 UTC 2011 TB --- 2011-05-02 19:24:19 - cd /src/sys/i386/conf TB --- 2011-05-02 19:24:19 - /usr/sbin/config -m PAE TB --- 2011-05-02 19:24:19 - building PAE kernel TB --- 2011-05-02 19:24:19 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-02 19:24:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-02 19:24:19 - TARGET=i386 TB --- 2011-05-02 19:24:19 - TARGET_ARCH=i386 TB --- 2011-05-02 19:24:19 - TZ=UTC TB --- 2011-05-02 19:24:19 - __MAKE_CONF=/dev/null TB --- 2011-05-02 19:24:19 - cd /src TB --- 2011-05-02 19:24:19 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Mon May 2 19:24:20 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/lge/if_lge.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/malo/if_malo.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/malo/if_malohal.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/malo/if_malo_pci.c cc1: warnings being treated as errors /src/sys/dev/malo/if_malo_pci.c: In function 'malo_pci_attach': /src/sys/dev/malo/if_malo_pci.c:232: warning: large integer implicitly truncated to unsigned type /src/sys/dev/malo/if_malo_pci.c:232: warning: large integer implicitly truncated to unsigned type *** Error code 1 Stop in /obj/i386.i386/src/sys/PAE. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-05-02 19:26:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-05-02 19:26:30 - ERROR: failed to build PAE kernel TB --- 2011-05-02 19:26:30 - 8034.06 user 1330.42 system 9990.43 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Tue May 3 02:30:00 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09F5C1065673 for ; Tue, 3 May 2011 02:30:00 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 60EB68FC0A for ; Tue, 3 May 2011 02:29:59 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 3084160E5 for ; Mon, 2 May 2011 22:29:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1304389798; bh=yX9pn8jDAPt+6bPNdrrSuKDEm6Q/6vaqPYy4VnsLI8M=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=WW6pWQQi1+QASp0/dc7Hbj/FfR0qMDBZ3nHJUYfxrrJ5+xbRicwd6WOLhpW6dO7HS FDdAbq14mBrkSNVsM98ilLCq4xn+ia5mnRnC3eUSNHUxPhrhME4Lya9JfksAeOw DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=HmgolPw7z39i5N8cMMBCrvJC4I9It/T++EnTlxTlPsy6wvT4C3pIqiFS7Q0ssPEhO vS0bxiPuaUDC1UMO3BtrEWKVeD2umBp1hXYJI/dMmv1YuRx4MrfNEzey+sdgcEC Message-ID: <4DBF68A4.6050405@protected-networks.net> Date: Mon, 02 May 2011 22:29:56 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: current@FreeBSD.org X-Enigmail-Version: 1.1.2 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: cardbus memory allocation problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 02:30:00 -0000 I've stared at this for a (long) while but haven't come to any reasonable conclusion as to why it does what it does or how to fix it :-( Specifically, the BIOS in this machine doesn't set up a memory window for the cardbus controller nor does it properly configure the PCI bridge to route to the correct buses. BSD tries but allocates memory from the wrong space. My question is - how to get PCI-cardbus bridge to allocate memory inside the window of the parent PCI-PCI bridge? .. the bus tree looks like .. imb@toshi:/home/imb> sudo lspci -t -[0000:00]-+-00.0 +-02.0 +-02.1 +-1b.0 +-1c.0-[02]-- +-1c.1-[03-04]-- +-1c.2-[05-06]----00.0 +-1d.0 +-1d.1 +-1d.2 +-1d.3 +-1d.7 +-1e.0-[07]--+-06.0 | +-06.1 | +-06.2 | +-06.3 | \-08.0 +-1f.0 +-1f.2 \-1f.3 I've annotated the verbose dmesg below to highlight the issues .. pcib4: at device 30.0 on pci0 pcib4: domain 0 pcib4: secondary bus 7 pcib4: subordinate bus 7 *** subordinate bus needs to be '9' so as to include both '8' & '9' *** for the PCI-cardbus bridge pcib4: I/O decode 0x4000-0x4fff pcib4: memory decode 0xf0900000-0xf09fffff *** this memory widow is what I expected all children to allocate from pcib4: no prefetched decode pcib4: Subtractively decoded bridge. pci7: on pcib4 pci7: domain=0, physical bus=7 found-> vendor=0x104c, dev=0x8039, revid=0x00 domain=0, bus=7, slot=6, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0000, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x40 (16000 ns), maxlat=0x03 (750 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0, size 12, memory disabled *** silly uninitialized value here outside of the expected window found-> vendor=0x104c, dev=0x803a, revid=0x00 domain=0, bus=7, slot=6, func=1 class=0c-00-10, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0210, cachelnsz=4 (dwords) lattimer=0x80 (3840 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) intpin=b, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf0906000, size 11, enabled *** everything else under the pcib4 bridge is in the right window pcib4: requested memory range 0xf0906000-0xf09067ff: good map[14]: type Memory, range 32, base 0xf0900000, size 14, enabled pcib4: requested memory range 0xf0900000-0xf0903fff: good pcib4: matched entry for 7.6.INTB pcib4: slot 6 INTB hardwired to IRQ 17 found-> vendor=0x104c, dev=0x803b, revid=0x00 domain=0, bus=7, slot=6, func=2 class=01-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0210, cachelnsz=4 (dwords) lattimer=0x80 (3840 ns), mingnt=0x07 (1750 ns), maxlat=0x04 (1000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf0904000, size 12, enabled pcib4: requested memory range 0xf0904000-0xf0904fff: good pcib4: matched entry for 7.6.INTA pcib4: slot 6 INTA hardwired to IRQ 18 found-> vendor=0x104c, dev=0x803c, revid=0x00 domain=0, bus=7, slot=6, func=3 class=08-05-01, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0210, cachelnsz=4 (dwords) lattimer=0x80 (3840 ns), mingnt=0x07 (1750 ns), maxlat=0x04 (1000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf0906800, size 8, enabled pcib4: requested memory range 0xf0906800-0xf09068ff: good pcib4: matched entry for 7.6.INTA pcib4: slot 6 INTA hardwired to IRQ 18 found-> vendor=0x8086, dev=0x1092, revid=0x02 domain=0, bus=7, slot=8, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x0290, cachelnsz=16 (dwords) lattimer=0x42 (1980 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf0905000, size 12, enabled pcib4: requested memory range 0xf0905000-0xf0905fff: good map[14]: type I/O Port, range 32, base 0x4000, size 6, enabled pcib4: requested I/O range 0x4000-0x403f: in range pcib4: matched entry for 7.8.INTA pcib4: slot 8 INTA hardwired to IRQ 20 cbb0: at device 6.0 on pci7 pcib4: cbb0 requested memory range 0x0-0xffffffff: good *** what appears to be a "wildcard" alloc request cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xbf670000 *** but which isn't constrained to be within the parent bridge's space cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pcib4: matched entry for 7.6.INTA pcib4: slot 6 INTA hardwired to IRQ 18 cbb0: PCI Configuration space: 0x00: 0x8039104c 0x02100007 0x06070000 0x00824000 0x10: 0xbf670000 0x020000a0 0x20090807 0xfffff000 ^^^^^^^^^^ ^ ^ ^ | | + primary bus | + secondary bus + subordinate bus 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x07400112 0x40: 0xff101179 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x48409060 0x02830019 0x000f0000 0x01a01b22 0x90: 0x606600c0 0x00000000 0x00000000 0x00000000 0xa0: 0xfe120001 0x00c00000 0x00000000 0x00000000 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x44072b31 0x8d019449 0x00000000 0x00000000 'lspci' reports the following nonsense configuration .. 07:06.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller Subsystem: Toshiba America Info Systems Device ff10 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset+ 16bInt- PostWrite+ 16-bit legacy interface ports at 0001 Any hints as to where to look to work around this would be appreciated, imb From owner-freebsd-current@FreeBSD.ORG Tue May 3 08:58:34 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26214106564A for ; Tue, 3 May 2011 08:58:34 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 017768FC24 for ; Tue, 3 May 2011 08:58:33 +0000 (UTC) Received: by pzk27 with SMTP id 27so4474594pzk.13 for ; Tue, 03 May 2011 01:58:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.57.105 with SMTP id h9mr906060pbq.206.1304413113422; Tue, 03 May 2011 01:58:33 -0700 (PDT) Received: by 10.68.40.4 with HTTP; Tue, 3 May 2011 01:58:33 -0700 (PDT) In-Reply-To: References: <4D94A354.9080903@sentex.net> Date: Tue, 3 May 2011 10:58:33 +0200 Message-ID: From: Olivier Smedts To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD current mailing list , Mike Tancsa Subject: Re: problems with em(4) since update to driver 7.2.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 08:58:34 -0000 Hello, 2011/4/27 Jack Vogel : > If you get "cannot setup receive structures" you cannot go on and try to > use the thing :) It means you have inadequate mbuf clusters to setup > your receive side, you simply have to increase it and reload the driver. I tried increasing kern.ipc.nmbjumbo* (is it what you suggested ?). Values doubled : kern.ipc.nmbjumbo16: 6400 kern.ipc.nmbjumbo9: 12800 kern.ipc.nmbjumbop: 25600 And unloaded / reloaded the kernel module. Still no luck, same problem, on latest 9-CURRENT (r221363). %sysctl -a | grep mbuf dev.em.0.mbuf_alloc_fail: 0 What can I do ? Do you want a dump of "sysctl dev.em" with old and new if_em module ? Thanks >> >> Here is what gives me netstat -m with my new 9-CURRENT kernel but with >> old (working, after some time of computer use) if_em.ko : >> 1027/3458/4485 mbufs in use (current/cache/total) >> 1024/2066/3090/25600 mbuf clusters in use (current/cache/total/max) >> 1024/1792 mbuf+clusters out of packet secondary zone in use >> (current/cache) >> 0/367/367/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) >> 2304K/6464K/8769K 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 >> >> And here is the output with the new (non-working) if_em.ko : >> 1029/3456/4485 mbufs in use (current/cache/total) >> 1023/2067/3090/25600 mbuf clusters in use (current/cache/total/max) >> 1023/1793 mbuf+clusters out of packet secondary zone in use >> (current/cache) >> 0/367/367/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) >> 2303K/6466K/8769K 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 >> >> I've got the "em0: Could not setup receive structures" messages with >> the new if_em.ko even in single user mode. No network connectivity. I >> tried removing all other network-related modules (vboxnet, ipfw...) >> and still have this problem (again, even when booting in single-user >> mode). >> My network card is "em0@pci0:0:25:0: =A0 =A0 =A0 =A0class=3D0x020000 >> card=3D0x304b103c chip=3D0x10ef8086 rev=3D0x05 hdr=3D0x00". I'm using a >> stripped-down GENERIC amd64 kernel (no network, no scsi, no raid...), >> a nearly empty sysctl.conf and loader.conf (except module loading). >> >> I saw at the time of the commit that an MFC to 8-STABLE was planned, >> but I don't think it should happen so soon. Given that my network >> adapter was previously working well before the em driver update, can't >> this be considerd a serious regression ? >> >> Thanks, >> Olivier --=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-current@FreeBSD.ORG Tue May 3 11:43:19 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EFF4106564A for ; Tue, 3 May 2011 11:43:19 +0000 (UTC) (envelope-from edwinlculp@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id C64BD8FC1C for ; Tue, 3 May 2011 11:43:18 +0000 (UTC) Received: by vws18 with SMTP id 18so6512416vws.13 for ; Tue, 03 May 2011 04:43:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=j24kJPibVyn4r2o5rcYCWfFQ5XhagNgdazptKF/QEwg=; b=Ln+TxxxUqMoMzEdzvKq9MSkY3coyoo4vbXUo03H8HuC+tkMWosMdDU0oyAHjOSfL+R hD7CB0FPoiA8cIOcwj5DZPtEt+H/XwqJFVOkzsxMhNmnqO1TJy9YQ8iR3BovJnG6kgbp 1g9FN2IL8TC3te7PDEg1c8IXwLEGD48LUMW7k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=mHVZGMEhMzoCp4cAFOcELcPvmQPD+09SL58xurqtd172kQTb+waiGGObIZmJRllNod MTLMRQKBtYK2b+Q2/cxtFGWj093aX/14cmRo5lhiC/QAFKVXrLn8JMZj30qdaYLoQpzj eNeRMgV9QW+YohR0DZQ7ljVEaDRYo1zVo71sM= MIME-Version: 1.0 Received: by 10.52.95.138 with SMTP id dk10mr1396569vdb.277.1304421394156; Tue, 03 May 2011 04:16:34 -0700 (PDT) Received: by 10.52.107.5 with HTTP; Tue, 3 May 2011 04:16:34 -0700 (PDT) Date: Tue, 3 May 2011 06:16:34 -0500 Message-ID: From: "Edwin L. Culp W." To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 Subject: I am very confused and would appreciate some help on device renameing or on renumbering on current fstab. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 11:43:19 -0000 I have two disks on this old machine that I have keep current sin FreeBSD 6 IIRC as preparation for all the new goodies but this really bit me in the morning with a generic kernel and had a heck of a time getting it up. I have a new kernel with the new options. options ATA_CAM device ahci device mvs device siis This morning was such a shock that I am tempted to go back to the old kernel config that I understand still works but gonna try to bite the bullit. My fstab that I assume is still needed, is as before, although I had changed ad4xx to ada4xx (etc) that I found was incorrect the HARD way after trying to reboot; /dev/ad4s1b none swap sw 0 0 /dev/ad4s1a / ufs rw 1 1 /dev/ad4s2g /backup ufs rw 2 2 /dev/ad4s1g /home ufs rw 2 2 /dev/ad4s2f /release ufs rw 2 2 /dev/ad4s2d /tmp ufs rw 2 2 /dev/ad4s1e /usr ufs rw 2 2 /dev/ad4s1h /usr/local ufs rw 2 2 /dev/ad4s1f /var ufs rw 2 2 /dev/ad4s2e /var/tmp ufs rw 2 2 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 /dev/acd1 /cdrom1 cd9660 ro,noauto 0 0 /dev/cd0 /cdrom cd9660 ro,noauto 0 0 /dev/cd1 /cdrom cd9660 ro,noauto 0 0 # /dev/ad0s1a /new ufs rw 1 1 /dev/ad0s1g /new/home ufs rw 2 2 /dev/ad0s1d /new/tmp ufs rw 2 2 /dev/ad0s1e /new/usr ufs rw 2 2 /dev/ad0s1h /new/usr/local ufs rw 2 2 /dev/ad0s1f /new/var ufs rw 2 2 I am totally confused on how these should now be. Any and all help appreciated. ed From owner-freebsd-current@FreeBSD.ORG Tue May 3 12:21:09 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D15F410657A1 for ; Tue, 3 May 2011 12:21:09 +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 8C7BF8FC16 for ; Tue, 3 May 2011 12:21:09 +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 4639646B43; Tue, 3 May 2011 08:21:09 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D8D6E8A02A; Tue, 3 May 2011 08:21:08 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 3 May 2011 07:58:12 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <4DBF68A4.6050405@protected-networks.net> In-Reply-To: <4DBF68A4.6050405@protected-networks.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105030758.12792.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 03 May 2011 08:21:08 -0400 (EDT) Cc: Michael Butler Subject: Re: cardbus memory allocation problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 12:21:10 -0000 On Monday, May 02, 2011 10:29:56 pm Michael Butler wrote: > I've stared at this for a (long) while but haven't come to any > reasonable conclusion as to why it does what it does or how to fix it :-( > > Specifically, the BIOS in this machine doesn't set up a memory window > for the cardbus controller nor does it properly configure the PCI bridge > to route to the correct buses. BSD tries but allocates memory from the > wrong space. > > My question is - how to get PCI-cardbus bridge to allocate memory inside > the window of the parent PCI-PCI bridge? .. the bus tree looks like .. > > imb@toshi:/home/imb> sudo lspci -t > -[0000:00]-+-00.0 > +-02.0 > +-02.1 > +-1b.0 > +-1c.0-[02]-- > +-1c.1-[03-04]-- > +-1c.2-[05-06]----00.0 > +-1d.0 > +-1d.1 > +-1d.2 > +-1d.3 > +-1d.7 > +-1e.0-[07]--+-06.0 > | +-06.1 > | +-06.2 > | +-06.3 > | \-08.0 > +-1f.0 > +-1f.2 > \-1f.3 > > I've annotated the verbose dmesg below to highlight the issues .. > > pcib4: at device 30.0 on pci0 > pcib4: domain 0 > pcib4: secondary bus 7 > pcib4: subordinate bus 7 > *** subordinate bus needs to be '9' so as to include both '8' & '9' > *** for the PCI-cardbus bridge I have WIP patches to fix this but they aren't ready yet. > pcib4: I/O decode 0x4000-0x4fff > pcib4: memory decode 0xf0900000-0xf09fffff > *** this memory widow is what I expected all children to allocate from > > pcib4: no prefetched decode > pcib4: Subtractively decoded bridge. It's a subtractive bridge, so the resources do not have to be allocated from the window. That said, I'm committing the last of my patches to HEAD today to rework how PCI-PCI bridges handle I/O windows to support growing windows, etc. and the new PCI-PCI bridge driver will attempt to grow the memory window to allocate a new range before falling back to depending on the subtractive decode. > cbb0: at device 6.0 on pci7 > pcib4: cbb0 requested memory range 0x0-0xffffffff: good > *** what appears to be a "wildcard" alloc request > > cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xbf670000 > *** but which isn't constrained to be within the parent bridge's space Yes, it is a subtractive bridge, so that should be fine. The problem may be that the bf670000 address may not be decoded by the parent Host-PCI bridge. There are some tunable hacks you can try to force this address higher, but I am also working on other patches (before the bus numbering ones) to query ACPI for the list of valid decoded ranges of PCI addresses for Host-PCI bridges and to restrict PCI allocations to coming from those ranges. You can try increasing hw.acpi.host_mem_start or hw.cbb.memory_start loader tunables. (There should be sysctl's with the current values I think.) -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue May 3 12:21:11 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0310F10657A3 for ; Tue, 3 May 2011 12:21:11 +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 C94CC8FC1A for ; Tue, 3 May 2011 12:21:10 +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 825D546B06; Tue, 3 May 2011 08:21:10 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 224C58A01B; Tue, 3 May 2011 08:21:10 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 3 May 2011 07:59:09 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105030759.09518.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 03 May 2011 08:21:10 -0400 (EDT) Cc: Subject: Re: I am very confused and would appreciate some help on device renameing or on renumbering on current fstab. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 12:21:11 -0000 On Tuesday, May 03, 2011 7:16:34 am Edwin L. Culp W. wrote: > I have two disks on this old machine that I have keep current sin > FreeBSD 6 IIRC as preparation for all the new goodies but this really > bit me in the morning with a generic kernel and had a heck of a time > getting it up. > > I have a new kernel with the new options. > options ATA_CAM > device ahci > device mvs > device siis > > This morning was such a shock that I am tempted to go back to the old > kernel config that I understand still works but gonna try to bite the > bullit. > > My fstab that I assume is still needed, is as before, although I had > changed ad4xx to ada4xx (etc) that I found was incorrect the HARD way > after trying to reboot; > > /dev/ad4s1b none swap sw 0 0 > /dev/ad4s1a / ufs rw 1 1 > /dev/ad4s2g /backup ufs rw 2 2 > /dev/ad4s1g /home ufs rw 2 2 > /dev/ad4s2f /release ufs rw > 2 2 > /dev/ad4s2d /tmp ufs rw 2 2 > /dev/ad4s1e /usr ufs rw 2 2 > /dev/ad4s1h /usr/local ufs rw > 2 2 > /dev/ad4s1f /var ufs rw 2 2 > /dev/ad4s2e /var/tmp ufs rw > 2 2 > /dev/acd0 /cdrom cd9660 ro,noauto 0 0 > /dev/acd1 /cdrom1 cd9660 ro,noauto 0 0 > /dev/cd0 /cdrom cd9660 ro,noauto 0 0 > /dev/cd1 /cdrom cd9660 ro,noauto 0 0 > # > /dev/ad0s1a /new ufs rw 1 1 > /dev/ad0s1g /new/home ufs rw 2 2 > /dev/ad0s1d /new/tmp ufs rw 2 2 > /dev/ad0s1e /new/usr ufs rw 2 2 > /dev/ad0s1h /new/usr/local ufs rw 2 2 > /dev/ad0s1f /new/var ufs rw 2 2 > > I am totally confused on how these should now be. > > Any and all help appreciated. It will be ada0 rather than ad4. With adaX the weird ATA_STATIC_ID stuff is gone and ATA disks are now numbered starting from 0 just like SCSI disks use da0, da1, ... etc. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue May 3 12:44:33 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 579F61065677; Tue, 3 May 2011 12:44:33 +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 34C648FC20; Tue, 3 May 2011 12:44: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 PAA03697; Tue, 03 May 2011 15:44:29 +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 1QHExp-0003HQ-HJ; Tue, 03 May 2011 15:44:29 +0300 Message-ID: <4DBFF8AB.6090401@FreeBSD.org> Date: Tue, 03 May 2011 15:44:27 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110308 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <4DB54F40.8050608@FreeBSD.org> <4DB7C7B7.9020201@FreeBSD.org> <4DBAED76.3030006@FreeBSD.org> In-Reply-To: <4DBAED76.3030006@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , freebsd-geom@FreeBSD.org Subject: Re: A replacement for GEOM_LABEL's gpt/gptid X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 12:44:33 -0000 on 29/04/2011 19:55 Andrey V. Elsukov said the following: > On 27.04.2011 11:37, Andrey V. Elsukov wrote: >>> I wrote a small extension for the GEOM_PART class. It adds an ability >>> to GEOM_PART class to create partition labels for schemes which are >>> support them. > > Hi All, > > i got several successful reports from users, but now i decided to make > this functional available for another consumers. > New patch: > http://people.freebsd.org/~ae/geom_alias.diff I really like your approach. One question - is it somehow possible to make the alias geom even more transparent? I mean completely eliminating g_alias_start() or making it more noop-ish. Thank you! > What it contains: > * gpt/gptid support removed from GEOM_LABEL class; > * new GEOM_ALIAS class added. This class has two public functions: > void g_alias_create(struct g_provider *pp, const char *name); > void g_alias_spoil(struct g_provider *pp); > * first two consumers of GEOM_ALIAS class are GEOM_PART and GEOM_DISK: > > GEOM_DISK uses g_alias_create() to create aliases for disks, disk's > serial number is used for alias name. > > GEOM_PART uses g_alias_create() to create aliases for labeled partitions > (gpt/gptid, apm and pc98). > > How it looks like: > http://paste.org.ru/?5exeve > -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue May 3 12:51:04 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09B4B106566C for ; Tue, 3 May 2011 12:51:04 +0000 (UTC) (envelope-from edwinlculp@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id A105C8FC1B for ; Tue, 3 May 2011 12:51:03 +0000 (UTC) Received: by vws18 with SMTP id 18so31080vws.13 for ; Tue, 03 May 2011 05:51:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4ddup2u0lknGrmzWX0pcIxtQ8Z3HDiSzXILNOkRO9eA=; b=ZShYuVvGgeKBUlXeWXfXwD1BSR4sFSGz+u0cJNHDm204msDqu5MJ65ufK9hRpteiHm 8Ssac3HjIAwHl4rnZoB68Jj4pJqONj/F45KD8kbPtmX7sI26N6Jdo2uP8ZkQwBDwyPk4 Zrk1wc9eo11q2TjB2PST5RQUryeRG4RZTO0CA= 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=BLIfNURfaFkl6rgYfHnlv5AwHtrU2072Kca0W3VacmlB3AGBC1hUIjvWJdqUqbFnb7 ZAsJ1mopqnZpiMEQRyxDon9p+/qnsMFdmWuDMzXKHx7t2hVwRCQwt0vXJNVNQPDUTta/ /EVZ2zyhiVIGCd9O25eMoxTRFTk3gwo6bBsYY= MIME-Version: 1.0 Received: by 10.52.97.229 with SMTP id ed5mr1542443vdb.237.1304427062759; Tue, 03 May 2011 05:51:02 -0700 (PDT) Received: by 10.52.107.5 with HTTP; Tue, 3 May 2011 05:51:02 -0700 (PDT) In-Reply-To: <201105030759.09518.jhb@freebsd.org> References: <201105030759.09518.jhb@freebsd.org> Date: Tue, 3 May 2011 07:51:02 -0500 Message-ID: From: "Edwin L. Culp W." To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: I am very confused and would appreciate some help on device renameing or on renumbering on current fstab. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 12:51:04 -0000 On Tue, May 3, 2011 at 6:59 AM, John Baldwin wrote: > On Tuesday, May 03, 2011 7:16:34 am Edwin L. Culp W. wrote: >> I have two disks on this old machine that I have keep current sin >> FreeBSD 6 IIRC as preparation for all the new goodies but this really >> bit me in the morning with a generic kernel and had a heck of a time >> getting it up. >> >> I have a new kernel with the new options. >> =A0 =A0 =A0 =A0 =A0 =A0 options =A0 =A0 =A0 =A0ATA_CAM >> =A0 =A0 =A0 =A0 =A0 =A0 device =A0 =A0 =A0 =A0 ahci >> =A0 =A0 =A0 =A0 =A0 =A0 device =A0 =A0 =A0 =A0 mvs >> =A0 =A0 =A0 =A0 =A0 =A0 device =A0 =A0 =A0 =A0 siis >> >> This =A0morning was such a shock that I am tempted to go back to the old >> kernel config that I understand still works but gonna try to bite the >> bullit. >> >> My fstab that I assume is still needed, is as before, although I had >> changed ad4xx to ada4xx (etc) that I found was incorrect the HARD way >> after trying to reboot; >> >> =A0/dev/ad4s1b =A0 =A0 =A0 =A0 =A0 =A0none =A0 =A0 =A0 =A0 =A0 =A0swap = =A0 =A0sw =A0 =A0 =A0 =A0 =A0 =A0 =A00 =A0 =A0 =A0 0 >> =A0/dev/ad4s1a =A0 =A0 =A0 =A0 =A0 =A0/ =A0 =A0 =A0 =A0 =A0 =A0 =A0 ufs = =A0 =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A01 =A0 =A0 =A0 1 >> =A0/dev/ad4s2g =A0 =A0 =A0 =A0 =A0 =A0/backup =A0 =A0 =A0 =A0 ufs =A0 = =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 >> =A0/dev/ad4s1g =A0 =A0 =A0 =A0 =A0 =A0/home =A0 =A0 =A0 =A0 =A0 ufs =A0 = =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 >> =A0/dev/ad4s2f =A0 =A0 =A0 =A0 =A0 =A0/release =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0ufs =A0 =A0 rw >> =A02 =A0 =A0 =A0 2 >> =A0/dev/ad4s2d =A0 =A0 =A0 =A0 =A0 =A0/tmp =A0 =A0 =A0 =A0 =A0 =A0ufs = =A0 =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 >> =A0/dev/ad4s1e =A0 =A0 =A0 =A0 =A0 =A0/usr =A0 =A0 =A0 =A0 =A0 =A0ufs = =A0 =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 >> =A0/dev/ad4s1h =A0 =A0 =A0 =A0 =A0 =A0/usr/local =A0 =A0 =A0 =A0 =A0 =A0= =A0ufs =A0 =A0 rw >> =A02 =A0 =A0 =A0 2 >> =A0/dev/ad4s1f =A0 =A0 =A0 =A0 =A0 =A0/var =A0 =A0 =A0 =A0 =A0 =A0ufs = =A0 =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 >> =A0/dev/ad4s2e =A0 =A0 =A0 =A0 =A0 =A0/var/tmp =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0ufs =A0 =A0 rw >> =A02 =A0 =A0 =A0 2 >> =A0/dev/acd0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/cdrom =A0 =A0 =A0 =A0 =A0cd9660= =A0ro,noauto =A0 =A0 =A0 0 =A0 =A0 =A0 0 >> =A0/dev/acd1 =A0 =A0 =A0 =A0 =A0 =A0 =A0/cdrom1 =A0 =A0 =A0 =A0 cd9660 = =A0ro,noauto =A0 =A0 =A0 0 =A0 =A0 =A0 0 >> =A0/dev/cd0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /cdrom =A0 =A0 =A0 =A0 =A0cd9660= =A0ro,noauto =A0 =A0 =A0 0 =A0 =A0 =A0 0 >> =A0/dev/cd1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /cdrom =A0 =A0 =A0 =A0 =A0cd9660= =A0ro,noauto =A0 =A0 =A0 0 =A0 =A0 =A0 0 >> # >> /dev/ad0s1a =A0 =A0 =A0 =A0 =A0 /new =A0 =A0 =A0 =A0 =A0 =A0ufs =A0 =A0 = rw =A0 =A0 =A0 =A0 =A0 =A0 =A01 =A0 =A0 =A0 1 >> /dev/ad0s1g =A0 =A0 =A0 =A0 =A0/new/home =A0 =A0 =A0 ufs =A0 =A0 rw =A0 = =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 >> /dev/ad0s1d =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/new/tmp =A0 =A0 =A0 =A0ufs = =A0 =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 >> /dev/ad0s1e =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/new/usr =A0 =A0 =A0 =A0ufs = =A0 =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 >> /dev/ad0s1h =A0 =A0 =A0 =A0 =A0/new/usr/local =A0ufs =A0 =A0 rw =A0 =A0 = =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 >> /dev/ad0s1f =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/new/var =A0 =A0 =A0 =A0ufs = =A0 =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 >> >> I am totally confused on how these should now be. >> >> Any and all help appreciated. > > It will be ada0 rather than ad4. =A0With adaX the weird ATA_STATIC_ID stu= ff is > gone and ATA disks are now numbered starting from 0 just like SCSI disks = use > da0, da1, ... etc. > > -- > John Baldwin > Thanks, John. I was afraid that was the answer. Now, II'm really confused. I'm guessing that the partitions will notl need to be shown in fstab (ada0s1a). What little mind I have left is a blank, /dev/ad4s1g will be automatically be detected. Is that correct? What will I do with my second disk /dev/ad0s1a that is already zero? I apologize but I have really confused myself. I've filled my glass with too much water and I'm drowning. Thanks for everyone's patience. ed P.S. If I am not the only idiot, maybe a couple of lines as an example could go into UPDATING. From owner-freebsd-current@FreeBSD.ORG Tue May 3 13:19:21 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C14381065670 for ; Tue, 3 May 2011 13:19:21 +0000 (UTC) (envelope-from eculp@encontacto.net) Received: from ns2.bafirst.com (ns2.bafirst.com [97.67.198.91]) by mx1.freebsd.org (Postfix) with ESMTP id 2E4FB8FC19 for ; Tue, 3 May 2011 13:19:19 +0000 (UTC) Received: from unixmania.com ([189.251.79.134]) by ns2.bafirst.com with esmtp; Tue, 03 May 2011 08:09:09 -0500 id 000DA802.4DBFFE75.00004B5C Received: from localhost (localhost [127.0.0.1]) (uid 80) by unixmania.com with local; Mon, 02 May 2011 19:28:52 -0500 id 000CF6EA.4DBF4C44.0001735C Received: from dsl-189-251-79-134-dyn.prod-infinitum.com.mx (dsl-189-251-79-134-dyn.prod-infinitum.com.mx [189.251.79.134]) by econet.encontacto.net (Horde Framework) with HTTP; Mon, 02 May 2011 19:28:52 -0500 Message-ID: <20110502192852.18002gkkic9fy44k@econet.encontacto.net> Date: Mon, 02 May 2011 19:28:52 -0500 From: eculp To: freebsd-current MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (5.0-cvs) X-Remote-Browser: Mozilla/5.0 (X11; FreeBSD i386; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 X-IMP-Server: 189.251.79.134 X-Originating-IP: 189.251.79.134 X-Originating-User: eculp@encontacto.net Subject: Totally confused with the /usrsrc/UPDATING for 20110424 CAM-based ATA stack X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 13:19:21 -0000 With this confusion I need someone to give me an idea on renumbering. I have two disks on this old machine that I have keep current sin =20 FreeBSD 6 IIRC as preparation for all the new goodies but this really =20 bit me in the morning with a generic kernel and had a heck of a time =20 getting it up. I have a new kernel with the new options. options ATA_CAM device ahci device mvs device siis This morning was such a shock that I am tempted to go back to the old =20 kernel config that I understand still works but gonna try to bite the =20 bullit. My fstab that I assume is still necessary is: /dev/ad4s1b none swap sw 0 0 /dev/ad4s1a / ufs rw 1 1 /dev/ad4s2g /backup ufs rw 2 2 /dev/ad4s1g /home ufs rw 2 2 /dev/ad4s2f /release ufs rw =20 2 2 /dev/ad4s2d /tmp ufs rw 2 2 /dev/ad4s1e /usr ufs rw 2 2 /dev/ad4s1h /usr/local ufs rw =20 2 2 /dev/ad4s1f /var ufs rw 2 2 /dev/ad4s2e /var/tmp ufs rw =20 2 2 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 /dev/acd1 /cdrom1 cd9660 ro,noauto 0 0 /dev/cd0 /cdrom cd9660 ro,noauto 0 0 /dev/cd1 /cdrom cd9660 ro,noauto 0 0 # /dev/ad0s1a /new ufs rw 1 1 /dev/ad0s1g /new/home ufs rw 2 2 /dev/ad0s1d /new/tmp ufs rw 2 2 /dev/ad0s1e /new/usr ufs rw 2 2 /dev/ada01h /new/usr/local ufs rw 2 2 /dev/ada01f /new/var ufs rw 2 2 I am totally confused on how these should now be. Any help appreciated. ed From owner-freebsd-current@FreeBSD.ORG Tue May 3 13:59:04 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B381106566C for ; Tue, 3 May 2011 13:59:04 +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 040258FC08 for ; Tue, 3 May 2011 13:59:03 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.4/8.14.4) with ESMTP id p43Dx3lb011497; Tue, 3 May 2011 07:59:03 -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 p43Dx37l011494; Tue, 3 May 2011 07:59:03 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Tue, 3 May 2011 07:59:03 -0600 (MDT) From: Warren Block To: "Edwin L. Culp W." In-Reply-To: Message-ID: References: <201105030759.09518.jhb@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-902635197-155913889-1304430762=:11416" Content-ID: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Tue, 03 May 2011 07:59:03 -0600 (MDT) Cc: freebsd-current@freebsd.org Subject: Re: I am very confused and would appreciate some help on device renameing or on renumbering on current fstab. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 13:59:04 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---902635197-155913889-1304430762=:11416 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: On Tue, 3 May 2011, Edwin L. Culp W. wrote: >> It will be ada0 rather than ad4.  With adaX the weird ATA_STATIC_ID stuff is >> gone and ATA disks are now numbered starting from 0 just like SCSI disks use >> da0, da1, ... etc. >> >> -- >> John Baldwin > > Thanks, John. I was afraid that was the answer. Now, II'm really > confused. I'm guessing that the partitions will notl need to be shown > in fstab (ada0s1a). What little mind I have left is a blank, > /dev/ad4s1g will be automatically be detected. Is that correct? > > What will I do with my second disk /dev/ad0s1a that is already zero? The device names change from ad to ada. Slice and partition identifiers don't change. Device numbering is dynamic with ahci. Using labels is an easy way to not have to worry about a device's name or number. Moving A FreeBSD System To AHCI http://www.wonkity.com/~wblock/docs/html/ahci.html FreeBSD Labeled Filesystems http://www.wonkity.com/~wblock/docs/html/labels.html ---902635197-155913889-1304430762=:11416-- From owner-freebsd-current@FreeBSD.ORG Tue May 3 14:02:43 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E28F5106566C for ; Tue, 3 May 2011 14:02:43 +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 9CBC58FC08 for ; Tue, 3 May 2011 14:02:43 +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 1348A46B43; Tue, 3 May 2011 10:02:43 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9F0F08A027; Tue, 3 May 2011 10:02:42 -0400 (EDT) From: John Baldwin To: "Edwin L. Culp W." Date: Tue, 3 May 2011 10:02:36 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <201105030759.09518.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105031002.36612.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 03 May 2011 10:02:42 -0400 (EDT) Cc: freebsd-current@freebsd.org Subject: Re: I am very confused and would appreciate some help on device renameing or on renumbering on current fstab. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 14:02:44 -0000 On Tuesday, May 03, 2011 8:51:02 am Edwin L. Culp W. wrote: > On Tue, May 3, 2011 at 6:59 AM, John Baldwin wrote: > > On Tuesday, May 03, 2011 7:16:34 am Edwin L. Culp W. wrote: > >> I have two disks on this old machine that I have keep current sin > >> FreeBSD 6 IIRC as preparation for all the new goodies but this really > >> bit me in the morning with a generic kernel and had a heck of a time > >> getting it up. > >> > >> I have a new kernel with the new options. > >> options ATA_CAM > >> device ahci > >> device mvs > >> device siis > >> > >> This morning was such a shock that I am tempted to go back to the old > >> kernel config that I understand still works but gonna try to bite the > >> bullit. > >> > >> My fstab that I assume is still needed, is as before, although I had > >> changed ad4xx to ada4xx (etc) that I found was incorrect the HARD way > >> after trying to reboot; > >> > >> /dev/ad4s1b none swap sw 0 0 > >> /dev/ad4s1a / ufs rw 1 1 > >> /dev/ad4s2g /backup ufs rw 2 2 > >> /dev/ad4s1g /home ufs rw 2 2 > >> /dev/ad4s2f /release ufs rw > >> 2 2 > >> /dev/ad4s2d /tmp ufs rw 2 2 > >> /dev/ad4s1e /usr ufs rw 2 2 > >> /dev/ad4s1h /usr/local ufs rw > >> 2 2 > >> /dev/ad4s1f /var ufs rw 2 2 > >> /dev/ad4s2e /var/tmp ufs rw > >> 2 2 > >> /dev/acd0 /cdrom cd9660 ro,noauto 0 0 > >> /dev/acd1 /cdrom1 cd9660 ro,noauto 0 0 > >> /dev/cd0 /cdrom cd9660 ro,noauto 0 0 > >> /dev/cd1 /cdrom cd9660 ro,noauto 0 0 > >> # > >> /dev/ad0s1a /new ufs rw 1 1 > >> /dev/ad0s1g /new/home ufs rw 2 2 > >> /dev/ad0s1d /new/tmp ufs rw 2 2 > >> /dev/ad0s1e /new/usr ufs rw 2 2 > >> /dev/ad0s1h /new/usr/local ufs rw 2 2 > >> /dev/ad0s1f /new/var ufs rw 2 2 > >> > >> I am totally confused on how these should now be. > >> > >> Any and all help appreciated. > > > > It will be ada0 rather than ad4. With adaX the weird ATA_STATIC_ID stuff is > > gone and ATA disks are now numbered starting from 0 just like SCSI disks use > > da0, da1, ... etc. > > > > -- > > John Baldwin > > > > Thanks, John. I was afraid that was the answer. Now, II'm really > confused. I'm guessing that the partitions will notl need to be shown > in fstab (ada0s1a). What little mind I have left is a blank, > /dev/ad4s1g will be automatically be detected. Is that correct? > > What will I do with my second disk /dev/ad0s1a that is already zero? > > I apologize but I have really confused myself. I've filled my glass > with too much water and I'm drowning. > > Thanks for everyone's patience. > > ed > > P.S. If I am not the only idiot, maybe a couple of lines as an > example could go into UPDATING. Oh, I missed that you had an ad0. Most likely ad0 will become ada0, and ad4 will become ada1. All the partitions will still exist, so ad0s1a will become ada0s1a and ad4s1a will become ada1s1a. There is a chance that ad0 will become ada1 and ad4 will become ada1 instead. That depends on how your PCI devices are laid out on the PCI bus. I can't answer that without seeing a dmesg though. Do you have mav's latest changes? They should provide aliases for the old names along with printfs to let you know what the new names are for each old disk I think. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue May 3 14:24:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 893331065673; Tue, 3 May 2011 14:24:25 +0000 (UTC) (envelope-from dnebdal@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 E3CA38FC18; Tue, 3 May 2011 14:24:24 +0000 (UTC) Received: by iwn33 with SMTP id 33so140258iwn.13 for ; Tue, 03 May 2011 07:24:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3FOPbKnTVHN9qpVbPpUFwx/NoGo284ZLAdwazzlfK+0=; b=qyDW8zOj8Rk+ZLeLN5javzc6kcH4VOnRDT/A2QhwLEj0M4tiS0TejG7zORqOt5F2bI oe5Fqd1iSODDSqJ4zzZYto/38Ym/vaxtqn8kmxIIUQAMX/dezG+3nAt+hkEjpa5lblqy 7OE2NzQp7P/Ibr8j/WNvg+BEiaNZ8JCMsbJB4= 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=VRovnb//w2ytL18SWnaZ1XfTFGq5KbeTUhoCx0l7q3N8N6ATzOz5KPkZaoGk7lyisI u5Y4/GKFw5tZMGHtfQQVOFQIj1tPLZt0TE2T8EK2C4jXm2+vmCfGGAOiBXv03oi7cKP3 cVJswwau4vn0sNm+4lH5yMCE5TDb6G7HjMraM= MIME-Version: 1.0 Received: by 10.42.158.66 with SMTP id g2mr346085icx.125.1304430882797; Tue, 03 May 2011 06:54:42 -0700 (PDT) Received: by 10.231.11.4 with HTTP; Tue, 3 May 2011 06:54:42 -0700 (PDT) In-Reply-To: References: <201105030759.09518.jhb@freebsd.org> Date: Tue, 3 May 2011 15:54:42 +0200 Message-ID: From: Daniel Nebdal To: "Edwin L. Culp W." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: I am very confused and would appreciate some help on device renameing or on renumbering on current fstab. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 14:24:25 -0000 > > Thanks, John. =A0I was afraid that was the answer. Now, II'm really > confused. =A0I'm guessing that the partitions will notl need to be shown > in fstab (ada0s1a). =A0 What little mind I have left is a blank, > /dev/ad4s1g will be automatically be detected. =A0Is that correct? > > What will I do with my second disk /dev/ad0s1a that is already zero? > > I apologize but I have really confused myself. =A0I've filled my glass > with too much water and I'm drowning. > > Thanks for everyone's patience. > > ed > > P.S. =A0If I am not the only idiot, maybe a couple of lines as an > example could go into UPDATING. If I have understood ada correct, the "first" disk (lowest current number) is ada0, the next ada1, and so on. If you have ad0 and ad4, they will be ad0=3Dada0, and ad4=3Dada1 . It doesn't affect anything _except_ the disk names, so ad4s1f =3D ada1s1f and so on. You'll have to change most of your fstab, basically s/ad0/ada0/g and s/ad4/ada1/g . That said, my one ad to ada transition was on a ZFS-only system, which took the fstab editing out of it. I might be horribly wrong in some or all of the above. --=20 Daniel Nebdal From owner-freebsd-current@FreeBSD.ORG Tue May 3 14:42:55 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E6781065674 for ; Tue, 3 May 2011 14:42:55 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id C90478FC1A for ; Tue, 3 May 2011 14:42:54 +0000 (UTC) Received: from bb.ipt.ru ([194.62.233.89]) by services.ipt.ru with esmtps (TLSv1:AES128-SHA:128) (Exim 4.54 (FreeBSD)) id 1QHGoP-000ITB-3n for freebsd-current@FreeBSD.org; Tue, 03 May 2011 18:42:53 +0400 From: Boris Samorodov To: freebsd-current@FreeBSD.org Date: Tue, 03 May 2011 18:42:52 +0400 Message-ID: <00959411@bb.ipt.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: a process waits forever X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 14:42:55 -0000 Hi, I've got a problem which I harly can explain. Latest CURRENT built with gcc and clang suffers. Both hosts with CURRENT I have an access to has this problem. The most clean way to reproduce the error (for me) is to reload (sometimes once or twice, sometimes more, but not more than a dozen) current and latest builds at my local tinderbox. Firefox (I use FF4) reloads the page (it's seen since time counter is updated) shows "X" with red foreground instead of a reload sign at the very end of an URL window. The next symptom is using gsasl within emacs (gnus). Sometimes communication between gnus and an imap server stops. The only way to resume operations is to do "killall gsasl". BTW, a gsasl process is at a "select" state. Sometimes gnus displays something like "garbage received, enter RET to continue". I never managed to reproduce the bug by a script (i.e. fetching the problem URL 100 times succeeds). And I'm not sure how to diagnose the case further. Any suggestions? Thanks! -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Tue May 3 15:46:26 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C24931065673 for ; Tue, 3 May 2011 15:46:26 +0000 (UTC) (envelope-from larinus@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 5300B8FC15 for ; Tue, 3 May 2011 15:46:26 +0000 (UTC) Received: by fxm11 with SMTP id 11so255338fxm.13 for ; Tue, 03 May 2011 08:46:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:subject:message-id:organization :x-mailer:mime-version:content-type:content-transfer-encoding; bh=FYqfOune6FYXYIqCbfjWiJQosR+eBZh9H2aYB72FPRE=; b=MCOMCAO8SfM28lYggYiGQ13XPEJmUG626mv3PCFfv23NEYBPC3bekQwJy7AouKyd3K LG+OSuvwc+PXDz1pAmrJfBuZHk0YndU1aV5gIoGxo4frqUM9yD8d1b126L8C9f/trAb5 O/LDqxCjfGzhL8D0YfHQ+ol1fCSPkVZukSKng= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:organization:x-mailer:mime-version :content-type:content-transfer-encoding; b=gsmW7iBoAKgTOXEf0UOwnkHSzjczICypF1wbPN5rZXXWC93jIsE9hKfXZbji71y9hc ZhH/LT+jYIjkdMPhxKq5bCmJEYagUOSGd2dhTX4JpAz2mvncRDUnpEQPej0N8ytT+xR8 YIuuOVNNQcPxQXaVTqjOG4336CMEny9v8u7EQ= Received: by 10.223.64.201 with SMTP id f9mr100759fai.102.1304433919616; Tue, 03 May 2011 07:45:19 -0700 (PDT) Received: from laptop ([178.125.228.7]) by mx.google.com with ESMTPS id n7sm53390fam.11.2011.05.03.07.45.18 (version=SSLv3 cipher=OTHER); Tue, 03 May 2011 07:45:19 -0700 (PDT) Date: Tue, 3 May 2011 17:49:49 +0300 From: Vitaly Liaschuk To: FreeBSD current mailing list Message-ID: <20110503174949.7ada20dc@laptop> Organization: HOME X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: firefox4+html5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 15:46:26 -0000 Hi, list! I do not know in what part of forum to write, so I decide write in General. I'm trying to use html5 on youtube.com. I getting the video stream, but audio "stutters" on most of video files . I tried to use the chrome-browser and he is works fine. Also, I tried boot from usb flash drive with installed ubuntu and firefox 4 and this works. So, I believe what trouble is in my FreeBSD. [QUOTE] > uname -a FreeBSD laptop 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r221296M: Sun May 1 20:13:15 EEST 2011 larin@laptop:/usr/obj/usr/src/sys/GENERIC amd64 > [/QUOTE] My box is: Laptop asus UL30A, 3 GB ram, Intel CPU U2300 1.2Mhz. Thanks in advance. From owner-freebsd-current@FreeBSD.ORG Tue May 3 16:11:25 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BBD1106564A for ; Tue, 3 May 2011 16:11:25 +0000 (UTC) (envelope-from Holger.Kipp@alogis.com) Received: from alogis.com (firewall.solit-ag.de [212.184.102.1]) by mx1.freebsd.org (Postfix) with ESMTP id C86AD8FC0C for ; Tue, 3 May 2011 16:11:24 +0000 (UTC) Received: from msx3.exchange.alogis.com (exchange.alogis.com [10.1.1.6]) by alogis.com (8.13.4/8.13.1) with ESMTP id p43Fw7Bu044374; Tue, 3 May 2011 17:58:07 +0200 (CEST) (envelope-from Holger.Kipp@alogis.com) Received: from MSX3.exchange.alogis.com ([fe80::c8ed:428a:a157:b61]) by msx3.exchange.alogis.com ([fe80::c8ed:428a:a157:b61%13]) with mapi id 14.01.0255.000; Tue, 3 May 2011 17:59:23 +0200 From: Holger Kipp To: Vitaly Liaschuk , FreeBSD current mailing list Thread-Topic: firefox4+html5 Thread-Index: AQHMCamlkoCQWbitOUyBzHFoAFEy4ZR7QVsN Date: Tue, 3 May 2011 15:59:23 +0000 Message-ID: <814C9E9472FDCC40AAC3FC95A2D67E3B0BD798A3@msx3.exchange.alogis.com> References: <20110503174949.7ada20dc@laptop> In-Reply-To: <20110503174949.7ada20dc@laptop> Accept-Language: en-GB, de-DE, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [212.184.101.130] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Subject: RE: firefox4+html5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 16:11:25 -0000 Dear Vitaly, I'm usually not using FreeBSD for accessing youtube, but as you're using FreeBSD 9.0-current, please note that this presumably has Witness enabled (because FreeBSD 9.0-current is still development branch), which will reduce performance and hence might give the problems you described. from http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-op= tions.html options WITNESS: this option enables run-time lock order tracking and verif= ication, and is an invaluable tool for deadlock diagnosis. WITNESS maintain= s a graph of acquired lock orders by lock type, and checks the graph at eac= h acquire for cycles (implicit or explicit). If a cycle is detected, a warn= ing and stack trace are generated to the console, indicating that a potenti= al deadlock might have occurred. WITNESS is required in order to use the sh= ow locks, show witness and show alllocks DDB commands. This debug option ha= s significant performance overhead, which may be somewhat mitigated through= the use of options WITNESS_SKIPSPIN. Detailed documentation may be found i= n witness(4). =3D> http://www.freebsd.org/cgi/man.cgi?query=3Dwitness&sektion=3D4 Best regards, Holger ________________________________________ From: owner-freebsd-current@freebsd.org [owner-freebsd-current@freebsd.org]= on behalf of Vitaly Liaschuk [larinus@gmail.com] Sent: 03 May 2011 16:49 To: FreeBSD current mailing list Subject: firefox4+html5 Hi, list! I do not know in what part of forum to write, so I decide write in Gene= ral. I'm trying to use html5 on youtube.com. I getting the video stream, but= audio "stutters" on most of video files . I tried to use the chrome-browse= r and he is works fine. Also, I tried boot from usb flash drive with instal= led ubuntu and firefox 4 and this works. So, I believe what trouble is in my FreeBSD. [QUOTE] > uname -a FreeBSD laptop 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r221296M: Sun May 1 20:1= 3:15 EEST 2011 larin@laptop:/usr/obj/usr/src/sys/GENERIC amd64 > [/QUOTE] My box is: Laptop asus UL30A, 3 GB ram, Intel CPU U2300 1.2Mhz. Thanks in advance. _______________________________________________ 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" -- Holger Kipp Diplom-Mathematiker Senior Consultant Tel. : +49 30 436 58 114 Fax. : +49 30 436 58 214 Mobil: +49 178 36 58 114 Email: holger.kipp@alogis.com alogis AG Alt-Moabit 90b D-10559 Berlin web : http://www.alogis.com ---------------------------------------------------------- alogis AG Sitz/Registergericht: Berlin/AG Charlottenburg, HRB 71484 Vorstand: Arne Friedrichs, Joern Samuelson Aufsichtsratsvorsitzender: Reinhard Mielke From owner-freebsd-current@FreeBSD.ORG Tue May 3 17:41:27 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 980A2106566B for ; Tue, 3 May 2011 17:41:27 +0000 (UTC) (envelope-from francois.gerodez@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5DE048FC28 for ; Tue, 3 May 2011 17:41:27 +0000 (UTC) Received: by iyj12 with SMTP id 12so369329iyj.13 for ; Tue, 03 May 2011 10:41:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9zpajs2LsoT/o3+lXeVHHfJyDl/pMwqUBOa4KkJh5bk=; b=phujp5rPSuv6s1n7/BHjTatcje72x2nHqhEkYNxtr/V8R0v0Hy3qYFf+P2m3M544ng Oh5nG9IaNKHo29Jx1rS0hLjWWG41sr5lTVIDEE4BoPYExiFs4Nn1MsZzCFP4Y8pKQFLd gmzIYKTEybO4JtmJxVEyoyFOZ5KK/Nt+d+vhQ= 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=NbANeAwTQSECyXrGP2a2ElGqlWI/zzOSeW/Kt2NIA3PbaBjOHexqLG0Jc1CGUCsfKG sCEDGYCE4dcEECkMuxpqA0Tpo2Ix+MUt7XmAT0ItH4yBLPICoDkszUG+VHhkQzgGb1s3 HB3wI86/4az7kpUzoqJ7CoLJVK+3QaGnm/qcg= MIME-Version: 1.0 Received: by 10.42.134.129 with SMTP id l1mr173052ict.73.1304443166113; Tue, 03 May 2011 10:19:26 -0700 (PDT) Received: by 10.231.37.131 with HTTP; Tue, 3 May 2011 10:19:26 -0700 (PDT) In-Reply-To: <20110503174949.7ada20dc@laptop> References: <20110503174949.7ada20dc@laptop> Date: Tue, 3 May 2011 19:19:26 +0200 Message-ID: From: Francois Gerodez To: Vitaly Liaschuk Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD current mailing list Subject: Re: firefox4+html5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 17:41:27 -0000 Hi all, I'm currently running FreeBSD 8.1 (latest update) and I'm experiencing a similar issue. HTML5 videos are very laggy (both image and sound) with Firefox 4. I ended up installing the flash player to watch youtube streaming. I didn't spot any particular warning/error messages so I don't know where to start... Thanks! 2011/5/3 Vitaly Liaschuk > Hi, list! > I do not know in what part of forum to write, so I decide write in > General. > I'm trying to use html5 on youtube.com. I getting the video stream, but > audio "stutters" on most of video files . I tried to use the chrome-browser > and he is works fine. Also, I tried boot from usb flash drive with installed > ubuntu and firefox 4 and this works. > So, I believe what trouble is in my FreeBSD. > [QUOTE] > > uname -a > FreeBSD laptop 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r221296M: Sun May 1 > 20:13:15 EEST 2011 larin@laptop:/usr/obj/usr/src/sys/GENERIC amd64 > > > [/QUOTE] > > My box is: Laptop asus UL30A, 3 GB ram, Intel CPU U2300 1.2Mhz. > > Thanks in advance. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue May 3 17:56:42 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F642106566B for ; Tue, 3 May 2011 17:56:42 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 15C5B8FC16 for ; Tue, 3 May 2011 17:56:41 +0000 (UTC) Received: by iyj12 with SMTP id 12so385391iyj.13 for ; Tue, 03 May 2011 10:56:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mPNKygQ+S1ZZ1XCgg371hdRJcsR4TdBIZO4HyTVQOiM=; b=RJZo+NqcEVonZN7aIOJoW22IziwGE/f/3wfqShtL3HAz6RPGrFoUyRstwVXFtWsDzU 6I45lFLNUJV5Bfmb2FE1neCTAtIgf/QJ2+cpQ/weZSseTV2QQ5u49DBRWjUyaOvBSrYM 3GeaCGGZuhRNe6pKKc4itFhg0n2btDUKpbmJU= 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=UY7SxflTZcvUqX8oLYAgUm/pxLeoLgNDaCWcwUDmHMbvndt9JilhqMq1DdCuUuA1Mn sHkKBLzN2yXmqiYo5ogxNkjYCyWsIFJ+C244Yjqin38pd/AzDcImARjJ2izP9fUBvMnN 2qjG20V3uDRfTQlSdE80fEx6OxWodrypbOXBw= MIME-Version: 1.0 Received: by 10.42.150.8 with SMTP id y8mr149866icv.471.1304445401201; Tue, 03 May 2011 10:56:41 -0700 (PDT) Received: by 10.42.167.5 with HTTP; Tue, 3 May 2011 10:56:41 -0700 (PDT) In-Reply-To: <20110502192852.18002gkkic9fy44k@econet.encontacto.net> References: <20110502192852.18002gkkic9fy44k@econet.encontacto.net> Date: Tue, 3 May 2011 13:56:41 -0400 Message-ID: From: Arnaud Lacombe To: eculp Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current Subject: Re: Totally confused with the /usrsrc/UPDATING for 20110424 CAM-based ATA stack X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 17:56:42 -0000 Hi, On Mon, May 2, 2011 at 8:28 PM, eculp wrote: > With this confusion I need someone to give me an idea on renumbering. > > I have two disks on this old machine that I have keep current sin FreeBSD= 6 > IIRC as preparation for all the new goodies but this really bit me in the > morning with a generic kernel and had a heck of a time getting it up. > > I have a new kernel with the new options. > =A0 =A0 =A0 =A0 =A0 =A0options =A0 =A0 =A0 =A0ATA_CAM > =A0 =A0 =A0 =A0 =A0 =A0device =A0 =A0 =A0 =A0 ahci > =A0 =A0 =A0 =A0 =A0 =A0device =A0 =A0 =A0 =A0 mvs > =A0 =A0 =A0 =A0 =A0 =A0device =A0 =A0 =A0 =A0 siis > I've got the following in my stripped down GENERIC: # ATA controllers device ahci # AHCI-compatible SATA controllers device ata # Legacy ATA/SATA controllers options ATA_CAM # Handle legacy controllers with CAM # ATA/SCSI peripherals device scbus # SCSI bus (required for ATA/SCSI) device da # Direct Access (disks) device pass # Passthrough device (direct ATA/SCSI acces= s) I'm able to boot from CF on a couple of different machine. It would seem that without: device ata # Legacy ATA/SATA controllers the disk is not detected. With, the disk shows up as: ada0 at ata3 bus 0 scbus1 target 0 lun 0 ada0: < 20070709> ATA-0 device ada0: 16.700MB/s transfers (WDMA2, PIO 512bytes) ada0: 967MB (1981728 512 byte sectors: 16H 63S/T 1966C) ada0: Previously was known as ad0 and I did not need any /etc/fstab modification. my .2 credits, - Arnaud > This =A0morning was such a shock that I am tempted to go back to the old > kernel config that I understand still works but gonna try to bite the > bullit. > > My fstab that I assume is still necessary is: > > =A0/dev/ad4s1b =A0 =A0 =A0 =A0 =A0 =A0none =A0 =A0 =A0 =A0 =A0 =A0swap = =A0 =A0sw =A0 =A0 =A0 =A0 =A0 =A0 =A00 =A0 =A0 =A0 0 > =A0/dev/ad4s1a =A0 =A0 =A0 =A0 =A0 =A0/ =A0 =A0 =A0 =A0 =A0 =A0 =A0 ufs = =A0 =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A01 =A0 =A0 =A0 1 > =A0/dev/ad4s2g =A0 =A0 =A0 =A0 =A0 =A0/backup =A0 =A0 =A0 =A0 ufs =A0 =A0= rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 > =A0/dev/ad4s1g =A0 =A0 =A0 =A0 =A0 =A0/home =A0 =A0 =A0 =A0 =A0 ufs =A0 = =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 > =A0/dev/ad4s2f =A0 =A0 =A0 =A0 =A0 =A0/release =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0ufs =A0 =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 > =A0 =A0 2 > =A0/dev/ad4s2d =A0 =A0 =A0 =A0 =A0 =A0/tmp =A0 =A0 =A0 =A0 =A0 =A0ufs =A0= =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 > =A0/dev/ad4s1e =A0 =A0 =A0 =A0 =A0 =A0/usr =A0 =A0 =A0 =A0 =A0 =A0ufs =A0= =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 > =A0/dev/ad4s1h =A0 =A0 =A0 =A0 =A0 =A0/usr/local =A0 =A0 =A0 =A0 =A0 =A0 = =A0ufs =A0 =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 > =A0 =A0 2 > =A0/dev/ad4s1f =A0 =A0 =A0 =A0 =A0 =A0/var =A0 =A0 =A0 =A0 =A0 =A0ufs =A0= =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 > =A0/dev/ad4s2e =A0 =A0 =A0 =A0 =A0 =A0/var/tmp =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0ufs =A0 =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 > =A0 =A0 2 > =A0/dev/acd0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/cdrom =A0 =A0 =A0 =A0 =A0cd9660 = =A0ro,noauto =A0 =A0 =A0 0 =A0 =A0 =A0 0 > =A0/dev/acd1 =A0 =A0 =A0 =A0 =A0 =A0 =A0/cdrom1 =A0 =A0 =A0 =A0 cd9660 = =A0ro,noauto =A0 =A0 =A0 0 =A0 =A0 =A0 0 > =A0/dev/cd0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /cdrom =A0 =A0 =A0 =A0 =A0cd9660 = =A0ro,noauto =A0 =A0 =A0 0 =A0 =A0 =A0 0 > =A0/dev/cd1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /cdrom =A0 =A0 =A0 =A0 =A0cd9660 = =A0ro,noauto =A0 =A0 =A0 0 =A0 =A0 =A0 0 > # > /dev/ad0s1a =A0 =A0 =A0 =A0 =A0 /new =A0 =A0 =A0 =A0 =A0 =A0ufs =A0 =A0 r= w =A0 =A0 =A0 =A0 =A0 =A0 =A01 =A0 =A0 =A0 1 > /dev/ad0s1g =A0 =A0 =A0 =A0 =A0/new/home =A0 =A0 =A0 ufs =A0 =A0 rw =A0 = =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 > /dev/ad0s1d =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/new/tmp =A0 =A0 =A0 =A0ufs = =A0 =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 > /dev/ad0s1e =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/new/usr =A0 =A0 =A0 =A0ufs = =A0 =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 > /dev/ada01h =A0 =A0 =A0 =A0 =A0/new/usr/local =A0ufs =A0 =A0 rw =A0 =A0 = =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 > /dev/ada01f =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/new/var =A0 =A0 =A0 =A0ufs = =A0 =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 > > I am totally confused on how these should now be. > > Any help appreciated. > > ed > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Tue May 3 18:13:06 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74F4E1065670; Tue, 3 May 2011 18:13:06 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.212.176]) by mx1.freebsd.org (Postfix) with ESMTP id 481778FC0C; Tue, 3 May 2011 18:13:06 +0000 (UTC) Received: by pxi11 with SMTP id 11so234092pxi.35 for ; Tue, 03 May 2011 11:13:06 -0700 (PDT) Received: by 10.68.51.194 with SMTP id m2mr146659pbo.180.1304444595049; Tue, 03 May 2011 10:43:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.54.71 with HTTP; Tue, 3 May 2011 10:42:55 -0700 (PDT) In-Reply-To: <4DBFF8AB.6090401@FreeBSD.org> References: <4DB54F40.8050608@FreeBSD.org> <4DB7C7B7.9020201@FreeBSD.org> <4DBAED76.3030006@FreeBSD.org> <4DBFF8AB.6090401@FreeBSD.org> From: =?UTF-8?Q?Marius_N=C3=BCnnerich?= Date: Tue, 3 May 2011 19:42:55 +0200 Message-ID: To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Andrey V. Elsukov" , FreeBSD Current , freebsd-geom@freebsd.org Subject: Re: A replacement for GEOM_LABEL's gpt/gptid X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 18:13:06 -0000 Hi Andrey, just want to say you don't have to wait for me anymore. Just can't find the time to analyze your aproach. Thanks for your work on this. 2011/5/3 Andriy Gapon : > on 29/04/2011 19:55 Andrey V. Elsukov said the following: >> On 27.04.2011 11:37, Andrey V. Elsukov wrote: >>>> I wrote a small extension for the GEOM_PART class. It adds an ability >>>> to GEOM_PART class to create partition labels for schemes which are >>>> support them. >> >> Hi All, >> >> i got several successful reports from users, but now i decided to make >> this functional available for another consumers. >> New patch: >> http://people.freebsd.org/~ae/geom_alias.diff > > I really like your approach. > One question - is it somehow possible to make the alias geom even more > transparent? =C2=A0I mean completely eliminating g_alias_start() or makin= g it more > noop-ish. > > Thank you! > >> What it contains: >> * gpt/gptid support removed from GEOM_LABEL class; >> * new GEOM_ALIAS class added. This class has two public functions: >> =C2=A0 =C2=A0 =C2=A0 void g_alias_create(struct g_provider *pp, const ch= ar *name); >> =C2=A0 =C2=A0 =C2=A0 void g_alias_spoil(struct g_provider *pp); >> * first two consumers of GEOM_ALIAS class are GEOM_PART and GEOM_DISK: >> >> GEOM_DISK uses g_alias_create() to create aliases for disks, disk's >> serial number is used for alias name. >> >> GEOM_PART uses g_alias_create() to create aliases for labeled partitions >> (gpt/gptid, apm and pc98). >> >> How it looks like: >> http://paste.org.ru/?5exeve >> > > > -- > Andriy Gapon > _______________________________________________ > freebsd-geom@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-geom > To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue May 3 18:19:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C70A01065678; Tue, 3 May 2011 18:19:37 +0000 (UTC) (envelope-from edwinlculp@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 695958FC08; Tue, 3 May 2011 18:19:37 +0000 (UTC) Received: by vxc34 with SMTP id 34so399535vxc.13 for ; Tue, 03 May 2011 11:19:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JaKjuuKdS/Npw9g4uBIpR/EttpDJTHLcE1bEqjCriPw=; b=DJOD3KSXt669NJjOGy5RlEL95FGDu7CAgUeO/LNXl2FUxkaqnuZtj5yoaJouaaVnUJ XkrneBTboCy4D3ake1So6tgu8mn/eBIXxfZn7yAw7cQefYt60HRVuEHkvI0dnTk8CRLQ LqWTn2Gp+rO8xVGAeDbKd4fG5+rVpx5HGA8Jw= 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=QembunRRu+5gXbdNnkRgFyeOw4b9dGErbtUnO2RiHoClKM7yK0hIGxC/Kjvy9K3dF2 VpDgziOIlGtCYyxgkZ1Czt40X10F7lbmqgfwMxIGtYWaIEQylfh/yslp6FjPvry3qKBN gNo7fQnGNvUe6o/X7lUr0dbN3Dmws02bG3q68= MIME-Version: 1.0 Received: by 10.52.175.199 with SMTP id cc7mr177322vdc.197.1304446776676; Tue, 03 May 2011 11:19:36 -0700 (PDT) Received: by 10.52.107.5 with HTTP; Tue, 3 May 2011 11:19:36 -0700 (PDT) In-Reply-To: References: <201105030759.09518.jhb@freebsd.org> Date: Tue, 3 May 2011 13:19:36 -0500 Message-ID: From: "Edwin L. Culp W." To: Daniel Nebdal Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: I am very confused and would appreciate some help on device renameing or on renumbering on current fstab. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 18:19:37 -0000 On Tue, May 3, 2011 at 8:54 AM, Daniel Nebdal wrote: >> >> Thanks, John. =A0I was afraid that was the answer. Now, II'm really >> confused. =A0I'm guessing that the partitions will notl need to be shown >> in fstab (ada0s1a). =A0 What little mind I have left is a blank, >> /dev/ad4s1g will be automatically be detected. =A0Is that correct? >> >> What will I do with my second disk /dev/ad0s1a that is already zero? >> >> I apologize but I have really confused myself. =A0I've filled my glass >> with too much water and I'm drowning. >> >> Thanks for everyone's patience. >> >> ed >> >> P.S. =A0If I am not the only idiot, maybe a couple of lines as an >> example could go into UPDATING. > > If I have understood ada correct, the "first" disk (lowest current > number) is ada0, the next ada1, and so on. If you have ad0 and ad4, > they will be ad0=3Dada0, and ad4=3Dada1 . It doesn't affect anything > _except_ the disk names, so ad4s1f =3D ada1s1f and so on. You'll have to > change most of your fstab, basically s/ad0/ada0/g and s/ad4/ada1/g . > > That said, my one ad to ada transition was on a ZFS-only system, which > took the fstab editing out of it. I might be horribly wrong in some or > all of the above. Thanks, Daniel. Your explanation makes sense to me and to eleminate problems with ad0, it is an old disk, that I will bring up later and just change ad4 to ada0 and ad4s1g to ada0s1g, etc. and reboot it again early tomorrow morning about 5 am CDT and will post a working fstab, if I manage to get it to work. Thanks again, ed > > -- > Daniel Nebdal > From owner-freebsd-current@FreeBSD.ORG Tue May 3 18:30:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7643B1065674 for ; Tue, 3 May 2011 18:30:29 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id 192B38FC13 for ; Tue, 3 May 2011 18:30:28 +0000 (UTC) Received: from megatron.madpilot.net (localhost [127.0.0.1]) by megatron.madpilot.net (Postfix) with ESMTP id A751F14E2 for ; Tue, 3 May 2011 20:13:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :references:subject:subject:mime-version:user-agent:from:from :date:date:message-id:received:received; s=mail; t=1304446421; x=1306260821; bh=CbbUyIyChe60TkinlzqlsBkarZplbsk7+IJf/xei6+g=; b= tizHJ9TOf7LkKlkOgsZX8P0WjrSSfXXpKP0rmrnn2+1Cf/DLBOToPI61KP+DPZYW 1mR1tdoxqQGeZqVZPqV7FR0IuptzALEqFzL269BbxzYabp2fdolnbOiCQRqC5ajE sSyna/gCbD7MU/8U6/KnNiSvoHhCIeuaS9x5P/HnVYE= X-Virus-Scanned: amavisd-new at madpilot.net Received: from megatron.madpilot.net ([127.0.0.1]) by megatron.madpilot.net (megatron.madpilot.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCpXJbpFUz8N for ; Tue, 3 May 2011 20:13:41 +0200 (CEST) Received: from marvin.madpilot.net (localhost [127.0.0.1]) by megatron.madpilot.net (Postfix) with ESMTP for ; Tue, 3 May 2011 20:13:41 +0200 (CEST) Message-ID: <4DC045D5.7000802@madpilot.net> Date: Tue, 03 May 2011 20:13:41 +0200 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20110503174949.7ada20dc@laptop> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: firefox4+html5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 18:30:29 -0000 On 05/03/11 19:19, Francois Gerodez wrote: > Hi all, > > I'm currently running FreeBSD 8.1 (latest update) and I'm experiencing a > similar issue. HTML5 videos are very laggy (both image and sound) with > Firefox 4. I ended up installing the flash player to watch youtube > streaming. > > I didn't spot any particular warning/error messages so I don't know where to > start... > I have these symptoms too, but usually if I pause the video, send it back to the start with the slider and finally start playing it goes smoothly usually. This is quite strange, I know. Perhaps someone else should check if this is the same for everyone or just something that is happening to me. -- Guido Falsi From owner-freebsd-current@FreeBSD.ORG Tue May 3 18:35:43 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B58281065675 for ; Tue, 3 May 2011 18:35:43 +0000 (UTC) (envelope-from lacombar@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 7D2168FC1B for ; Tue, 3 May 2011 18:35:43 +0000 (UTC) Received: by iwn33 with SMTP id 33so417180iwn.13 for ; Tue, 03 May 2011 11:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=r6JCYHV+5tUxJdiHCYFRBaDKD7dnTmInLdWD2Kvm+to=; b=hcRbJhUO9rijZ6MG4fFsKKTLck1fw15KP3LW+TV5I2G/p/5QPRV02Q/KfY+3JAvOA5 nWfZ+f83egTeHkeUm5C+ReZCJjJk1bHbL15fqiPXVEZEnUh/lR77LsB8AAAuZZqPgsYY C4hfe1Nt+ldgqr/599mHi27H6TrkD9D/eszGg= 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=ZxyLpJsAYUJsXzRBqibuVtUtPhlixGh6FTcktrOfuBCJNj8v//L35JfI5t3YmwlqL+ iWAqbNqVUPSSLliOvP8dWpDREMGQlaxU3YtSKffBsTfV9y8uuhfY3Y2gfx/gxPyf/w1w b0u2DUwnmq5LOtabWRMJnhyl/dR+cB6O4axIY= MIME-Version: 1.0 Received: by 10.42.246.133 with SMTP id ly5mr210035icb.404.1304447742602; Tue, 03 May 2011 11:35:42 -0700 (PDT) Received: by 10.42.167.5 with HTTP; Tue, 3 May 2011 11:35:42 -0700 (PDT) In-Reply-To: References: Date: Tue, 3 May 2011 14:35:42 -0400 Message-ID: From: Arnaud Lacombe To: "Edwin L. Culp W." Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current Subject: Re: I am very confused and would appreciate some help on device renameing or on renumbering on current fstab. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 18:35:43 -0000 Hi, On Tue, May 3, 2011 at 7:16 AM, Edwin L. Culp W. wrote: > ... thanks a lot to have posted the same message, twice, under different subject... - Arnaud From owner-freebsd-current@FreeBSD.ORG Tue May 3 18:35:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 765E91065784; Tue, 3 May 2011 18:35:52 +0000 (UTC) (envelope-from edwinlculp@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1260B8FC15; Tue, 3 May 2011 18:35:51 +0000 (UTC) Received: by vxc34 with SMTP id 34so418319vxc.13 for ; Tue, 03 May 2011 11:35:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Ls+IO6wcwvYbmqIFwvcdkthvIhAei6TTtk6PGex9x8M=; b=gFN1OeQjxWhLXJ1qmAhgKfO2DyEpcvB57xePcmkIrCNquko+KNYtpLMzAbhYAOs0Bs tOVCvAYwCaGtHg2itBCu3peuWNhxjNbYyelKwDJRhPMSTKRCyUZnHT2iFyJAKfVsVmif 7xW8/6Mt52KwAH4pYOaaKRt2rDL8GOweXBvlw= 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=P+IL21NHvJ3/rdsZRsz66eFCsMrp8HoSTjtqMsGB3IJ/jQSLf9CciWC/OTW6pP34EL a/twzzqY2tP2bjhrdwt4tpoez8rMIpOOl+Yx4zDz7N1orLU2jIV8htkAX8oEKWpcaIal FiQKi2IQpzNmveVRgw63Y2kkUKSiPVSySw46o= MIME-Version: 1.0 Received: by 10.52.68.168 with SMTP id x8mr226808vdt.77.1304447751058; Tue, 03 May 2011 11:35:51 -0700 (PDT) Received: by 10.52.107.5 with HTTP; Tue, 3 May 2011 11:35:51 -0700 (PDT) In-Reply-To: <201105031002.36612.jhb@freebsd.org> References: <201105030759.09518.jhb@freebsd.org> <201105031002.36612.jhb@freebsd.org> Date: Tue, 3 May 2011 13:35:51 -0500 Message-ID: From: "Edwin L. Culp W." To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: I am very confused and would appreciate some help on device renameing or on renumbering on current fstab. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 18:35:52 -0000 On Tue, May 3, 2011 at 9:02 AM, John Baldwin wrote: > On Tuesday, May 03, 2011 8:51:02 am Edwin L. Culp W. wrote: >> On Tue, May 3, 2011 at 6:59 AM, John Baldwin wrote: >> > On Tuesday, May 03, 2011 7:16:34 am Edwin L. Culp W. wrote: >> >> I have two disks on this old machine that I have keep current sin >> >> FreeBSD 6 IIRC as preparation for all the new goodies but this really >> >> bit me in the morning with a generic kernel and had a heck of a time >> >> getting it up. >> >> >> >> I have a new kernel with the new options. >> >> =A0 =A0 =A0 =A0 =A0 =A0 options =A0 =A0 =A0 =A0ATA_CAM >> >> =A0 =A0 =A0 =A0 =A0 =A0 device =A0 =A0 =A0 =A0 ahci >> >> =A0 =A0 =A0 =A0 =A0 =A0 device =A0 =A0 =A0 =A0 mvs >> >> =A0 =A0 =A0 =A0 =A0 =A0 device =A0 =A0 =A0 =A0 siis >> >> >> >> This =A0morning was such a shock that I am tempted to go back to the = old >> >> kernel config that I understand still works but gonna try to bite the >> >> bullit. >> >> >> >> My fstab that I assume is still needed, is as before, although I had >> >> changed ad4xx to ada4xx (etc) that I found was incorrect the HARD way >> >> after trying to reboot; >> >> >> >> =A0/dev/ad4s1b =A0 =A0 =A0 =A0 =A0 =A0none =A0 =A0 =A0 =A0 =A0 =A0swa= p =A0 =A0sw =A0 =A0 =A0 =A0 =A0 =A0 =A00 =A0 =A0 =A0 0 >> >> =A0/dev/ad4s1a =A0 =A0 =A0 =A0 =A0 =A0/ =A0 =A0 =A0 =A0 =A0 =A0 =A0 u= fs =A0 =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A01 =A0 =A0 =A0 1 >> >> =A0/dev/ad4s2g =A0 =A0 =A0 =A0 =A0 =A0/backup =A0 =A0 =A0 =A0 ufs =A0= =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 >> >> =A0/dev/ad4s1g =A0 =A0 =A0 =A0 =A0 =A0/home =A0 =A0 =A0 =A0 =A0 ufs = =A0 =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 >> >> =A0/dev/ad4s2f =A0 =A0 =A0 =A0 =A0 =A0/release =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0ufs =A0 =A0 rw >> >> =A02 =A0 =A0 =A0 2 >> >> =A0/dev/ad4s2d =A0 =A0 =A0 =A0 =A0 =A0/tmp =A0 =A0 =A0 =A0 =A0 =A0ufs= =A0 =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 >> >> =A0/dev/ad4s1e =A0 =A0 =A0 =A0 =A0 =A0/usr =A0 =A0 =A0 =A0 =A0 =A0ufs= =A0 =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 >> >> =A0/dev/ad4s1h =A0 =A0 =A0 =A0 =A0 =A0/usr/local =A0 =A0 =A0 =A0 =A0 = =A0 =A0ufs =A0 =A0 rw >> >> =A02 =A0 =A0 =A0 2 >> >> =A0/dev/ad4s1f =A0 =A0 =A0 =A0 =A0 =A0/var =A0 =A0 =A0 =A0 =A0 =A0ufs= =A0 =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 >> >> =A0/dev/ad4s2e =A0 =A0 =A0 =A0 =A0 =A0/var/tmp =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0ufs =A0 =A0 rw >> >> =A02 =A0 =A0 =A0 2 >> >> =A0/dev/acd0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/cdrom =A0 =A0 =A0 =A0 =A0cd9= 660 =A0ro,noauto =A0 =A0 =A0 0 =A0 =A0 =A0 0 >> >> =A0/dev/acd1 =A0 =A0 =A0 =A0 =A0 =A0 =A0/cdrom1 =A0 =A0 =A0 =A0 cd966= 0 =A0ro,noauto =A0 =A0 =A0 0 =A0 =A0 =A0 0 >> >> =A0/dev/cd0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /cdrom =A0 =A0 =A0 =A0 =A0cd9= 660 =A0ro,noauto =A0 =A0 =A0 0 =A0 =A0 =A0 0 >> >> =A0/dev/cd1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /cdrom =A0 =A0 =A0 =A0 =A0cd9= 660 =A0ro,noauto =A0 =A0 =A0 0 =A0 =A0 =A0 0 >> >> # >> >> /dev/ad0s1a =A0 =A0 =A0 =A0 =A0 /new =A0 =A0 =A0 =A0 =A0 =A0ufs =A0 = =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A01 =A0 =A0 =A0 1 >> >> /dev/ad0s1g =A0 =A0 =A0 =A0 =A0/new/home =A0 =A0 =A0 ufs =A0 =A0 rw = =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 >> >> /dev/ad0s1d =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/new/tmp =A0 =A0 =A0 =A0uf= s =A0 =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 >> >> /dev/ad0s1e =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/new/usr =A0 =A0 =A0 =A0uf= s =A0 =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 >> >> /dev/ad0s1h =A0 =A0 =A0 =A0 =A0/new/usr/local =A0ufs =A0 =A0 rw =A0 = =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 >> >> /dev/ad0s1f =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/new/var =A0 =A0 =A0 =A0uf= s =A0 =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 >> >> >> >> I am totally confused on how these should now be. >> >> >> >> Any and all help appreciated. >> > >> > It will be ada0 rather than ad4. =A0With adaX the weird ATA_STATIC_ID = stuff is >> > gone and ATA disks are now numbered starting from 0 just like SCSI dis= ks use >> > da0, da1, ... etc. >> > >> > -- >> > John Baldwin >> > >> >> Thanks, John. =A0I was afraid that was the answer. Now, II'm really >> confused. =A0I'm guessing that the partitions will notl need to be shown >> in fstab (ada0s1a). =A0 What little mind I have left is a blank, >> /dev/ad4s1g will be automatically be detected. =A0Is that correct? >> >> What will I do with my second disk /dev/ad0s1a that is already zero? >> >> I apologize but I have really confused myself. =A0I've filled my glass >> with too much water and I'm drowning. >> >> Thanks for everyone's patience. >> >> ed >> >> P.S. =A0If I am not the only idiot, maybe a couple of lines as an >> example could go into UPDATING. > > Oh, I missed that you had an ad0. =A0Most likely ad0 will become ada0, an= d > ad4 will become ada1. =A0All the partitions will still exist, so ad0s1a > will become ada0s1a and ad4s1a will become ada1s1a. > > There is a chance that ad0 will become ada1 and ad4 will become ada1 > instead. =A0That depends on how your PCI devices are laid out on the > PCI bus. =A0I can't answer that without seeing a dmesg though. > > Do you have mav's latest changes? =A0They should provide aliases for the > old names along with printfs to let you know what the new names are for > each old disk I think. > > -- > John Baldwin > Thanks, John. I apologize for being so thick on this but since I screwed it up the first time, but It took a few extra minutes to get it up and make me a bit nervous. Need it for dns and a few other things, . I cvsup current, build and install a new world and kernel every morning so I assume that I should have mav's latest changes. I'll try it again in the morning with the new build, correct kernel config and fstab entry.. I'll report the results on this thread then. Thanks for you help. ed From owner-freebsd-current@FreeBSD.ORG Tue May 3 18:55:57 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6E4C106566C for ; Tue, 3 May 2011 18:55:57 +0000 (UTC) (envelope-from edwinlculp@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 920398FC1F for ; Tue, 3 May 2011 18:55:57 +0000 (UTC) Received: by qwc9 with SMTP id 9so305566qwc.13 for ; Tue, 03 May 2011 11:55:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/HxVulTPwBBa25qbrUQ8sjrj9JeOiUxw7XSqt+QSswQ=; b=WC3Y3ic60bpwfiRUbXmb8liirAM5KrtmcWzNIT2nG1YLsN3+OT/MsNmVJpqbPU00re Nm7V0hNOBRDcpK0570FjJwqt5rnXPhj3mP6ftK7il8HQUEzHhWqd721UuYXUmFPdUgtJ RpPYFIFpPWAE1ukEi6/so6rLhmBlnSOmMpCp0= 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=cS2+pNpTeVBpKB1vopUhYCA+jXNpu1nTB1HfZJk63dhZR07CzrUFwqjTZFriE2lUPl TS/uHCm743HM6QjbdKSTLI3P7UsFE+JOU6ECavlpfF3K1Euf7UDspgYyFqCJnyl7RitP DHzS/BM0B+6ztzkap32pJiG6YOGae7b42CUMQ= MIME-Version: 1.0 Received: by 10.52.175.99 with SMTP id bz3mr251294vdc.117.1304448956393; Tue, 03 May 2011 11:55:56 -0700 (PDT) Received: by 10.52.107.5 with HTTP; Tue, 3 May 2011 11:55:56 -0700 (PDT) In-Reply-To: References: <20110502192852.18002gkkic9fy44k@econet.encontacto.net> Date: Tue, 3 May 2011 13:55:56 -0500 Message-ID: From: "Edwin L. Culp W." To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current , eculp Subject: Re: Totally confused with the /usrsrc/UPDATING for 20110424 CAM-based ATA stack X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 18:55:57 -0000 On Tue, May 3, 2011 at 12:56 PM, Arnaud Lacombe wrote: > Hi, > > On Mon, May 2, 2011 at 8:28 PM, eculp wrote: >> With this confusion I need someone to give me an idea on renumbering. >> >> I have two disks on this old machine that I have keep current sin FreeBS= D 6 >> IIRC as preparation for all the new goodies but this really bit me in th= e >> morning with a generic kernel and had a heck of a time getting it up. >> >> I have a new kernel with the new options. >> =A0 =A0 =A0 =A0 =A0 =A0options =A0 =A0 =A0 =A0ATA_CAM >> =A0 =A0 =A0 =A0 =A0 =A0device =A0 =A0 =A0 =A0 ahci >> =A0 =A0 =A0 =A0 =A0 =A0device =A0 =A0 =A0 =A0 mvs >> =A0 =A0 =A0 =A0 =A0 =A0device =A0 =A0 =A0 =A0 siis >> > I've got the following in my stripped down GENERIC: > > # ATA controllers > device =A0 =A0 =A0 =A0 =A0ahci =A0 =A0 =A0 =A0 =A0 =A0# AHCI-compatible S= ATA controllers > device =A0 =A0 =A0 =A0 =A0ata =A0 =A0 =A0 =A0 =A0 =A0 # Legacy ATA/SATA c= ontrollers > options =A0 =A0 =A0 =A0 ATA_CAM =A0 =A0 =A0 =A0 # Handle legacy controlle= rs with CAM > > # ATA/SCSI peripherals > device =A0 =A0 =A0 =A0 =A0scbus =A0 =A0 =A0 =A0 =A0 # SCSI bus (required = for ATA/SCSI) > device =A0 =A0 =A0 =A0 =A0da =A0 =A0 =A0 =A0 =A0 =A0 =A0# Direct Access (= disks) > device =A0 =A0 =A0 =A0 =A0pass =A0 =A0 =A0 =A0 =A0 =A0# Passthrough devic= e (direct ATA/SCSI access) > > I'm able to boot from CF on a couple of different machine. It would > seem that without: > > device =A0 =A0 =A0 =A0 =A0ata =A0 =A0 =A0 =A0 =A0 =A0 # Legacy ATA/SATA c= ontrollers > > the disk is not detected. With, the disk shows up as: > > ada0 at ata3 bus 0 scbus1 target 0 lun 0 > ada0: < 20070709> ATA-0 device > ada0: 16.700MB/s transfers (WDMA2, PIO 512bytes) > ada0: 967MB (1981728 512 byte sectors: 16H 63S/T 1966C) > ada0: Previously was known as ad0 > > and I did not need any /etc/fstab modification. > > my .2 credits, > =A0- Arnaud Thanks Arnaud, Again I apologize of having posted this problem twice but as I mentioned on the previous thread the machine in question is dns and my screwing with it to get it up and runing having a bad fstab. I wrote this email before checking and I thought it was lost. Tomorrow morning I'll get to the bottom of my misunderstanding and hopefully be able to help make this a bit more clear for others who haven't taken the jump yet. ed > >> This =A0morning was such a shock that I am tempted to go back to the old >> kernel config that I understand still works but gonna try to bite the >> bullit. >> >> My fstab that I assume is still necessary is: >> >> =A0/dev/ad4s1b =A0 =A0 =A0 =A0 =A0 =A0none =A0 =A0 =A0 =A0 =A0 =A0swap = =A0 =A0sw =A0 =A0 =A0 =A0 =A0 =A0 =A00 =A0 =A0 =A0 0 >> =A0/dev/ad4s1a =A0 =A0 =A0 =A0 =A0 =A0/ =A0 =A0 =A0 =A0 =A0 =A0 =A0 ufs = =A0 =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A01 =A0 =A0 =A0 1 >> =A0/dev/ad4s2g =A0 =A0 =A0 =A0 =A0 =A0/backup =A0 =A0 =A0 =A0 ufs =A0 = =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 >> =A0/dev/ad4s1g =A0 =A0 =A0 =A0 =A0 =A0/home =A0 =A0 =A0 =A0 =A0 ufs =A0 = =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 >> =A0/dev/ad4s2f =A0 =A0 =A0 =A0 =A0 =A0/release =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0ufs =A0 =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 >> =A0 =A0 2 >> =A0/dev/ad4s2d =A0 =A0 =A0 =A0 =A0 =A0/tmp =A0 =A0 =A0 =A0 =A0 =A0ufs = =A0 =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 >> =A0/dev/ad4s1e =A0 =A0 =A0 =A0 =A0 =A0/usr =A0 =A0 =A0 =A0 =A0 =A0ufs = =A0 =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 >> =A0/dev/ad4s1h =A0 =A0 =A0 =A0 =A0 =A0/usr/local =A0 =A0 =A0 =A0 =A0 =A0= =A0ufs =A0 =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 >> =A0 =A0 2 >> =A0/dev/ad4s1f =A0 =A0 =A0 =A0 =A0 =A0/var =A0 =A0 =A0 =A0 =A0 =A0ufs = =A0 =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 >> =A0/dev/ad4s2e =A0 =A0 =A0 =A0 =A0 =A0/var/tmp =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0ufs =A0 =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 >> =A0 =A0 2 >> =A0/dev/acd0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/cdrom =A0 =A0 =A0 =A0 =A0cd9660= =A0ro,noauto =A0 =A0 =A0 0 =A0 =A0 =A0 0 >> =A0/dev/acd1 =A0 =A0 =A0 =A0 =A0 =A0 =A0/cdrom1 =A0 =A0 =A0 =A0 cd9660 = =A0ro,noauto =A0 =A0 =A0 0 =A0 =A0 =A0 0 >> =A0/dev/cd0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /cdrom =A0 =A0 =A0 =A0 =A0cd9660= =A0ro,noauto =A0 =A0 =A0 0 =A0 =A0 =A0 0 >> =A0/dev/cd1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /cdrom =A0 =A0 =A0 =A0 =A0cd9660= =A0ro,noauto =A0 =A0 =A0 0 =A0 =A0 =A0 0 >> # >> /dev/ad0s1a =A0 =A0 =A0 =A0 =A0 /new =A0 =A0 =A0 =A0 =A0 =A0ufs =A0 =A0 = rw =A0 =A0 =A0 =A0 =A0 =A0 =A01 =A0 =A0 =A0 1 >> /dev/ad0s1g =A0 =A0 =A0 =A0 =A0/new/home =A0 =A0 =A0 ufs =A0 =A0 rw =A0 = =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 >> /dev/ad0s1d =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/new/tmp =A0 =A0 =A0 =A0ufs = =A0 =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 >> /dev/ad0s1e =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/new/usr =A0 =A0 =A0 =A0ufs = =A0 =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 >> /dev/ada01h =A0 =A0 =A0 =A0 =A0/new/usr/local =A0ufs =A0 =A0 rw =A0 =A0 = =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 >> /dev/ada01f =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/new/var =A0 =A0 =A0 =A0ufs = =A0 =A0 rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 >> >> I am totally confused on how these should now be. >> >> Any help appreciated. >> >> ed >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Tue May 3 19:13:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16339106564A for ; Tue, 3 May 2011 19:13:24 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id EB7138FC22 for ; Tue, 3 May 2011 19:13:23 +0000 (UTC) Received: by pwj8 with SMTP id 8so251015pwj.13 for ; Tue, 03 May 2011 12:13:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.4.129 with SMTP id k1mr291275pbk.72.1304450003381; Tue, 03 May 2011 12:13:23 -0700 (PDT) Received: by 10.68.40.4 with HTTP; Tue, 3 May 2011 12:13:23 -0700 (PDT) In-Reply-To: <4DC04F29.2050401@mail.zedat.fu-berlin.de> References: <4DBDB8D4.6050102@mail.zedat.fu-berlin.de> <4DC04F29.2050401@mail.zedat.fu-berlin.de> Date: Tue, 3 May 2011 21:13:23 +0200 Message-ID: From: Olivier Smedts To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Building FreeBSD 9.0-CUR/amd64 with CLANG fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 19:13:24 -0000 2011/5/3 O. Hartmann : > On 05/02/11 14:19, Olivier Smedts wrote: >> >> 2011/5/1 O. Hartmann: >>> >>> Well, >>> I tried the first time building FreeBSD 9.0-CURRENT/amd64 (sources from >>> today's latest svn) and it failed (taken the /etc/make.conf addition fr= om >>> the wiki), giving the below showed error. >> >> Did you follow the instructions on the wiki ? Do you have the >> following lines in your /etc/make.conf ? >> NO_WERROR=3D >> WERROR=3D >> >>> Is this a well known issue and FreeBSD isn't building correctly at the >>> moment or did I miss something (not mentioned on the wiki's page)? >>> > > Today, I tried again, after CLANG/LLVM has been updated to version 3.0. > Same error. > > This is the addendum I made to the /etc/make.conf: > > ## > ## =A0 =A0 =A0CLANG > ## > .if defined(USE_CLANG) Why do you have the previous line ? Can you try without it and the last end= if ? > .if !defined(CC) || ${CC} =3D=3D "cc" > CC=3Dclang > .endif > .if !defined(CXX) || ${CXX} =3D=3D "c++" > CXX=3Dclang++ > .endif > # Don't die on warnings > NO_WERROR=3D > WERROR=3D > # Don't forget this when using Jails! > NO_FSCHG=3D > .endif > > > I think I should file a PR ... > > oliver > --=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-current@FreeBSD.ORG Tue May 3 18:53:31 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F39551065675 for ; Tue, 3 May 2011 18:53:30 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 9F4A38FC15 for ; Tue, 3 May 2011 18:53:30 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1QHKiv-0001Wt-Cj>; Tue, 03 May 2011 20:53:29 +0200 Received: from e178037031.adsl.alicedsl.de ([85.178.37.31] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1QHKiv-0007pp-6r>; Tue, 03 May 2011 20:53:29 +0200 Message-ID: <4DC04F29.2050401@mail.zedat.fu-berlin.de> Date: Tue, 03 May 2011 20:53:29 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Olivier Smedts References: <4DBDB8D4.6050102@mail.zedat.fu-berlin.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Originating-IP: 85.178.37.31 X-Mailman-Approved-At: Tue, 03 May 2011 19:47:23 +0000 Cc: freebsd-current@freebsd.org Subject: Re: Building FreeBSD 9.0-CUR/amd64 with CLANG fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 18:53:31 -0000 On 05/02/11 14:19, Olivier Smedts wrote: > 2011/5/1 O. Hartmann: >> Well, >> I tried the first time building FreeBSD 9.0-CURRENT/amd64 (sources fro= m >> today's latest svn) and it failed (taken the /etc/make.conf addition f= rom >> the wiki), giving the below showed error. > > Did you follow the instructions on the wiki ? Do you have the > following lines in your /etc/make.conf ? > NO_WERROR=3D > WERROR=3D > >> Is this a well known issue and FreeBSD isn't building correctly at the= >> moment or did I miss something (not mentioned on the wiki's page)? >> >> >> >> clang: warning: argument unused during compilation: >> '-finhibit-size-directive' >> clang: warning: argument unused during compilation: '-fno-toplevel-reo= rder' >> sh /usr/src/tools/install.sh -o root -g wheel -m 444 =EF=BF=BDcrtbegin= =2Eo >> /usr/obj/usr/src/lib32/usr/lib32/crtbegin.o >> sh /usr/src/tools/install.sh -o root -g wheel -m 444 =EF=BF=BDcrtend.o= >> /usr/obj/usr/src/lib32/usr/lib32/crtend.o >> sh /usr/src/tools/install.sh -o root -g wheel -m 444 =EF=BF=BDcrtbegin= T.o >> /usr/obj/usr/src/lib32/usr/lib32/crtbeginT.o >> sh /usr/src/tools/install.sh -o root -g wheel -m 444 =EF=BF=BDcrtbegin= =2ESo >> /usr/obj/usr/src/lib32/usr/lib32/crtbeginS.o >> sh /usr/src/tools/install.sh -o root -g wheel -m 444 =EF=BF=BDcrtend.S= o >> /usr/obj/usr/src/lib32/usr/lib32/crtendS.o >> =3D=3D=3D> lib/csu/i386-elf (obj,depend,all,install) >> rm -f .depend >> CC=3D'clang' mkdep -f .depend -a =EF=BF=BD =EF=BF=BD-I/usr/src/lib/csu= /i386-elf/../common >> -I/usr/src/lib/csu/i386-elf/../../libc/include >> /usr/src/lib/csu/i386-elf/crti.S /usr/src/lib/csu/i386-elf/crtn.S >> clang -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common >> -I/usr/src/lib/csu/i386-elf/../../libc/include -std=3Dgnu99 -Wsystem-h= eaders >> -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes >> -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual >> -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align >> -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls >> -Wold-style-definition -Wno-pointer-sign =EF=BF=BD-c >> /usr/src/lib/csu/i386-elf/crti.S >> clang -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common >> -I/usr/src/lib/csu/i386-elf/../../libc/include -std=3Dgnu99 -Wsystem-h= eaders >> -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes >> -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual >> -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align >> -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls >> -Wold-style-definition -Wno-pointer-sign =EF=BF=BD-c >> /usr/src/lib/csu/i386-elf/crtn.S >> clang -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common >> -I/usr/src/lib/csu/i386-elf/../../libc/include -std=3Dgnu99 -Wsystem-h= eaders >> -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes >> -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual >> -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align >> -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls >> -Wold-style-definition -Wno-pointer-sign -DGCRT -S -o gcrt1_c.s >> /usr/src/lib/csu/i386-elf/crt1_c.c >> sed -i "" -e '/\.note\.ABI-tag/s/progbits/note/' gcrt1_c.s >> clang -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common >> -I/usr/src/lib/csu/i386-elf/../../libc/include -std=3Dgnu99 -Wsystem-h= eaders >> -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes >> -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual >> -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align >> -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls >> -Wold-style-definition -Wno-pointer-sign -c -o gcrt1_c.o gcrt1_c.s >> clang: warning: argument unused during compilation: '-I >> /usr/src/lib/csu/i386-elf/../common' >> clang: warning: argument unused during compilation: '-I >> /usr/src/lib/csu/i386-elf/../../libc/include' >> clang: warning: argument unused during compilation: '-std=3Dgnu99' >> clang: warning: argument unused during compilation: '-Wsystem-headers'= >> clang: warning: argument unused during compilation: '-Wall' >> clang: warning: argument unused during compilation: '-Wno-format-y2k' >> clang: warning: argument unused during compilation: '-W' >> clang: warning: argument unused during compilation: '-Wno-unused-param= eter' >> clang: warning: argument unused during compilation: '-Wstrict-prototyp= es' >> clang: warning: argument unused during compilation: '-Wmissing-prototy= pes' >> clang: warning: argument unused during compilation: '-Wpointer-arith' >> clang: warning: argument unused during compilation: '-Wreturn-type' >> clang: warning: argument unused during compilation: '-Wcast-qual' >> clang: warning: argument unused during compilation: '-Wwrite-strings' >> clang: warning: argument unused during compilation: '-Wswitch' >> clang: warning: argument unused during compilation: '-Wshadow' >> clang: warning: argument unused during compilation: '-Wunused-paramete= r' >> clang: warning: argument unused during compilation: '-Wcast-align' >> clang: warning: argument unused during compilation: '-Wchar-subscripts= ' >> clang: warning: argument unused during compilation: '-Winline' >> clang: warning: argument unused during compilation: '-Wnested-externs'= >> clang: warning: argument unused during compilation: '-Wredundant-decls= ' >> clang: warning: argument unused during compilation: '-Wold-style-defin= ition' >> clang: warning: argument unused during compilation: '-Wno-pointer-sign= ' >> clang -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common >> -I/usr/src/lib/csu/i386-elf/../../libc/include -std=3Dgnu99 -Wsystem-h= eaders >> -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes >> -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual >> -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align >> -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls >> -Wold-style-definition -Wno-pointer-sign =EF=BF=BD-c >> /usr/src/lib/csu/i386-elf/crt1_s.S >> ld -m elf_i386_fbsd -Y P,/usr/obj/usr/src/lib32/usr/lib32 =EF=BF=BD-o = gcrt1.o -r >> crt1_s.o gcrt1_c.o >> ld: Relocatable linking with relocations from format elf64-x86-64-free= bsd >> (crt1_s.o) to format elf32-i386-freebsd (gcrt1.o) is not supported >> *** Error code 1 >> >> Stop in /usr/src/lib/csu/i386-elf. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 Today, I tried again, after CLANG/LLVM has been updated to version 3.0. Same error. This is the addendum I made to the /etc/make.conf: ## ## CLANG ## =2Eif defined(USE_CLANG) =2Eif !defined(CC) || ${CC} =3D=3D "cc" CC=3Dclang =2Eendif =2Eif !defined(CXX) || ${CXX} =3D=3D "c++" CXX=3Dclang++ =2Eendif # Don't die on warnings NO_WERROR=3D WERROR=3D # Don't forget this when using Jails! NO_FSCHG=3D =2Eendif I think I should file a PR ... oliver From owner-freebsd-current@FreeBSD.ORG Tue May 3 19:17:59 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1251106564A for ; Tue, 3 May 2011 19:17:59 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 8CBE28FC12 for ; Tue, 3 May 2011 19:17:59 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1QHL6c-0004jB-KR>; Tue, 03 May 2011 21:17:58 +0200 Received: from e178037031.adsl.alicedsl.de ([85.178.37.31] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1QHL6c-0000oc-HU>; Tue, 03 May 2011 21:17:58 +0200 Message-ID: <4DC054E6.3030801@mail.zedat.fu-berlin.de> Date: Tue, 03 May 2011 21:17:58 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Olivier Smedts References: <4DBDB8D4.6050102@mail.zedat.fu-berlin.de> <4DC04F29.2050401@mail.zedat.fu-berlin.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Originating-IP: 85.178.37.31 X-Mailman-Approved-At: Tue, 03 May 2011 21:10:25 +0000 Cc: freebsd-current@freebsd.org Subject: Re: Building FreeBSD 9.0-CUR/amd64 with CLANG fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 19:17:59 -0000 On 05/03/11 21:13, Olivier Smedts wrote: > 2011/5/3 O. Hartmann: >> On 05/02/11 14:19, Olivier Smedts wrote: >>> >>> 2011/5/1 O. Hartmann: >>>> >>>> Well, >>>> I tried the first time building FreeBSD 9.0-CURRENT/amd64 (sources f= rom >>>> today's latest svn) and it failed (taken the /etc/make.conf addition= from >>>> the wiki), giving the below showed error. >>> >>> Did you follow the instructions on the wiki ? Do you have the >>> following lines in your /etc/make.conf ? >>> NO_WERROR=3D >>> WERROR=3D >>> >>>> Is this a well known issue and FreeBSD isn't building correctly at t= he >>>> moment or did I miss something (not mentioned on the wiki's page)? >>>> >> >> Today, I tried again, after CLANG/LLVM has been updated to version 3.0= =2E >> Same error. >> >> This is the addendum I made to the /etc/make.conf: >> >> ## >> ## =EF=BF=BD =EF=BF=BD =EF=BF=BDCLANG >> ## >> .if defined(USE_CLANG) > > Why do you have the previous line ? Can you try without it and the last= endif ? Setting USE_CLANG=3Dyes at the beginning of /etc/make.conf avoids=20 commenting out or uncommenting the CLANG-stuff. I'll try. > >> .if !defined(CC) || ${CC} =3D=3D "cc" >> CC=3Dclang >> .endif >> .if !defined(CXX) || ${CXX} =3D=3D "c++" >> CXX=3Dclang++ >> .endif >> # Don't die on warnings >> NO_WERROR=3D >> WERROR=3D >> # Don't forget this when using Jails! >> NO_FSCHG=3D >> .endif >> >> >> I think I should file a PR ... >> >> oliver >> > From owner-freebsd-current@FreeBSD.ORG Tue May 3 21:24:38 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1F341065670 for ; Tue, 3 May 2011 21:24:37 +0000 (UTC) (envelope-from jfvogel@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 AB41E8FC16 for ; Tue, 3 May 2011 21:24:37 +0000 (UTC) Received: by qwc9 with SMTP id 9so444990qwc.13 for ; Tue, 03 May 2011 14:24:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=c0r+GjJ+r2Yi4tuLurKaG1Ceq2Z2ovn9ldTDcbjMTII=; b=AyaYk/q6n1ZGnvGBHYCu37/7SYNHrTTUcMzsG43ElgkR/i1jp9wFTAvRA9wSEoSV1s pJzr9gc9jztzVnPdGKANb49ePOCIxEVbm1F4L0ANLzKxMO57ojfpqSkWzzkBUlf7hZBM x7hYP7513gNxJMJ2ubuSBZmJ4JB9/SlQSWoks= 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=EgmFhPz47QBfIjr0Gxe74zvKhdfneePLwT5NZjMqOwR9krOh74Yhq7pOL4Tyj3YlHR dOGKd4QHDZ7BQ/oB0VBLK1PwWnQXvQHIi07hNLnt+dtlW3DumPH3tnU11torV0QGD4Ng oKdexAGqPYBDqqu0KZrGq8YPLYGoAiJJapKno= MIME-Version: 1.0 Received: by 10.52.89.2 with SMTP id bk2mr415535vdb.284.1304457876818; Tue, 03 May 2011 14:24:36 -0700 (PDT) Received: by 10.52.184.169 with HTTP; Tue, 3 May 2011 14:24:36 -0700 (PDT) In-Reply-To: <4DC07013.9070707@gmx.net> References: <4D94A354.9080903@sentex.net> <4DC07013.9070707@gmx.net> Date: Tue, 3 May 2011 14:24:36 -0700 Message-ID: From: Jack Vogel To: Michael Schmiedgen Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Olivier Smedts , FreeBSD current mailing list , Mike Tancsa Subject: Re: problems with em(4) since update to driver 7.2.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 21:24:38 -0000 If you get the setup receive structures fail, then increase the nmbclusters. If you use standard MTU then what you need are mbufs, and standard size clusters (2K). Only when you use jumbo frames will you need larger. You must configure enough, its that simple. Jack On Tue, May 3, 2011 at 2:13 PM, Michael Schmiedgen wrote: > Hi, > > I have the very same problem. > > - GENERIC 9.0-CURRENT (April 28) > - em0 PRO/1000 7.2.3 > > - "em0: Could not setup receive structures" > > On 03.05.2011 10:58, Olivier Smedts wrote: > >> I tried increasing kern.ipc.nmbjumbo* (is it what you suggested ?). >> Values doubled : >> kern.ipc.nmbjumbo16: 6400 >> kern.ipc.nmbjumbo9: 12800 >> kern.ipc.nmbjumbop: 25600 >> >> And unloaded / reloaded the kernel module. Still no luck, same >> problem, on latest 9-CURRENT (r221363). >> > > Same here. > > If I should provide some more configuration settings, > please let me know. > > Michael > > From owner-freebsd-current@FreeBSD.ORG Tue May 3 21:36:03 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03D7110656B9 for ; Tue, 3 May 2011 21:36:03 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id B65BD8FC31 for ; Tue, 3 May 2011 21:36:02 +0000 (UTC) Received: from julian-mac.elischer.org ([216.51.42.66]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p43LZwgc016801 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 3 May 2011 14:36:00 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4DC07535.4050809@freebsd.org> Date: Tue, 03 May 2011 15:35:49 -0600 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: firewire debugging X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 21:36:03 -0000 does anyone know if there is a limitation on firewire debugging on a machine with > 4GB or memory? I have 1394 {a,b} cards. does it make a difference? also, the firewire card on one machine stops it from booting.. is there a way to disable it during boot other than recompiling the kernel without firewire? From owner-freebsd-current@FreeBSD.ORG Tue May 3 21:40:38 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBCDB1065672 for ; Tue, 3 May 2011 21:40:38 +0000 (UTC) (envelope-from schmiedgen@gmx.net) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by mx1.freebsd.org (Postfix) with SMTP id 2102B8FC0C for ; Tue, 3 May 2011 21:40:37 +0000 (UTC) Received: (qmail invoked by alias); 03 May 2011 21:13:57 -0000 Received: from dslb-088-074-229-025.pools.arcor-ip.net (EHLO [192.168.20.100]) [88.74.229.25] by mail.gmx.net (mp071) with SMTP; 03 May 2011 23:13:57 +0200 X-Authenticated: #3631242 X-Provags-ID: V01U2FsdGVkX1+jAEoluNKjLFT9XGo22AFqOiczHRdYDZt+n+KRra SeHyb5sQIR0jFl Message-ID: <4DC07013.9070707@gmx.net> Date: Tue, 03 May 2011 23:13:55 +0200 From: Michael Schmiedgen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Jack Vogel References: <4D94A354.9080903@sentex.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Olivier Smedts , FreeBSD current mailing list , Mike Tancsa Subject: Re: problems with em(4) since update to driver 7.2.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 21:40:38 -0000 Hi, I have the very same problem. - GENERIC 9.0-CURRENT (April 28) - em0 PRO/1000 7.2.3 - "em0: Could not setup receive structures" On 03.05.2011 10:58, Olivier Smedts wrote: > I tried increasing kern.ipc.nmbjumbo* (is it what you suggested ?). > Values doubled : > kern.ipc.nmbjumbo16: 6400 > kern.ipc.nmbjumbo9: 12800 > kern.ipc.nmbjumbop: 25600 > > And unloaded / reloaded the kernel module. Still no luck, same > problem, on latest 9-CURRENT (r221363). Same here. If I should provide some more configuration settings, please let me know. Michael From owner-freebsd-current@FreeBSD.ORG Tue May 3 21:50:56 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DE72106564A for ; Tue, 3 May 2011 21:50:56 +0000 (UTC) (envelope-from schmiedgen@gmx.net) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by mx1.freebsd.org (Postfix) with SMTP id 86E9A8FC13 for ; Tue, 3 May 2011 21:50:55 +0000 (UTC) Received: (qmail invoked by alias); 03 May 2011 21:50:53 -0000 Received: from dslb-088-074-229-025.pools.arcor-ip.net (EHLO [192.168.20.2]) [88.74.229.25] by mail.gmx.net (mp039) with SMTP; 03 May 2011 23:50:53 +0200 X-Authenticated: #3631242 X-Provags-ID: V01U2FsdGVkX18NJbhugFENbdfZ/tMqlEoYjuOE2bm46wUnRbnH4P L6BfTEn1+fMR2p Message-ID: <4DC078BD.9080908@gmx.net> Date: Tue, 03 May 2011 23:50:53 +0200 From: Michael Schmiedgen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Jack Vogel References: <4D94A354.9080903@sentex.net> <4DC07013.9070707@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Olivier Smedts , FreeBSD current mailing list , Mike Tancsa Subject: Re: problems with em(4) since update to driver 7.2.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 21:50:56 -0000 On 03.05.2011 23:24, Jack Vogel wrote: > If you get the setup receive structures fail, then increase the nmbclusters. > > If you use standard MTU then what you need are mbufs, and standard size > clusters (2K). > Only when you use jumbo frames will you need larger. > > You must configure enough, its that simple. I doubled the nmbclusters as well. But nothing happened. I have no load on this machine and nothing special configured. Thanks, Michael From owner-freebsd-current@FreeBSD.ORG Tue May 3 22:00:21 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DA2C106566B for ; Tue, 3 May 2011 22:00:21 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 02E458FC12 for ; Tue, 3 May 2011 22:00:20 +0000 (UTC) Received: by mail-vx0-f182.google.com with SMTP id 34so660654vxc.13 for ; Tue, 03 May 2011 15:00:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=I1hBrnPduGsGNLWbaeUk96TK0PUn4Lix2LirKJyofXs=; b=FMt0i8krIckzlhgf/+3DsJbefn1U7H2sdOiFj/kdFcbYBDYR+DzqYhmDxThBF9w4NU XmmCi6QFmyQPk9cZPRNHrhHniKhX7g25d+RAsgJAZEzJu/UCwS2YiUBYy179UQZ066p4 Ks0hNUD+0kcMABiCPD8g4O/GNn6oyQt2J/zj8= 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=XzUmu57oCz1ki/xKpXTad+73g8XkhfN5IZt7n0f113CjcKww2Qqi+BIhxjenQgK4Ek +YgISYfGffKFBSXpNH/utQQXyvYJwByDUzHJsSV8sgPQ6EelMyRZ9bMJfVHaOMNJieW5 pLSyHf1RoHkgfO1MPuewtIRyCcfm07l+ZZw64= MIME-Version: 1.0 Received: by 10.52.76.193 with SMTP id m1mr478215vdw.204.1304460020251; Tue, 03 May 2011 15:00:20 -0700 (PDT) Received: by 10.52.184.169 with HTTP; Tue, 3 May 2011 15:00:20 -0700 (PDT) In-Reply-To: <4DC078BD.9080908@gmx.net> References: <4D94A354.9080903@sentex.net> <4DC07013.9070707@gmx.net> <4DC078BD.9080908@gmx.net> Date: Tue, 3 May 2011 15:00:20 -0700 Message-ID: From: Jack Vogel To: Michael Schmiedgen Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Olivier Smedts , FreeBSD current mailing list , Mike Tancsa Subject: Re: problems with em(4) since update to driver 7.2.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 22:00:21 -0000 It has nothing to do with load, it has to do with the prerequisites to init your interfaces. The amount you need is fixed, it doesn't vary with load. Every RX descriptor needs one, so its simple math, number-of-interfaces X number-of-queues X size of the ring. If you have other network interfaces beside Intel they also consume mbufs remember. Jack On Tue, May 3, 2011 at 2:50 PM, Michael Schmiedgen wrote: > On 03.05.2011 23:24, Jack Vogel wrote: > >> If you get the setup receive structures fail, then increase the >> nmbclusters. >> >> If you use standard MTU then what you need are mbufs, and standard size >> clusters (2K). >> Only when you use jumbo frames will you need larger. >> >> You must configure enough, its that simple. >> > > I doubled the nmbclusters as well. But nothing happened. > > I have no load on this machine and nothing special > configured. > > Thanks, > Michael > From owner-freebsd-current@FreeBSD.ORG Tue May 3 23:25:28 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0E0B106564A for ; Tue, 3 May 2011 23:25:28 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.212.176]) by mx1.freebsd.org (Postfix) with ESMTP id 8BC258FC1A for ; Tue, 3 May 2011 23:25:28 +0000 (UTC) Received: by pxi11 with SMTP id 11so407117pxi.35 for ; Tue, 03 May 2011 16:25:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.4.129 with SMTP id k1mr601372pbk.72.1304465127627; Tue, 03 May 2011 16:25:27 -0700 (PDT) Received: by 10.68.40.4 with HTTP; Tue, 3 May 2011 16:25:27 -0700 (PDT) In-Reply-To: References: <4D94A354.9080903@sentex.net> <4DC07013.9070707@gmx.net> <4DC078BD.9080908@gmx.net> Date: Wed, 4 May 2011 01:25:27 +0200 Message-ID: From: Olivier Smedts To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Mike Tancsa , Jack Vogel , Michael Schmiedgen , FreeBSD current mailing list Subject: Re: problems with em(4) since update to driver 7.2.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 23:25:28 -0000 2011/5/4 Arnaud Lacombe : > A more rude version might be "Why the frak my network adapter stopped > working with the default setting ?" :) ...on a -STABLE branch --=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-current@FreeBSD.ORG Tue May 3 23:34:41 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF51E106566C for ; Tue, 3 May 2011 23:34:41 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8F7728FC12 for ; Tue, 3 May 2011 23:34:41 +0000 (UTC) Received: by iyj12 with SMTP id 12so705612iyj.13 for ; Tue, 03 May 2011 16:34:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=32IrOl6X5vbwWTpc5nwyOM7h+5KPMUVV9EZvzx3UMis=; b=K7onH9R4B24yQI8X1aeXIKdFprnXun93Xib4sKHB3LWuY/q1RQ4CdLkSnoViEDc2xE 2uOnPDLFOtRz7OJMzjD9bc98TzkJ6adk87hMLKWFB+vxKkD1lfSxTJFz3r7Y2qAVmG1Z zhMFeO538n376ZbrmQoHd9uXmssi6ZGFxNrUU= 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=MsC3mFo6CiWYXRWeKrEMylYfnQkfe0nUEWdh2RwmsGamJxb1XC2zxCacE5yQfu/cYs /ADkF2Lyld3fXFPEowSgbyYD2kL9kb+LX4mZnIEHl/eh9R57zTVXzpVSOLfHdhzq5fC/ sRatnra/OECW9dP5bdTe/EWD6PePYFjm/12F4= MIME-Version: 1.0 Received: by 10.42.162.196 with SMTP id z4mr737350icx.2.1304464277648; Tue, 03 May 2011 16:11:17 -0700 (PDT) Received: by 10.42.167.5 with HTTP; Tue, 3 May 2011 16:11:17 -0700 (PDT) In-Reply-To: References: <4D94A354.9080903@sentex.net> <4DC07013.9070707@gmx.net> <4DC078BD.9080908@gmx.net> Date: Tue, 3 May 2011 19:11:17 -0400 Message-ID: From: Arnaud Lacombe To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Olivier Smedts , FreeBSD current mailing list , Michael Schmiedgen , Mike Tancsa Subject: Re: problems with em(4) since update to driver 7.2.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 23:34:42 -0000 Hi Jack, On Tue, May 3, 2011 at 6:00 PM, Jack Vogel wrote: > It has nothing to do with load, it has to do with the prerequisites to in= it > your interfaces. > The amount you need is fixed, it doesn't vary with load. Every RX descrip= tor > needs one, > so its simple math, number-of-interfaces X number-of-queues X size of the > ring. > I guess the question is more: why would I need N*M (M > 1) nmbclusters with driver version X when driver version X-1 worked perfectly fine, from my daily-average-user point of view, with N nmbclusters ? A more rude version might be "Why the frak my network adapter stopped working with the default setting ?" :) - Arnaud > If you have other network interfaces beside Intel they also consume mbufs > remember. > > Jack > > > > On Tue, May 3, 2011 at 2:50 PM, Michael Schmiedgen wr= ote: > >> On 03.05.2011 23:24, Jack Vogel wrote: >> >>> If you get the setup receive structures fail, then increase the >>> nmbclusters. >>> >>> If you use standard MTU then what you need are mbufs, and standard size >>> clusters (2K). >>> Only when you use jumbo frames will you need larger. >>> >>> You must configure enough, its that simple. >>> >> >> I doubled the nmbclusters as well. But nothing happened. >> >> I have no load on this machine and nothing special >> configured. >> >> Thanks, >> =A0Michael >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Tue May 3 23:49:32 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B7E01065670; Tue, 3 May 2011 23:49:32 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 01FEB8FC08; Tue, 3 May 2011 23:49:32 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 1A4BB60D5; Tue, 3 May 2011 19:49:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1304466571; bh=xUxRZxZ6zvE+W5rVwIfb4ysU6U1ZRcf/sC+Th683gMk=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=HAYOVq2T8tTdOpu2BYnmo16ZIBHWZvOUyvPBZT9RQ18HTg3DCHHrPcOVVZleL6KkD noMaauAnt0WrWQiZwrF2dCLcT1B9Vtic1R8LZSiwfPpK7C3USQFnXD+DGrkwypy DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=KMn7+FYHSoThZFjz4GCpIAX8oxC3JZJyFoli0gSa6Xr+aWsUQ9uHTjUgDhxIyHg4N da7X9SOcGAZ/izZMyH0nzSvx+GF1fMw8f6N4KiBdCfU2Lu2+4SXutlcuH/G7fbg Message-ID: <4DC09489.6060804@protected-networks.net> Date: Tue, 03 May 2011 19:49:29 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: John Baldwin References: <4DBF68A4.6050405@protected-networks.net> <201105030758.12792.jhb@freebsd.org> In-Reply-To: <201105030758.12792.jhb@freebsd.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: cardbus memory allocation problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 23:49:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I have WIP patches to fix this but they aren't ready yet. > >> pcib4: I/O decode 0x4000-0x4fff >> pcib4: memory decode 0xf0900000-0xf09fffff >> *** this memory widow is what I expected all children to allocate from >> >> pcib4: no prefetched decode >> pcib4: Subtractively decoded bridge. > > It's a subtractive bridge, so the resources do not have to be allocated from > the window. That said, I'm committing the last of my patches to HEAD today to > rework how PCI-PCI bridges handle I/O windows to support growing windows, etc. > and the new PCI-PCI bridge driver will attempt to grow the memory window to > allocate a new range before falling back to depending on the subtractive > decode. You might be pleased to hear that, without any "special arrangements" in loader.conf, the new PCI-PCI code does The Right Thing with memory allocation :-) Parent bridge: I "fixed" the subordinate bus using "setpci -s 07:06.2 4c.b=02" 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) (prog-if 01 [Subtractive decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=07, subordinate=09, sec-latency=64 I/O behind bridge: 00004000-00004fff Memory behind bridge: f0900000-f09fffff Cardbus bridge: 07:06.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller Subsystem: Toshiba America Info Systems Device ff10 Flags: bus master, medium devsel, latency 64, IRQ 18 Memory at f0907000 (32-bit, non-prefetchable) Bus: primary=07, secondary=08, subordinate=09, sec-latency=32 16-bit legacy interface ports at 0001 [ .. snip .. ] Cardbus inserted .. 08:00.0 Ethernet controller: Atheros Communications Inc. Atheros AR5001X+ Wireless Network Adapter (rev 01) Subsystem: Netgear WG511T 108 Mbps Wireless PC Card (rev.A/B) Flags: medium devsel, IRQ 18 Memory at f0910000 (32-bit, non-prefetchable) Capabilities: [44] Power Management version 2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk3AlIkACgkQQv9rrgRC1JKC1ACcDVsXXN/4NrR9y707OkCMaBAm NmEAoKJfwjaP0+92LKDYI9FRDULy8gPx =m/J6 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed May 4 01:01:05 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83345106566C; Wed, 4 May 2011 01:01:05 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4C9578FC1A; Wed, 4 May 2011 01:01:05 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 71A9460D5; Tue, 3 May 2011 21:01:04 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1304470864; bh=eV5mAAP9PCbFqRReNNJIqSxSh/L7pt/FPgPZYzQCkvU=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=oXeAU7NQa//y2Noo2K12MZrcQV6ARNRMnKHaQtA6sN31xVrpsJLzUJtHtPN7hygdc 2tHc85h4oYoPYFMUR0RbGwzNNnp5KPVo9wjp8i6wc8YISOw2ppBsncaQuqS33Cn DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=eYc+s9FFdQiuhciIvlaDyuldZkDXfi2DwIq0QjqmTvpNmsUEvbRn0QlZzH/NVffHe eK3LdJ/pvX4wTYHUWZgbcgwmKElVIjWVdJPzWTogEcNzw9L3v2SuG07nDzvDmF7 Message-ID: <4DC0A54F.4010708@protected-networks.net> Date: Tue, 03 May 2011 21:01:03 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: John Baldwin References: <4DBF68A4.6050405@protected-networks.net> <201105030758.12792.jhb@freebsd.org> <4DC09489.6060804@protected-networks.net> In-Reply-To: <4DC09489.6060804@protected-networks.net> X-Enigmail-Version: 1.1.2 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: cardbus memory allocation problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 01:01:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/03/11 19:49, I wrote: > Parent bridge: > > I "fixed" the subordinate bus using "setpci -s 07:06.2 4c.b=02" Correction: this should be "pciconf -wb pci0:0:30:0 0x1a 9" imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk3ApU4ACgkQQv9rrgRC1JKDTwCgyv7JAXZgsI459vCaFOCsYlwe 8x4AnAyeMAS2c23xglr29BdYQNXftlyW =NB2b -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed May 4 01:18:20 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CA18106566C for ; Wed, 4 May 2011 01:18:20 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [216.101.162.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0FAA28FC08 for ; Wed, 4 May 2011 01:18:19 +0000 (UTC) Received: from T61p.pozo.com (t61p.pozo.com [192.168.0.4]) (authenticated bits=0) by pozo.com (8.14.4/8.14.4) with ESMTP id p4417NTR048534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 3 May 2011 18:07:23 -0700 (PDT) (envelope-from null@pozo.com) Message-Id: <201105040107.p4417NTR048534@pozo.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 03 May 2011 18:07:18 -0700 To: current@freebsd.org From: Manfred Antar Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-100.9 required=5.0 tests=ALL_TRUSTED,MISSING_MID, USER_IN_WHITELIST autolearn=no version=3.3.1, No X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: p4417NTR048534 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com Cc: Subject: Clang error make buildworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 01:18:20 -0000 I get this error when trying to buildworld on current i386. It's been this way for awhile Any Ideas ? ===> boot/i386/boot0 (all) clang -O2 -pipe -DVOLUME_SERIAL -DPXE -DFLAGS=0x8f -DTICKS=0xb6 -DCOMSPEED="7 << 5 + 3" -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -std=gnu99 -c /usr/src/sys/boot/i386/boot0/boot0.S clang: warning: argument unused during compilation: '-mpreferred-stack-boundary=2' /tmp/cc-4SXZt8.s:42:11: error: .code16 not supported yet .code16 # This runs in real mode ^ /tmp/cc-4SXZt8.s:313:3: error: unknown use of instruction mnemonic without a size suffix jmp *%bx # Invoke bootstrap ^ /tmp/cc-4SXZt8.s:346:3: error: invalid operand for instruction retw # To caller ^ /tmp/cc-4SXZt8.s:372:3: error: invalid operand for instruction retw # To caller ^ *** Error code 1 Stop in /usr/src/sys/boot/i386/boot0. *** Error code 1 Stop in /usr/src/sys/boot/i386. *** Error code 1 Stop in /usr/src/sys/boot. *** Error code 1 Stop in /usr/src/sys. Thanks Manfred ======================== || null@pozo.com || || Ph. (415) 681-6235 || ======================== -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-current@FreeBSD.ORG Wed May 4 02:26:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CD67106566B; Wed, 4 May 2011 02:26:17 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8F4DB8FC17; Wed, 4 May 2011 02:26:16 +0000 (UTC) Received: by vxc34 with SMTP id 34so934127vxc.13 for ; Tue, 03 May 2011 19:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=l1ElypN4UVXqEbOCEGRgjRPit5eBeuNjK45qJVILIW8=; b=g5f6zjm4gWdkJyIwbHCx4P4L8za6NbPOvJx3W+TBVE7sHUtpPg3rwg0L82VQEg8FWN k9l6eosXrH+ovA4dX9tbdPP0oyVvCdjg7U/T3YhHjm/dPZLXV5VIxm0RNSDHttNNW8G3 XKycF6eMzDm3H8BIgabzPjtxgIxpU/glzKQ2g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ctFAxGTbAhoDqsRJ41XUxu2SoJWOM2SYqz4hduE41P8FaKKIBddQNBNE3eWzhMg0TX YSy5eMVedCji0Pq86Sa8qtek351SLzy0lqBRaN4g8XDRHjLBQgWJ7EBpfkiHNvuutgeH IIlRF0MhdKVHC6Ct/FPRAnxk8lqOr38Q9jZMk= MIME-Version: 1.0 Received: by 10.52.183.136 with SMTP id em8mr656979vdc.262.1304475975528; Tue, 03 May 2011 19:26:15 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.52.157.202 with HTTP; Tue, 3 May 2011 19:26:15 -0700 (PDT) In-Reply-To: <201105040223.p442Nx1r026636@svn.freebsd.org> References: <201105040223.p442Nx1r026636@svn.freebsd.org> Date: Wed, 4 May 2011 10:26:15 +0800 X-Google-Sender-Auth: HnTPwcFqwYEXKnfHNOSAGZhKlHY Message-ID: From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current , freebsd-mobile@freebsd.org Subject: Fwd: svn commit: r221418 - head/sys/net80211 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 02:26:17 -0000 This has the potential to subtly break things, so I'd appreciate it if users of wireless devices would please test this out and let me know if it breaks anything. Thanks, Adrian ---------- Forwarded message ---------- From: Adrian Chadd Date: 4 May 2011 10:23 Subject: svn commit: r221418 - head/sys/net80211 To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Author: adrian Date: Wed May =A04 02:23:59 2011 New Revision: 221418 URL: http://svn.freebsd.org/changeset/base/221418 Log: =A0Fix some corner cases in the net80211 sequence number retransmission =A0handling. =A0The current sequence number code does a few things incorrectly: =A0* It didn't try eliminating duplications from HT nodes. I guess it's ass= umed =A0 =A0that out of order / retransmission handling would be handled by the = AMPDU RX =A0 =A0routines. If a HT node isn't doing AMPDU RX, then retransmissions ne= ed to =A0 =A0be eliminated. Since most of my debugging is based on this (as AMPDU= TX =A0 =A0software packet aggregation isn't yet handled), handle this corner c= ase. =A0* When a sequence number of 4095 was received, any subsequent sequence n= umber =A0 =A0is going to be (by definition) less than 4095. So if the following s= equence =A0 =A0number (0) doesn't initially occur and the retransmit is received, i= t's =A0 =A0incorrectly eliminated by the IEEE80211_FC1_RETRY && SEQ_LEQ() check= . =A0 =A0Try to handle this better. =A0This almost completely eliminates out of order TCP statistics showing up= during =A0iperf testing for the 11a, 11g and non-aggregate 11n AMPDU RX case. The = only =A0other packet loss conditions leading to this are due to baseband resets = or =A0heavy interference. Modified: =A0head/sys/net80211/ieee80211_adhoc.c =A0head/sys/net80211/ieee80211_hostap.c =A0head/sys/net80211/ieee80211_input.h =A0head/sys/net80211/ieee80211_mesh.c =A0head/sys/net80211/ieee80211_sta.c =A0head/sys/net80211/ieee80211_wds.c Modified: head/sys/net80211/ieee80211_adhoc.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/net80211/ieee80211_adhoc.c Wed May =A04 01:39:44 2011 =A0(r221417) +++ head/sys/net80211/ieee80211_adhoc.c Wed May =A04 02:23:59 2011 =A0(r221418) @@ -285,7 +285,6 @@ doprint(struct ieee80211vap *vap, int su =A0static int =A0adhoc_input(struct ieee80211_node *ni, struct mbuf *m, int rssi, int nf) =A0{ -#define =A0 =A0 =A0 =A0SEQ_LEQ(a,b) =A0 =A0((int)((a)-(b)) <=3D 0) =A0#define =A0 =A0 =A0 =A0HAS_SEQ(type) =A0 ((type & 0x4) =3D=3D 0) =A0 =A0 =A0 =A0struct ieee80211vap *vap =3D ni->ni_vap; =A0 =A0 =A0 =A0struct ieee80211com *ic =3D ni->ni_ic; @@ -412,9 +411,7 @@ adhoc_input(struct ieee80211_node *ni, s =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0TID_TO_WME_AC(tid) >= =3D WME_AC_VI) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ic->ic_wme.w= me_hipri_traffic++; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rxseq =3D le16toh(*(uint16_t= *)wh->i_seq); - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((ni->ni_flags & IEEE80211= _NODE_HT) =3D=3D 0 && - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (wh->i_fc[1] & IEEE80= 211_FC1_RETRY) && - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 SEQ_LEQ(rxseq, ni->ni= _rxseqs[tid])) { + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (! ieee80211_check_rxseq(n= i, wh)) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* duplicate= , discard */ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IEEE80211_DI= SCARD_MAC(vap, IEEE80211_MSG_INPUT, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bssi= d, "duplicate", @@ -660,7 +657,6 @@ out: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0m_freem(m); =A0 =A0 =A0 =A0} =A0 =A0 =A0 =A0return type; -#undef SEQ_LEQ =A0} =A0static int Modified: head/sys/net80211/ieee80211_hostap.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/net80211/ieee80211_hostap.c =A0 =A0 =A0 =A0Wed May =A04 01:39:= 44 2011 =A0 =A0 =A0 =A0(r221417) +++ head/sys/net80211/ieee80211_hostap.c =A0 =A0 =A0 =A0Wed May =A04 02:23:= 59 2011 =A0 =A0 =A0 =A0(r221418) @@ -472,7 +472,6 @@ doprint(struct ieee80211vap *vap, int su =A0static int =A0hostap_input(struct ieee80211_node *ni, struct mbuf *m, int rssi, int nf= ) =A0{ -#define =A0 =A0 =A0 =A0SEQ_LEQ(a,b) =A0 =A0((int)((a)-(b)) <=3D 0) =A0#define =A0 =A0 =A0 =A0HAS_SEQ(type) =A0 ((type & 0x4) =3D=3D 0) =A0 =A0 =A0 =A0struct ieee80211vap *vap =3D ni->ni_vap; =A0 =A0 =A0 =A0struct ieee80211com *ic =3D ni->ni_ic; @@ -572,9 +571,7 @@ hostap_input(struct ieee80211_node *ni, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0TID_TO_WME_AC(tid) >= =3D WME_AC_VI) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ic->ic_wme.w= me_hipri_traffic++; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rxseq =3D le16toh(*(uint16_t= *)wh->i_seq); - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((ni->ni_flags & IEEE80211= _NODE_HT) =3D=3D 0 && - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (wh->i_fc[1] & IEEE80= 211_FC1_RETRY) && - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 SEQ_LEQ(rxseq, ni->ni= _rxseqs[tid])) { + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (! ieee80211_check_rxseq(n= i, wh)) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* duplicate= , discard */ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IEEE80211_DI= SCARD_MAC(vap, IEEE80211_MSG_INPUT, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bssi= d, "duplicate", @@ -914,7 +911,6 @@ out: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0m_freem(m); =A0 =A0 =A0 =A0} =A0 =A0 =A0 =A0return type; -#undef SEQ_LEQ =A0} =A0static void Modified: head/sys/net80211/ieee80211_input.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/net80211/ieee80211_input.h Wed May =A04 01:39:44 2011 =A0(r221417) +++ head/sys/net80211/ieee80211_input.h Wed May =A04 02:23:59 2011 =A0(r221418) @@ -142,6 +142,104 @@ ishtinfooui(const uint8_t *frm) =A0 =A0 =A0 =A0return frm[1] > 3 && LE_READ_4(frm+2) =3D=3D ((BCM_OUI_HTINF= O<<24)|BCM_OUI); =A0} +#include =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* For le16toh() */ + +/* + * Check the current frame sequence number against the current TID + * state and return whether it's in sequence or should be dropped. + * + * Since out of order packet and duplicate packet eliminations should + * be done by the AMPDU RX code, this routine blindly accepts all + * frames from a HT station w/ a TID that is currently doing AMPDU-RX. + * HT stations without WME or where the TID is not doing AMPDU-RX + * are checked like non-HT stations. + * + * The routine only eliminates packets whose sequence/fragment + * match or are less than the last seen sequence/fragment number + * AND are retransmits It doesn't try to eliminate out of order packets. + * + * Since all frames after sequence number 4095 will be less than 4095 + * (as the seqnum wraps), handle that special case so packets aren't + * incorrectly dropped - ie, if the next packet is sequence number 0 + * but a retransmit since the initial packet didn't make it. + */ +static __inline int +ieee80211_check_rxseq(struct ieee80211_node *ni, struct ieee80211_frame *w= h) +{ +#define =A0 =A0 =A0 =A0SEQ_LEQ(a,b) =A0 =A0((int)((a)-(b)) <=3D 0) +#define =A0 =A0 =A0 =A0SEQ_EQ(a,b) =A0 =A0 ((int)((a)-(b)) =3D=3D 0) +#define =A0 =A0 =A0 =A0HAS_SEQ(type) =A0 ((type & 0x4) =3D=3D 0) +#define =A0 =A0 =A0 =A0SEQNO(a) =A0 =A0 =A0 =A0((a) >> IEEE80211_SEQ_SEQ_S= HIFT) +#define =A0 =A0 =A0 =A0FRAGNO(a) =A0 =A0 =A0 ((a) & IEEE80211_SEQ_FRAG_MAS= K) + =A0 =A0 =A0 uint16_t rxseq; + =A0 =A0 =A0 uint8_t type; + =A0 =A0 =A0 uint8_t tid; + =A0 =A0 =A0 struct ieee80211_rx_ampdu *rap; + + =A0 =A0 =A0 rxseq =3D le16toh(*(uint16_t *)wh->i_seq); + =A0 =A0 =A0 type =3D wh->i_fc[0] & IEEE80211_FC0_TYPE_MASK; + + =A0 =A0 =A0 /* Types with no sequence number are always treated valid */ + =A0 =A0 =A0 if (! HAS_SEQ(type)) + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 1; + + =A0 =A0 =A0 tid =3D ieee80211_gettid(wh); + + =A0 =A0 =A0 /* + =A0 =A0 =A0 =A0* Only do the HT AMPDU check for WME stations; non-WME HT = stations + =A0 =A0 =A0 =A0* shouldn't exist outside of debugging. We should at least + =A0 =A0 =A0 =A0* handle that. + =A0 =A0 =A0 =A0*/ + =A0 =A0 =A0 if (tid < WME_NUM_TID) { + =A0 =A0 =A0 =A0 =A0 =A0 =A0 rap =3D &ni->ni_rx_ampdu[tid]; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* HT nodes currently doing RX AMPDU are alwa= ys valid */ + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((ni->ni_flags & IEEE80211_NODE_HT) && + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (rap->rxa_flags & IEEE80211_AGGR_RUNN= ING)) + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 1; + =A0 =A0 =A0 } + + =A0 =A0 =A0 /* + =A0 =A0 =A0 =A0* Otherwise, retries for packets below or equal to the las= t + =A0 =A0 =A0 =A0* seen sequence number should be dropped. + =A0 =A0 =A0 =A0*/ + + =A0 =A0 =A0 /* + =A0 =A0 =A0 =A0* Treat frame seqnum 4095 as special due to boundary + =A0 =A0 =A0 =A0* wrapping conditions. + =A0 =A0 =A0 =A0*/ + =A0 =A0 =A0 if (SEQNO(ni->ni_rxseqs[tid]) =3D=3D 4095) { + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Drop retransmits on seqnum 4095/current = fragment for itself. + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/ + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (SEQ_EQ(rxseq, ni->ni_rxseqs[tid]) && + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (wh->i_fc[1] & IEEE80211_FC1_RETRY)) + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Treat any subsequent frame as fine if th= e last seen frame + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* is 4095 and it's not a retransmit for th= e same sequence + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* number. However, this doesn't capture in= correctly ordered + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* fragments w/ sequence number 4095. It sh= ouldn't be seen + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* in practice, but see the comment above f= or further info. + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/ + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 1; + =A0 =A0 =A0 } + + =A0 =A0 =A0 /* + =A0 =A0 =A0 =A0* At this point we assume that retransmitted seq/frag numb= ers below + =A0 =A0 =A0 =A0* the current can simply be eliminated. + =A0 =A0 =A0 =A0*/ + =A0 =A0 =A0 if ((wh->i_fc[1] & IEEE80211_FC1_RETRY) && + =A0 =A0 =A0 =A0 =A0 SEQ_LEQ(rxseq, ni->ni_rxseqs[tid])) + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0; + + =A0 =A0 =A0 return 1; +#undef SEQ_LEQ +#undef SEQ_EQ +#undef HAS_SEQ +#undef SEQNO +#undef FRAGNO +} + =A0void =A0 ieee80211_deliver_data(struct ieee80211vap *, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0struct ieee80211_node *, struct mbuf *); =A0struct mbuf *ieee80211_defrag(struct ieee80211_node *, Modified: head/sys/net80211/ieee80211_mesh.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/net80211/ieee80211_mesh.c =A0Wed May =A04 01:39:44 2011 =A0(r221417) +++ head/sys/net80211/ieee80211_mesh.c =A0Wed May =A04 02:23:59 2011 =A0(r221418) @@ -1040,7 +1040,6 @@ mesh_isucastforme(struct ieee80211vap *v =A0static int =A0mesh_input(struct ieee80211_node *ni, struct mbuf *m, int rssi, int nf) =A0{ -#define =A0 =A0 =A0 =A0SEQ_LEQ(a,b) =A0 =A0((int)((a)-(b)) <=3D 0) =A0#define =A0 =A0 =A0 =A0HAS_SEQ(type) =A0 ((type & 0x4) =3D=3D 0) =A0 =A0 =A0 =A0struct ieee80211vap *vap =3D ni->ni_vap; =A0 =A0 =A0 =A0struct ieee80211com *ic =3D ni->ni_ic; @@ -1094,9 +1093,7 @@ mesh_input(struct ieee80211_node *ni, st =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0TID_TO_WME_AC(tid) >= =3D WME_AC_VI) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ic->ic_wme.w= me_hipri_traffic++; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rxseq =3D le16toh(*(uint16_t= *)wh->i_seq); - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((ni->ni_flags & IEEE80211= _NODE_HT) =3D=3D 0 && - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (wh->i_fc[1] & IEEE80= 211_FC1_RETRY) && - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 SEQ_LEQ(rxseq, ni->ni= _rxseqs[tid])) { + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (! ieee80211_check_rxseq(n= i, wh)) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* duplicate= , discard */ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IEEE80211_DI= SCARD_MAC(vap, IEEE80211_MSG_INPUT, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0wh->= i_addr1, "duplicate", Modified: head/sys/net80211/ieee80211_sta.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/net80211/ieee80211_sta.c =A0 Wed May =A04 01:39:44 2011 =A0(r221417) +++ head/sys/net80211/ieee80211_sta.c =A0 Wed May =A04 02:23:59 2011 =A0(r221418) @@ -512,7 +512,6 @@ doprint(struct ieee80211vap *vap, int su =A0static int =A0sta_input(struct ieee80211_node *ni, struct mbuf *m, int rssi, int nf) =A0{ -#define =A0 =A0 =A0 =A0SEQ_LEQ(a,b) =A0 =A0((int)((a)-(b)) <=3D 0) =A0#define =A0 =A0 =A0 =A0HAS_SEQ(type) =A0 ((type & 0x4) =3D=3D 0) =A0 =A0 =A0 =A0struct ieee80211vap *vap =3D ni->ni_vap; =A0 =A0 =A0 =A0struct ieee80211com *ic =3D ni->ni_ic; @@ -591,9 +590,7 @@ sta_input(struct ieee80211_node *ni, str =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0TID_TO_WME_AC(tid) >= =3D WME_AC_VI) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ic->ic_wme.w= me_hipri_traffic++; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rxseq =3D le16toh(*(uint16_t= *)wh->i_seq); - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((ni->ni_flags & IEEE80211= _NODE_HT) =3D=3D 0 && - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (wh->i_fc[1] & IEEE80= 211_FC1_RETRY) && - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 SEQ_LEQ(rxseq, ni->ni= _rxseqs[tid])) { + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (! ieee80211_check_rxseq(n= i, wh)) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* duplicate= , discard */ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IEEE80211_DI= SCARD_MAC(vap, IEEE80211_MSG_INPUT, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bssi= d, "duplicate", @@ -910,7 +907,6 @@ out: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0m_freem(m); =A0 =A0 =A0 =A0} =A0 =A0 =A0 =A0return type; -#undef SEQ_LEQ =A0} =A0static void Modified: head/sys/net80211/ieee80211_wds.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/net80211/ieee80211_wds.c =A0 Wed May =A04 01:39:44 2011 =A0(r221417) +++ head/sys/net80211/ieee80211_wds.c =A0 Wed May =A04 02:23:59 2011 =A0(r221418) @@ -406,7 +406,6 @@ wds_newstate(struct ieee80211vap *vap, e =A0static int =A0wds_input(struct ieee80211_node *ni, struct mbuf *m, int rssi, int nf) =A0{ -#define =A0 =A0 =A0 =A0SEQ_LEQ(a,b) =A0 =A0((int)((a)-(b)) <=3D 0) =A0#define =A0 =A0 =A0 =A0HAS_SEQ(type) =A0 ((type & 0x4) =3D=3D 0) =A0 =A0 =A0 =A0struct ieee80211vap *vap =3D ni->ni_vap; =A0 =A0 =A0 =A0struct ieee80211com *ic =3D ni->ni_ic; @@ -495,9 +494,7 @@ wds_input(struct ieee80211_node *ni, str =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0TID_TO_WME_AC(tid) >=3D WME_AC_VI) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ic->ic_wme.wme_hipri_traffic= ++; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rxseq =3D le16toh(*(uint16_t *)wh->i_seq); - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((ni->ni_flags & IEEE80211_NODE_HT) =3D=3D= 0 && - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (wh->i_fc[1] & IEEE80211_FC1_RETRY) &= & - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 SEQ_LEQ(rxseq, ni->ni_rxseqs[tid])) { + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (! ieee80211_check_rxseq(ni, wh)) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* duplicate, discard */ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IEEE80211_DISCARD_MAC(vap, I= EEE80211_MSG_INPUT, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0wh->i_addr1, "duplic= ate", @@ -741,7 +738,6 @@ out: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0m_freem(m); =A0 =A0 =A0 =A0} =A0 =A0 =A0 =A0return type; -#undef SEQ_LEQ =A0} =A0static void From owner-freebsd-current@FreeBSD.ORG Wed May 4 03:13:18 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 226DD1065672; Wed, 4 May 2011 03:13:18 +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 BA84F8FC1E; Wed, 4 May 2011 03:13:17 +0000 (UTC) Received: by mail-iw0-f182.google.com with SMTP id 33so841369iwn.13 for ; Tue, 03 May 2011 20:13:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=m7dvXTQVFHw8p1b8JS6QHNAh5ok+GDMKwqCTKadGqMA=; b=lKHn3ndFaEbKMXPeDIiWh9TQQFgVtgcGD9xxyq5tFmCTPGL6VNSvAbMtoT/kAHtMAy 6AR6MD8sns6Gckjd7NEH200B9iOZaOALsNh7+cY7R1wN5tPgw7oKBoVUDCeC88MKygFq wc+A69uthFF83Z2wFRE1Har2ZrSXmQdhkGAVY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=COSSBVTicOyFceHkhF2259wxiln6IWjFmFvPkscSEFFL1JL52mCL0WjbIfW8JFuCtL LrjlWuJKyGAr6YCKojgEulSOSIbClQJ/z+AsDGGY/tIR6n1+HACuxZFhXT7auNAxb5cI dOEDU5WByHJIgBHWjQXi/rB0lTBaEq70pvCbw= Received: by 10.42.179.200 with SMTP id br8mr1037181icb.279.1304478797568; Tue, 03 May 2011 20:13:17 -0700 (PDT) Received: from DataIX.net (adsl-99-190-84-116.dsl.klmzmi.sbcglobal.net [99.190.84.116]) by mx.google.com with ESMTPS id f28sm275545ibh.33.2011.05.03.20.13.15 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 May 2011 20:13:16 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p443DC0N013003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 May 2011 23:13:13 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p443DCts013002; Tue, 3 May 2011 23:13:12 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Tue, 3 May 2011 23:13:12 -0400 From: Jason Hellenthal To: "Edwin L. Culp W." Message-ID: <20110504031312.GA78390@DataIX.net> References: <201105030759.09518.jhb@freebsd.org> <201105031002.36612.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline In-Reply-To: X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: freebsd-current@freebsd.org Subject: Re: I am very confused and would appreciate some help on device renameing or on renumbering on current fstab. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 03:13:18 -0000 --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Edwin, >>> >> =A0/dev/acd0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/cdrom =A0 =A0 =A0 =A0 =A0cd= 9660 =A0ro,noauto =A0 =A0 =A0 0 =A0 =A0 =A0 0 >>> >> =A0/dev/acd1 =A0 =A0 =A0 =A0 =A0 =A0 =A0/cdrom1 =A0 =A0 =A0 =A0 cd96= 60 =A0ro,noauto =A0 =A0 =A0 0 =A0 =A0 =A0 0 As a side note. These are also now useless & can be sent to /dev/null for= =20 extra padding ;) Shouldn't cause no harm being there but just for reference. --=20 Regards, (jhell) Jason Hellenthal --2fHTh5uZTiUOsy+g Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNwMRHAAoJEJBXh4mJ2FR+zIUH/A4gw2PhwhGGrhw3uZA7YPi8 hbK3lJcVJ9o4s3OoZO0ykI/dwHpDjsCJ5ebG3SM68Nb154eiT71BY76uge/cCFVb 09XyGTsNo1CX68HY7s0DxqPP9NPpbLGH034l8AFabWykCCfIzQJIr9PH2UXpyHa4 13RCu6PBTT8iLD0a9C3TcNVUdrWh879KY9XOekkrOCSJcQqOhXLCs/isA9u5+afL iRWj+KV9//ZpHUdmXeHKOJ5237+hRGzb6hpfOSeQFNy6EFeooC5zsuWydMguc6/H MN8hvOW99StCVpj926ZW01EHB+l8Sav+L1N7yMG5v1G7YMoV1KCIP6G/HzXEaqM= =NqZ2 -----END PGP SIGNATURE----- --2fHTh5uZTiUOsy+g-- From owner-freebsd-current@FreeBSD.ORG Wed May 4 05:40:27 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84D24106564A for ; Wed, 4 May 2011 05:40:27 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2E3E78FC08 for ; Wed, 4 May 2011 05:40:26 +0000 (UTC) Received: by vxc34 with SMTP id 34so1092854vxc.13 for ; Tue, 03 May 2011 22:40:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=AlVVEFLPoAh2CXMN2TT4HjR3wZiyGnJAapypTy3fmhc=; b=wgkGaFm+a9nktfbqC/CClb/hoOE3m0si4fq0qZ5m1M6iU0FOpi0/ht/fxGb/ah6emm Vz9exx+TOKi04AQQqTFfgMeWLDbhKWkGldmkze6ZOuBQEjlySTqhzikF5+qUvrdEmHXG QvS64U7gkGWp92GQGzFR8Mqh23bmYFURzImpg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=vMDiQ3NOmt6AIS5VFPPaQ1nAyKSvoSCGttdd5Q3HFE0R+Pgx2A6LpFq3nJ4nEat8/B f0S37Z3TeebY1vxljzKkGwnVED+2aQqdIZ/NlQRI4Rub3C3Dy3Pynxo92c5Vw7RBTXq8 Ry3blHqiairdN1P4PdfONYfx0Wd/wKz9hFyHk= MIME-Version: 1.0 Received: by 10.52.176.194 with SMTP id ck2mr808501vdc.248.1304487626484; Tue, 03 May 2011 22:40:26 -0700 (PDT) Received: by 10.220.199.130 with HTTP; Tue, 3 May 2011 22:40:26 -0700 (PDT) Date: Tue, 3 May 2011 22:40:26 -0700 Message-ID: From: Garrett Cooper To: Jeff Roberson , Marshall Kirk McKusick Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current Subject: Nasty non-recursive lockmgr panic on softdep only enabled UFS partition when filesystem full X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 05:40:27 -0000 Hi Jeff and Dr. McKusick, Ran into this panic when /usr ran out of space doing a make universe on amd64/r221219 (it took ~15 minutes for the panic to occur after the filesystem ran out of space -- wasn't quite sure what it was doing at the time): pid 24486 (ld), uid 0 inumber 9993 on /usr: filesystem full pid 24511 (config), uid 0 inumber 361082 on /usr: filesystem full pid 24494 (make), uid 0 inumber 1886295 on /usr: filesystem full panic: __lockmgr_args: recursing on non recursive lockmgr bufwait @ /usr/src/sys/ufs/ffs/ffs_softdep.c:11025 (kgdb) #0 doadump () at pcpu.h:224 #1 0xffffffff802af22c in db_fncall (dummy1=Variable "dummy1" is not available. ) at /usr/src/sys/ddb/db_command.c:548 #2 0xffffffff802af561 in db_command (last_cmdp=0xffffffff808f93c0, cmd_table=Variable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #3 0xffffffff802af7a9 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xffffffff802b1737 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 #5 0xffffffff803f7d48 in kdb_trap (type=3, code=0, tf=0xffffff834e4c8ef0) at /usr/src/sys/kern/subr_kdb.c:533 #6 0xffffffff80599da5 in trap (frame=0xffffff834e4c8ef0) at /usr/src/sys/amd64/amd64/trap.c:590 #7 0xffffffff80584ef3 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 #8 0xffffffff803f7baf in kdb_enter (why=0xffffffff806178cf "panic", msg=0xa
) at cpufunc.h:63 #9 0xffffffff803c4b6f in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:584 #10 0xffffffff803af3ac in __lockmgr_args (lk=0x100, flags=0, ilk=0xfffffe00b95766c0, wmesg=Variable "wmesg" is not available. ) at /usr/src/sys/kern/kern_lock.c:720 #11 0xffffffff8054240b in softdep_sync_metadata (vp=0xfffffe017fe5d000) at lockmgr.h:97 #12 0xffffffff80548e90 in ffs_syncvnode (vp=0xfffffe017fe5d000, waitfor=Variable "waitfor" is not available. ) at /usr/src/sys/ufs/ffs/ffs_vnops.c:331 #13 0xffffffff8053be23 in softdep_request_cleanup (fs=0xfffffe00086ef000, vp=0xfffffe00b95765a0, cred=Variable "cred" is not available. ) at /usr/src/sys/ufs/ffs/ffs_softdep.c:11392 #14 0xffffffff80523895 in ffs_realloccg (ip=0xfffffe00b9285bd0, lbprev=0, bprev=10092847, bpref=10723304, osize=2048, nsize=4096, flags=65536, cred=0xfffffe026e905a00, bpp=0xffffff834e4c95f0) at /usr/src/sys/ufs/ffs/ffs_alloc.c:423 #15 0xffffffff805266de in ffs_balloc_ufs2 (vp=0xfffffe00b95765a0, startoffset=Variable "startoffset" is not available. ) at /usr/src/sys/ufs/ffs/ffs_balloc.c:699 #16 0xffffffff8054fbfb in ufs_direnter (dvp=0xfffffe00b95765a0, tvp=0xfffffe00701c4000, dirp=0xffffff834e4c97b0, cnp=Variable "cnp" is not available. ) at /usr/src/sys/ufs/ufs/ufs_lookup.c:910 #17 0xffffffff80557af8 in ufs_mkdir (ap=0xffffff834e4c9a90) at /usr/src/sys/ufs/ufs/ufs_vnops.c:1961 #18 0xffffffff805d666b in VOP_MKDIR_APV (vop=0xffffffff808c2a40, a=0xffffff834e4c9a90) at vnode_if.c:1534 #19 0xffffffff80457eb8 in kern_mkdirat (td=0xfffffe0149df4000, fd=-100, path=0x6096e0
, segflg=Variable "segflg" is not available. ) at vnode_if.h:665 #20 0xffffffff80404cd1 in syscallenter (td=0xfffffe0149df4000, sa=0xffffff834e4c9bb0) at /usr/src/sys/kern/subr_trap.c:344 #21 0xffffffff8059996e in syscall (frame=0xffffff834e4c9c50) at /usr/src/sys/amd64/amd64/trap.c:910 #22 0xffffffff805851bd in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:384 #23 0x0000000800b3798c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) $ sudo tunefs -p /usr tunefs: POSIX.1e ACLs: (-a) disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) disabled tunefs: gjournal: (-J) disabled tunefs: trim: (-t) disabled tunefs: maximum blocks per file in a cylinder group: (-e) 2048 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: optimization preference: (-o) time tunefs: volume label: (-L) Let me know what other commands you would like for me to run in kgdb. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Wed May 4 06:38:35 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 936DF1065673 for ; Wed, 4 May 2011 06:38:35 +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 56DA28FC0C for ; Wed, 4 May 2011 06:38:35 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:e12e:ab0b:b5d8:d1f0] (unknown [IPv6:2001:7b8:3a7:0:e12e:ab0b:b5d8:d1f0]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 7D2135C59; Wed, 4 May 2011 08:38:33 +0200 (CEST) Message-ID: <4DC0F46C.3020806@FreeBSD.org> Date: Wed, 04 May 2011 08:38:36 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110415 Lanikai/3.1.11pre MIME-Version: 1.0 To: Manfred Antar References: <201105040107.p4417NTR048534@pozo.com> In-Reply-To: <201105040107.p4417NTR048534@pozo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Clang error make buildworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 06:38:35 -0000 On 2011-05-04 03:07, Manfred Antar wrote: > I get this error when trying to buildworld on current i386. > It's been this way for awhile Any Ideas ? > > ===> boot/i386/boot0 (all) > clang -O2 -pipe -DVOLUME_SERIAL -DPXE -DFLAGS=0x8f -DTICKS=0xb6 -DCOMSPEED="7<< 5 + 3" -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -std=gnu99 -c /usr/src/sys/boot/i386/boot0/boot0.S > clang: warning: argument unused during compilation: '-mpreferred-stack-boundary=2' > /tmp/cc-4SXZt8.s:42:11: error: .code16 not supported yet For some reason, on your system, it does not compile boot0.S with -no-integrated-as. It works fine here though, so it must be something local to your system. Can you please post: - Your full make.conf and src.conf - The first 30 lines of sys/boot/i386/boot0/Makefile From owner-freebsd-current@FreeBSD.ORG Wed May 4 06:42:34 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F23F106564A; Wed, 4 May 2011 06:42:34 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 32FF58FC1A; Wed, 4 May 2011 06:42:33 +0000 (UTC) Received: by vxc34 with SMTP id 34so1145205vxc.13 for ; Tue, 03 May 2011 23:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3JIKyo3g+hmUdomcTALYFkL5gm2/dnwhDFiHqzAM6BA=; b=JXHw6Q2L3x8biV1YmLpQt9lEoiDUdZsOBUUICL7SUbYwfolPztC1heL5fU0RKQXWqp V8gqhcIKfapqk/MjMl9iPHZQ7xyKOIvezwkRu4IS8K0wlQw1sPyY4QQtRrQLHtCQKI8Y DnymY1pzWHvHJYzvl78M+WDjrMkDqMH8GmeXI= 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=kIeEYN4c/4fdA22jEQgPQjdQ1wAyHfrYbpdcQyCdjDgHjN2XUlXnjyTdFLJe1eKuKw Y8F1AnGpjkeOjI9qYHmaczVLLv+kTcz7x0ZaZMkLKnq0pknRp1mfisgjJLJj08p+UfUJ TH2nBtfloMIgATfOyRsaQ73GQPCyb3Q5ZndSE= MIME-Version: 1.0 Received: by 10.220.202.77 with SMTP id fd13mr188001vcb.81.1304491353219; Tue, 03 May 2011 23:42:33 -0700 (PDT) Received: by 10.220.199.130 with HTTP; Tue, 3 May 2011 23:42:32 -0700 (PDT) In-Reply-To: <201105040559.p445xEJ5024585@chez.mckusick.com> References: <201105040559.p445xEJ5024585@chez.mckusick.com> Date: Tue, 3 May 2011 23:42:32 -0700 Message-ID: From: Garrett Cooper To: Kirk McKusick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: Nasty non-recursive lockmgr panic on softdep only enabled UFS partition when filesystem full X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 06:42:34 -0000 On Tue, May 3, 2011 at 10:59 PM, Kirk McKusick wrot= e: >> Date: Tue, 3 May 2011 22:40:26 -0700 >> Subject: Nasty non-recursive lockmgr panic on softdep only enabled UFS >> =A0partition when filesystem full >> From: Garrett Cooper >> To: Jeff Roberson , >> =A0 =A0 =A0 =A0 Marshall Kirk McKusick >> Cc: FreeBSD Current >> >> Hi Jeff and Dr. McKusick, >> =A0 =A0 Ran into this panic when /usr ran out of space doing a make >> universe on amd64/r221219 (it took ~15 minutes for the panic to occur >> after the filesystem ran out of space -- wasn't quite sure what it was >> doing at the time): >> >> ... >> >> =A0 =A0 Let me know what other commands you would like for me to run in = kgdb. >> Thanks, >> -Garrett > > You did not indicate whether you are running an 8.X system or a 9-current > system. It would be helpful to know that. I've actually been running CURRENT for a few years now, but you're right -- I didn't mention that part. > Jeff thinks that there may be a potential race in the locking code for > softdep_request_cleanup. If so, this patch for 9-current should fix it: > > Index: ffs_softdep.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- ffs_softdep.c =A0 =A0 =A0 (revision 221385) > +++ ffs_softdep.c =A0 =A0 =A0 (working copy) > @@ -11380,7 +11380,8 @@ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0continue; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MNT_IUNLOCK(mp); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (vget(lvp, LK_EXCLUSIVE = | LK_INTERLOCK, curthread)) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (vget(lvp, LK_EXCLUSIVE = | LK_NOWAIT | LK_INTERLOCK, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 curthread)) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MNT_ILOCK(= mp); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0continue; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > > If you are running an 8.X system, hopefully you will be able to apply it. I've applied it, rebuilt and installed the kernel, and trying to repro the case again. Will let you know how things go! Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Wed May 4 06:58:51 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 319CF106564A; Wed, 4 May 2011 06:58:51 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id C36818FC0C; Wed, 4 May 2011 06:58:50 +0000 (UTC) Received: by vxc34 with SMTP id 34so1158771vxc.13 for ; Tue, 03 May 2011 23:58:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=clVKLWDJI4B2+SIVGFMHn/WFJtJLTCyXbYBNCO9A/JQ=; b=UNslqKxba87e1NJeXABnMUPlA8G6S8PRgjoIn9bbjBcqvr842OQl7tJ3WlarqqCemP +cW+AbQf5wPCfM6bRYUndEofjj02W7H2blPt5g7DX6BcOFFhGwFKdAaXd2eLH3DhkNlp nTY8Hjcc9/LAixELxktlDMHxrTyZcmh8ZULxg= 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=g3f0yuZA+P8iBbsuoxV2tYN9dnHcZP2Mml38lBVfMBFOo1JzKiJh2aA4R2Z4DiZoTt wXM1FkFBTozB3P7Ls8VzGi8JsONg+thwDtOOTOoMvckIbf6lgdHbAuhz5bQOpXotIEhP L7uVrq5Wdcd738kYNpXZm4XmGgl4OmDY2SFLg= MIME-Version: 1.0 Received: by 10.52.77.6 with SMTP id o6mr907343vdw.168.1304492329723; Tue, 03 May 2011 23:58:49 -0700 (PDT) Received: by 10.220.199.130 with HTTP; Tue, 3 May 2011 23:58:49 -0700 (PDT) In-Reply-To: References: <201105040559.p445xEJ5024585@chez.mckusick.com> Date: Tue, 3 May 2011 23:58:49 -0700 Message-ID: From: Garrett Cooper To: Kirk McKusick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: Nasty non-recursive lockmgr panic on softdep only enabled UFS partition when filesystem full X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 06:58:51 -0000 On Tue, May 3, 2011 at 11:42 PM, Garrett Cooper wrote: > On Tue, May 3, 2011 at 10:59 PM, Kirk McKusick wr= ote: >>> Date: Tue, 3 May 2011 22:40:26 -0700 >>> Subject: Nasty non-recursive lockmgr panic on softdep only enabled UFS >>> =A0partition when filesystem full >>> From: Garrett Cooper >>> To: Jeff Roberson , >>> =A0 =A0 =A0 =A0 Marshall Kirk McKusick >>> Cc: FreeBSD Current >>> >>> Hi Jeff and Dr. McKusick, >>> =A0 =A0 Ran into this panic when /usr ran out of space doing a make >>> universe on amd64/r221219 (it took ~15 minutes for the panic to occur >>> after the filesystem ran out of space -- wasn't quite sure what it was >>> doing at the time): >>> >>> ... >>> >>> =A0 =A0 Let me know what other commands you would like for me to run in= kgdb. >>> Thanks, >>> -Garrett >> >> You did not indicate whether you are running an 8.X system or a 9-curren= t >> system. It would be helpful to know that. > > I've actually been running CURRENT for a few years now, but you're right = -- > I didn't mention that part. > >> Jeff thinks that there may be a potential race in the locking code for >> softdep_request_cleanup. If so, this patch for 9-current should fix it: >> >> Index: ffs_softdep.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- ffs_softdep.c =A0 =A0 =A0 (revision 221385) >> +++ ffs_softdep.c =A0 =A0 =A0 (working copy) >> @@ -11380,7 +11380,8 @@ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0continue; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MNT_IUNLOCK(mp); >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (vget(lvp, LK_EXCLUSIVE= | LK_INTERLOCK, curthread)) { >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (vget(lvp, LK_EXCLUSIVE= | LK_NOWAIT | LK_INTERLOCK, >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 curthread)) { >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MNT_ILOCK= (mp); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0continue; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >> >> If you are running an 8.X system, hopefully you will be able to apply it= . > > =A0 =A0I've applied it, rebuilt and installed the kernel, and trying to > repro the case again. Will let you know how things go! Happened again with the change. It's really easy to repro: 1. Get a filesystem with UFS+SU 2. Execute something that does a large number of small writes to a partitio= n. 3. 'dd if=3D/dev/zero of=3DFOO bs=3D10m' on the same partition The kernel will panic with the issue I discussed above. Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Wed May 4 07:00:26 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33B081065673 for ; Wed, 4 May 2011 07:00:26 +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 E72078FC12 for ; Wed, 4 May 2011 07:00:25 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:e12e:ab0b:b5d8:d1f0] (unknown [IPv6:2001:7b8:3a7:0:e12e:ab0b:b5d8:d1f0]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 22BA45C59; Wed, 4 May 2011 09:00:25 +0200 (CEST) Message-ID: <4DC0F98D.3020601@FreeBSD.org> Date: Wed, 04 May 2011 09:00:29 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110415 Lanikai/3.1.11pre MIME-Version: 1.0 To: "O. Hartmann" References: <4DBDB8D4.6050102@mail.zedat.fu-berlin.de> <4DC04F29.2050401@mail.zedat.fu-berlin.de> In-Reply-To: <4DC04F29.2050401@mail.zedat.fu-berlin.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Olivier Smedts , freebsd-current@freebsd.org Subject: Re: Building FreeBSD 9.0-CUR/amd64 with CLANG fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 07:00:26 -0000 On 2011-05-03 20:53, O. Hartmann wrote: =2E.. >>> ld -m elf_i386_fbsd -Y P,/usr/obj/usr/src/lib32/usr/lib32 =EF=BF=BD-o= gcrt1.o -r >>> crt1_s.o gcrt1_c.o >>> ld: Relocatable linking with relocations from format elf64-x86-64-fre= ebsd >>> (crt1_s.o) to format elf32-i386-freebsd (gcrt1.o) is not supported =2E.. > Today, I tried again, after CLANG/LLVM has been updated to version 3.0.= > Same error. > > This is the addendum I made to the /etc/make.conf: > > ## > ## CLANG > ## > .if defined(USE_CLANG) > .if !defined(CC) || ${CC} =3D=3D "cc" > CC=3Dclang > .endif > .if !defined(CXX) || ${CXX} =3D=3D "c++" > CXX=3Dclang++ > .endif > # Don't die on warnings > NO_WERROR=3D > WERROR=3D > # Don't forget this when using Jails! > NO_FSCHG=3D > .endif Ok, that looks good, I use a similar construction. However, in my case it works fine, so there must be something special on your system that breaks the build. What happens here, is that the 32-bit stage on amd64 fails, because it tries to link together 64-bit and 32-bit object files, which is not allowed. This can occur if Makefile.inc1 cannot set CC to the correct value, but there might also be something else going on. To debug this further, can you please post: - Your full /etc/make.conf - Your full /etc/src.conf - Any modifications you made to your source tree - The specific procedure you use for buildworld - An url to a full build log (don't post it to the list, because it will be rather large) From owner-freebsd-current@FreeBSD.ORG Wed May 4 07:58:39 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9158106564A for ; Wed, 4 May 2011 07:58:39 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.212.176]) by mx1.freebsd.org (Postfix) with ESMTP id 5CA778FC08 for ; Wed, 4 May 2011 07:58:39 +0000 (UTC) Received: by pxi11 with SMTP id 11so628479pxi.35 for ; Wed, 04 May 2011 00:58:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.35.228 with SMTP id l4mr1264374pbj.5.1304495918994; Wed, 04 May 2011 00:58:38 -0700 (PDT) Received: by 10.68.40.4 with HTTP; Wed, 4 May 2011 00:58:38 -0700 (PDT) In-Reply-To: References: <4D94A354.9080903@sentex.net> <4DC07013.9070707@gmx.net> <4DC078BD.9080908@gmx.net> Date: Wed, 4 May 2011 09:58:38 +0200 Message-ID: From: Olivier Smedts To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD current mailing list , Michael Schmiedgen , Mike Tancsa Subject: Re: problems with em(4) since update to driver 7.2.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 07:58:39 -0000 2011/5/4 Jack Vogel : > It has nothing to do with load, it has to do with the prerequisites to in= it > your interfaces. > The amount you need is fixed, it doesn't vary with load. Every RX descrip= tor > needs one, > so its simple math, number-of-interfaces X number-of-queues X size of the > ring. > > If you have other network interfaces beside Intel they also consume mbufs > remember. Only one network interface. # kldunload if_em.ko (the old one) # sysctl kern.ipc.nmbclusters=3D512000 (I also tried with lower and more meaningful values) # kldload ./if_em.ko (the new one) # dmesg em0: detached pci0: at device 25.0 (no driver attached) em0: port 0x2100-0x211f mem 0xf0000000-0xf001ffff,0xf0025000-0xf0025fff irq 19 at device 25.0 on pci0 em0: Using an MSI interrupt em0: Ethernet address: d4:85:64:b2:aa:f5 em0: Could not setup receive structures em0: Could not setup receive structures What can we do to help you debug this ? --=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-current@FreeBSD.ORG Wed May 4 08:05:26 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE6C6106564A for ; Wed, 4 May 2011 08:05:26 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.212.176]) by mx1.freebsd.org (Postfix) with ESMTP id B8A418FC0C for ; Wed, 4 May 2011 08:05:26 +0000 (UTC) Received: by pxi11 with SMTP id 11so631937pxi.35 for ; Wed, 04 May 2011 01:05:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.35.228 with SMTP id l4mr1272854pbj.5.1304496326420; Wed, 04 May 2011 01:05:26 -0700 (PDT) Received: by 10.68.40.4 with HTTP; Wed, 4 May 2011 01:05:26 -0700 (PDT) In-Reply-To: <4DC0FD83.5080504@mail.zedat.fu-berlin.de> References: <4DBDB8D4.6050102@mail.zedat.fu-berlin.de> <4DC04F29.2050401@mail.zedat.fu-berlin.de> <4DC0F98D.3020601@FreeBSD.org> <4DC0FD83.5080504@mail.zedat.fu-berlin.de> Date: Wed, 4 May 2011 10:05:26 +0200 Message-ID: From: Olivier Smedts To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Dimitry Andric Subject: Re: Building FreeBSD 9.0-CUR/amd64 with CLANG fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 08:05:27 -0000 2011/5/4 O. Hartmann : > > But when I tried to compile essential ports (essential to me), like > x11-wm/windowmaker, mulitmedia/ffmpeg, for instance, I run into serious > compiler/assembler error with LLVM/CLANG. I guess the ports- tree isn't > mature for clang. So am I right in this thinking: leaving /etc/make.conf > untouched in terms of not putting there the CLANG build construct and > putting this instead into /etc/src.conf will only affect the OS' source t= ree > to be build by clang and all ports are build by the antique system's gcc > 4.2.1? A lot of ports can't be build with clang. You can add something like this to your /etc/make.conf (modifying paths accordingly) : .if ${.CURDIR:M/usr/src*} || ${.CURDIR:M*/usr/ports/emulators/virtualbox-ose-kmod*} .if !defined(CC) || ${CC} =3D=3D "cc" CC=3Dclang .endif .if !defined(CXX) || ${CXX} =3D=3D "c++" CXX=3Dclang++ .endif NO_WERROR=3D WERROR=3D .endif That's what I use. Note the first if statement. Cheers --=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-current@FreeBSD.ORG Wed May 4 08:28:15 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25735106566B for ; Wed, 4 May 2011 08:28:15 +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 D8B358FC18 for ; Wed, 4 May 2011 08:28:14 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:e12e:ab0b:b5d8:d1f0] (unknown [IPv6:2001:7b8:3a7:0:e12e:ab0b:b5d8:d1f0]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 04D5A5C59; Wed, 4 May 2011 10:28:13 +0200 (CEST) Message-ID: <4DC10E21.2070503@FreeBSD.org> Date: Wed, 04 May 2011 10:28:17 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110415 Lanikai/3.1.11pre MIME-Version: 1.0 To: "O. Hartmann" References: <4DBDB8D4.6050102@mail.zedat.fu-berlin.de> <4DC04F29.2050401@mail.zedat.fu-berlin.de> <4DC0F98D.3020601@FreeBSD.org> <4DC0FD83.5080504@mail.zedat.fu-berlin.de> In-Reply-To: <4DC0FD83.5080504@mail.zedat.fu-berlin.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Olivier Smedts , freebsd-current@freebsd.org Subject: Re: Building FreeBSD 9.0-CUR/amd64 with CLANG fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 08:28:15 -0000 On 2011-05-04 09:17, O. Hartmann wrote: ... > But when I tried to compile essential ports (essential to me), like > x11-wm/windowmaker, mulitmedia/ffmpeg, for instance, I run into serious > compiler/assembler error with LLVM/CLANG. I guess the ports- tree isn't > mature for clang. Several patches for this are available at: http://rainbow-runner.nl/clang/patches/ but getting these into the ports tree itself is proving to be rather slow, for some reason. I see an ffmpeg patch in there, but no windowmaker one. I will have a look at what the problem is. Note that if you run into problems with clang's integrated assembler, you can always add "-no-integrated-as" to CFLAGS, then it will use GNU as instead. It will just be a bit slower. On the other hand, if there is a way to actually correct the assembly, or if it is really a bug in the integrated assembler, we would rather fix it properly. :) > So am I right in this thinking: leaving /etc/make.conf > untouched in terms of not putting there the CLANG build construct and > putting this instead into /etc/src.conf will only affect the OS' source > tree to be build by clang and all ports are build by the antique > system's gcc 4.2.1? No, you really *must* put any CC= definitions in make.conf; if you put them in src.conf, they will not be picked up early enough in some cases. If you only want to build /usr/src with clang, and ports with gcc, it is probably best to surround the CC=clang definitions with: .if !empty(.CURDIR:M/usr/src*) # ...clang definitions here... .endif From owner-freebsd-current@FreeBSD.ORG Wed May 4 09:05:06 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EF281065670 for ; Wed, 4 May 2011 09:05:06 +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 C3D608FC16 for ; Wed, 4 May 2011 09:05:05 +0000 (UTC) Received: by qwc9 with SMTP id 9so698055qwc.13 for ; Wed, 04 May 2011 02:05:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zMM8Le7d1Q+/2g9E++/ixrzz9VpuDur+hDgtsOPf9Fg=; b=F2p5N5GOJVaXf1ApyGC0jOIE5NdANQgro58AYvS4/HF2lTvvvjOAT7dbLMlbSWIG+h E/XuIjviHWBim5XVSThCafD+RyN2KuvhZrXAY0nFc1O3N6Sk8VoqDqHDA2gZ0DNyhBMR vKV/CDhKx1hZO/WBsnNF587GL6WFre+JCAius= 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=EC11ctF9Idfp0uRhfWwXOKdTF/BN0WE5v+61Zjh0B9hYYZdEY8gE1XUt39JMwdU0u5 f0i3bwAX1tM2ZDhbznF+BN7S+598YfQvM2Ajc1+3dHoHXFhxBfbsejvAVSm0kQxjO05t E0XMbbj4Xtq1HngpuDK6LlOjZc+AuOS/3ZVVk= MIME-Version: 1.0 Received: by 10.229.112.21 with SMTP id u21mr545507qcp.62.1304499905150; Wed, 04 May 2011 02:05:05 -0700 (PDT) Received: by 10.229.97.146 with HTTP; Wed, 4 May 2011 02:05:05 -0700 (PDT) In-Reply-To: References: <201105040559.p445xEJ5024585@chez.mckusick.com> Date: Wed, 4 May 2011 13:05:05 +0400 Message-ID: From: Sergey Kandaurov To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kirk McKusick , FreeBSD Current Subject: Re: Nasty non-recursive lockmgr panic on softdep only enabled UFS partition when filesystem full X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 09:05:06 -0000 On 4 May 2011 10:42, Garrett Cooper wrote: > On Tue, May 3, 2011 at 10:59 PM, Kirk McKusick wr= ote: >>> Date: Tue, 3 May 2011 22:40:26 -0700 >>> Subject: Nasty non-recursive lockmgr panic on softdep only enabled UFS >>> =A0partition when filesystem full >>> From: Garrett Cooper >>> To: Jeff Roberson , >>> =A0 =A0 =A0 =A0 Marshall Kirk McKusick >>> Cc: FreeBSD Current >>> >>> Hi Jeff and Dr. McKusick, >>> =A0 =A0 Ran into this panic when /usr ran out of space doing a make >>> universe on amd64/r221219 (it took ~15 minutes for the panic to occur >>> after the filesystem ran out of space -- wasn't quite sure what it was >>> doing at the time): >>> >>> ... >>> >>> =A0 =A0 Let me know what other commands you would like for me to run in= kgdb. >>> Thanks, >>> -Garrett >> >> You did not indicate whether you are running an 8.X system or a 9-curren= t >> system. It would be helpful to know that. > > I've actually been running CURRENT for a few years now, but you're right = -- > I didn't mention that part. > >> Jeff thinks that there may be a potential race in the locking code for >> softdep_request_cleanup. If so, this patch for 9-current should fix it: >> >> Index: ffs_softdep.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- ffs_softdep.c =A0 =A0 =A0 (revision 221385) >> +++ ffs_softdep.c =A0 =A0 =A0 (working copy) >> @@ -11380,7 +11380,8 @@ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0continue; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MNT_IUNLOCK(mp); >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (vget(lvp, LK_EXCLUSIVE= | LK_INTERLOCK, curthread)) { >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (vget(lvp, LK_EXCLUSIVE= | LK_NOWAIT | LK_INTERLOCK, >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 curthread)) { >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MNT_ILOCK= (mp); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0continue; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >> FYI, I was playing with head (w/o the above patch) to reproduce the panic and go= t this LOR when filesystem was eventually filled. I'm not sure the patch would fix the panic but I think it should at least fix the LOR. kernel: pid 66153 (dd), uid 0 inumber 4 on /mnt: filesystem full lock order reversal: 1st 0xfffffe001d7d3310 ufs (ufs) @ /usr/src/sys/kern/vfs_vnops.c:614 2nd 0xffffff807ba8a800 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:265= 8 3rd 0xfffffe001ade7588 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2126 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff802d9eba =3D db_trace_self_wrapper+0x2= a kdb_backtrace() at 0xffffffff80475d17 =3D kdb_backtrace+0x37 _witness_debugger() at 0xffffffff8048b4fe =3D _witness_debugger+0x2e witness_checkorder() at 0xffffffff8048c7a7 =3D witness_checkorder+0x807 __lockmgr_args() at 0xffffffff80427553 =3D __lockmgr_args+0xd63 ffs_lock() at 0xffffffff806578fc =3D ffs_lock+0x9c VOP_LOCK1_APV() at 0xffffffff806f285f =3D VOP_LOCK1_APV+0xbf _vn_lock() at 0xffffffff804e87c7 =3D _vn_lock+0x57 vget() at 0xffffffff804dbb5b =3D vget+0x7b softdep_request_cleanup() at 0xffffffff80649f31 =3D softdep_request_cleanup= +0x311 ffs_alloc() at 0xffffffff80630b64 =3D ffs_alloc+0x134 ffs_balloc_ufs2() at 0xffffffff8063426c =3D ffs_balloc_ufs2+0x11ac ffs_write() at 0xffffffff8065889f =3D ffs_write+0x22f VOP_WRITE_APV() at 0xffffffff806f33dd =3D VOP_WRITE_APV+0x14d vn_write() at 0xffffffff804e9a42 =3D vn_write+0x2a2 dofilewrite() at 0xffffffff8048df25 =3D dofilewrite+0x85 kern_writev() at 0xffffffff8048f740 =3D kern_writev+0x60 write() at 0xffffffff8048f845 =3D write+0x55 syscallenter() at 0xffffffff80483cbb =3D syscallenter+0x1cb syscall() at 0xffffffff806abaf0 =3D syscall+0x60 Xfast_syscall() at 0xffffffff8069670d =3D Xfast_syscall+0xdd --- syscall (4, FreeBSD ELF64, write), rip =3D 0x8009438fc, rsp =3D 0x7fffffffda68, rbp =3D 0xa00000 --- --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Wed May 4 09:07:34 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4E10106567A for ; Wed, 4 May 2011 09:07:33 +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 792688FC20 for ; Wed, 4 May 2011 09:07:33 +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 p4497ImV074959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 May 2011 12:07:18 +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 p4497IVj026752; Wed, 4 May 2011 12:07:18 +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 p4497Itp026751; Wed, 4 May 2011 12:07:18 +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: Wed, 4 May 2011 12:07:18 +0300 From: Kostik Belousov To: Garrett Cooper Message-ID: <20110504090718.GN48734@deviant.kiev.zoral.com.ua> References: <201105040559.p445xEJ5024585@chez.mckusick.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZaNUQUWeUBsaJYg9" Content-Disposition: inline In-Reply-To: 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=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS,SUBJECT_FUZZY_TION autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Kirk McKusick , FreeBSD Current Subject: Re: Nasty non-recursive lockmgr panic on softdep only enabled UFS partition when filesystem full X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 09:07:34 -0000 --ZaNUQUWeUBsaJYg9 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 03, 2011 at 11:58:49PM -0700, Garrett Cooper wrote: > On Tue, May 3, 2011 at 11:42 PM, Garrett Cooper wrot= e: > > On Tue, May 3, 2011 at 10:59 PM, Kirk McKusick = wrote: > >>> Date: Tue, 3 May 2011 22:40:26 -0700 > >>> Subject: Nasty non-recursive lockmgr panic on softdep only enabled UFS > >>> =9Apartition when filesystem full > >>> From: Garrett Cooper > >>> To: Jeff Roberson , > >>> =9A =9A =9A =9A Marshall Kirk McKusick > >>> Cc: FreeBSD Current > >>> > >>> Hi Jeff and Dr. McKusick, > >>> =9A =9A Ran into this panic when /usr ran out of space doing a make > >>> universe on amd64/r221219 (it took ~15 minutes for the panic to occur > >>> after the filesystem ran out of space -- wasn't quite sure what it was > >>> doing at the time): > >>> > >>> ... > >>> > >>> =9A =9A Let me know what other commands you would like for me to run = in kgdb. > >>> Thanks, > >>> -Garrett > >> > >> You did not indicate whether you are running an 8.X system or a 9-curr= ent > >> system. It would be helpful to know that. > > > > I've actually been running CURRENT for a few years now, but you're righ= t -- > > I didn't mention that part. > > > >> Jeff thinks that there may be a potential race in the locking code for > >> softdep_request_cleanup. If so, this patch for 9-current should fix it: > >> > >> Index: ffs_softdep.c > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> --- ffs_softdep.c =9A =9A =9A (revision 221385) > >> +++ ffs_softdep.c =9A =9A =9A (working copy) > >> @@ -11380,7 +11380,8 @@ > >> =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Acontinu= e; > >> =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A} > >> =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9AMNT_IUNLOCK(mp); > >> - =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A if (vget(lvp, LK_EXCLUSI= VE | LK_INTERLOCK, curthread)) { > >> + =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A if (vget(lvp, LK_EXCLUSI= VE | LK_NOWAIT | LK_INTERLOCK, > >> + =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A curthread)) { > >> =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9AMNT_ILO= CK(mp); > >> =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Acontinu= e; > >> =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A} > >> > >> If you are running an 8.X system, hopefully you will be able to apply = it. > > > > =9A =9AI've applied it, rebuilt and installed the kernel, and trying to > > repro the case again. Will let you know how things go! >=20 > Happened again with the change. It's really easy to repro: >=20 > 1. Get a filesystem with UFS+SU > 2. Execute something that does a large number of small writes to a partit= ion. > 3. 'dd if=3D/dev/zero of=3DFOO bs=3D10m' on the same partition >=20 > The kernel will panic with the issue I discussed above. > Thanks! Jeff' change is required to avoid LORs, but it is not sufficient to prevent recursion. We must skip the vnode supplied as a parameter to softdep_request_cleanup(). Theoretically, other vnodes might be also locked by curthread, thus I think the change below is needed. Try this. diff --git a/sys/ufs/ffs/ffs_softdep.c b/sys/ufs/ffs/ffs_softdep.c index a6d4441..25fa5d6 100644 --- a/sys/ufs/ffs/ffs_softdep.c +++ b/sys/ufs/ffs/ffs_softdep.c @@ -11380,7 +11380,9 @@ retry: continue; } MNT_IUNLOCK(mp); - if (vget(lvp, LK_EXCLUSIVE | LK_INTERLOCK, curthread)) { + if (VOP_ISLOCKED(lvp) || + vget(lvp, LK_EXCLUSIVE | LK_INTERLOCK | LK_NOWAIT, + curthread)) { MNT_ILOCK(mp); continue; } --ZaNUQUWeUBsaJYg9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk3BF0YACgkQC3+MBN1Mb4i3iwCgz7uiG4c0n6uwFrvwpleaYTxO jCkAoLNhIi1EzRnMf7XANzcTxW71VY8d =As9g -----END PGP SIGNATURE----- --ZaNUQUWeUBsaJYg9-- From owner-freebsd-current@FreeBSD.ORG Wed May 4 10:23:52 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E68B1106564A for ; Wed, 4 May 2011 10:23:52 +0000 (UTC) (envelope-from larinus@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 6BAA38FC0A for ; Wed, 4 May 2011 10:23:51 +0000 (UTC) Received: by ewy1 with SMTP id 1so382928ewy.13 for ; Wed, 04 May 2011 03:23:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:in-reply-to :references:organization:x-mailer:mime-version:content-type :content-transfer-encoding; bh=j6P+PZjoIDQzvHCuG7TwRGZ6dFCjkKVSxokc+8shEzs=; b=rmESBWfz+iZa2YVYa3B6olUxjAcFG4NJePDz+eM+KRpr9arPklk8O7w6nTPi5maNqL F6AXKWp82fZhEDnzs42KE13n8Nt3gq/1zfSUhV9bX1t/jzvPpinXQQa5SvqckVnAEU+m Xy726TsPZEtrwd4HXGq3TVAoPFE9gUY7ib+ck= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:x-mailer:mime-version:content-type :content-transfer-encoding; b=nEYvCabVHvlpuILi1uJSIP6h7KD3JhmX4ORZLMt0B//XgI43P82U4b5lQgRhbt+sdA hB8B/kqA/pFLrZY7kTrxIM1pu+PpXqXEcFeQNyVozfLnQdgYrNL+SOZmRD9DgkABrkD+ IQYoOwFnRXh/kNVN2VGlXal0k5GBxWc9B4Jbw= Received: by 10.14.15.78 with SMTP id e54mr454831eee.80.1304504630741; Wed, 04 May 2011 03:23:50 -0700 (PDT) Received: from laptop (cs-service.by [195.222.65.5]) by mx.google.com with ESMTPS id y15sm733675eeh.13.2011.05.04.03.23.49 (version=SSLv3 cipher=OTHER); Wed, 04 May 2011 03:23:50 -0700 (PDT) Date: Wed, 4 May 2011 13:28:18 +0300 From: Vitaly Liaschuk To: Holger Kipp Message-ID: <20110504132818.62ea1695@laptop> In-Reply-To: <814C9E9472FDCC40AAC3FC95A2D67E3B0BD798A3@msx3.exchange.alogis.com> References: <20110503174949.7ada20dc@laptop> <814C9E9472FDCC40AAC3FC95A2D67E3B0BD798A3@msx3.exchange.alogis.com> Organization: HOME X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD current mailing list Subject: Re: firefox4+html5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 10:23:53 -0000 Yes, I understand this, but the same issue occurs on 8.x branch... But, I turned off all options for debugging and rebuild the kernel. Issue has not disappeared. On Tue, 3 May 2011 15:59:23 +0000 Holger Kipp wrote: > Dear Vitaly, > > I'm usually not using FreeBSD for accessing youtube, but > as you're using FreeBSD 9.0-current, please note that this > presumably has Witness enabled (because FreeBSD 9.0-current > is still development branch), which will reduce performance > and hence might give the problems you described. > > > from > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-options.html > > options WITNESS: this option enables run-time lock order tracking and > verification, and is an invaluable tool for deadlock diagnosis. > WITNESS maintains a graph of acquired lock orders by lock type, and > checks the graph at each acquire for cycles (implicit or explicit). > If a cycle is detected, a warning and stack trace are generated to > the console, indicating that a potential deadlock might have > occurred. WITNESS is required in order to use the show locks, show > witness and show alllocks DDB commands. This debug option has > significant performance overhead, which may be somewhat mitigated > through the use of options WITNESS_SKIPSPIN. Detailed documentation > may be found in witness(4). > > => http://www.freebsd.org/cgi/man.cgi?query=witness&sektion=4 > > Best regards, > Holger > > ________________________________________ > From: owner-freebsd-current@freebsd.org > [owner-freebsd-current@freebsd.org] on behalf of Vitaly Liaschuk > [larinus@gmail.com] Sent: 03 May 2011 16:49 To: FreeBSD current > mailing list Subject: firefox4+html5 > > Hi, list! > I do not know in what part of forum to write, so I decide write > in General. I'm trying to use html5 on youtube.com. I getting the > video stream, but audio "stutters" on most of video files . I tried > to use the chrome-browser and he is works fine. Also, I tried boot > from usb flash drive with installed ubuntu and firefox 4 and this > works. So, I believe what trouble is in my FreeBSD. [QUOTE] > > uname -a > FreeBSD laptop 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r221296M: Sun May > 1 20:13:15 EEST 2011 larin@laptop:/usr/obj/usr/src/sys/GENERIC > amd64 > > > [/QUOTE] > > My box is: Laptop asus UL30A, 3 GB ram, Intel CPU U2300 1.2Mhz. > > Thanks in advance. > _______________________________________________ > 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" > > > -- > Holger Kipp > Diplom-Mathematiker > Senior Consultant > > Tel. : +49 30 436 58 114 > Fax. : +49 30 436 58 214 > Mobil: +49 178 36 58 114 > Email: holger.kipp@alogis.com > > alogis AG > Alt-Moabit 90b > D-10559 Berlin > > web : http://www.alogis.com > > ---------------------------------------------------------- > > alogis AG > Sitz/Registergericht: Berlin/AG Charlottenburg, HRB 71484 > Vorstand: Arne Friedrichs, Joern Samuelson > Aufsichtsratsvorsitzender: Reinhard Mielke From owner-freebsd-current@FreeBSD.ORG Wed May 4 10:36:54 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 536AC106564A for ; Wed, 4 May 2011 10:36:54 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id EA96B8FC14 for ; Wed, 4 May 2011 10:36:53 +0000 (UTC) Received: from megatron.madpilot.net (localhost [127.0.0.1]) by megatron.madpilot.net (Postfix) with ESMTP id 816F31A56 for ; Wed, 4 May 2011 12:36:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= user-agent:in-reply-to:content-disposition:content-type :content-type:mime-version:references:message-id:subject:subject :from:from:date:date:received:received; s=mail; t=1304505410; x= 1306319810; bh=Mu3CCz12qOntxmrFaauoZrqr+WdBlRR5CVdDX73fBTA=; b=U 8Xdd19vcHiuppSCxxNvtGH7RvQhOUv+zZEGTM6iiCmJjr0kExUI+6haEK5lAfKCC eNiUdDh1xq/tKrJyVNYzznKBHaxGUFMVi2GP3RGcTfVLtGiKaGn7FyBEk2PuUP9A sQhIKJLKQM/QRKmdJ4ln7sYRGwQUNEqlovnHGyorgI= X-Virus-Scanned: amavisd-new at madpilot.net Received: from megatron.madpilot.net ([127.0.0.1]) by megatron.madpilot.net (megatron.madpilot.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id jjMclxAyIpdp for ; Wed, 4 May 2011 12:36:50 +0200 (CEST) Received: by megatron.madpilot.net (Postfix, from userid 1000) id 25C581A4D; Wed, 4 May 2011 12:36:50 +0200 (CEST) Date: Wed, 4 May 2011 12:36:49 +0200 From: Guido Falsi To: freebsd-current@freebsd.org Message-ID: <20110504103649.GB29667@megatron.madpilot.net> References: <20110503174949.7ada20dc@laptop> <4DC045D5.7000802@madpilot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DC045D5.7000802@madpilot.net> X-Operating-System: FreeBSD 8.2-STABLE User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: firefox4+html5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 10:36:54 -0000 On Tue, May 03, 2011 at 08:13:41PM +0200, Guido Falsi wrote: > On 05/03/11 19:19, Francois Gerodez wrote: > >Hi all, > > > >I'm currently running FreeBSD 8.1 (latest update) and I'm experiencing a > >similar issue. HTML5 videos are very laggy (both image and sound) with > >Firefox 4. I ended up installing the flash player to watch youtube > >streaming. > > > >I didn't spot any particular warning/error messages so I don't know where to > >start... > > > > I have these symptoms too, but usually if I pause the video, send it > back to the start with the slider and finally start playing it goes > smoothly usually. > > This is quite strange, I know. Perhaps someone else should check if > this is the same for everyone or just something that is happening to > me. Forgot to mension. I'm using 8-stable, not -current. Did not check which list I was writing to. Sorry. -- Guido Falsi From owner-freebsd-current@FreeBSD.ORG Wed May 4 10:45:03 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C013D106564A for ; Wed, 4 May 2011 10:45:03 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from fallbackmx06.syd.optusnet.com.au (fallbackmx06.syd.optusnet.com.au [211.29.132.8]) by mx1.freebsd.org (Postfix) with ESMTP id 4C1078FC08 for ; Wed, 4 May 2011 10:45:02 +0000 (UTC) Received: from mail14.syd.optusnet.com.au (mail14.syd.optusnet.com.au [211.29.132.195]) by fallbackmx06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p448M6J2012566 for ; Wed, 4 May 2011 18:22:06 +1000 Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail14.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p448M33u016402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 May 2011 18:22:04 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id p448M3FC064806; Wed, 4 May 2011 18:22:03 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id p448M2cx064805; Wed, 4 May 2011 18:22:02 +1000 (EST) (envelope-from peter) Date: Wed, 4 May 2011 18:22:02 +1000 From: Peter Jeremy To: Rick Macklem Message-ID: <20110504082202.GA64659@server.vk2pj.dyndns.org> References: <1088403240.552644.1303777994659.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline In-Reply-To: <1088403240.552644.1303777994659.JavaMail.root@erie.cs.uoguelph.ca> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: Re: newnfs NFS client testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 10:45:03 -0000 --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Apr-25 20:33:14 -0400, Rick Macklem wrote: >I believe that the new/experimental NFS client in head is now >compatible with the old/regular NFS client. Possibly even too compatible... Both the old and new NFS clients assume a 1:1 mapping between NFS error codes (NFSERR_* macros defined in ) and the E* macros in : In the old client, the NFS status is copied =66rom the RPC response by nfsclient/nfs_krpc.c:nfs_request(), returned and passed back up the call chain. In the new client, the status is copied from the RPC response into struct nfsrv_descript.nd_repstat by fs/nfs/nfs_commonkrpc.c:newnfs_request() and then moved into an error return in fs/nfsclient/nfs_clrpcops.c:nfsrpc_*(). This is not currently a problem but it would seem useful to include notes in and warning of this assumption in case of future changes. Note that both NFS servers do include code for error code mapping. --=20 Peter Jeremy --EeQfGwPcQSOJBaQU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk3BDKoACgkQ/opHv/APuIdi6ACfV7oz27277ZxpRDKif44Nh3ly RR4AnRMUKwXPumMGDdTHsYPHNPT7UFsx =b0AG -----END PGP SIGNATURE----- --EeQfGwPcQSOJBaQU-- From owner-freebsd-current@FreeBSD.ORG Wed May 4 06:35:42 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15629106564A; Wed, 4 May 2011 06:35:42 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [64.81.247.49]) by mx1.freebsd.org (Postfix) with ESMTP id CD9EE8FC13; Wed, 4 May 2011 06:35:41 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id p445xEJ5024585; Tue, 3 May 2011 22:59:14 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201105040559.p445xEJ5024585@chez.mckusick.com> To: Garrett Cooper In-reply-to: Date: Tue, 03 May 2011 22:59:14 -0700 From: Kirk McKusick X-Spam-Status: No, score=0.4 required=5.0 tests=MISSING_MID, SUBJECT_FUZZY_TION, UNPARSEABLE_RELAY autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on chez.mckusick.com X-Mailman-Approved-At: Wed, 04 May 2011 11:15:30 +0000 Cc: FreeBSD Current Subject: Re: Nasty non-recursive lockmgr panic on softdep only enabled UFS partition when filesystem full X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 06:35:42 -0000 > Date: Tue, 3 May 2011 22:40:26 -0700 > Subject: Nasty non-recursive lockmgr panic on softdep only enabled UFS > partition when filesystem full > From: Garrett Cooper > To: Jeff Roberson , > Marshall Kirk McKusick > Cc: FreeBSD Current > > Hi Jeff and Dr. McKusick, > Ran into this panic when /usr ran out of space doing a make > universe on amd64/r221219 (it took ~15 minutes for the panic to occur > after the filesystem ran out of space -- wasn't quite sure what it was > doing at the time): > > ... > > Let me know what other commands you would like for me to run in kgdb. > Thanks, > -Garrett You did not indicate whether you are running an 8.X system or a 9-current system. It would be helpful to know that. Jeff thinks that there may be a potential race in the locking code for softdep_request_cleanup. If so, this patch for 9-current should fix it: Index: ffs_softdep.c =================================================================== --- ffs_softdep.c (revision 221385) +++ ffs_softdep.c (working copy) @@ -11380,7 +11380,8 @@ continue; } MNT_IUNLOCK(mp); - if (vget(lvp, LK_EXCLUSIVE | LK_INTERLOCK, curthread)) { + if (vget(lvp, LK_EXCLUSIVE | LK_NOWAIT | LK_INTERLOCK, + curthread)) { MNT_ILOCK(mp); continue; } If you are running an 8.X system, hopefully you will be able to apply it. Kirk McKusick From owner-freebsd-current@FreeBSD.ORG Wed May 4 07:12:20 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2668D1065670 for ; Wed, 4 May 2011 07:12:20 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id D72AF8FC0C for ; Wed, 4 May 2011 07:12:19 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1QHWFu-0000QJ-S2>; Wed, 04 May 2011 09:12:18 +0200 Received: from e178021236.adsl.alicedsl.de ([85.178.21.236] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1QHWFu-0002rQ-Od>; Wed, 04 May 2011 09:12:18 +0200 Message-ID: <4DC0FC52.8070701@mail.zedat.fu-berlin.de> Date: Wed, 04 May 2011 09:12:18 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Dimitry Andric References: <4DBDB8D4.6050102@mail.zedat.fu-berlin.de> <4DC04F29.2050401@mail.zedat.fu-berlin.de> <4DC0F98D.3020601@FreeBSD.org> In-Reply-To: <4DC0F98D.3020601@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Originating-IP: 85.178.21.236 X-Mailman-Approved-At: Wed, 04 May 2011 11:15:41 +0000 Cc: Olivier Smedts , freebsd-current@freebsd.org Subject: Re: Building FreeBSD 9.0-CUR/amd64 with CLANG fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 07:12:20 -0000 On 05/04/11 09:00, Dimitry Andric wrote: > On 2011-05-03 20:53, O. Hartmann wrote: > ... >>>> ld -m elf_i386_fbsd -Y P,/usr/obj/usr/src/lib32/usr/lib32 =EF=BF=BD-= o >>>> gcrt1.o -r >>>> crt1_s.o gcrt1_c.o >>>> ld: Relocatable linking with relocations from format >>>> elf64-x86-64-freebsd >>>> (crt1_s.o) to format elf32-i386-freebsd (gcrt1.o) is not supported > ... >> Today, I tried again, after CLANG/LLVM has been updated to version 3.0= =2E >> Same error. >> >> This is the addendum I made to the /etc/make.conf: >> >> ## >> ## CLANG >> ## >> .if defined(USE_CLANG) >> .if !defined(CC) || ${CC} =3D=3D "cc" >> CC=3Dclang >> .endif >> .if !defined(CXX) || ${CXX} =3D=3D "c++" >> CXX=3Dclang++ >> .endif >> # Don't die on warnings >> NO_WERROR=3D >> WERROR=3D >> # Don't forget this when using Jails! >> NO_FSCHG=3D >> .endif > > Ok, that looks good, I use a similar construction. However, in my case > it works fine, so there must be something special on your system that > breaks the build. > > What happens here, is that the 32-bit stage on amd64 fails, because it > tries to link together 64-bit and 32-bit object files, which is not > allowed. This can occur if Makefile.inc1 cannot set CC to the correct > value, but there might also be something else going on. > > To debug this further, can you please post: > - Your full /etc/make.conf > - Your full /etc/src.conf > - Any modifications you made to your source tree > - The specific procedure you use for buildworld > - An url to a full build log (don't post it to the list, because it wil= l > be rather large) > When commenting out the wrapping =2Eif defined(USE_CLANG) =2Eendif construct, as suffested by Olivier, it works. I gues I found my mistake: = From an earlier attempt of building FreeBSD with clang, I placed the=20 WIKI suggestions into /etc/src.conf and I never recalled this. I delete=20 it and try again ... On my lab's box, same OS, same revision, nearly same hardware, building=20 world/kernel worked fine even with the 'switch' - but there wasn't=20 /etc/src.conf. Thanks for the hints. I'll report again. Regards, Oliver From owner-freebsd-current@FreeBSD.ORG Wed May 4 07:16:23 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABCC0106564A for ; Wed, 4 May 2011 07:16:23 +0000 (UTC) (envelope-from agh@fastmail.fm) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 758D78FC13 for ; Wed, 4 May 2011 07:16:22 +0000 (UTC) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.messagingengine.com (Postfix) with ESMTP id 80AC020764; Wed, 4 May 2011 03:00:22 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Wed, 04 May 2011 03:00:22 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=date:from:to:cc:subject:message-id:references:mime-version:content-type:in-reply-to; s=smtpout; bh=Pn8vXfF5hIREQOQPWbgn0kxwtj0=; b=Ns6rWNS95h3fEVJJORCHRLYMsn7DkuYH/+NrZrIOZ5zDBq75vKwH/lEMvr5/Ga+xNgEkucyR/Xf/ujY/iiblq0zSVnC2++hakUuglAIO3ItKQ/qxHj+RJWXRcxx+TYmDsR04X111mFs/EqrpupxHwHdOv82LjnfFi9Jj1McUdZk= X-Sasl-enc: 29hjhyMYIWOd7kVEkcWr3TSvh8M6CzRL7gpNl39rY/IL 1304492421 Received: from direwolf (203-59-221-16.perm.iinet.net.au [203.59.221.16]) by mail.messagingengine.com (Postfix) with ESMTPSA id 3E4AB446184; Wed, 4 May 2011 03:00:19 -0400 (EDT) Date: Wed, 4 May 2011 15:00:16 +0800 From: Alastair Hogge To: Michael Schmiedgen Message-ID: <20110504070015.GB2700@direwolf> References: <4D94A354.9080903@sentex.net> <4DC07013.9070707@gmx.net> <4DC078BD.9080908@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DC078BD.9080908@gmx.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Wed, 04 May 2011 11:15:53 +0000 Cc: Olivier Smedts , Mike Tancsa , Jack Vogel , FreeBSD current mailing list Subject: Re: problems with em(4) since update to driver 7.2.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 07:16:23 -0000 On Tue, May 03, 2011 at 11:50:53PM +0200, Michael Schmiedgen wrote: > On 03.05.2011 23:24, Jack Vogel wrote: > > If you get the setup receive structures fail, then increase the nmbclusters. > > > > If you use standard MTU then what you need are mbufs, and standard size > > clusters (2K). > > Only when you use jumbo frames will you need larger. > > > > You must configure enough, its that simple. > > I doubled the nmbclusters as well. But nothing happened. > > I have no load on this machine and nothing special > configured. > > Thanks, > Michael Just a me too. I've been following -CURRENT(r221415) but I keep /sys/dev/e1000 at r218909 to keep em0 working without problems on -CURRENT. I also tried 2x, & 4x 25600 for max mbuff clusters via kern.ipc.nmbclusters. This didn't help. -alastair From owner-freebsd-current@FreeBSD.ORG Wed May 4 07:17:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD865106564A for ; Wed, 4 May 2011 07:17:24 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 7A7DF8FC0A for ; Wed, 4 May 2011 07:17:24 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1QHWKp-0002lM-OP>; Wed, 04 May 2011 09:17:23 +0200 Received: from e178021236.adsl.alicedsl.de ([85.178.21.236] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1QHWKp-0003DM-Kz>; Wed, 04 May 2011 09:17:23 +0200 Message-ID: <4DC0FD83.5080504@mail.zedat.fu-berlin.de> Date: Wed, 04 May 2011 09:17:23 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Dimitry Andric References: <4DBDB8D4.6050102@mail.zedat.fu-berlin.de> <4DC04F29.2050401@mail.zedat.fu-berlin.de> <4DC0F98D.3020601@FreeBSD.org> In-Reply-To: <4DC0F98D.3020601@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Originating-IP: 85.178.21.236 X-Mailman-Approved-At: Wed, 04 May 2011 11:16:06 +0000 Cc: Olivier Smedts , freebsd-current@freebsd.org Subject: Re: Building FreeBSD 9.0-CUR/amd64 with CLANG fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 07:17:24 -0000 On 05/04/11 09:00, Dimitry Andric wrote: > On 2011-05-03 20:53, O. Hartmann wrote: > ... >>>> ld -m elf_i386_fbsd -Y P,/usr/obj/usr/src/lib32/usr/lib32 =EF=BF=BD-= o >>>> gcrt1.o -r >>>> crt1_s.o gcrt1_c.o >>>> ld: Relocatable linking with relocations from format >>>> elf64-x86-64-freebsd >>>> (crt1_s.o) to format elf32-i386-freebsd (gcrt1.o) is not supported > ... >> Today, I tried again, after CLANG/LLVM has been updated to version 3.0= =2E >> Same error. >> >> This is the addendum I made to the /etc/make.conf: >> >> ## >> ## CLANG >> ## >> .if defined(USE_CLANG) >> .if !defined(CC) || ${CC} =3D=3D "cc" >> CC=3Dclang >> .endif >> .if !defined(CXX) || ${CXX} =3D=3D "c++" >> CXX=3Dclang++ >> .endif >> # Don't die on warnings >> NO_WERROR=3D >> WERROR=3D >> # Don't forget this when using Jails! >> NO_FSCHG=3D >> .endif > > Ok, that looks good, I use a similar construction. However, in my case > it works fine, so there must be something special on your system that > breaks the build. > > What happens here, is that the 32-bit stage on amd64 fails, because it > tries to link together 64-bit and 32-bit object files, which is not > allowed. This can occur if Makefile.inc1 cannot set CC to the correct > value, but there might also be something else going on. > > To debug this further, can you please post: > - Your full /etc/make.conf > - Your full /etc/src.conf > - Any modifications you made to your source tree > - The specific procedure you use for buildworld > - An url to a full build log (don't post it to the list, because it wil= l > be rather large) > Sorry for the noise. But when I tried to compile essential ports (essential to me), like=20 x11-wm/windowmaker, mulitmedia/ffmpeg, for instance, I run into serious=20 compiler/assembler error with LLVM/CLANG. I guess the ports- tree isn't=20 mature for clang. So am I right in this thinking: leaving /etc/make.conf = untouched in terms of not putting there the CLANG build construct and=20 putting this instead into /etc/src.conf will only affect the OS' source=20 tree to be build by clang and all ports are build by the antique=20 system's gcc 4.2.1? Oliver From owner-freebsd-current@FreeBSD.ORG Wed May 4 11:17:01 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF31B1065675 for ; Wed, 4 May 2011 11:17:01 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id ACF6F8FC26 for ; Wed, 4 May 2011 11:17:01 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1QHa4i-0001JG-UE>; Wed, 04 May 2011 13:17:00 +0200 Received: from e178021236.adsl.alicedsl.de ([85.178.21.236] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1QHa4i-0005X0-Rp>; Wed, 04 May 2011 13:17:00 +0200 Message-ID: <4DC135AC.2060402@mail.zedat.fu-berlin.de> Date: Wed, 04 May 2011 13:17:00 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.21.236 X-Mailman-Approved-At: Wed, 04 May 2011 11:55:11 +0000 Subject: FreeBSD 9.0/CUR/amd64, built with LLVM/CLANG fails starting LibreOffice 3.3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 11:17:02 -0000 After building FreeBSD 9.0/amd64 (FreeBSD 9.0-CURRENT #182 r221413: Tue May 3 23:30:11 CEST 2011), the opensource office software LibreOffice (libreoffice-3.3.2) won't start and crashes with pid 53801 (soffice.bin), uid 8152: exited on signal 8 (core dumped) (shown in console). What's wrong? Oliver From owner-freebsd-current@FreeBSD.ORG Wed May 4 13:44:37 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 143FF1065670 for ; Wed, 4 May 2011 13:44:37 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [216.101.162.50]) by mx1.freebsd.org (Postfix) with ESMTP id B73A88FC08 for ; Wed, 4 May 2011 13:44:36 +0000 (UTC) Received: from T61p.pozo.com (t61p.pozo.com [192.168.0.4]) (authenticated bits=0) by pozo.com (8.14.4/8.14.4) with ESMTP id p44DiOId032272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 May 2011 06:44:24 -0700 (PDT) (envelope-from null@pozo.com) Message-Id: <201105041344.p44DiOId032272@pozo.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 04 May 2011 06:44:18 -0700 To: Dimitry Andric From: Manfred Antar In-Reply-To: <4DC0F46C.3020806@FreeBSD.org> References: <201105040107.p4417NTR048534@pozo.com> <4DC0F46C.3020806@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-100.9 required=5.0 tests=ALL_TRUSTED,MISSING_MID, USER_IN_WHITELIST autolearn=no version=3.3.1, No X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: p44DiOId032272 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com Cc: current@FreeBSD.org Subject: Re: Clang error make buildworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 13:44:37 -0000 At 11:38 PM 5/3/2011, Dimitry Andric wrote: >On 2011-05-04 03:07, Manfred Antar wrote: >>I get this error when trying to buildworld on current i386. >>It's been this way for awhile Any Ideas ? >> >>===> boot/i386/boot0 (all) >>clang -O2 -pipe -DVOLUME_SERIAL -DPXE -DFLAGS=0x8f -DTICKS=0xb6 -DCOMSPEED="7<< 5 + 3" -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -std=gnu99 -c /usr/src/sys/boot/i386/boot0/boot0.S >>clang: warning: argument unused during compilation: '-mpreferred-stack-boundary=2' >>/tmp/cc-4SXZt8.s:42:11: error: .code16 not supported yet > >For some reason, on your system, it does not compile boot0.S with >-no-integrated-as. It works fine here though, so it must be something >local to your system. Can you please post: > >- Your full make.conf and src.conf >- The first 30 lines of sys/boot/i386/boot0/Makefile Ok: src.conf: WITHOUT_DYNAMICROOT=yes WITH_IDEA=yes .if !defined(CC) || ${CC} == "cc" CC=clang .endif .if !defined(CXX) || ${CXX} == "c++" CXX=clang++ .endif #Don't die on warnings NO_WERROR= WERROR= make conf: # $FreeBSD: src/share/examples/etc/make.conf,v 1.276 2006/03/21 09:49:05 ru Exp $ # # NOTE: Please would any committer updating this file also update the # make.conf(5) manual page, if necessary, which is located in # src/share/man/man5/make.conf.5. # # /etc/make.conf, if present, will be read by make (see # /usr/share/mk/sys.mk). It allows you to override macro definitions # to make without changing your source tree, or anything the source # tree installs. # # This file must be in valid Makefile syntax. # # There are additional things you can put into /etc/make.conf. # You have to find those in the Makefiles and documentation of # the source tree. # # Note, that you should not set MAKEOBJDIRPREFIX or MAKEOBJDIR # from make.conf (or as command line variables to make). # Both variables are environment variables for make and must be used as: # # env MAKEOBJDIRPREFIX=/big/directory make # # # The CPUTYPE variable controls which processor should be targeted for # generated code. This controls processor-specific optimizations in # certain code (currently only OpenSSL) as well as modifying the value # of CFLAGS to contain the appropriate optimization directive to gcc. # The automatic setting of CFLAGS may be overridden using the # NO_CPU_CFLAGS variable below. # Currently the following CPU types are recognized: # Intel x86 architecture: # (AMD CPUs) opteron athlon64 athlon-mp athlon-xp athlon-4 # athlon-tbird athlon k8 k6-3 k6-2 k6 k5 # (Intel CPUs) nocona pentium4[m] prescott pentium3[m] pentium-m # pentium2 pentiumpro pentium-mmx pentium i486 i386 # Alpha/AXP architecture: ev67 ev6 pca56 ev56 ev5 ev45 ev4 # AMD64 architecture: opteron, athlon64, nocona # Intel ia64 architecture: itanium2, itanium # # (?= allows to buildworld for a different CPUTYPE.) # #CPUTYPE?=pentium3 #NO_CPU_CFLAGS= # Don't add -march= to CFLAGS automatically #NO_CPU_COPTFLAGS= # Don't add -march= to COPTFLAGS automatically # # CFLAGS controls the compiler settings used when compiling C code. # Note that optimization settings other than -O and -O2 are not recommended # or supported for compiling the world or the kernel - please revert any # nonstandard optimization settings to "-O" or -O2 before submitting bug # reports without patches to the developers. # #CFLAGS= -O -pipe -Wl,--export-dynamic #FOR APACHE# #CFLAGS= -O -pipe -no-integrated-as # # CXXFLAGS controls the compiler settings used when compiling C++ code. # Note that CXXFLAGS is initially set to the value of CFLAGS. If you wish # to add to CXXFLAGS value, "+=" must be used rather than "=". Using "=" # alone will remove the often needed contents of CFLAGS from CXXFLAGS. # #CXXFLAGS+= -fconserve-space # # MAKE_SHELL controls the shell used internally by make(1) to process the # command scripts in makefiles. Three shells are supported, sh, ksh, and # csh. Using sh is most common, and advised. Using ksh *may* work, but is # not guaranteed to. Using csh is absurd. The default is to use sh. # #MAKE_SHELL?=sh # # BDECFLAGS are a set of gcc warning settings that Bruce Evans has suggested # for use in developing FreeBSD and testing changes. They can be used by # putting "CFLAGS+=${BDECFLAGS}" in /etc/make.conf. -Wconversion is not # included here due to compiler bugs, e.g., mkdir()'s mode_t argument. # #BDECFLAGS= -W -Wall -ansi -pedantic -Wbad-function-cast -Wcast-align \ # -Wcast-qual -Wchar-subscripts -Winline \ # -Wmissing-prototypes -Wnested-externs -Wpointer-arith \ # -Wredundant-decls -Wshadow -Wstrict-prototypes -Wwrite-strings # # To compile just the kernel with special optimizations, you should use # this instead of CFLAGS (which is not applicable to kernel builds anyway). # There is very little to gain by using higher optimization levels, and doing # so can cause problems. # COPTFLAGS= -O -pipe # # Compare before install #INSTALL=install -C # # Mtree will follow symlinks #MTREE_FOLLOWS_SYMLINKS= -L # # To enable installing ssh(1) with the setuid bit turned on #ENABLE_SUID_SSH= # # To enable installing newgrp(1) with the setuid bit turned on. # Without the setuid bit, newgrp cannot change users' groups. #ENABLE_SUID_NEWGRP= # # To avoid building various parts of the base system: #NO_MODULES= # do not build modules with the kernel #NO_SHARE= # do not go into the share subdir #NO_SHARED= # build /bin and /sbin statically linked (bad idea) # # Variables that control how ppp(8) is built. #PPP_NO_NAT= # do not build with NAT support (see make.conf(5)) #PPP_NO_NETGRAPH= # do not build with Netgraph support #PPP_NO_RADIUS= # do not build with RADIUS support #PPP_NO_SUID= # build with normal permissions # #TRACEROUTE_NO_IPSEC= # do not build traceroute(8) with IPSEC support # # To build sys/modules when building the world (our old way of doing things) #MODULES_WITH_WORLD= # do not build modules when building kernel # # The list of modules to build instead of all of them. #MODULES_OVERRIDE= ispfw linux linprocfs acpi MODULES_OVERRIDE= linux linprocfs # # The list of modules to never build, applied *after* MODULES_OVERRIDE. #WITHOUT_MODULES= bktr plip # # If you do not want unformatted manual pages to be compressed # when they are installed: # #NO_MANCOMPRESS= # # # Default format for system documentation, depends on your printer. # Set this to "ascii" for simple printers or screen # #PRINTERDEVICE= ps # # # How long to wait for a console keypress before booting the default kernel. # This value is approximately in milliseconds. Keypresses are accepted by the # BIOS before booting from disk, making it possible to give custom boot # parameters even when this is set to 0. # #BOOTWAIT=0 #BOOTWAIT=30000 # # By default, the system will always use the keyboard/video card as system # console. However, the boot blocks may be dynamically configured to use a # serial port in addition to or instead of the keyboard/video console. # # By default we use COM1 as our serial console port *if* we're going to use # a serial port as our console at all. Alter as necessary. # # COM1: = 0x3F8, COM2: = 0x2F8, COM3: = 0x3E8, COM4: = 0x2E8 # BOOT_COMCONSOLE_PORT= 0x3F8 # # The default serial console speed is 9600. Set the speed to a larger value # for better interactive response. # BOOT_COMCONSOLE_SPEED= 57600 # # By default the 'pxeboot' loader retrieves the kernel via NFS. Defining # this and recompiling /usr/src/sys/boot will cause it to retrieve the kernel # via TFTP. This allows pxeboot to load a custom BOOTP diskless kernel yet # still mount the server's '/' (i.e. rather than load the server's kernel). # #LOADER_TFTP_SUPPORT= YES # # # Kerberos 5 su (k5su) # If you want to use the k5su utility, define this to have it installed # set-user-ID. #ENABLE_SUID_K5SU= # # # CVSup update flags. Edit SUPFILE settings to reflect whichever distribution # file(s) you use on your site (see /usr/share/examples/cvsup/README for more # information on CVSup and these files). To use, do "make update" in /usr/src. # SUP_UPDATE=yes # SUP= /usr/local/bin/cvsup SUPFLAGS= -L 2 -g SUPHOST= cvsup.us.freebsd.org SUPFILE= /usr/src/share/examples/cvsup/standard-supfile PORTSSUPFILE= /usr/src/share/examples/cvsup/ports-supfile DOCSUPFILE= /usr/src/share/examples/cvsup/doc-supfile # # top(1) uses a hash table for the user names. The size of this hash # can be tuned to match the number of local users. The table size should # be a prime number approximately twice as large as the number of lines in # /etc/passwd. The default number is 20011. # #TOP_TABLE_SIZE= 101 # # Documentation # # The list of languages and encodings to build and install # #DOC_LANG= en_US.ISO8859-1 ru_RU.KOI8-R # # # sendmail # # The following sets the default m4 configuration file to use at # install time. Use with caution as a make install will overwrite # any existing /etc/mail/sendmail.cf. Note that SENDMAIL_CF is now # deprecated. The value should be a fully qualified path name. # SENDMAIL_MC=/root/sendmail/pozo.mc # # The following sets the default m4 configuration file for mail # submission to use at install time. Use with caution as a make # install will overwrite any existing /etc/mail/submit.cf. The # value should be a fully qualified path name. # SENDMAIL_SUBMIT_MC=/root/sendmail/pozo-submit.mc # # If you need to build additional .cf files during a make buildworld, # include the full paths to the .mc files in SENDMAIL_ADDITIONAL_MC. # #SENDMAIL_ADDITIONAL_MC=/etc/mail/foo.mc /etc/mail/bar.mc # # The following overrides the default location for the m4 configuration # files used to build a .cf file from a .mc file. # #SENDMAIL_CF_DIR=/usr/local/share/sendmail/cf # # Setting the following variable modifies the flags passed to m4 when # building a .cf file from a .mc file. It can be used to enable # features disabled by default. # #SENDMAIL_M4_FLAGS= # # Setting the following variables modifies the build environment for # sendmail and its related utilities. For example, SASL support can be # added with settings such as: # # with SASLv1: # SENDMAIL_CFLAGS=-I/usr/local/include/sasl1 -DSASL # SENDMAIL_LDFLAGS=-L/usr/local/lib # SENDMAIL_LDADD=-lsasl # # with SASLv2: # SENDMAIL_CFLAGS=-I/usr/local/include -DSASL=2 # SENDMAIL_LDFLAGS=-L/usr/local/lib # SENDMAIL_LDADD=-lsasl2 # # Note: If you are using Cyrus SASL with other applications which require # access to the sasldb file, you should add the following to your # sendmail.mc file: # # define(`confDONT_BLAME_SENDMAIL',`GroupReadableSASLDBFile') # # SENDMAIL_CFLAGS=-I/usr/local/include -DSASL=2 SENDMAIL_LDFLAGS=-L/usr/local/lib SENDMAIL_LDADD=-lsasl2 #SENDMAIL_CFLAGS=-I/usr/local/include/sasl1 -DSASL #SENDMAIL_LDFLAGS=-L/usr/local/lib -R/usr/local/lib -L/usr/local/lib/mysql -R/usr/local/lib/mysql #SENDMAIL_LDADD=-lsasl -lmysqlclient -ldb3 #SENDMAIL_DPADD= # # Setting SENDMAIL_SET_USER_ID will install the sendmail binary as a # set-user-ID root binary instead of a set-group-ID smmsp binary and will # prevent the installation of /etc/mail/submit.cf. # This is a deprecated mode of operation. See etc/mail/README for more # information. # #SENDMAIL_SET_USER_ID= # # The permissions to use on alias and map databases generated using # /etc/mail/Makefile. Defaults to 0640. # #SENDMAIL_MAP_PERMS= # # ########My Stuff######################################################## APACHE_PORT?=www/apache22 INSTALL_NODEBUG=yes X_WINDOW_SYSTEM=xorg HAVE_MOTIF=yes USA_RESIDENT=YES FORCE_PKG_REGISTER=YES KERNCONF=COMPAQ JADETEX=yes WITH_ISPELL=yes WITH_LZW=yes WITH_MUTT_NNTP=yes #WITH_MUTT_MBOX_HOOK_PATCH=yes WITH_MUTT_EDIT_THREADS=yes WITH_MUTT_SLANG2=yes MUTT_USES_SLANG2=yes WITH_MUTT_ASPELL=yes #WITH_MUTT-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MENU=yes WITH_MUTT_IFDEF_PATCH=yes WITH_MUTT_MAILDIR_MTIME_PATCH=yes WITH_ARTS=yes WITH_ESOUND=yes WITH_GUI=yes ENABLE_SUIDPERL=yes WITH_GDBM=yes WITHOUT_PERL_MALLOC=yes INLINE_IMAGE=yes WITH_TOC2MP3=yes WITHOUT_PILOT=yes WANT_STATIC_BASH=yes WITH_SSL_AND_PLAINTEXT=yes WITH_BDB_VER=41 WITH_STATIC_BASH=yes WITH_OPENSSL_BASE=yes BUILD_STATIC=yes ##########NVIDIA############## WITH_NVIDIA_GL=no WITHOUT_XVMC=yes ####RXVT STUFF ####### WITH_GRAPHICS=yes WITH_MENUBAR=yes WITH_NEXT_SCROLLBAR=yes WITH_SMART_RESIZE=yes ######FFMPEG############ WITH_DTS=YES WITH_FAAC=YES WITH_FAAD=YES WITH_FREETYPE2=YES WITH_LAME=YES WITH_VORBIS=YES WITH_X264=YES WITH_XVID=YES WITH_GECKO=libxul # added by use.perl 2011-01-25 10:00:28 PERL_VERSION=5.12.3 # $FreeBSD: src/sys/boot/i386/boot0/Makefile,v 1.37 2011/02/20 19:33:47 dim Exp $ PROG?= boot0 STRIP= BINMODE=${NOBINMODE} NO_MAN= SRCS= ${PROG}.S # Additional options that you can specify with make OPTS="..." # (these only apply to boot0.S) # # -DVOLUME_SERIAL support volume serial number (NT, XP, Vista) # -DSIO do I/O using COM1: # -DPXE fallback to INT18/PXE with F6 # -DCHECK_DRIVE enable checking drive number # -DONLY_F_KEYS accept only Fx keys in console # -DTEST print drive number on entry # OPTS ?= -DVOLUME_SERIAL -DPXE CFLAGS += ${OPTS} .if ${CC:T:Mclang} == "clang" # XXX: clang integrated-as doesn't grok .codeNN directives yet CFLAGS+= ${.IMPSRC:T:Mboot0.S:C/^.+$/-no-integrated-as/} CFLAGS+= ${.IMPSRC:T:Mboot0ext.S:C/^.+$/-no-integrated-as/} .endif # Flags used in the boot0.S code: # 0x0f all valid partitions enabled. # 0x80 'packet', use BIOS EDD (LBA) extensions instead of CHS # to read from disk. boot0.S does not check that the extensions # are supported, but all modern BIOSes should have them. # 0x40 'noupdate', disable writing boot0 back to disk so that # the current selection is not preserved across reboots. # 0x20 'setdrv', override the drive number supplied by the bios # with the one in the boot sector. From owner-freebsd-current@FreeBSD.ORG Wed May 4 14:20:40 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AA161065673 for ; Wed, 4 May 2011 14:20:40 +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 D07CD8FC26 for ; Wed, 4 May 2011 14:20:39 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:e12e:ab0b:b5d8:d1f0] (unknown [IPv6:2001:7b8:3a7:0:e12e:ab0b:b5d8:d1f0]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id B81895C59; Wed, 4 May 2011 16:20:38 +0200 (CEST) Message-ID: <4DC160B9.5060004@FreeBSD.org> Date: Wed, 04 May 2011 16:20:41 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110415 Lanikai/3.1.11pre MIME-Version: 1.0 To: Manfred Antar References: <201105040107.p4417NTR048534@pozo.com> <4DC0F46C.3020806@FreeBSD.org> <201105041344.p44DiOId032272@pozo.com> In-Reply-To: <201105041344.p44DiOId032272@pozo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: Clang error make buildworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 14:20:40 -0000 On 2011-05-04 15:44, Manfred Antar wrote: ... > src.conf: > > WITHOUT_DYNAMICROOT=yes > WITH_IDEA=yes > .if !defined(CC) || ${CC} == "cc" > CC=clang > .endif > .if !defined(CXX) || ${CXX} == "c++" > CXX=clang++ > .endif > #Don't die on warnings > NO_WERROR= > WERROR= Aha. Please move the clang-related stuff to make.conf instead, e.g. this fragment: .if !defined(CC) || ${CC} == "cc" CC=clang .endif .if !defined(CXX) || ${CXX} == "c++" CXX=clang++ .endif #Don't die on warnings NO_WERROR= WERROR= It will not work properly if you put it in src.conf. (You can really only use src.conf for WITH_FOO and WITHOUT_BAR type settings.) From owner-freebsd-current@FreeBSD.ORG Wed May 4 15:06:45 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42A951065679 for ; Wed, 4 May 2011 15:06:45 +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 1A4DD8FC15 for ; Wed, 4 May 2011 15:06:45 +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 C1D6546B43; Wed, 4 May 2011 11:06:44 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 50B8D8A02B; Wed, 4 May 2011 11:06:44 -0400 (EDT) From: John Baldwin To: Michael Butler Date: Wed, 4 May 2011 09:00:02 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <4DBF68A4.6050405@protected-networks.net> <201105030758.12792.jhb@freebsd.org> <4DC09489.6060804@protected-networks.net> In-Reply-To: <4DC09489.6060804@protected-networks.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105040900.02840.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 04 May 2011 11:06:44 -0400 (EDT) Cc: freebsd-current@freebsd.org Subject: Re: cardbus memory allocation problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 15:06:45 -0000 On Tuesday, May 03, 2011 7:49:29 pm Michael Butler wrote: > > I have WIP patches to fix this but they aren't ready yet. > > > >> pcib4: I/O decode 0x4000-0x4fff > >> pcib4: memory decode 0xf0900000-0xf09fffff > >> *** this memory widow is what I expected all children to allocate from > >> > >> pcib4: no prefetched decode > >> pcib4: Subtractively decoded bridge. > > > > It's a subtractive bridge, so the resources do not have to be allocated from > > the window. That said, I'm committing the last of my patches to HEAD today to > > rework how PCI-PCI bridges handle I/O windows to support growing windows, etc. > > and the new PCI-PCI bridge driver will attempt to grow the memory window to > > allocate a new range before falling back to depending on the subtractive > > decode. > > You might be pleased to hear that, without any "special arrangements" in > loader.conf, the new PCI-PCI code does The Right Thing with memory > allocation :-) > > Parent bridge: > > I "fixed" the subordinate bus using "setpci -s 07:06.2 4c.b=02" I believe it should work even if you don't disable subtractive decoding. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed May 4 15:34:53 2011 Return-Path: Delivered-To: Current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6A721065676 for ; Wed, 4 May 2011 15:34:53 +0000 (UTC) (envelope-from Daan@vehosting.nl) Received: from VM01.VEHosting.nl (VM016.VEHosting.nl [IPv6:2001:1af8:2100:b020::140]) by mx1.freebsd.org (Postfix) with ESMTP id 501118FC15 for ; Wed, 4 May 2011 15:34:53 +0000 (UTC) Received: from [192.168.72.11] (124-54.bbned.dsl.internl.net [92.254.54.124]) (authenticated bits=0) by VM01.VEHosting.nl (8.14.3/8.13.8) with ESMTP id p44FYsSl088707; Wed, 4 May 2011 17:34:54 +0200 (CEST) (envelope-from Daan@vehosting.nl) From: Daan Vreeken Organization: http://VEHosting.nl/ To: Current@FreeBSD.org Date: Wed, 4 May 2011 17:34:50 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201105041734.50738.Daan@vehosting.nl> x-ve-auth-version: mi-1.1.5 2011-02-07 - Copyright (c) 2008, 2011 - Daan Vreeken - VEHosting x-ve-auth: authenticated as 'pa4dan' on VM01.VEHosting.nl X-Mailman-Approved-At: Wed, 04 May 2011 15:39:33 +0000 Cc: Jack Vogel Subject: Interrupt storm with MSI in combination with em1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 15:34:53 -0000 Hi All, I've just updated a machine to -current (r221321) and since then I'm seeing an interrupt storm on irq 16. The storm goes away when I disable MSI/MSIX with the following lines in "loader.conf" : hw.pci.enable_msix="0" hw.pci.enable_msi="0" According to "dmesg" the following devices share IRQ 16 : pcib1: irq 16 at device 1.0 on pci0 em0: port 0xcc00-0xcc1f mem 0xf7de0000-0xf7dfffff,0xf7d00000-0xf7d7ffff,0xf7ddc000-0xf7ddffff irq 16 at device 0.0 on pci1 vgapci0: port 0xbc00-0xbc07 mem 0xf7800000-0xf7bfffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 ehci0: mem 0xf7cfa000-0xf7cfa3ff irq 16 at device 26.0 on pci0 em1: port 0xec00-0xec1f mem 0xf7fe0000-0xf7ffffff,0xf7f00000-0xf7f7ffff,0xf7fdc000-0xf7fdffff irq 16 at device 0.0 on pci4 pcib4: irq 16 at device 28.5 on pci0 During a storm "vmstat -i" shows a rate of about 220.000 interrupts/sec. MSI interrupt delivery to both 'em0' and 'em1' seems to work correctly during a storm, as I see their counters increase normally in the "vmstat -i" output. As only 'em0' and 'em1' seem to be using MSI interrupts, my guess is that the e1000 driver is causing this problem. Could it be that the driver forgets to clear/mask legacy interrupts when attaching the MSI interrupts perhaps? Any tips on how to debug and/or fix this? The full output of "dmesg" can be found here : http://vehosting.nl/pub_diffs/dmesg_plantje2_2011_05_04.txt And the full output of "pciconf -lv" is here : http://vehosting.nl/pub_diffs/pciconf_plantje2_2011_05_04.txt Regards, -- Daan Vreeken VEHosting http://VEHosting.nl tel: +31-(0)40-7113050 / +31-(0)6-46210825 KvK nr: 17174380 From owner-freebsd-current@FreeBSD.ORG Wed May 4 15:38:15 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B28DD106564A for ; Wed, 4 May 2011 15:38:15 +0000 (UTC) (envelope-from kraduk@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 3CB248FC12 for ; Wed, 4 May 2011 15:38:15 +0000 (UTC) Received: by wwc33 with SMTP id 33so1289165wwc.31 for ; Wed, 04 May 2011 08:38:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=C1JSTTa7GLgJDVqtSpMnWvwahNGhEz0dsQ2gSMgUlNs=; b=JBme0xcm0YqCddyPXrrOBoHdK4FC5zJfZLiuXRJmBkUCyCPfRxrHiDSb2e8uz62r8b ktLdwb5pD6j2OFw6VJB1A/4xCtySgmBqSkaSDrJhT5crzEX3NVlpAGod7BY9aX5Ske6/ wWCFphZmHKXTLJNWRUl6ZEaFKGDoQfNpUe4+A= 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=xKMVp5e3I4f1xKZNLwmJQHskhubXAe0QkdqaZwK6RyK53ufF1xKcQKU1D/yI6iwHrC EACnp3BcP2LcvV2A+P4f68o/GRPW8DzTl6gkx/W0vO9GL/H3u5ZH9DpLXzP/x4UsqGez zpCwG/l4zbufwFwkc9xsEoD6TXWzdE730KceU= MIME-Version: 1.0 Received: by 10.217.7.66 with SMTP id z44mr1223242wes.100.1304522160480; Wed, 04 May 2011 08:16:00 -0700 (PDT) Received: by 10.216.15.73 with HTTP; Wed, 4 May 2011 08:16:00 -0700 (PDT) In-Reply-To: <20110504031312.GA78390@DataIX.net> References: <201105030759.09518.jhb@freebsd.org> <201105031002.36612.jhb@freebsd.org> <20110504031312.GA78390@DataIX.net> Date: Wed, 4 May 2011 16:16:00 +0100 Message-ID: From: krad To: Jason Hellenthal X-Mailman-Approved-At: Wed, 04 May 2011 15:48:43 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: I am very confused and would appreciate some help on device renameing or on renumbering on current fstab. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 15:38:15 -0000 On 4 May 2011 04:13, Jason Hellenthal wrote: > > Edwin, > > >>> >> /dev/acd0 /cdrom cd9660 ro,noauto 0 > 0 > >>> >> /dev/acd1 /cdrom1 cd9660 ro,noauto 0 > 0 > > As a side note. These are also now useless & can be sent to /dev/null for > extra padding ;) > > Shouldn't cause no harm being there but just for reference. > > -- > > Regards, (jhell) > Jason Hellenthal > > Just a sanity check here people, but if the machine was built with freebsd 6.x i would guess it machine is a few years old. If so i doubt the hardware would support ahci, and therefore wouldn't have the ada type devices, it would have the old ad style ata ones and therefore noe fstab twiddling should be necessary. Forgive me if im missing something here. From owner-freebsd-current@FreeBSD.ORG Wed May 4 16:03:06 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 462EE1065670 for ; Wed, 4 May 2011 16:03:06 +0000 (UTC) (envelope-from fjwcash@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 F13418FC0A for ; Wed, 4 May 2011 16:03:05 +0000 (UTC) Received: by yxl31 with SMTP id 31so569523yxl.13 for ; Wed, 04 May 2011 09:03:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VAkJh/BW09PDoJ5r6aVe+mzFXWsPRw56LusGehEDfO4=; b=B0WaZl6aW+cbCvqG3h2ImuzSnPH45XwnM1tKbKWJb8bJc/g7loG7qHL3pLZG/lNJAe iAF8eBasvS79mssvKz8xf5UTAC7gdMp0kqSPgKLJXL7FuKxNda0PiH46d6jM+/GttMa8 0NtrsVkAcIh73sj7yyVXOzUNTmr9YjjxZWb4I= 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=Zmx7cRVAeDnr7AmVnOe1p037Uc6/bj5MTwl9HnyJ6QhGnHryDT/RnafF73Vfy4rnqk SItcANAvRQbr7RnAJSI3cFIR61t4YNetUgSfsneMjuMsLLZvVEmJVkFAAbdsOTjUOxke OijzGqPtkmyuuZGwEk8xEpfZKDH1w2HGeBcGI= MIME-Version: 1.0 Received: by 10.91.161.6 with SMTP id n6mr1240310ago.86.1304524985131; Wed, 04 May 2011 09:03:05 -0700 (PDT) Received: by 10.90.52.15 with HTTP; Wed, 4 May 2011 09:03:05 -0700 (PDT) In-Reply-To: References: <201105030759.09518.jhb@freebsd.org> <201105031002.36612.jhb@freebsd.org> <20110504031312.GA78390@DataIX.net> Date: Wed, 4 May 2011 09:03:05 -0700 Message-ID: From: Freddie Cash To: krad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: I am very confused and would appreciate some help on device renameing or on renumbering on current fstab. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 16:03:06 -0000 On Wed, May 4, 2011 at 8:16 AM, krad wrote: > On 4 May 2011 04:13, Jason Hellenthal wrote: >> Edwin, >> >> >>> >> =C2=A0/dev/acd0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/= cdrom =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cd9660 =C2=A0ro,noauto =C2=A0 =C2= =A0 =C2=A0 0 >> =C2=A0 =C2=A0 0 >> >>> >> =C2=A0/dev/acd1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/= cdrom1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 cd9660 =C2=A0ro,noauto =C2=A0 =C2=A0 =C2= =A0 0 >> =C2=A0 =C2=A0 0 >> >> As a side note. These are also now useless & can be sent to /dev/null fo= r >> extra padding ;) >> >> Shouldn't cause no harm being there but just for reference. >> > Just a sanity check here people, but if the machine was built with freebs= d > 6.x i would guess it machine is a few years old. If so i doubt the hardwa= re > would support ahci, and therefore wouldn't have the ada type devices, it > would have the old ad style ata ones and therefore noe fstab twiddling > should be necessary. > > Forgive me if im missing something here. If you enable "options ATA_CAM" in the kernel, which uses the old ata(4) driver via some cam(4) shims, then you also get the adaX device nodes. There's currently 4 ways to access PATA/SATA disks: - old-style ata(4) using adX device nodes - old-style ata(4) using ataahci(4) for ACHI-like access to PATA/SATA disks, I believe using adX - old-style ata(4) via ATA_CAM using adaX device nodes - new-style ahci(4)/siis(4)/another(4) using adaX device nodes I forget the name of the other AHCI-style driver. The first two options uses atacontrol to manage the disks. The last two options use camcontrol to manage the disks. I believe the plan in 9.0 is to have everything accessed via ATA_CAM/ahci(4) so all PATA/SATA drives show up the same, as adaX, with everything being managed via camcontrol, finally unifying all PATA/SATA/SCSI/SAS disk access via cam(4). --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Wed May 4 16:41:58 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98D1C1065672 for ; Wed, 4 May 2011 16:41:58 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4C8D88FC0A for ; Wed, 4 May 2011 16:41:57 +0000 (UTC) Received: by vxc34 with SMTP id 34so1821581vxc.13 for ; Wed, 04 May 2011 09:41:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hWn7lk6RhxS0jSxyUmKmrzDfdS+jwHF28SaykwQmdnM=; b=Ljf9WqwTLrD5zya/okaexXWP2m/iF7I0OtRx9jyMOvccs69xAau9ZrmfkIf35SHNzN G+vGkNbSw9ei4H0jL1DyNuPuVi3Zqzc0ZwWAMpw8F0vRUJW6tPxzz16qdT95XPX7hO42 vNfIKcKUgX0kQSGRnFmRgnZf6V2Pm6UnSB0Uc= 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=KRTS2prlU5yYte2f5nBD5yJvK3oryTl6srqYkRGXMgBcxg0xXwem6dlSZ/goXiM7Jq wiHp5zVj8How4zpAKXJJE4rMWZYRzP/YBYuz7719NIsm2SEiZFKlAfxsPm0PHcdbyJd7 XHHUaHQQvdpf6h1H+wbYv6imN9VRhG139h+ao= MIME-Version: 1.0 Received: by 10.52.176.194 with SMTP id ck2mr1606320vdc.248.1304527316861; Wed, 04 May 2011 09:41:56 -0700 (PDT) Received: by 10.220.199.130 with HTTP; Wed, 4 May 2011 09:41:56 -0700 (PDT) In-Reply-To: <20110504090718.GN48734@deviant.kiev.zoral.com.ua> References: <201105040559.p445xEJ5024585@chez.mckusick.com> <20110504090718.GN48734@deviant.kiev.zoral.com.ua> Date: Wed, 4 May 2011 09:41:56 -0700 Message-ID: From: Garrett Cooper To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kirk McKusick , FreeBSD Current Subject: Re: Nasty non-recursive lockmgr panic on softdep only enabled UFS partition when filesystem full X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 16:41:58 -0000 2011/5/4 Kostik Belousov : > On Tue, May 03, 2011 at 11:58:49PM -0700, Garrett Cooper wrote: >> On Tue, May 3, 2011 at 11:42 PM, Garrett Cooper wro= te: >> > On Tue, May 3, 2011 at 10:59 PM, Kirk McKusick = wrote: >> >>> Date: Tue, 3 May 2011 22:40:26 -0700 >> >>> Subject: Nasty non-recursive lockmgr panic on softdep only enabled U= FS >> >>> =A0partition when filesystem full >> >>> From: Garrett Cooper >> >>> To: Jeff Roberson , >> >>> =A0 =A0 =A0 =A0 Marshall Kirk McKusick >> >>> Cc: FreeBSD Current >> >>> >> >>> Hi Jeff and Dr. McKusick, >> >>> =A0 =A0 Ran into this panic when /usr ran out of space doing a make >> >>> universe on amd64/r221219 (it took ~15 minutes for the panic to occu= r >> >>> after the filesystem ran out of space -- wasn't quite sure what it w= as >> >>> doing at the time): >> >>> >> >>> ... >> >>> >> >>> =A0 =A0 Let me know what other commands you would like for me to run= in kgdb. >> >>> Thanks, >> >>> -Garrett >> >> >> >> You did not indicate whether you are running an 8.X system or a 9-cur= rent >> >> system. It would be helpful to know that. >> > >> > I've actually been running CURRENT for a few years now, but you're rig= ht -- >> > I didn't mention that part. >> > >> >> Jeff thinks that there may be a potential race in the locking code fo= r >> >> softdep_request_cleanup. If so, this patch for 9-current should fix i= t: >> >> >> >> Index: ffs_softdep.c >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> --- ffs_softdep.c =A0 =A0 =A0 (revision 221385) >> >> +++ ffs_softdep.c =A0 =A0 =A0 (working copy) >> >> @@ -11380,7 +11380,8 @@ >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0contin= ue; >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MNT_IUNLOCK(mp); >> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (vget(lvp, LK_EXCLUS= IVE | LK_INTERLOCK, curthread)) { >> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (vget(lvp, LK_EXCLUS= IVE | LK_NOWAIT | LK_INTERLOCK, >> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 curthread)) { >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MNT_IL= OCK(mp); >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0contin= ue; >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >> >> >> >> If you are running an 8.X system, hopefully you will be able to apply= it. >> > >> > =A0 =A0I've applied it, rebuilt and installed the kernel, and trying t= o >> > repro the case again. Will let you know how things go! >> >> =A0 =A0 Happened again with the change. It's really easy to repro: >> >> 1. Get a filesystem with UFS+SU >> 2. Execute something that does a large number of small writes to a parti= tion. >> 3. 'dd if=3D/dev/zero of=3DFOO bs=3D10m' on the same partition >> >> =A0 =A0 The kernel will panic with the issue I discussed above. >> Thanks! > > Jeff' change is required to avoid LORs, but it is not sufficient to > prevent recursion. We must skip the vnode supplied as a parameter to > softdep_request_cleanup(). Theoretically, other vnodes might be also > locked by curthread, thus I think the change below is needed. Try this. > > diff --git a/sys/ufs/ffs/ffs_softdep.c b/sys/ufs/ffs/ffs_softdep.c > index a6d4441..25fa5d6 100644 > --- a/sys/ufs/ffs/ffs_softdep.c > +++ b/sys/ufs/ffs/ffs_softdep.c > @@ -11380,7 +11380,9 @@ retry: > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0continue; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MNT_IUNLOCK(mp); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (vget(lvp, LK_EXCLUSIVE = | LK_INTERLOCK, curthread)) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (VOP_ISLOCKED(lvp) || > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 vget(lvp, LK_EXCLUS= IVE | LK_INTERLOCK | LK_NOWAIT, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 curthread)) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MNT_ILOCK(= mp); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0continue; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} Ok. I'll let the make universe I have going run to completion, and once I get back home later on, I'll take a look at repro'ing this again with the above patch applied. Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Wed May 4 17:17:45 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B25891065670 for ; Wed, 4 May 2011 17:17:45 +0000 (UTC) (envelope-from lacombar@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 74DC78FC15 for ; Wed, 4 May 2011 17:17:45 +0000 (UTC) Received: by iwn33 with SMTP id 33so1569414iwn.13 for ; Wed, 04 May 2011 10:17:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=w3bI0m8crSsSxi34V5nCX/cmzIcg4gAhG8yRyQ8saYM=; b=gAHV7lSNHcGrWTPzQ39g74Q1BlUwXLh10jbB1JdI3pHxC3nni3MmHM9tdlkV0c24te r6SHGoOc0XTzHVIC49sCDgesnvqiGfxVFKzvWI1039ogMkna8iL05oBNHosxaIqDKP5b eNcC2vGk/nh+VtmT0y46Y1Yn/5Y/AYwKiPRLc= 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=DWsaV8PhTaJYhbkr4/gXyqwMUsbVsmLaSW6ajcc+BrF6/yb1qJzllpn6eUqG13QUbZ L4jmg9G5WcHACXmQur56FQRLOD2ncEhGUlU1G1UtdMW5AMrUeWjWqRT4ahBp1ka8gc7J 50e1i628qFaaSzfKh3Pt5P3rvkWaLcandaoDk= MIME-Version: 1.0 Received: by 10.42.139.5 with SMTP id e5mr2131707icu.136.1304529464756; Wed, 04 May 2011 10:17:44 -0700 (PDT) Received: by 10.42.167.5 with HTTP; Wed, 4 May 2011 10:17:44 -0700 (PDT) In-Reply-To: References: <4D94A354.9080903@sentex.net> <4DC07013.9070707@gmx.net> <4DC078BD.9080908@gmx.net> Date: Wed, 4 May 2011 13:17:44 -0400 Message-ID: From: Arnaud Lacombe To: Olivier Smedts Content-Type: text/plain; charset=ISO-8859-1 Cc: Mike Tancsa , Jack Vogel , Michael Schmiedgen , FreeBSD current mailing list Subject: Re: problems with em(4) since update to driver 7.2.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 17:17:45 -0000 Hi, On Wed, May 4, 2011 at 3:58 AM, Olivier Smedts wrote: > em0: Using an MSI interrupt > em0: Ethernet address: d4:85:64:b2:aa:f5 > em0: Could not setup receive structures > em0: Could not setup receive structures > > What can we do to help you debug this ? > At some point in time, in late February, I had the same issue on a 6-interface machine. I tracked this down to the fact that the main loop in em_setup_receive_ring() was not being entered. This resulted in junk being returned as `error' is not explicitly initialized. At the time, the following patch worked for me. Without it the driver was unable to initialize with RX/TX ring's size of 512. With it, ring's size of 1024 initialized fine. diff --git a/sys/dev/e1000/if_em.c b/sys/dev/e1000/if_em.c index fb6ed67..f02059a 100644 --- a/sys/dev/e1000/if_em.c +++ b/sys/dev/e1000/if_em.c @@ -3901,7 +3901,7 @@ em_setup_receive_ring(struct rx_ring *rxr) struct adapter *adapter = rxr->adapter; struct em_buffer *rxbuf; bus_dma_segment_t seg[1]; - int i, j, nsegs, error; + int i, j, nsegs, error = 0; I did not dig much more at the time, but I was definitively seeing an odd behavior. Anyhow, I am no longer able to reproduce this with 7.2.3, so cannot dig in more details. Btw, I wish you all luck, it took me nearly two full months to convince Jack (and other FreeBSD devs) that there was a bug in the mbuf refresh code. - Arnaud From owner-freebsd-current@FreeBSD.ORG Wed May 4 17:20:48 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 474E3106566C for ; Wed, 4 May 2011 17:20:48 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 06A198FC14 for ; Wed, 4 May 2011 17:20:47 +0000 (UTC) Received: by iyj12 with SMTP id 12so1590813iyj.13 for ; Wed, 04 May 2011 10:20:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nFHs5Ij7iX/i6K+qPOqGIq2VRCFU0ufkuWGq9oKtKYs=; b=sR1jLKyLD55QikuPu1EMNAroYqcmYsAvABYGWLvAhXV++/w7OaxEdLBFezl2uBU+Gm 1+ZYGj9+BpFUsbYI4tG0PUMuapfwf8Pw4ozOZW8wp30amiVLRRVGvf/goJlYjqyzTII9 dr8BxAx12ANZ7CS+I0hXKRQ4heWNtdDklt1eo= 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=vYvV4wFhSB/2oZ9/CTzlLTu6mdTz4j+oQKV6WCYKN/6TagYGAdfID6Hj5NLzjLupsW DP+cHKZV4D6A7eaabt1QVrl21VPeMvOCF5OOERpxZxMAnoVnxfJpxaoEPWlSS12ubLnl Fq5ihbGx+6VSaN785WCQr405c0i60/00mYuQQ= MIME-Version: 1.0 Received: by 10.42.230.1 with SMTP id jk1mr151659icb.337.1304529647166; Wed, 04 May 2011 10:20:47 -0700 (PDT) Received: by 10.42.167.5 with HTTP; Wed, 4 May 2011 10:20:47 -0700 (PDT) In-Reply-To: References: <4D94A354.9080903@sentex.net> <4DC07013.9070707@gmx.net> <4DC078BD.9080908@gmx.net> Date: Wed, 4 May 2011 13:20:47 -0400 Message-ID: From: Arnaud Lacombe To: Olivier Smedts Content-Type: text/plain; charset=ISO-8859-1 Cc: Mike Tancsa , Jack Vogel , Michael Schmiedgen , FreeBSD current mailing list Subject: Re: problems with em(4) since update to driver 7.2.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 17:20:48 -0000 Hi, On Tue, May 3, 2011 at 7:25 PM, Olivier Smedts wrote: > 2011/5/4 Arnaud Lacombe : >> A more rude version might be "Why the frak my network adapter stopped >> working with the default setting ?" :) > > ...on a -STABLE branch > Maybe you should not have picked the rude version, Jack has a relatively low cut-off frequency :-) - Arnaud From owner-freebsd-current@FreeBSD.ORG Wed May 4 17:24:02 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F3C8106566B for ; Wed, 4 May 2011 17:24:02 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2B5FE8FC08 for ; Wed, 4 May 2011 17:24:01 +0000 (UTC) Received: by vxc34 with SMTP id 34so1868828vxc.13 for ; Wed, 04 May 2011 10:24:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1m1PnwTGHmMohQM8wMxqgPDs6jF1WCIDV7h2mJh3+fg=; b=VgmySraQA6UwxX9nFHrhWpUhtiwuMe2bk8XFen3zkJcgKgjF3bvZpblIdcZGlDU7Mj zkcwRgVuNtz/EFd7DSR3yeqqIp6hy9Ws3sEGNrsMyeuSan8Il88jcibOUf4Ej4ZDAt7J wmJmnLGHLkhYKPx6/uC+qQvTD1TUdSf3OG8p0= 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=SVbA3FMJhAsBYRwonVxRyv5ctOt5Vmro+ZscwSjPRklQhO2GQ84X2K6JwfB/ccNEaL X4xfiPEVneumUR5SQ7aEMuXjd/BqDlu0uPC5vMLaucND6mlhLNldWic1Wl7TH4CZ2PFH t086hJ0jdUkzu849qOzhsqRTNxXe5hJNx0l6I= MIME-Version: 1.0 Received: by 10.52.98.227 with SMTP id el3mr1737439vdb.244.1304529840662; Wed, 04 May 2011 10:24:00 -0700 (PDT) Received: by 10.52.184.169 with HTTP; Wed, 4 May 2011 10:24:00 -0700 (PDT) In-Reply-To: References: <4D94A354.9080903@sentex.net> <4DC07013.9070707@gmx.net> <4DC078BD.9080908@gmx.net> Date: Wed, 4 May 2011 10:24:00 -0700 Message-ID: From: Jack Vogel To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Olivier Smedts , FreeBSD current mailing list , Michael Schmiedgen , Mike Tancsa Subject: Re: problems with em(4) since update to driver 7.2.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 17:24:02 -0000 No, I do not Arnaud. But I refuse to rise to rude and uncivil behavior. Its your behavior again and again which causes you to not get responses, not my willingness to help and respond to those that behave like respectful customers and adults. Jack On Wed, May 4, 2011 at 10:20 AM, Arnaud Lacombe wrote: > Hi, > > On Tue, May 3, 2011 at 7:25 PM, Olivier Smedts wrote: > > 2011/5/4 Arnaud Lacombe : > >> A more rude version might be "Why the frak my network adapter stopped > >> working with the default setting ?" :) > > > > ...on a -STABLE branch > > > Maybe you should not have picked the rude version, Jack has a > relatively low cut-off frequency :-) > > - Arnaud > From owner-freebsd-current@FreeBSD.ORG Wed May 4 17:27:38 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B083106566B for ; Wed, 4 May 2011 17:27:38 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id EDA5D8FC1D for ; Wed, 4 May 2011 17:27:37 +0000 (UTC) Received: by iyj12 with SMTP id 12so1598494iyj.13 for ; Wed, 04 May 2011 10:27:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lTilNEpEGtcARsLVKUGnBQOeMQ51cSYmrU+NoIDGcKs=; b=YRcAEY8uCb46bDyWJOIUqQXiL+NH2yrGfVKNILn/OFbrwOjAc6KQYvAHcJO3IoZ8ul 5gt9t1dbg3UUal2YqDHfq0kjgbV8y5X8MDocsDkb52WP/8tdzf2o01LKfG5mTUqv4kCx zrbZIiMHv0q1OUbb5aUfghwucFc+RzQ7C90m8= 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=jIak2S+vh8Uw8CKqhecgqlNExcYcyWZEvh4U9RyPNJ5nMHLj6iDL4IRL1LBp6Ipbjp XHVlfkciHcpsDMS734nAqXDJqoLV4geOjdK5TlwiIZL3pNHjZP8AaxP+PrHUlIZP2pQw /9ytqDfAvHGVkEjtgpLgEuLLu3PUZQoOEycpk= MIME-Version: 1.0 Received: by 10.42.150.8 with SMTP id y8mr291417icv.471.1304530056691; Wed, 04 May 2011 10:27:36 -0700 (PDT) Received: by 10.42.167.5 with HTTP; Wed, 4 May 2011 10:27:36 -0700 (PDT) In-Reply-To: References: <4D94A354.9080903@sentex.net> <4DC07013.9070707@gmx.net> <4DC078BD.9080908@gmx.net> Date: Wed, 4 May 2011 13:27:36 -0400 Message-ID: From: Arnaud Lacombe To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Olivier Smedts , FreeBSD current mailing list , Michael Schmiedgen , Mike Tancsa Subject: Re: problems with em(4) since update to driver 7.2.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 17:27:38 -0000 Hi, On Wed, May 4, 2011 at 1:24 PM, Jack Vogel wrote: > No, I do not Arnaud. But I refuse to rise to rude and uncivil behavior.= =A0 Its > your > behavior again and again which causes you to not get responses, not my > willingness to help and respond to those that behave like respectful > customers > and adults. > Obviously, I am no longer the only one finding that em(4) has unacceptable issue, this thread is the proof. - Arrnaud > Jack > > > On Wed, May 4, 2011 at 10:20 AM, Arnaud Lacombe wrot= e: >> >> Hi, >> >> On Tue, May 3, 2011 at 7:25 PM, Olivier Smedts wrote: >> > 2011/5/4 Arnaud Lacombe : >> >> A more rude version might be "Why the frak my network adapter stopped >> >> working with the default setting ?" :) >> > >> > ...on a -STABLE branch >> > >> Maybe you should not have picked the rude version, Jack has a >> relatively low cut-off frequency :-) >> >> =A0- Arnaud > > From owner-freebsd-current@FreeBSD.ORG Wed May 4 17:46:06 2011 Return-Path: Delivered-To: Current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B225D106566B for ; Wed, 4 May 2011 17:46:06 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 69BEE8FC13 for ; Wed, 4 May 2011 17:46:06 +0000 (UTC) Received: by vxc34 with SMTP id 34so1893414vxc.13 for ; Wed, 04 May 2011 10:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cLCTX8Tj91gACJFk2lNl8f03nv40GoG2CJ8hndKyv1E=; b=XRc021LP9Ya7SqpkaQtnF1Fjjr51uJyACJdqP6ig+AzOOu/y52o5g807T510umNwYl lRu2sE30FfNX1OH+8/ivTcZ47xJQF1GGsVJFFiXWZp9Z1b5B1ltBYdR8tkbgpLCD2R5Z homjnHRa0OdIFj9pSfIR7iz9uI6adcHwaYr9U= 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=pq9JyVrV9BwgxaEUVo3SJwuSfVNWD8jr4uQ38EMlLNRfnnRelQd9D6ORSsNxG3peEj /InEE7b//lzR1T6Iy8DC1ucIUGG2NdUdCiDKxY3KcQbz24Z5tNBtGmPTckJd8h4mHSuq ZlfhBdVtbU/R143pgq/45kgOOGWWRQaCLWb5o= MIME-Version: 1.0 Received: by 10.52.76.102 with SMTP id j6mr1800520vdw.44.1304531165587; Wed, 04 May 2011 10:46:05 -0700 (PDT) Received: by 10.52.184.169 with HTTP; Wed, 4 May 2011 10:46:05 -0700 (PDT) In-Reply-To: <201105041734.50738.Daan@vehosting.nl> References: <201105041734.50738.Daan@vehosting.nl> Date: Wed, 4 May 2011 10:46:05 -0700 Message-ID: From: Jack Vogel To: Daan Vreeken Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Current@freebsd.org Subject: Re: Interrupt storm with MSI in combination with em1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 17:46:06 -0000 Who makes your motherboard? The problem you are having is that MSIX AND MSI are both failing as em0 comes up, so it falls back to Legacy interrupt mode, and must be having some issue with sharing the line, causing the storm. This is the second report in a matter of a week perhaps about a problematic motherboard, I would like to know who makes them. Thanks, Jack On Wed, May 4, 2011 at 8:34 AM, Daan Vreeken wrote: > Hi All, > > I've just updated a machine to -current (r221321) and since then I'm seeing > an > interrupt storm on irq 16. The storm goes away when I disable MSI/MSIX with > the following lines in "loader.conf" : > > hw.pci.enable_msix="0" > hw.pci.enable_msi="0" > > According to "dmesg" the following devices share IRQ 16 : > > pcib1: irq 16 at device 1.0 on pci0 > em0: port 0xcc00-0xcc1f > mem > 0xf7de0000-0xf7dfffff,0xf7d00000-0xf7d7ffff,0xf7ddc000-0xf7ddffff > irq 16 at device 0.0 on pci1 > vgapci0: port 0xbc00-0xbc07 > mem 0xf7800000-0xf7bfffff,0xe0000000-0xefffffff irq 16 at device > 2.0 on > pci0 > ehci0: mem > 0xf7cfa000-0xf7cfa3ff > irq 16 at device 26.0 on pci0 > em1: port 0xec00-0xec1f > mem > 0xf7fe0000-0xf7ffffff,0xf7f00000-0xf7f7ffff,0xf7fdc000-0xf7fdffff > irq 16 at device 0.0 on pci4 > pcib4: irq 16 at device 28.5 on pci0 > > During a storm "vmstat -i" shows a rate of about 220.000 interrupts/sec. > MSI > interrupt delivery to both 'em0' and 'em1' seems to work correctly during a > storm, as I see their counters increase normally in the "vmstat -i" output. > > As only 'em0' and 'em1' seem to be using MSI interrupts, my guess is that > the > e1000 driver is causing this problem. Could it be that the driver forgets > to > clear/mask legacy interrupts when attaching the MSI interrupts perhaps? > > Any tips on how to debug and/or fix this? > > > The full output of "dmesg" can be found here : > http://vehosting.nl/pub_diffs/dmesg_plantje2_2011_05_04.txt > > And the full output of "pciconf -lv" is here : > http://vehosting.nl/pub_diffs/pciconf_plantje2_2011_05_04.txt > > > Regards, > -- > Daan Vreeken > VEHosting > http://VEHosting.nl > tel: +31-(0)40-7113050 / +31-(0)6-46210825 > KvK nr: 17174380 > From owner-freebsd-current@FreeBSD.ORG Wed May 4 18:19:25 2011 Return-Path: Delivered-To: Current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C313A106564A for ; Wed, 4 May 2011 18:19:25 +0000 (UTC) (envelope-from Daan@vehosting.nl) Received: from VM01.VEHosting.nl (VM016.VEHosting.nl [IPv6:2001:1af8:2100:b020::140]) by mx1.freebsd.org (Postfix) with ESMTP id 58FD98FC0A for ; Wed, 4 May 2011 18:19:25 +0000 (UTC) Received: from [192.168.45.11] (180-161.ftth.onsbrabantnet.nl [88.159.161.180]) (authenticated bits=0) by VM01.VEHosting.nl (8.14.3/8.13.8) with ESMTP id p44IJRp4090330; Wed, 4 May 2011 20:19:27 +0200 (CEST) (envelope-from Daan@vehosting.nl) From: Daan Vreeken Organization: http://VEHosting.nl/ To: Jack Vogel Date: Wed, 4 May 2011 20:19:23 +0200 User-Agent: KMail/1.9.10 References: <201105041734.50738.Daan@vehosting.nl> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201105042019.23899.Daan@vehosting.nl> x-ve-auth-version: mi-1.1.5 2011-02-07 - Copyright (c) 2008, 2011 - Daan Vreeken - VEHosting x-ve-auth: authenticated as 'pa4dan' on VM01.VEHosting.nl Cc: Current@freebsd.org Subject: Re: Interrupt storm with MSI in combination with em1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 18:19:25 -0000 Hi Jack, Wednesday 04 May 2011 19:46:05 Jack Vogel wrote: > Who makes your motherboard? The problem you are having is that MSIX AND > MSI are both failing as em0 comes up, so it falls back to Legacy interrupt > mode, > and must be having some issue with sharing the line, causing the storm. The motherboard is an Asus "P7H55-M". Sorry, I should have mentioned that the dmesg output is from booting with : > > hw.pci.enable_msix="0" > > hw.pci.enable_msi="0" .. in "loader.conf". With those lines in "loader.conf", MSI and MSIX is disabled, both cards work like they should and there is no interrupt storm. With MSI/MSIX enabled, both cards work like they should and I see the counters of the MSI interrupts increase (in small amounts, like they should), but at boot-time an interrupt storm starts on 'legacy' IRQ 16. Because the only difference between disabling/enabling MSI/MSIX seems to be in the way em0/em1 are used, and because 'em1' shares IRQ 16 according to the dmesg, I'm suspecting 'em1' is causing the storm. (But please correct me if I'm wrong :) What can I do to help track this problem down? > > > > According to "dmesg" the following devices share IRQ 16 : > > > > pcib1: irq 16 at device 1.0 on pci0 > > em0: port > > 0xcc00-0xcc1f mem > > 0xf7de0000-0xf7dfffff,0xf7d00000-0xf7d7ffff,0xf7ddc000-0xf7ddffff > > irq 16 at device 0.0 on pci1 > > vgapci0: port 0xbc00-0xbc07 > > mem 0xf7800000-0xf7bfffff,0xe0000000-0xefffffff irq 16 at > > device 2.0 on > > pci0 > > ehci0: mem > > 0xf7cfa000-0xf7cfa3ff > > irq 16 at device 26.0 on pci0 > > em1: port > > 0xec00-0xec1f mem > > 0xf7fe0000-0xf7ffffff,0xf7f00000-0xf7f7ffff,0xf7fdc000-0xf7fdffff > > irq 16 at device 0.0 on pci4 > > pcib4: irq 16 at device 28.5 on pci0 > > > > During a storm "vmstat -i" shows a rate of about 220.000 interrupts/sec. > > MSI > > interrupt delivery to both 'em0' and 'em1' seems to work correctly during > > a storm, as I see their counters increase normally in the "vmstat -i" > > output. > > > > As only 'em0' and 'em1' seem to be using MSI interrupts, my guess is that > > the > > e1000 driver is causing this problem. Could it be that the driver forgets > > to > > clear/mask legacy interrupts when attaching the MSI interrupts perhaps? > > > > Any tips on how to debug and/or fix this? > > > > > > The full output of "dmesg" can be found here : > > http://vehosting.nl/pub_diffs/dmesg_plantje2_2011_05_04.txt > > > > And the full output of "pciconf -lv" is here : > > http://vehosting.nl/pub_diffs/pciconf_plantje2_2011_05_04.txt > > Regards, -- Daan Vreeken VEHosting http://VEHosting.nl tel: +31-(0)40-7113050 / +31-(0)6-46210825 KvK nr: 17174380 From owner-freebsd-current@FreeBSD.ORG Wed May 4 18:47:34 2011 Return-Path: Delivered-To: Current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AA95106566C for ; Wed, 4 May 2011 18:47:34 +0000 (UTC) (envelope-from jfvogel@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 3E0EF8FC0A for ; Wed, 4 May 2011 18:47:33 +0000 (UTC) Received: by qwc9 with SMTP id 9so1217692qwc.13 for ; Wed, 04 May 2011 11:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/t8+u4lhgY5DJH8WAQ78IQnw3EacvW0o+bvnYALLqyE=; b=nemjJ8nFn2a2FzPT5PuGZJdsGjarKlXenUfImuK6zxI7Z5AioBXGBkrmb5Q0AxU4ZO nPNIpA1r9nAa2qkZNpTofAH0jbrZEqNCFPQMUhZrMsUPGxhyUkNloUH+SKsu38PK3Nq6 OXovG/0NmnQeeSzwwUqWoJuxTy2CmzFNt4CJ4= 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=J5BGDLCaios337/7TI2e9BO/zZbzLOJCBUuk6XyPgzPhkwowllY9m++SosEWULMJFL PcxRPQJnJxtu8NdKjLrDx/HLyE5rHn93AUSinw9dFGBpVNhOTIamP9YA+gNeLfNqxU2e GV3IW41gR3HbERGCRTr28pt21mkFu/7p4i/CE= MIME-Version: 1.0 Received: by 10.52.76.193 with SMTP id m1mr1845165vdw.204.1304534852692; Wed, 04 May 2011 11:47:32 -0700 (PDT) Received: by 10.52.184.169 with HTTP; Wed, 4 May 2011 11:47:32 -0700 (PDT) In-Reply-To: <201105042019.23899.Daan@vehosting.nl> References: <201105041734.50738.Daan@vehosting.nl> <201105042019.23899.Daan@vehosting.nl> Date: Wed, 4 May 2011 11:47:32 -0700 Message-ID: From: Jack Vogel To: Daan Vreeken Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Current@freebsd.org Subject: Re: Interrupt storm with MSI in combination with em1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 18:47:34 -0000 Will you please set it back to a default and then boot and capture the message for me? Thank you, Jack On Wed, May 4, 2011 at 11:19 AM, Daan Vreeken wrote: > Hi Jack, > > Wednesday 04 May 2011 19:46:05 Jack Vogel wrote: > > Who makes your motherboard? The problem you are having is that MSIX AND > > MSI are both failing as em0 comes up, so it falls back to Legacy > interrupt > > mode, > > and must be having some issue with sharing the line, causing the storm. > > The motherboard is an Asus "P7H55-M". > Sorry, I should have mentioned that the dmesg output is from booting with : > > > > hw.pci.enable_msix="0" > > > hw.pci.enable_msi="0" > > .. in "loader.conf". > > With those lines in "loader.conf", MSI and MSIX is disabled, both cards > work > like they should and there is no interrupt storm. > > With MSI/MSIX enabled, both cards work like they should and I see the > counters > of the MSI interrupts increase (in small amounts, like they should), but at > boot-time an interrupt storm starts on 'legacy' IRQ 16. > > Because the only difference between disabling/enabling MSI/MSIX seems to be > in > the way em0/em1 are used, and because 'em1' shares IRQ 16 according to the > dmesg, I'm suspecting 'em1' is causing the storm. > (But please correct me if I'm wrong :) > > What can I do to help track this problem down? > > > > > > > According to "dmesg" the following devices share IRQ 16 : > > > > > > pcib1: irq 16 at device 1.0 on pci0 > > > em0: port > > > 0xcc00-0xcc1f mem > > > 0xf7de0000-0xf7dfffff,0xf7d00000-0xf7d7ffff,0xf7ddc000-0xf7ddffff > > > irq 16 at device 0.0 on pci1 > > > vgapci0: port 0xbc00-0xbc07 > > > mem 0xf7800000-0xf7bfffff,0xe0000000-0xefffffff irq 16 at > > > device 2.0 on > > > pci0 > > > ehci0: mem > > > 0xf7cfa000-0xf7cfa3ff > > > irq 16 at device 26.0 on pci0 > > > em1: port > > > 0xec00-0xec1f mem > > > 0xf7fe0000-0xf7ffffff,0xf7f00000-0xf7f7ffff,0xf7fdc000-0xf7fdffff > > > irq 16 at device 0.0 on pci4 > > > pcib4: irq 16 at device 28.5 on pci0 > > > > > > During a storm "vmstat -i" shows a rate of about 220.000 > interrupts/sec. > > > MSI > > > interrupt delivery to both 'em0' and 'em1' seems to work correctly > during > > > a storm, as I see their counters increase normally in the "vmstat -i" > > > output. > > > > > > As only 'em0' and 'em1' seem to be using MSI interrupts, my guess is > that > > > the > > > e1000 driver is causing this problem. Could it be that the driver > forgets > > > to > > > clear/mask legacy interrupts when attaching the MSI interrupts perhaps? > > > > > > Any tips on how to debug and/or fix this? > > > > > > > > > The full output of "dmesg" can be found here : > > > http://vehosting.nl/pub_diffs/dmesg_plantje2_2011_05_04.txt > > > > > > And the full output of "pciconf -lv" is here : > > > http://vehosting.nl/pub_diffs/pciconf_plantje2_2011_05_04.txt > > > > > > Regards, > -- > Daan Vreeken > VEHosting > http://VEHosting.nl > tel: +31-(0)40-7113050 / +31-(0)6-46210825 > KvK nr: 17174380 > From owner-freebsd-current@FreeBSD.ORG Wed May 4 19:22:11 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C3D7106564A for ; Wed, 4 May 2011 19:22:11 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.212.176]) by mx1.freebsd.org (Postfix) with ESMTP id 70DF58FC1C for ; Wed, 4 May 2011 19:22:11 +0000 (UTC) Received: by pxi11 with SMTP id 11so1066855pxi.7 for ; Wed, 04 May 2011 12:22:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.35.228 with SMTP id l4mr2048867pbj.5.1304536930871; Wed, 04 May 2011 12:22:10 -0700 (PDT) Received: by 10.68.40.4 with HTTP; Wed, 4 May 2011 12:22:10 -0700 (PDT) In-Reply-To: References: <4D94A354.9080903@sentex.net> <4DC07013.9070707@gmx.net> <4DC078BD.9080908@gmx.net> Date: Wed, 4 May 2011 21:22:10 +0200 Message-ID: From: Olivier Smedts To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Mike Tancsa , Jack Vogel , Michael Schmiedgen , FreeBSD current mailing list Subject: Re: problems with em(4) since update to driver 7.2.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 19:22:11 -0000 2011/5/4 Arnaud Lacombe : > Obviously, I am no longer the only one finding that em(4) has > unacceptable issue, this thread is the proof. Right, and Jack seems to be willing to help, he asked something (I'll reply tomorrow when I'll be in front of the hardware) and is trying to find the same hardware. Now please not get out of the thread, everybody back to work :) --=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-current@FreeBSD.ORG Wed May 4 21:06:04 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83B1B106564A for ; Wed, 4 May 2011 21:06:04 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 3DFC48FC15 for ; Wed, 4 May 2011 21:06:03 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAG++wU2DaFvO/2dsb2JhbACEUKJFiHKtBpEwgSqDXIEBBI81jlY X-IronPort-AV: E=Sophos;i="4.64,316,1301889600"; d="scan'208";a="119634539" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 04 May 2011 17:06:03 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 39FFFB3F24; Wed, 4 May 2011 17:06:03 -0400 (EDT) Date: Wed, 4 May 2011 17:06:03 -0400 (EDT) From: Rick Macklem To: Peter Jeremy Message-ID: <341885942.1025101.1304543163223.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110504082202.GA64659@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: freebsd-current@freebsd.org Subject: Re: newnfs NFS client testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 21:06:04 -0000 > On 2011-Apr-25 20:33:14 -0400, Rick Macklem > wrote: > >I believe that the new/experimental NFS client in head is now > >compatible with the old/regular NFS client. > > Possibly even too compatible... > > Both the old and new NFS clients assume a 1:1 mapping between NFS > error codes (NFSERR_* macros defined in ) and the E* > macros in : In the old client, the NFS status is copied > from the RPC response by nfsclient/nfs_krpc.c:nfs_request(), returned > and passed back up the call chain. In the new client, the status is > copied from the RPC response into struct nfsrv_descript.nd_repstat > by fs/nfs/nfs_commonkrpc.c:newnfs_request() and then moved into an > error return in fs/nfsclient/nfs_clrpcops.c:nfsrpc_*(). > > This is not currently a problem but it would seem useful to include > notes in and warning of this assumption > in case of future changes. > > Note that both NFS servers do include code for error code mapping. > I guess that a comment might be in order. I know that the NFS ones will never change, since they're wired into the RFCs. I doubt anyone has an urge to renumber errno.h (the ones up to about 70), but a comment w.r.t. that in nfsproto.h could be useful. Thanks for the good suggestion, rick From owner-freebsd-current@FreeBSD.ORG Wed May 4 21:38:26 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BE25106564A for ; Wed, 4 May 2011 21:38:26 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4723D8FC0C for ; Wed, 4 May 2011 21:38:25 +0000 (UTC) Received: by vxc34 with SMTP id 34so2163946vxc.13 for ; Wed, 04 May 2011 14:38:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kEsQMSNgYT9hOjfmH7GVyuD9+ss/fLV7/1hA8bBZh0A=; b=uykDipF/nd1XJPa4DJh01zvLPw856rKft4OD+JijJNhl7NsM+QQF0nUz7BYhU2C+p6 cuJGmxdsTfr0TAXkDZ8aqoHhmXboUlHaovWuOXQxBtxI1d0kEd7GvrnNiwjUZS8Jvsfg qOO0Mm1ByUREXwUfc60n6QwOWlFueup9wiwaI= 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=QCtLiEXMdHHCjtjCXnp0dL0y+cd85w4QD/WTn1MYNB//A4BL4kg6MqACBjk3CVUD8e QiQwRVEmjfgC8H2QgIRdJ+2tqSTJr6zTtk9IGFDFFQf6mHajOxpafL7urVzmaAsxPokA //DgCteNHnitRUEG4C3AxxsMe64/98XJG2Vn0= MIME-Version: 1.0 Received: by 10.52.18.14 with SMTP id s14mr2068229vdd.164.1304545105417; Wed, 04 May 2011 14:38:25 -0700 (PDT) Received: by 10.52.184.169 with HTTP; Wed, 4 May 2011 14:38:25 -0700 (PDT) In-Reply-To: References: <4D94A354.9080903@sentex.net> <4DC07013.9070707@gmx.net> <4DC078BD.9080908@gmx.net> Date: Wed, 4 May 2011 14:38:25 -0700 Message-ID: From: Jack Vogel To: Olivier Smedts Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD current mailing list Subject: Re: problems with em(4) since update to driver 7.2.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 21:38:26 -0000 I have had my validation engineer busy all day, we have tried both a 9 kernel as well as 8.2, using the code from HEAD, and we cannot reproduce this problem. The data your netstat -m shows suggests to me that what's happening is somehow setup of the receive ring is running more than once maybe?? You asked at one point how this could go into STABLE, well, because not only here at Intel, but at lots of external customers this code has been used and tested thoroughly. I am not calling into question your problem, but until I understand what it is I cannot "fix" it :) The thing I am guessing right now is the culprit is the setup code, the reason is that when I ported to the igb driver I found that it did not work on our newer hardware, and so I went back to the older version of setup for igb. Now, even though I have not seen hardware fail with em, maybe there is some. To help me give me a complete pciconf -lv, and if its a namebrand system tell me that, including all hardware in it. If you like Olivier I can make a version of em for you that also reverts the setup code the way I did for igb, see if that fixes it for you? Thanks for your patience, Jack From owner-freebsd-current@FreeBSD.ORG Wed May 4 21:49:44 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E64D8106564A for ; Wed, 4 May 2011 21:49:43 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9D7B08FC13 for ; Wed, 4 May 2011 21:49:43 +0000 (UTC) Received: by iyj12 with SMTP id 12so1869257iyj.13 for ; Wed, 04 May 2011 14:49:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LlAGSYQOuhMIDPr+LMbFjB96H8fdB+gGdCyCtnqS5LM=; b=m4N27eJfLYkfDEqfRkglRF3U07Q4gnpPQLW/h1DGiNqX86VsOU2TJ3YLEEGA/YxPry wYZ2Sltrdh4MZKyBQhfO5BxCnbnUMMOwRiYaajqVgZcjGdBLLFW1zB7axqSwee1/rhhZ jEE4rf9yn/feTJ4z1MDCcp3djsz/aReOG/sQU= 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=oDRNtk3G5ClHnDFhaHF3lJt5NR0KBgVVodtPFnMIoE9RJF+cK0xoAfg6R6cSLij0gp CAqmPjl1d6eHVtSe7k+uXzZ+qeOQk7fC0RT8sEIxqcaDvaJq0VposLDWQnWX1CQyGOus ZMnGqfJiWj/ygjj864wjv5v2jguUcoFnf2fg8= MIME-Version: 1.0 Received: by 10.42.246.133 with SMTP id ly5mr2159636icb.404.1304545783100; Wed, 04 May 2011 14:49:43 -0700 (PDT) Received: by 10.42.167.5 with HTTP; Wed, 4 May 2011 14:49:43 -0700 (PDT) In-Reply-To: References: <4D94A354.9080903@sentex.net> <4DC07013.9070707@gmx.net> <4DC078BD.9080908@gmx.net> Date: Wed, 4 May 2011 17:49:43 -0400 Message-ID: From: Arnaud Lacombe To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Olivier Smedts , FreeBSD current mailing list Subject: Re: problems with em(4) since update to driver 7.2.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 21:49:44 -0000 Hi, On Wed, May 4, 2011 at 5:38 PM, Jack Vogel wrote: > I have had my validation engineer busy all day, we have tried both > a 9 kernel as well as 8.2, =A0using the code from HEAD, and we > cannot reproduce this problem. > > The data your netstat -m shows suggests to me that what's happening > is somehow setup of the receive ring is running more than once maybe?? > That would be consistent with what I reported back in February. I'll try to see if I can have a look at that on our platform tonight. - Arnaud > You asked at one point how this could go into STABLE, well, because > not only here at Intel, but at lots of external customers this code has b= een > used and tested thoroughly. > > I am not calling into question your problem, but until I understand what = it > is I cannot "fix" it :) > > The thing I am guessing right now is the culprit is the setup code, the > reason > is that when I ported to the igb driver I found that it did not work on o= ur > newer > hardware, and so I went back to the older version of setup for igb. Now, > even > though I have not seen hardware fail with em, maybe there is some. > > To help me give me a complete pciconf -lv, and if its a namebrand system > tell me that, including all hardware in it. > > If you like Olivier I can make a version of em for you that also reverts = the > setup code the way I did for igb, see if that fixes it for you? > > Thanks for your patience, > > Jack > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Wed May 4 22:04:34 2011 Return-Path: Delivered-To: Current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2676B106566C for ; Wed, 4 May 2011 22:04:34 +0000 (UTC) (envelope-from Daan@vehosting.nl) Received: from VM01.VEHosting.nl (VM016.VEHosting.nl [IPv6:2001:1af8:2100:b020::140]) by mx1.freebsd.org (Postfix) with ESMTP id AD36C8FC0A for ; Wed, 4 May 2011 22:04:33 +0000 (UTC) Received: from [192.168.45.11] (180-161.ftth.onsbrabantnet.nl [88.159.161.180]) (authenticated bits=0) by VM01.VEHosting.nl (8.14.3/8.13.8) with ESMTP id p44M4anH092517; Thu, 5 May 2011 00:04:36 +0200 (CEST) (envelope-from Daan@vehosting.nl) From: Daan Vreeken Organization: http://VEHosting.nl/ To: Jack Vogel Date: Thu, 5 May 2011 00:04:31 +0200 User-Agent: KMail/1.9.10 References: <201105041734.50738.Daan@vehosting.nl> <201105042019.23899.Daan@vehosting.nl> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201105050004.31745.Daan@vehosting.nl> x-ve-auth-version: mi-1.1.5 2011-02-07 - Copyright (c) 2008, 2011 - Daan Vreeken - VEHosting x-ve-auth: authenticated as 'pa4dan' on VM01.VEHosting.nl Cc: Current@freebsd.org Subject: Re: Interrupt storm with MSI in combination with em1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 22:04:34 -0000 Hi, On Wednesday 04 May 2011 20:47:32 Jack Vogel wrote: > Will you please set it back to a default and then boot and capture the > message for me? No problem. Here's the output with MSI/MSIX enabled : http://vehosting.nl/pub_diffs/dmesg_plantje2_with_msix_2011_05_04.txt I've also added the output of "vmstat -i" a couple of minutes after a reboot with MSI enabled : http://vehosting.nl/pub_diffs/vmstat_i_2011_05_04.txt Note that in the above "vmstat -i" dump the interrupt storm hasn't started yet. For some reason the storm doesn't always start directly at boot. I haven't been able (yet) to pinpoint what's triggering it to start. > On Wed, May 4, 2011 at 11:19 AM, Daan Vreeken wrote: > > Hi Jack, > > > > Wednesday 04 May 2011 19:46:05 Jack Vogel wrote: > > > Who makes your motherboard? The problem you are having is that MSIX AND > > > MSI are both failing as em0 comes up, so it falls back to Legacy > > > > interrupt > > > > > mode, > > > and must be having some issue with sharing the line, causing the storm. > > > > The motherboard is an Asus "P7H55-M". > > > > Sorry, I should have mentioned that the dmesg output is from booting with : > > > > hw.pci.enable_msix="0" > > > > hw.pci.enable_msi="0" > > > > .. in "loader.conf". > > > > With those lines in "loader.conf", MSI and MSIX is disabled, both cards > > work > > like they should and there is no interrupt storm. > > > > With MSI/MSIX enabled, both cards work like they should and I see the > > counters > > of the MSI interrupts increase (in small amounts, like they should), but > > at boot-time an interrupt storm starts on 'legacy' IRQ 16. > > > > Because the only difference between disabling/enabling MSI/MSIX seems to > > be in > > the way em0/em1 are used, and because 'em1' shares IRQ 16 according to > > the dmesg, I'm suspecting 'em1' is causing the storm. > > (But please correct me if I'm wrong :) > > > > What can I do to help track this problem down? > > > > > > According to "dmesg" the following devices share IRQ 16 : > > > > > > > > pcib1: irq 16 at device 1.0 on pci0 > > > > em0: port > > > > 0xcc00-0xcc1f mem > > > > 0xf7de0000-0xf7dfffff,0xf7d00000-0xf7d7ffff,0xf7ddc000-0xf7ddffff > > > > irq 16 at device 0.0 on pci1 > > > > vgapci0: port 0xbc00-0xbc07 > > > > mem 0xf7800000-0xf7bfffff,0xe0000000-0xefffffff irq 16 at > > > > device 2.0 on > > > > pci0 > > > > ehci0: mem > > > > 0xf7cfa000-0xf7cfa3ff > > > > irq 16 at device 26.0 on pci0 > > > > em1: port > > > > 0xec00-0xec1f mem > > > > 0xf7fe0000-0xf7ffffff,0xf7f00000-0xf7f7ffff,0xf7fdc000-0xf7fdffff > > > > irq 16 at device 0.0 on pci4 > > > > pcib4: irq 16 at device 28.5 on pci0 > > > > > > > > During a storm "vmstat -i" shows a rate of about 220.000 > > > > interrupts/sec. > > > > > > MSI > > > > interrupt delivery to both 'em0' and 'em1' seems to work correctly > > > > during > > > > > > a storm, as I see their counters increase normally in the "vmstat -i" > > > > output. > > > > > > > > As only 'em0' and 'em1' seem to be using MSI interrupts, my guess is > > > > that > > > > > > the > > > > e1000 driver is causing this problem. Could it be that the driver > > > > forgets > > > > > > to > > > > clear/mask legacy interrupts when attaching the MSI interrupts > > > > perhaps? > > > > > > > > Any tips on how to debug and/or fix this? > > > > > > > > > > > > The full output of "dmesg" can be found here : > > > > http://vehosting.nl/pub_diffs/dmesg_plantje2_2011_05_04.txt > > > > > > > > And the full output of "pciconf -lv" is here : > > > > http://vehosting.nl/pub_diffs/pciconf_plantje2_2011_05_04.txt > > > > Regards, > > -- > > Daan Vreeken > > VEHosting > > http://VEHosting.nl > > tel: +31-(0)40-7113050 / +31-(0)6-46210825 > > KvK nr: 17174380 Regards, -- Daan Vreeken VEHosting http://VEHosting.nl tel: +31-(0)40-7113050 / +31-(0)6-46210825 KvK nr: 17174380 From owner-freebsd-current@FreeBSD.ORG Wed May 4 22:15:45 2011 Return-Path: Delivered-To: Current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3674106566C for ; Wed, 4 May 2011 22:15:45 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 64A978FC13 for ; Wed, 4 May 2011 22:15:45 +0000 (UTC) Received: by vxc34 with SMTP id 34so2204072vxc.13 for ; Wed, 04 May 2011 15:15:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=exhFsKvXwOdQtP1FiUXeXnpo7Xrx3JXWJGFkqFWF6zc=; b=kbtDta//hO7In7ruPb1/BJLiOz/sX64zJweRP9dQqS+O5F4ILuyuTBfu0tJ8JJ0bmy EJTTjMaM7UcG8CJDeLzBzXUq575+jxbsL6+8j18Y1MT+1/sPQiGZqDqsbJ8v6D5+DqQp 7JHhMBvSkvM32KVgsOLN08hHfX+ri2iTINPiE= 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=Tbn48THPd1R+I+uXnUkFjW7R3sc/uQYH1YF+TMX87rMszzA4nIGfALZiEApsSOvnxQ bWLudkg2fhKxq592aQDhKn4j7IyFK5pQu/DSJwmPhr+fahrqzw8QxkeP5YiLZxHUmMMk 8cfYHEhP8duVUta5gl3cA9u8no4vDCHWH/vr0= MIME-Version: 1.0 Received: by 10.52.180.169 with SMTP id dp9mr806903vdc.84.1304547343464; Wed, 04 May 2011 15:15:43 -0700 (PDT) Received: by 10.52.184.169 with HTTP; Wed, 4 May 2011 15:15:43 -0700 (PDT) In-Reply-To: <201105050004.31745.Daan@vehosting.nl> References: <201105041734.50738.Daan@vehosting.nl> <201105042019.23899.Daan@vehosting.nl> <201105050004.31745.Daan@vehosting.nl> Date: Wed, 4 May 2011 15:15:43 -0700 Message-ID: From: Jack Vogel To: Daan Vreeken Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Current@freebsd.org Subject: Re: Interrupt storm with MSI in combination with em1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 22:15:45 -0000 This all looks completely kosher, what IRQ is the storm on?? Jack On Wed, May 4, 2011 at 3:04 PM, Daan Vreeken wrote: > Hi, > > On Wednesday 04 May 2011 20:47:32 Jack Vogel wrote: > > Will you please set it back to a default and then boot and capture the > > message for me? > > No problem. Here's the output with MSI/MSIX enabled : > > http://vehosting.nl/pub_diffs/dmesg_plantje2_with_msix_2011_05_04.txt > > I've also added the output of "vmstat -i" a couple of minutes after a > reboot > with MSI enabled : > http://vehosting.nl/pub_diffs/vmstat_i_2011_05_04.txt > > Note that in the above "vmstat -i" dump the interrupt storm hasn't started > yet. For some reason the storm doesn't always start directly at boot. I > haven't been able (yet) to pinpoint what's triggering it to start. > > > > On Wed, May 4, 2011 at 11:19 AM, Daan Vreeken wrote: > > > Hi Jack, > > > > > > Wednesday 04 May 2011 19:46:05 Jack Vogel wrote: > > > > Who makes your motherboard? The problem you are having is that MSIX > AND > > > > MSI are both failing as em0 comes up, so it falls back to Legacy > > > > > > interrupt > > > > > > > mode, > > > > and must be having some issue with sharing the line, causing the > storm. > > > > > > The motherboard is an Asus "P7H55-M". > > > > > > Sorry, I should have mentioned that the dmesg output is from booting > with : > > > > > hw.pci.enable_msix="0" > > > > > hw.pci.enable_msi="0" > > > > > > .. in "loader.conf". > > > > > > With those lines in "loader.conf", MSI and MSIX is disabled, both cards > > > work > > > like they should and there is no interrupt storm. > > > > > > With MSI/MSIX enabled, both cards work like they should and I see the > > > counters > > > of the MSI interrupts increase (in small amounts, like they should), > but > > > at boot-time an interrupt storm starts on 'legacy' IRQ 16. > > > > > > Because the only difference between disabling/enabling MSI/MSIX seems > to > > > be in > > > the way em0/em1 are used, and because 'em1' shares IRQ 16 according to > > > the dmesg, I'm suspecting 'em1' is causing the storm. > > > (But please correct me if I'm wrong :) > > > > > > What can I do to help track this problem down? > > > > > > > > According to "dmesg" the following devices share IRQ 16 : > > > > > > > > > > pcib1: irq 16 at device 1.0 on pci0 > > > > > em0: port > > > > > 0xcc00-0xcc1f mem > > > > > 0xf7de0000-0xf7dfffff,0xf7d00000-0xf7d7ffff,0xf7ddc000-0xf7ddffff > > > > > irq 16 at device 0.0 on pci1 > > > > > vgapci0: port 0xbc00-0xbc07 > > > > > mem 0xf7800000-0xf7bfffff,0xe0000000-0xefffffff irq 16 at > > > > > device 2.0 on > > > > > pci0 > > > > > ehci0: mem > > > > > 0xf7cfa000-0xf7cfa3ff > > > > > irq 16 at device 26.0 on pci0 > > > > > em1: port > > > > > 0xec00-0xec1f mem > > > > > 0xf7fe0000-0xf7ffffff,0xf7f00000-0xf7f7ffff,0xf7fdc000-0xf7fdffff > > > > > irq 16 at device 0.0 on pci4 > > > > > pcib4: irq 16 at device 28.5 on pci0 > > > > > > > > > > During a storm "vmstat -i" shows a rate of about 220.000 > > > > > > interrupts/sec. > > > > > > > > MSI > > > > > interrupt delivery to both 'em0' and 'em1' seems to work correctly > > > > > > during > > > > > > > > a storm, as I see their counters increase normally in the "vmstat > -i" > > > > > output. > > > > > > > > > > As only 'em0' and 'em1' seem to be using MSI interrupts, my guess > is > > > > > > that > > > > > > > > the > > > > > e1000 driver is causing this problem. Could it be that the driver > > > > > > forgets > > > > > > > > to > > > > > clear/mask legacy interrupts when attaching the MSI interrupts > > > > > perhaps? > > > > > > > > > > Any tips on how to debug and/or fix this? > > > > > > > > > > > > > > > The full output of "dmesg" can be found here : > > > > > http://vehosting.nl/pub_diffs/dmesg_plantje2_2011_05_04.txt > > > > > > > > > > And the full output of "pciconf -lv" is here : > > > > > > http://vehosting.nl/pub_diffs/pciconf_plantje2_2011_05_04.txt > > > > > > Regards, > > > -- > > > Daan Vreeken > > > VEHosting > > > http://VEHosting.nl > > > tel: +31-(0)40-7113050 / +31-(0)6-46210825 > > > KvK nr: 17174380 > > > Regards, > -- > Daan Vreeken > VEHosting > http://VEHosting.nl > tel: +31-(0)40-7113050 / +31-(0)6-46210825 > KvK nr: 17174380 > From owner-freebsd-current@FreeBSD.ORG Wed May 4 22:30:28 2011 Return-Path: Delivered-To: Current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AAFA1065670 for ; Wed, 4 May 2011 22:30:28 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4D54B8FC16 for ; Wed, 4 May 2011 22:30:27 +0000 (UTC) Received: by vxc34 with SMTP id 34so2219274vxc.13 for ; Wed, 04 May 2011 15:30:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=njDP871rq5iPSvdD2OQdPRCt2Sx0gVuaR9lzayi1mNE=; b=jIVdD3YVTHOlwBQGFWo3VnCrdzXIxyE5y98L/G+DOFK50ZFQNzo/u5ECTJlr+O0C4/ sF8zaJ2we0YyNlT7Z41X+xwNUdd6NkBwzPJ6R8OIzeiYaC9DjlCFm8Ku9ksmpZwhfU+1 nNZVPP4FBDQUBfQLmyycPhiPUW/KBjSeSIdRg= 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=Z9yZauZz44iqotApY2eDu+kFAKSgWvtFnwVzfYXrxHczCJf4bL6HRNy/+tosISowg6 pBrVrwzyLJSYAsW24rMgQ/3z1efiO4cWP681gNnRBoN91jCvOkg54I5X/YACxpr+RMGD JR4StUKhXwXgiK394LRUfFQ3n9SgcX0MnE9Ws= MIME-Version: 1.0 Received: by 10.52.76.193 with SMTP id m1mr2119341vdw.204.1304548227443; Wed, 04 May 2011 15:30:27 -0700 (PDT) Received: by 10.52.184.169 with HTTP; Wed, 4 May 2011 15:30:27 -0700 (PDT) In-Reply-To: References: <201105041734.50738.Daan@vehosting.nl> Date: Wed, 4 May 2011 15:30:27 -0700 Message-ID: From: Jack Vogel To: Wiktor Niesiobedzki Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Current@freebsd.org Subject: Re: Interrupt storm with MSI in combination with em1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 22:30:28 -0000 Right, it was you Wiktor :) Oh, so yours is sort of a special case. Thanks, Jack On Wed, May 4, 2011 at 3:27 PM, Wiktor Niesiobedzki wrote: > 2011/5/4 Jack Vogel : > > This is the second report in a matter of a week perhaps about a > problematic > > motherboard, I would like to know who makes them. > > Just for the record, the motherboard with which I had problems (I > guess my problem is here referred) is VIA EPIA SN10000. It's nothing > new, and probably rarely used with additional PCIe cards, as this is > embedded-like creature. > > Cheers, > > Wiktor Niesiobedzki > From owner-freebsd-current@FreeBSD.ORG Wed May 4 22:53:08 2011 Return-Path: Delivered-To: Current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AA9A106564A for ; Wed, 4 May 2011 22:53:08 +0000 (UTC) (envelope-from bsd@vink.pl) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.212.176]) by mx1.freebsd.org (Postfix) with ESMTP id E7BB28FC14 for ; Wed, 4 May 2011 22:53:07 +0000 (UTC) Received: by pxi11 with SMTP id 11so1203113pxi.7 for ; Wed, 04 May 2011 15:53:07 -0700 (PDT) Received: by 10.68.5.137 with SMTP id s9mr2202930pbs.61.1304548043641; Wed, 04 May 2011 15:27:23 -0700 (PDT) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.212.176]) by mx.google.com with ESMTPS id t6sm997221pbc.21.2011.05.04.15.27.22 (version=SSLv3 cipher=OTHER); Wed, 04 May 2011 15:27:23 -0700 (PDT) Received: by pxi11 with SMTP id 11so1188521pxi.7 for ; Wed, 04 May 2011 15:27:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.40.65 with SMTP id v1mr2239063pbk.154.1304548042138; Wed, 04 May 2011 15:27:22 -0700 (PDT) Received: by 10.68.42.40 with HTTP; Wed, 4 May 2011 15:27:22 -0700 (PDT) In-Reply-To: References: <201105041734.50738.Daan@vehosting.nl> Date: Thu, 5 May 2011 00:27:22 +0200 Message-ID: From: Wiktor Niesiobedzki To: Jack Vogel Content-Type: text/plain; charset=UTF-8 Cc: Current@freebsd.org Subject: Re: Interrupt storm with MSI in combination with em1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 22:53:08 -0000 2011/5/4 Jack Vogel : > This is the second report in a matter of a week perhaps about a problematic > motherboard, I would like to know who makes them. Just for the record, the motherboard with which I had problems (I guess my problem is here referred) is VIA EPIA SN10000. It's nothing new, and probably rarely used with additional PCIe cards, as this is embedded-like creature. Cheers, Wiktor Niesiobedzki From owner-freebsd-current@FreeBSD.ORG Wed May 4 23:27:28 2011 Return-Path: Delivered-To: Current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 410991065673 for ; Wed, 4 May 2011 23:27:28 +0000 (UTC) (envelope-from Daan@vehosting.nl) Received: from VM01.VEHosting.nl (VM016.VEHosting.nl [IPv6:2001:1af8:2100:b020::140]) by mx1.freebsd.org (Postfix) with ESMTP id C83498FC13 for ; Wed, 4 May 2011 23:27:27 +0000 (UTC) Received: from [192.168.45.11] (180-161.ftth.onsbrabantnet.nl [88.159.161.180]) (authenticated bits=0) by VM01.VEHosting.nl (8.14.3/8.13.8) with ESMTP id p44NRVPf093219; Thu, 5 May 2011 01:27:31 +0200 (CEST) (envelope-from Daan@vehosting.nl) From: Daan Vreeken Organization: http://VEHosting.nl/ To: Jack Vogel Date: Thu, 5 May 2011 01:27:26 +0200 User-Agent: KMail/1.9.10 References: <201105041734.50738.Daan@vehosting.nl> <201105050004.31745.Daan@vehosting.nl> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201105050127.26358.Daan@vehosting.nl> x-ve-auth-version: mi-1.1.5 2011-02-07 - Copyright (c) 2008, 2011 - Daan Vreeken - VEHosting x-ve-auth: authenticated as 'pa4dan' on VM01.VEHosting.nl Cc: Current@freebsd.org Subject: Re: Interrupt storm with MSI in combination with em1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 23:27:28 -0000 On Thursday 05 May 2011 00:15:43 you wrote: > This all looks completely kosher, what IRQ is the storm on?? IRQ 16. Further down this email there is a list of devices that share the IRQ according to 'dmesg'. > On Wed, May 4, 2011 at 3:04 PM, Daan Vreeken wrote: > > Hi, > > > > On Wednesday 04 May 2011 20:47:32 Jack Vogel wrote: > > > Will you please set it back to a default and then boot and capture the > > > message for me? > > > > No problem. Here's the output with MSI/MSIX enabled : > > > > http://vehosting.nl/pub_diffs/dmesg_plantje2_with_msix_2011_05_04.txt > > > > I've also added the output of "vmstat -i" a couple of minutes after a > > reboot > > with MSI enabled : > > http://vehosting.nl/pub_diffs/vmstat_i_2011_05_04.txt > > > > Note that in the above "vmstat -i" dump the interrupt storm hasn't > > started yet. For some reason the storm doesn't always start directly at > > boot. I haven't been able (yet) to pinpoint what's triggering it to > > start. > > > > > On Wed, May 4, 2011 at 11:19 AM, Daan Vreeken wrote: > > > > Hi Jack, > > > > > > > > Wednesday 04 May 2011 19:46:05 Jack Vogel wrote: > > > > > Who makes your motherboard? The problem you are having is that MSIX > > > > > AND MSI are both failing as em0 comes up, so it falls back to Legacy > > > > > interrupt mode, > > > > > and must be having some issue with sharing the line, causing the > > > > > storm. > > > > The motherboard is an Asus "P7H55-M". > > > > > > > > Sorry, I should have mentioned that the dmesg output is from booting > > > > with : > > > > > > hw.pci.enable_msix="0" > > > > > > hw.pci.enable_msi="0" > > > > .. in "loader.conf". > > > > > > > > With those lines in "loader.conf", MSI and MSIX is disabled, both > > > > cards work > > > > like they should and there is no interrupt storm. > > > > > > > > With MSI/MSIX enabled, both cards work like they should and I see the > > > > counters > > > > of the MSI interrupts increase (in small amounts, like they should), > > > > but at boot-time an interrupt storm starts on 'legacy' IRQ 16. > > > > > > > > Because the only difference between disabling/enabling MSI/MSIX seems > > > > to be in > > > > the way em0/em1 are used, and because 'em1' shares IRQ 16 according > > > > to the dmesg, I'm suspecting 'em1' is causing the storm. > > > > (But please correct me if I'm wrong :) > > > > > > > > What can I do to help track this problem down? > > > > > > > > > > According to "dmesg" the following devices share IRQ 16 : > > > > > > > > > > > > pcib1: irq 16 at device 1.0 on pci0 > > > > > > em0: port > > > > > > 0xcc00-0xcc1f mem > > > > > > 0xf7de0000-0xf7dfffff,0xf7d00000-0xf7d7ffff,0xf7ddc000-0xf7ddffff > > > > > > irq 16 at device 0.0 on pci1 > > > > > > vgapci0: port 0xbc00-0xbc07 > > > > > > mem 0xf7800000-0xf7bfffff,0xe0000000-0xefffffff irq 16 > > > > > > at device 2.0 on > > > > > > pci0 > > > > > > ehci0: mem > > > > > > 0xf7cfa000-0xf7cfa3ff > > > > > > irq 16 at device 26.0 on pci0 > > > > > > em1: port > > > > > > 0xec00-0xec1f mem > > > > > > 0xf7fe0000-0xf7ffffff,0xf7f00000-0xf7f7ffff,0xf7fdc000-0xf7fdffff > > > > > > irq 16 at device 0.0 on pci4 > > > > > > pcib4: irq 16 at device 28.5 on pci0 > > > > > > > > > > > > During a storm "vmstat -i" shows a rate of about 220.000 > > > > > > interrupts/sec. > > > > > > MSI > > > > > > interrupt delivery to both 'em0' and 'em1' seems to work > > > > > > correctly during > > > > > > a storm, as I see their counters increase normally in the "vmstat > > > > > > -i" output. > > > > > > As only 'em0' and 'em1' seem to be using MSI interrupts, my guess > > > > > > is that the > > > > > > e1000 driver is causing this problem. Could it be that the driver > > > > > > forgets to > > > > > > clear/mask legacy interrupts when attaching the MSI interrupts > > > > > > perhaps? > > > > > > > > > > > > Any tips on how to debug and/or fix this? > > > > > > > > > > > > > > > > > > The full output of "dmesg" can be found here : > > > > > > > > > > > > http://vehosting.nl/pub_diffs/dmesg_plantje2_2011_05_04.txt > > > > > > > > > > > > And the full output of "pciconf -lv" is here : > > > > http://vehosting.nl/pub_diffs/pciconf_plantje2_2011_05_04.txt Thanks, -- Daan Vreeken VEHosting http://VEHosting.nl tel: +31-(0)40-7113050 / +31-(0)6-46210825 KvK nr: 17174380 From owner-freebsd-current@FreeBSD.ORG Thu May 5 00:25:40 2011 Return-Path: Delivered-To: Current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B716106564A for ; Thu, 5 May 2011 00:25:40 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id D3E4E8FC15 for ; Thu, 5 May 2011 00:25:39 +0000 (UTC) Received: by vxc34 with SMTP id 34so2341046vxc.13 for ; Wed, 04 May 2011 17:25:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ETkVm56C/bCl1Vcx0zH7t1aLNEalOOvd8vPv1SXVsDU=; b=YTtygAvUpTb1qsDFNS5WGREWCzOJJ1ZgwtY+j5gpV/Ity/vYmRYf4B8yHORBJKhf66 GBMa52Km1EpqTU0dSbfpQ+wDl8hQuPL6+UOWhGVfJvVAVledqhrA+S293cj/c63sbYFY SpI4PxjbWVvlU+rvSz9kVBmD3XPKJrIG60+is= 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=ZSCgM6yqTk70EEVBfT0O36TRI3zrBUnGNA0j6KQZrZ4NAicMTvFJcsMOJMnBKCMko+ zwypQXMFnZpEkka7suxqXWS+H3gnsA89xzI4qKer/wlDWKXaI6Z3md3rhSkSHpMmLcco 2gbfyW7HQE62Km2HDzBB99L/eYegDmHkeoxSU= MIME-Version: 1.0 Received: by 10.52.111.68 with SMTP id ig4mr2278014vdb.4.1304555139222; Wed, 04 May 2011 17:25:39 -0700 (PDT) Received: by 10.52.184.169 with HTTP; Wed, 4 May 2011 17:25:39 -0700 (PDT) In-Reply-To: <201105050127.26358.Daan@vehosting.nl> References: <201105041734.50738.Daan@vehosting.nl> <201105050004.31745.Daan@vehosting.nl> <201105050127.26358.Daan@vehosting.nl> Date: Wed, 4 May 2011 17:25:39 -0700 Message-ID: From: Jack Vogel To: Daan Vreeken Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Current@freebsd.org Subject: Re: Interrupt storm with MSI in combination with em1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 00:25:40 -0000 OK, but the reason you see the multiple cases of irq 16 is that's the bridge, once you are using MSIX, as vmstat shows, its using other vectors. Can you capture the messages file with the actual storm happening? I noticed some complaints about checksums in the dmesg, have you checked on BIOS upgrades or something like that on your motherboard? Regards, Jack On Wed, May 4, 2011 at 4:27 PM, Daan Vreeken wrote: > On Thursday 05 May 2011 00:15:43 you wrote: > > This all looks completely kosher, what IRQ is the storm on?? > > IRQ 16. Further down this email there is a list of devices that share the > IRQ > according to 'dmesg'. > > > > On Wed, May 4, 2011 at 3:04 PM, Daan Vreeken wrote: > > > Hi, > > > > > > On Wednesday 04 May 2011 20:47:32 Jack Vogel wrote: > > > > Will you please set it back to a default and then boot and capture > the > > > > message for me? > > > > > > No problem. Here's the output with MSI/MSIX enabled : > > > > > > http://vehosting.nl/pub_diffs/dmesg_plantje2_with_msix_2011_05_04.txt > > > > > > I've also added the output of "vmstat -i" a couple of minutes after a > > > reboot > > > with MSI enabled : > > > http://vehosting.nl/pub_diffs/vmstat_i_2011_05_04.txt > > > > > > Note that in the above "vmstat -i" dump the interrupt storm hasn't > > > started yet. For some reason the storm doesn't always start directly at > > > boot. I haven't been able (yet) to pinpoint what's triggering it to > > > start. > > > > > > > On Wed, May 4, 2011 at 11:19 AM, Daan Vreeken > wrote: > > > > > Hi Jack, > > > > > > > > > > Wednesday 04 May 2011 19:46:05 Jack Vogel wrote: > > > > > > Who makes your motherboard? The problem you are having is that > MSIX > > > > > > AND MSI are both failing as em0 comes up, so it falls back to > Legacy > > > > > > interrupt mode, > > > > > > and must be having some issue with sharing the line, causing the > > > > > > storm. > > > > > The motherboard is an Asus "P7H55-M". > > > > > > > > > > Sorry, I should have mentioned that the dmesg output is from > booting > > > > > with : > > > > > > > hw.pci.enable_msix="0" > > > > > > > hw.pci.enable_msi="0" > > > > > .. in "loader.conf". > > > > > > > > > > With those lines in "loader.conf", MSI and MSIX is disabled, both > > > > > cards work > > > > > like they should and there is no interrupt storm. > > > > > > > > > > With MSI/MSIX enabled, both cards work like they should and I see > the > > > > > counters > > > > > of the MSI interrupts increase (in small amounts, like they > should), > > > > > but at boot-time an interrupt storm starts on 'legacy' IRQ 16. > > > > > > > > > > Because the only difference between disabling/enabling MSI/MSIX > seems > > > > > to be in > > > > > the way em0/em1 are used, and because 'em1' shares IRQ 16 according > > > > > to the dmesg, I'm suspecting 'em1' is causing the storm. > > > > > (But please correct me if I'm wrong :) > > > > > > > > > > What can I do to help track this problem down? > > > > > > > > > > > > According to "dmesg" the following devices share IRQ 16 : > > > > > > > > > > > > > > pcib1: irq 16 at device 1.0 on > pci0 > > > > > > > em0: port > > > > > > > 0xcc00-0xcc1f mem > > > > > > > > 0xf7de0000-0xf7dfffff,0xf7d00000-0xf7d7ffff,0xf7ddc000-0xf7ddffff > > > > > > > irq 16 at device 0.0 on pci1 > > > > > > > vgapci0: port 0xbc00-0xbc07 > > > > > > > mem 0xf7800000-0xf7bfffff,0xe0000000-0xefffffff irq > 16 > > > > > > > at device 2.0 on > > > > > > > pci0 > > > > > > > ehci0: mem > > > > > > > 0xf7cfa000-0xf7cfa3ff > > > > > > > irq 16 at device 26.0 on pci0 > > > > > > > em1: port > > > > > > > 0xec00-0xec1f mem > > > > > > > > 0xf7fe0000-0xf7ffffff,0xf7f00000-0xf7f7ffff,0xf7fdc000-0xf7fdffff > > > > > > > irq 16 at device 0.0 on pci4 > > > > > > > pcib4: irq 16 at device 28.5 on > pci0 > > > > > > > > > > > > > > During a storm "vmstat -i" shows a rate of about 220.000 > > > > > > > interrupts/sec. > > > > > > > MSI > > > > > > > interrupt delivery to both 'em0' and 'em1' seems to work > > > > > > > correctly during > > > > > > > a storm, as I see their counters increase normally in the > "vmstat > > > > > > > -i" output. > > > > > > > As only 'em0' and 'em1' seem to be using MSI interrupts, my > guess > > > > > > > is that the > > > > > > > e1000 driver is causing this problem. Could it be that the > driver > > > > > > > forgets to > > > > > > > clear/mask legacy interrupts when attaching the MSI interrupts > > > > > > > perhaps? > > > > > > > > > > > > > > Any tips on how to debug and/or fix this? > > > > > > > > > > > > > > > > > > > > > The full output of "dmesg" can be found here : > > > > > > > > > > > > > > http://vehosting.nl/pub_diffs/dmesg_plantje2_2011_05_04.txt > > > > > > > > > > > > > > And the full output of "pciconf -lv" is here : > > > > > > http://vehosting.nl/pub_diffs/pciconf_plantje2_2011_05_04.txt > > > Thanks, > -- > Daan Vreeken > VEHosting > http://VEHosting.nl > tel: +31-(0)40-7113050 / +31-(0)6-46210825 > KvK nr: 17174380 > From owner-freebsd-current@FreeBSD.ORG Thu May 5 05:20:31 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9119F106566B for ; Thu, 5 May 2011 05:20:31 +0000 (UTC) (envelope-from lacombar@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 4B7D58FC1D for ; Thu, 5 May 2011 05:20:30 +0000 (UTC) Received: by iwn33 with SMTP id 33so2154224iwn.13 for ; Wed, 04 May 2011 22:20:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JbG+DGTGRJ2H31sWa1Qq/BycmSLOP/2ZYxNLEzJM/LQ=; b=iMS4jZVifFqXpEULH1+HyXwSyqmdup4XYacUo/HJeurXtSq3koxtnOFwxidbAlz2hr 8kcVg4iOkYtPFRi2i3Dds4VUIgcEztZyATB5H4AodU+qYLhjsQkh4iJ1sO9YjMDgAPaF h2Nvx7xWeq7D27XTuBTfr/PWWi+MF3cOrUsR0= 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=t+yXgSKgd51AGjyPpMhneBUhbdUQFmEBtVTm1ZEBLrAe62n4znQQFjEHZCTIV2B0tI 2AsnOPUCs9jwtKYnA1F5FRBfx+lm7J0ffoHcahvNbzWt5efwA/57jNK7+7yOqa20ZLeu i0FuOUFUZZg/EL9g46Kr1lKEhD2ZUSRqJmBCY= MIME-Version: 1.0 Received: by 10.42.151.73 with SMTP id d9mr56547icw.2.1304572830501; Wed, 04 May 2011 22:20:30 -0700 (PDT) Received: by 10.42.167.5 with HTTP; Wed, 4 May 2011 22:20:30 -0700 (PDT) In-Reply-To: References: <4D94A354.9080903@sentex.net> <4DC07013.9070707@gmx.net> <4DC078BD.9080908@gmx.net> Date: Thu, 5 May 2011 01:20:30 -0400 Message-ID: From: Arnaud Lacombe To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Olivier Smedts , FreeBSD current mailing list Subject: Re: problems with em(4) since update to driver 7.2.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 05:20:31 -0000 Hi, On Wed, May 4, 2011 at 5:38 PM, Jack Vogel wrote: > I have had my validation engineer busy all day, we have tried both > a 9 kernel as well as 8.2, =A0using the code from HEAD, and we > cannot reproduce this problem. > Actually, it can be trivially reproduced by tainting `error'. As it is uninitialized in HEAD, it's value can be _anything_, so let's mark it as explicitly invalid. diff -u ./if_em.c /data/src/freebsd/em-7.2.2/src/if_em.c --- ./if_em.c 2011-02-18 01:18:23.000000000 -0500 +++ /data/src/freebsd/em-7.2.2/src/if_em.c 2011-05-05 01:12:01.000000000 -0400 @@ -3912,7 +3912,7 @@ struct adapter *adapter =3D rxr->adapter; struct em_buffer *rxbuf; bus_dma_segment_t seg[1]; - int i, j, nsegs, error; + int i, j, nsegs, error =3D -1; The error pointed out in this thread pops up in the next boot. - Arnaud > The data your netstat -m shows suggests to me that what's happening > is somehow setup of the receive ring is running more than once maybe?? > > You asked at one point how this could go into STABLE, well, because > not only here at Intel, but at lots of external customers this code has b= een > used and tested thoroughly. > > I am not calling into question your problem, but until I understand what = it > is I cannot "fix" it :) > > The thing I am guessing right now is the culprit is the setup code, the > reason > is that when I ported to the igb driver I found that it did not work on o= ur > newer > hardware, and so I went back to the older version of setup for igb. Now, > even > though I have not seen hardware fail with em, maybe there is some. > > To help me give me a complete pciconf -lv, and if its a namebrand system > tell me that, including all hardware in it. > > If you like Olivier I can make a version of em for you that also reverts = the > setup code the way I did for igb, see if that fixes it for you? > > Thanks for your patience, > > Jack > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Thu May 5 06:03:49 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 645E5106566B for ; Thu, 5 May 2011 06:03:49 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1D6328FC08 for ; Thu, 5 May 2011 06:03:48 +0000 (UTC) Received: by iyj12 with SMTP id 12so2203770iyj.13 for ; Wed, 04 May 2011 23:03:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=n1JO8WGhgy8OvVB8ybEf9QPI0+itaLf8H7eM8tJF5gY=; b=DqXyYrvTCCGILhBUBzToL+aAqyHF+tgtQd9OpS2hJSIo5j6u8yB7qEWBSv9TQ0UELm 5C7RvJ0JaAPLH6SpLxAMDoTnD1HR3w0mO6zaT9SJX6VwqcLyKVChHwZWDwyVj3Z44c8p kXbnMrUiChThjbzk2SlE4q0Ow7ePyFZuZrAiM= 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=rkE0APj4VFZqXcyFcabxIGkSBITdPipJtBFi8WDUewl854cVhKSk+VUWy8Up+mAAnS h5SksIe3viqKc9e38E58xrt7ToIBUbDmhE0ha3oBr0Fy7D6nCARQht48CIGjAcJp6WQJ VJIyAAw99BVO/FVE7p0hR8SoQh9dp0E6exeyQ= MIME-Version: 1.0 Received: by 10.42.246.133 with SMTP id ly5mr363502icb.404.1304575428170; Wed, 04 May 2011 23:03:48 -0700 (PDT) Received: by 10.42.167.5 with HTTP; Wed, 4 May 2011 23:03:48 -0700 (PDT) In-Reply-To: References: <4D94A354.9080903@sentex.net> <4DC07013.9070707@gmx.net> <4DC078BD.9080908@gmx.net> Date: Thu, 5 May 2011 02:03:48 -0400 Message-ID: From: Arnaud Lacombe To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Olivier Smedts , FreeBSD current mailing list Subject: Re: problems with em(4) since update to driver 7.2.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 06:03:49 -0000 Hi, On Thu, May 5, 2011 at 1:20 AM, Arnaud Lacombe wrote: > Hi, > > On Wed, May 4, 2011 at 5:38 PM, Jack Vogel wrote: >> I have had my validation engineer busy all day, we have tried both >> a 9 kernel as well as 8.2, =A0using the code from HEAD, and we >> cannot reproduce this problem. >> > Actually, it can be trivially reproduced by tainting `error'. As it is > uninitialized in HEAD, it's value can be _anything_, so let's mark it > as explicitly invalid. > > diff -u ./if_em.c /data/src/freebsd/em-7.2.2/src/if_em.c > --- ./if_em.c =A0 2011-02-18 01:18:23.000000000 -0500 > +++ /data/src/freebsd/em-7.2.2/src/if_em.c =A0 =A0 =A02011-05-05 > 01:12:01.000000000 -0400 > @@ -3912,7 +3912,7 @@ > =A0 =A0 =A0 =A0struct =A0adapter =A0 =A0 =A0 =A0 *adapter =3D rxr->adapte= r; > =A0 =A0 =A0 =A0struct em_buffer =A0 =A0 =A0 =A0*rxbuf; > =A0 =A0 =A0 =A0bus_dma_segment_t =A0 =A0 =A0 seg[1]; > - =A0 =A0 =A0 int =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 i, j, nsegs, er= ror; > + =A0 =A0 =A0 int =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 i, j, nsegs, er= ror =3D -1; > > The error pointed out in this thread pops up in the next boot. > I put a call to kdb_enter() at the beginning of the function, helped with some textdump I got all the backtrace [0] for all the time em_setup_receive_ring() is called. All are exactly the same: kdb_enter_why(0,c09f6511,f391aaa8,c09be1e2,c09f6511,...) at kdb_enter_why+0= x3b kdb_enter(c09f6511,0,3810,ffffffff,5dc,...) at kdb_enter+0x19 em_setup_receive_ring(c3c8d600,c3c8d7a4,c3c96004,310000fa,c3c8d600,...) at em_setup_receive_ring+0x22 em_setup_receive_structures(c3c96000,f15f2000,38,8100,3,...) at em_setup_receive_structures+0x26 em_init_locked(c3c96000,0,c09f5de5,414,10000,...) at em_init_locked+0x2f2 em_ioctl(c3c7d000,80206934,c3ce9d00,c07b7a0b,c3f2a230,...) at em_ioctl+0x1c= 3 ifhwioctl(c3f2a230,f391ac34,c07b7a0b,c3f3e3d0,c08df1c0,...) at ifhwioctl+0x= 4b8 ifioctl(c3f3e3d0,80206934,c3ce9d00,c3f2a230,c3f2a230,...) at ifioctl+0x82 kern_ioctl(c3f2a230,3,80206934,c3ce9d00,c3ce9d00,...) at kern_ioctl+0xa8 ioctl(c3f2a230,f391acf8,c,c,f391ad2c,...) at ioctl+0xc5 syscall(f391ad38) at syscall+0x17d Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (54, FreeBSD ELF32, ioctl), eip =3D 0x4816ee23, esp =3D 0xbfbfe67c, ebp =3D 0xbfbfe698 --- This fully explain why the main loop in em_setup_receive_ring() is never entered, as we always verify `j =3D=3D rxr->next_to_check' (provided that mbuf have been refreshed if some packet were transfered) and return the value on the stack. As of now, beside changing the call-site of em_setup_receive_ring() to ensure it is never re-entered, I'd guess that the patch I sent earlier today, is the only way to ensure that no junk is returned. I'd guess that the driver _is_ able to transmit, if the code was not explicitly calling em_stop() upon em_setup_receive_structures() failure. - Arnaud [0]: I wish that would have been as easy as in Linux, where a WARN() call do all the job automatically, but still, I should not hope for that much unless I am the one implementing it ... yes, free whining, it's 2a.m. ... > =A0- Arnaud > >> The data your netstat -m shows suggests to me that what's happening >> is somehow setup of the receive ring is running more than once maybe?? >> >> You asked at one point how this could go into STABLE, well, because >> not only here at Intel, but at lots of external customers this code has = been >> used and tested thoroughly. >> >> I am not calling into question your problem, but until I understand what= it >> is I cannot "fix" it :) >> >> The thing I am guessing right now is the culprit is the setup code, the >> reason >> is that when I ported to the igb driver I found that it did not work on = our >> newer >> hardware, and so I went back to the older version of setup for igb. Now, >> even >> though I have not seen hardware fail with em, maybe there is some. >> >> To help me give me a complete pciconf -lv, and if its a namebrand system >> tell me that, including all hardware in it. >> >> If you like Olivier I can make a version of em for you that also reverts= the >> setup code the way I did for igb, see if that fixes it for you? >> >> Thanks for your patience, >> >> Jack >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" >> > From owner-freebsd-current@FreeBSD.ORG Thu May 5 06:53:23 2011 Return-Path: Delivered-To: Current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 227131065673 for ; Thu, 5 May 2011 06:53:23 +0000 (UTC) (envelope-from s.seira@cdmon.com) Received: from correo.cdmon.com (correo.cdmon.com [212.36.82.9]) by mx1.freebsd.org (Postfix) with ESMTP id CEFD08FC19 for ; Thu, 5 May 2011 06:53:22 +0000 (UTC) Received: from genocida (localhost.cdmon.com [127.0.0.1]) by correo.cdmon.com (Postfix) with ESMTP id D290E130F3C for ; Thu, 5 May 2011 08:35:13 +0200 (CEST) Received: from antispam (localhost.cdmon.com [127.0.0.1]) by correo.cdmon.com (Postfix) with ESMTP id 84127130EFA for ; Thu, 5 May 2011 08:35:13 +0200 (CEST) Received: from [192.168.0.30] (155.Red-88-2-251.staticIP.rima-tde.net [88.2.251.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by correo.cdmon.com (Postfix) with ESMTP id A25C7130E84 for ; Thu, 5 May 2011 08:35:12 +0200 (CEST) Message-ID: <4DC24524.4090303@cdmon.com> Date: Thu, 05 May 2011 08:35:16 +0200 From: Sergi Seira User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100515 Lightning/1.0b1 Icedove/3.0.4 MIME-Version: 1.0 To: Current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: bsdlabel showing value zero on fsize, bsize and bps/cpg for all partitions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 06:53:23 -0000 Hello, on freebsd version 6 and 7 I was relaying on bsdlabel to get block size : # bsdlabel /dev/mirror/gm4s1 # /dev/mirror/gm4s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 4194304 0 4.2BSD 2048 16384 28528 b: 8388608 4194304 swap c: 293041602 0 unused 0 0 # "raw" part, don't edit d: 2097152 12582912 4.2BSD 2048 16384 28528 e: 52428800 14680064 4.2BSD 2048 16384 28528 f: 225932738 67108864 4.2BSD 2048 16384 28528 but on 8.1 and 8.2 I get zero values : # bsdlabel /dev/mirror/gm6s1 # /dev/mirror/gm6s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 4194304 0 4.2BSD 0 0 0 b: 17186816 4194304 swap c: 1953525105 0 unused 0 0 # "raw" part, don't edit d: 2097152 21381120 4.2BSD 0 0 0 e: 83886080 23478272 4.2BSD 0 0 0 f: 1846160753 107364352 4.2BSD 0 0 0 Has anyone seen this? Is it some step I missed on install? Is there another command to get block size? Thanks for your help, regards, Sergi From owner-freebsd-current@FreeBSD.ORG Thu May 5 06:59:20 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF392106564A for ; Thu, 5 May 2011 06:59:19 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 882018FC08 for ; Thu, 5 May 2011 06:59:19 +0000 (UTC) Received: by vxc34 with SMTP id 34so2680528vxc.13 for ; Wed, 04 May 2011 23:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gcUsFsJFxrH49dGvWtLQ4tLDYXwfnGWEI+Hsly799vg=; b=n80sEXJ8d7+VlEtnMxpehni8is5vYtd6OzaRRXlQRJ8GUvSVoC0JUe7iSuwoFsgVF1 wSfbSKZuY04yL7+fea7wfWbzHQG2gKRQhKzC0rzeIRr9wogq8ZfJS+4gt1HJPRW14wcO cy+LYflWkuddSJmBcyMfI6tEMh+Dfp8Ljyk9Y= 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=h76ST5Zakpe881DkLQayaqOepENx9TejiQL9EZ2bCpouXedm529CmEGhH65qHbGq5Q goBMXH2jXhdjBUnoQtIVsw6vZwk4QHaBserBQx3jmZ0Q0veOuRRUA+2/oylwyZWURDwV mMlcEbFty5fyU4UucVEIiH44VETYQdRfJ4qSA= MIME-Version: 1.0 Received: by 10.52.18.14 with SMTP id s14mr2522267vdd.164.1304578758804; Wed, 04 May 2011 23:59:18 -0700 (PDT) Received: by 10.52.184.169 with HTTP; Wed, 4 May 2011 23:59:18 -0700 (PDT) In-Reply-To: References: <4D94A354.9080903@sentex.net> <4DC07013.9070707@gmx.net> <4DC078BD.9080908@gmx.net> Date: Wed, 4 May 2011 23:59:18 -0700 Message-ID: From: Jack Vogel To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Olivier Smedts , FreeBSD current mailing list Subject: Re: problems with em(4) since update to driver 7.2.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 06:59:20 -0000 OK, but what this does not explain is why I do not see this if its so easily reproduced, what causes the failure case, any idea? As I said, given the code was not feasible for igb anyway I would not be unhappy about returning to the old way of doing things. Jack On Wed, May 4, 2011 at 11:03 PM, Arnaud Lacombe wrote: > Hi, > > On Thu, May 5, 2011 at 1:20 AM, Arnaud Lacombe wrote: > > Hi, > > > > On Wed, May 4, 2011 at 5:38 PM, Jack Vogel wrote: > >> I have had my validation engineer busy all day, we have tried both > >> a 9 kernel as well as 8.2, using the code from HEAD, and we > >> cannot reproduce this problem. > >> > > Actually, it can be trivially reproduced by tainting `error'. As it is > > uninitialized in HEAD, it's value can be _anything_, so let's mark it > > as explicitly invalid. > > > > diff -u ./if_em.c /data/src/freebsd/em-7.2.2/src/if_em.c > > --- ./if_em.c 2011-02-18 01:18:23.000000000 -0500 > > +++ /data/src/freebsd/em-7.2.2/src/if_em.c 2011-05-05 > > 01:12:01.000000000 -0400 > > @@ -3912,7 +3912,7 @@ > > struct adapter *adapter = rxr->adapter; > > struct em_buffer *rxbuf; > > bus_dma_segment_t seg[1]; > > - int i, j, nsegs, error; > > + int i, j, nsegs, error = -1; > > > > The error pointed out in this thread pops up in the next boot. > > > I put a call to kdb_enter() at the beginning of the function, helped > with some textdump I got all the backtrace [0] for all the time > em_setup_receive_ring() is called. All are exactly the same: > > kdb_enter_why(0,c09f6511,f391aaa8,c09be1e2,c09f6511,...) at > kdb_enter_why+0x3b > kdb_enter(c09f6511,0,3810,ffffffff,5dc,...) at kdb_enter+0x19 > em_setup_receive_ring(c3c8d600,c3c8d7a4,c3c96004,310000fa,c3c8d600,...) > at em_setup_receive_ring+0x22 > em_setup_receive_structures(c3c96000,f15f2000,38,8100,3,...) at > em_setup_receive_structures+0x26 > em_init_locked(c3c96000,0,c09f5de5,414,10000,...) at em_init_locked+0x2f2 > em_ioctl(c3c7d000,80206934,c3ce9d00,c07b7a0b,c3f2a230,...) at > em_ioctl+0x1c3 > ifhwioctl(c3f2a230,f391ac34,c07b7a0b,c3f3e3d0,c08df1c0,...) at > ifhwioctl+0x4b8 > ifioctl(c3f3e3d0,80206934,c3ce9d00,c3f2a230,c3f2a230,...) at ifioctl+0x82 > kern_ioctl(c3f2a230,3,80206934,c3ce9d00,c3ce9d00,...) at kern_ioctl+0xa8 > ioctl(c3f2a230,f391acf8,c,c,f391ad2c,...) at ioctl+0xc5 > syscall(f391ad38) at syscall+0x17d > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x4816ee23, esp = > 0xbfbfe67c, ebp = 0xbfbfe698 --- > > This fully explain why the main loop in em_setup_receive_ring() is > never entered, as we always verify `j == rxr->next_to_check' (provided > that mbuf have been refreshed if some packet were transfered) and > return the value on the stack. As of now, beside changing the > call-site of em_setup_receive_ring() to ensure it is never re-entered, > I'd guess that the patch I sent earlier today, is the only way to > ensure that no junk is returned. > > I'd guess that the driver _is_ able to transmit, if the code was not > explicitly calling em_stop() upon em_setup_receive_structures() > failure. > > - Arnaud > > [0]: I wish that would have been as easy as in Linux, where a WARN() > call do all the job automatically, but still, I should not hope for > that much unless I am the one implementing it ... yes, free whining, > it's 2a.m. ... > > > - Arnaud > > > >> The data your netstat -m shows suggests to me that what's happening > >> is somehow setup of the receive ring is running more than once maybe?? > >> > >> You asked at one point how this could go into STABLE, well, because > >> not only here at Intel, but at lots of external customers this code has > been > >> used and tested thoroughly. > >> > >> I am not calling into question your problem, but until I understand what > it > >> is I cannot "fix" it :) > >> > >> The thing I am guessing right now is the culprit is the setup code, the > >> reason > >> is that when I ported to the igb driver I found that it did not work on > our > >> newer > >> hardware, and so I went back to the older version of setup for igb. Now, > >> even > >> though I have not seen hardware fail with em, maybe there is some. > >> > >> To help me give me a complete pciconf -lv, and if its a namebrand system > >> tell me that, including all hardware in it. > >> > >> If you like Olivier I can make a version of em for you that also reverts > the > >> setup code the way I did for igb, see if that fixes it for you? > >> > >> Thanks for your patience, > >> > >> Jack > >> _______________________________________________ > >> freebsd-current@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to " > freebsd-current-unsubscribe@freebsd.org" > >> > > > From owner-freebsd-current@FreeBSD.ORG Thu May 5 08:19:06 2011 Return-Path: Delivered-To: Current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22518106566C for ; Thu, 5 May 2011 08:19:06 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward4.mail.yandex.net (forward4.mail.yandex.net [77.88.46.9]) by mx1.freebsd.org (Postfix) with ESMTP id C3C5E8FC15 for ; Thu, 5 May 2011 08:19:05 +0000 (UTC) Received: from smtp2.mail.yandex.net (smtp2.mail.yandex.net [77.88.46.102]) by forward4.mail.yandex.net (Yandex) with ESMTP id 70A32502D0C; Thu, 5 May 2011 12:05:07 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1304582707; bh=MxhbSpzMYLJuve7oipjvT6oX8UuThPdYBqf42ju/EEc=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=txQdcbp5fUzd3WbyI4RcoXtswcxejJOXGShXJghOE9gvEixLNwGoPq0b12uwJdBKQ XuJIof80lGuNe7S6cjWsUCPItWw3cMg6j6CNiaRY3Xtt05s6aSAw1NOg7DcahibzC5 HM31MeyROxg0xXx67BVQNANpLkNMoVzQ1cmzHWwE= Received: from [127.0.0.1] (ns.kirov.so-cdu.ru [77.72.136.145]) by smtp2.mail.yandex.net (Yandex) with ESMTPSA id 2D08D5D10061; Thu, 5 May 2011 12:05:07 +0400 (MSD) Message-ID: <4DC25A2E.4000508@yandex.ru> Date: Thu, 05 May 2011 12:05:02 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Sergi Seira References: <4DC24524.4090303@cdmon.com> In-Reply-To: <4DC24524.4090303@cdmon.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC726B3FF709279CFD908471A" X-Yandex-Spam: 1 Cc: Current@FreeBSD.org Subject: Re: bsdlabel showing value zero on fsize, bsize and bps/cpg for all partitions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 08:19:06 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC726B3FF709279CFD908471A Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 05.05.2011 10:35, Sergi Seira wrote: > on freebsd version 6 and 7 I was relaying on bsdlabel to get block size= : > Has anyone seen this? > Is it some step I missed on install? > Is there another command to get block size? I think dumpfs(8) is better tool for doing that. --=20 WBR, Andrey V. Elsukov --------------enigC726B3FF709279CFD908471A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJNwloxAAoJEAHF6gQQyKF6yXoH/jVmg+dS6aME02r8xPoeYKZO xf8DHwDiTtdKe9sH5RRKYhDcIBbe/0JBoeDKo8NfgQBlT26i1nspJiKWuCAzUYZN WSNyfd+LClmI5b0EdYFT3Xx+SBirDWk3ogFN/DBDKBTMQ4XMpI9YyvwVmBAKLH+Z X6eXwO8J2s4ix4vYh7oTB+CTdM2K8gdZhVGLBTeY3HSStBligBVYNXWErzwC7JGS G0pSPaBEiAV6OejicjploWLc0kjwXJrHq5bSTXsukC/qWJ/uxsiftGi11QwAEsrf D21cruFCRHL5QV+LVEwE5QRdVMB1wiHdTzx8D3X4DR00Ds2H9oPpEPXSwO06hmg= =uEBx -----END PGP SIGNATURE----- --------------enigC726B3FF709279CFD908471A-- From owner-freebsd-current@FreeBSD.ORG Thu May 5 08:06:26 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E64C106566C for ; Thu, 5 May 2011 08:06:26 +0000 (UTC) (envelope-from dougb@dougbarton.us) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 291318FC1B for ; Thu, 5 May 2011 08:06:25 +0000 (UTC) Received: (qmail 13442 invoked by uid 399); 5 May 2011 07:36:56 -0000 Received: from unknown (HELO 65-241-43-5.globalsuite.net) (dougb@dougbarton.us@65.241.43.5) by mail2.fluidhosting.com with ESMTPAM; 5 May 2011 07:36:56 -0000 X-Originating-IP: 65.241.43.5 X-Sender: dougb@dougbarton.us Message-ID: <4DC25396.1070909@dougbarton.us> Date: Thu, 05 May 2011 00:36:54 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org, Alexander Motin X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 05 May 2011 11:09:31 +0000 Cc: Subject: My problems with stability on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 08:06:26 -0000 This is long, sorry. I wish I could condense things down to just the answer, or even just the question, but here goes. I've used HEAD on my main workstation(s) for many years. It's common for there to be ups and downs, and that's fine. Lately however the problems have been debilitating. First a timeline. Since sometime before January 2008 I've been using a Dell Latitude D620 laptop as my primary system. It has a core 2 duo running at 2.33 G, and 2 G RAM. I 4xboot it with windows xp, freebsd current (amd64), another freebsd (usually 8.N-RELEASE i386) and Ubuntu. On the first and last I don't do a lot of compiling obviously, but even under heavy load on 8.2-RELEASE I'm not seeing problems, so the problems I _am_ seeing are not hardware related. I keep my system very close to stock. My kernel config is GENERIC minus devices I don't have, and plus the following: options EXT2FS options IEEE80211_DEBUG # enable debug msgs options VESA device atapicam device sound device snd_hda device snp I was building with clang for a while, but when the problems started I went back to gcc. I still have INVARIANTS on but I disabled WITNESS because with all the known+unfixed LORs it's kind of pointless. Nothing interesting in make/src.conf either, the latter is just a list of stuff not to build, KERNCONF, and MODULES_OVERRIDE. Starting around December 2009 I started having problems under load with -current. Often I reported them, sometimes problems were found, sometimes not. In the course of trying to debug those problems I disabled throttling, which helped. Switching to SCHED_4BSD also helped quite a bit with interactivity under load, although it was still worse than on 8.x. In October of 2010 I was lucky enough to receive a donation of a Dell Optiplex desktop that I started using as my primary workstation. Around that same time there was some work being done in the scheduler(s) and various related systems, and my desktop (which had a slightly faster core 2 duo and 4 G RAM) was running great. I assumed that the problems were solved. Then 2 months ago I packed up the desktop system and pulled out the laptop again. I updated to the latest -current on the laptop, and all heck broke loose. I couldn't do anything on my laptop that created even a mediocre load without it crashing. Trying to do something like a buildworld (even without -j) would cause the system to absolutely crawl. I'd get tons of the dreaded "calcru" messages about time going backwards, and the system clock would lose literally minutes of wall clock time. At one point when I could keep it up long enough to build the world without crashing it had lost 40 minutes of wall clock time when it finished. I think that specific problem happened sometime between March 15 and r220282. In trying to find that problem, I uncovered another, deeper problem with the "one-shot timers" from r212541. In order to make my binary search easier for the problem described above I was using a -current snapshot CD from August 2010 that I had laying around. I could easily build world with -j2, run X, do normal desktop stuff (firefox, thunderbird, pidgin, etc.) all at the same time. When I got closer to the more recent -current, it would crash as soon as I put a load on it. I eventually bifurcated down to that exact commit. I've been running on 212540 for over a week now without any problems, including lots of port builds with FORCE_MAKE_JOBS, etc. Alexander suggested some knobs to twist for the timers, and I'll be glad to do that once he gets back to me with more concrete suggestions now that he knows more about my specific problems. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Thu May 5 11:23:02 2011 Return-Path: Delivered-To: Current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D62D0106564A for ; Thu, 5 May 2011 11:23:02 +0000 (UTC) (envelope-from Daan@vehosting.nl) Received: from VM01.VEHosting.nl (VM016.VEHosting.nl [IPv6:2001:1af8:2100:b020::140]) by mx1.freebsd.org (Postfix) with ESMTP id 0F3688FC19 for ; Thu, 5 May 2011 11:23:01 +0000 (UTC) Received: from [192.168.72.11] (124-54.bbned.dsl.internl.net [92.254.54.124]) (authenticated bits=0) by VM01.VEHosting.nl (8.14.3/8.13.8) with ESMTP id p45BN2JC000744; Thu, 5 May 2011 13:23:02 +0200 (CEST) (envelope-from Daan@vehosting.nl) From: Daan Vreeken Organization: http://VEHosting.nl/ To: Jack Vogel Date: Thu, 5 May 2011 13:22:59 +0200 User-Agent: KMail/1.9.10 References: <201105041734.50738.Daan@vehosting.nl> <201105050127.26358.Daan@vehosting.nl> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201105051322.59654.Daan@vehosting.nl> x-ve-auth-version: mi-1.1.5 2011-02-07 - Copyright (c) 2008, 2011 - Daan Vreeken - VEHosting x-ve-auth: authenticated as 'pa4dan' on VM01.VEHosting.nl Cc: Current@freebsd.org Subject: Re: Interrupt storm with MSI in combination with em1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 11:23:02 -0000 Hi Jack, On Thursday 05 May 2011 02:25:39 Jack Vogel wrote: > OK, but the reason you see the multiple cases of irq 16 is that's the > bridge, > once you are using MSIX, as vmstat shows, its using other vectors. > > Can you capture the messages file with the actual storm happening? I'll do that as soon as I witness another storm. Right now the system has been up over half a day (with MSI/MSIX enabled) and everything seems to be working as it should. > I noticed some complaints about checksums in the dmesg, have you > checked on BIOS upgrades or something like that on your motherboard? Not yet. I'll reboot the machine later today when I have physical access to it to check the BIOS version. I'll keep you informed as soon as I get another storm going. > On Wed, May 4, 2011 at 4:27 PM, Daan Vreeken wrote: > > On Thursday 05 May 2011 00:15:43 you wrote: > > > This all looks completely kosher, what IRQ is the storm on?? > > > > IRQ 16. Further down this email there is a list of devices that share the > > IRQ > > according to 'dmesg'. > > > > > On Wed, May 4, 2011 at 3:04 PM, Daan Vreeken wrote: > > > > Hi, > > > > > > > > On Wednesday 04 May 2011 20:47:32 Jack Vogel wrote: > > > > > Will you please set it back to a default and then boot and capture > > the > > > > > message for me? > > > > > > > > No problem. Here's the output with MSI/MSIX enabled : > > > > > > > > http://vehosting.nl/pub_diffs/dmesg_plantje2_with_msix_2011_05_04.txt > > > > > > > > I've also added the output of "vmstat -i" a couple of minutes after a > > > > reboot > > > > with MSI enabled : > > > > http://vehosting.nl/pub_diffs/vmstat_i_2011_05_04.txt > > > > > > > > Note that in the above "vmstat -i" dump the interrupt storm hasn't > > > > started yet. For some reason the storm doesn't always start directly > > > > at boot. I haven't been able (yet) to pinpoint what's triggering it > > > > to start. > > > > > > > > > On Wed, May 4, 2011 at 11:19 AM, Daan Vreeken > > > > wrote: > > > > > > Hi Jack, > > > > > > > > > > > > Wednesday 04 May 2011 19:46:05 Jack Vogel wrote: > > > > > > > Who makes your motherboard? The problem you are having is that > > MSIX > > > > > > > AND MSI are both failing as em0 comes up, so it falls back to > > Legacy > > > > > > > interrupt mode, > > > > > > > and must be having some issue with sharing the line, causing > > > > > > > the storm. > > > > > > > > > > > > The motherboard is an Asus "P7H55-M". > > > > > > > > > > > > Sorry, I should have mentioned that the dmesg output is from > > booting > > > > > > with : > > > > > > > > hw.pci.enable_msix="0" > > > > > > > > hw.pci.enable_msi="0" > > > > > > > > > > > > .. in "loader.conf". > > > > > > > > > > > > With those lines in "loader.conf", MSI and MSIX is disabled, both > > > > > > cards work > > > > > > like they should and there is no interrupt storm. > > > > > > > > > > > > With MSI/MSIX enabled, both cards work like they should and I see > > the > > > > > > counters > > > > > > of the MSI interrupts increase (in small amounts, like they > > should), > > > > > > but at boot-time an interrupt storm starts on 'legacy' IRQ 16. > > > > > > > > > > > > Because the only difference between disabling/enabling MSI/MSIX > > seems > > > > > > to be in > > > > > > the way em0/em1 are used, and because 'em1' shares IRQ 16 > > > > > > according to the dmesg, I'm suspecting 'em1' is causing the > > > > > > storm. (But please correct me if I'm wrong :) > > > > > > > > > > > > What can I do to help track this problem down? > > > > > > > > > > > > > > According to "dmesg" the following devices share IRQ 16 : > > > > > > > > pcib1: irq 16 at device 1.0 on > > pci0 > > > > > > > > em0: port > > > > > > > > 0xcc00-0xcc1f mem > > 0xf7de0000-0xf7dfffff,0xf7d00000-0xf7d7ffff,0xf7ddc000-0xf7ddffff > > > > > > > > irq 16 at device 0.0 on pci1 > > > > > > > > vgapci0: port 0xbc00-0xbc07 > > > > > > > > mem 0xf7800000-0xf7bfffff,0xe0000000-0xefffffff irq > > 16 > > > > > > > > at device 2.0 on > > > > > > > > pci0 > > > > > > > > ehci0: mem > > > > > > > > 0xf7cfa000-0xf7cfa3ff > > > > > > > > irq 16 at device 26.0 on pci0 > > > > > > > > em1: port > > > > > > > > 0xec00-0xec1f mem > > 0xf7fe0000-0xf7ffffff,0xf7f00000-0xf7f7ffff,0xf7fdc000-0xf7fdffff > > > > > > > > irq 16 at device 0.0 on pci4 > > > > > > > > pcib4: irq 16 at device 28.5 on > > pci0 > > > > > > > > During a storm "vmstat -i" shows a rate of about 220.000 > > > > > > > > interrupts/sec. > > > > > > > > MSI > > > > > > > > interrupt delivery to both 'em0' and 'em1' seems to work > > > > > > > > correctly during > > > > > > > > a storm, as I see their counters increase normally in the > > "vmstat > > > > > > > > -i" output. > > > > > > > > As only 'em0' and 'em1' seem to be using MSI interrupts, my > > guess > > > > > > > > is that the > > > > > > > > e1000 driver is causing this problem. Could it be that the > > driver > > > > > > > > forgets to > > > > > > > > clear/mask legacy interrupts when attaching the MSI > > > > > > > > interrupts perhaps? > > > > > > > > > > > > > > > > Any tips on how to debug and/or fix this? > > > > > > > > > > > > > > > > > > > > > > > > The full output of "dmesg" can be found here : > > > > > > > > > > > > > > > > http://vehosting.nl/pub_diffs/dmesg_plantje2_2011_05_04.txt > > > > > > > > > > > > > > > > And the full output of "pciconf -lv" is here : > > > > > > > > http://vehosting.nl/pub_diffs/pciconf_plantje2_2011_05_04.txt > > > > Thanks, > > -- > > Daan Vreeken > > VEHosting > > http://VEHosting.nl > > tel: +31-(0)40-7113050 / +31-(0)6-46210825 > > KvK nr: 17174380 Regards, -- Daan Vreeken VEHosting http://VEHosting.nl tel: +31-(0)40-7113050 / +31-(0)6-46210825 KvK nr: 17174380 From owner-freebsd-current@FreeBSD.ORG Thu May 5 12:18:53 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAEEE106566C for ; Thu, 5 May 2011 12:18:52 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.212.176]) by mx1.freebsd.org (Postfix) with ESMTP id 928E18FC18 for ; Thu, 5 May 2011 12:18:52 +0000 (UTC) Received: by pxi11 with SMTP id 11so1623983pxi.7 for ; Thu, 05 May 2011 05:18:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.35.228 with SMTP id l4mr3286889pbj.5.1304597931815; Thu, 05 May 2011 05:18:51 -0700 (PDT) Received: by 10.68.40.4 with HTTP; Thu, 5 May 2011 05:18:51 -0700 (PDT) In-Reply-To: References: <4D94A354.9080903@sentex.net> <4DC07013.9070707@gmx.net> <4DC078BD.9080908@gmx.net> Date: Thu, 5 May 2011 14:18:51 +0200 Message-ID: From: Olivier Smedts To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Jack Vogel , FreeBSD current mailing list Subject: Re: problems with em(4) since update to driver 7.2.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 12:18:53 -0000 Hello, 2011/5/4 Arnaud Lacombe : > Hi, > > On Wed, May 4, 2011 at 3:58 AM, Olivier Smedts wrote: >> em0: Using an MSI interrupt >> em0: Ethernet address: d4:85:64:b2:aa:f5 >> em0: Could not setup receive structures >> em0: Could not setup receive structures >> >> What can we do to help you debug this ? >> > At some point in time, in late February, I had the same issue on a > 6-interface machine. I tracked this down to the fact that the main > loop in em_setup_receive_ring() was not being entered. This resulted > in junk being returned as `error' =A0is not explicitly initialized. At > the time, the following patch worked for me. Without it the driver was > unable to initialize with RX/TX ring's size of 512. With it, ring's > size of 1024 initialized fine. > > diff --git a/sys/dev/e1000/if_em.c b/sys/dev/e1000/if_em.c > index fb6ed67..f02059a 100644 > --- a/sys/dev/e1000/if_em.c > +++ b/sys/dev/e1000/if_em.c > @@ -3901,7 +3901,7 @@ em_setup_receive_ring(struct rx_ring *rxr) > =A0 =A0 =A0 =A0struct =A0adapter =A0 =A0 =A0 =A0 *adapter =3D rxr->adapte= r; > =A0 =A0 =A0 =A0struct em_buffer =A0 =A0 =A0 =A0*rxbuf; > =A0 =A0 =A0 =A0bus_dma_segment_t =A0 =A0 =A0 seg[1]; > - =A0 =A0 =A0 int =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 i, j, nsegs, er= ror; > + =A0 =A0 =A0 int =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 i, j, nsegs, er= ror =3D 0; This patch made the trick for me. I'll post what Jack asked for in the following mail. > I did not dig much more at the time, but I was definitively seeing an > odd behavior. Anyhow, I am no longer able to reproduce this with > 7.2.3, so cannot dig in more details. > > Btw, I wish you all luck, it took me nearly two full months to > convince Jack (and other FreeBSD devs) that there was a bug in the > mbuf refresh code. > > =A0- Arnaud > --=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-current@FreeBSD.ORG Thu May 5 12:27:28 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0056E106564A for ; Thu, 5 May 2011 12:27:28 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id C80428FC0C for ; Thu, 5 May 2011 12:27:27 +0000 (UTC) Received: by pvg11 with SMTP id 11so1234456pvg.13 for ; Thu, 05 May 2011 05:27:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.30.105 with SMTP id r9mr483056pbh.139.1304598447252; Thu, 05 May 2011 05:27:27 -0700 (PDT) Received: by 10.68.40.4 with HTTP; Thu, 5 May 2011 05:27:27 -0700 (PDT) In-Reply-To: References: <4D94A354.9080903@sentex.net> <4DC07013.9070707@gmx.net> <4DC078BD.9080908@gmx.net> Date: Thu, 5 May 2011 14:27:27 +0200 Message-ID: From: Olivier Smedts To: FreeBSD current mailing list Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Jack Vogel Subject: Re: problems with em(4) since update to driver 7.2.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 12:27:28 -0000 Hello, (sorry for dual posting) 2011/5/4 Jack Vogel : > I have had my validation engineer busy all day, we have tried both > a 9 kernel as well as 8.2,=A0 using the code from HEAD, and we > cannot reproduce this problem. > > The data your netstat -m shows suggests to me that what's happening > is somehow setup of the receive ring is running more than once maybe?? > > You asked at one point how this could go into STABLE, well, because > not only here at Intel, but at lots of external customers this code has b= een > used and tested thoroughly. > > I am not calling into question your problem, but until I understand what = it > is I cannot "fix" it :) > > The thing I am guessing right now is the culprit is the setup code, the > reason > is that when I ported to the igb driver I found that it did not work on o= ur > newer > hardware, and so I went back to the older version of setup for igb. Now, > even > though I have not seen hardware fail with em, maybe there is some. > > To help me give me a complete pciconf -lv, and if its a namebrand system > tell me that, including all hardware in it. The computer is a HP Compaq 8100 Elite Convertible Minitower PC. Here is what I have with the new driver and Arnaud Lacombe's patch. %uname -a FreeBSD zozo.afpicl.lan 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r219752:221420: Wed May 4 11:16:37 CEST 2011 root@zozo.afpicl.lan:/usr/obj/usr/src/sys/CORE amd64 %pciconf -lv hostb0@pci0:0:0:0: class=3D0x060000 card=3D0x304b103c chip=3D0xd131808= 6 rev=3D0x11 hdr=3D0x00 vendor =3D 'Intel Corporation' class =3D bridge subclass =3D HOST-PCI pcib1@pci0:0:3:0: class=3D0x060400 card=3D0x304b103c chip=3D0xd138808= 6 rev=3D0x11 hdr=3D0x01 vendor =3D 'Intel Corporation' class =3D bridge subclass =3D PCI-PCI none0@pci0:0:8:0: class=3D0x088000 card=3D0x004b003c chip=3D0xd155808= 6 rev=3D0x11 hdr=3D0x00 vendor =3D 'Intel Corporation' class =3D base peripheral none1@pci0:0:8:1: class=3D0x088000 card=3D0x004b003c chip=3D0xd156808= 6 rev=3D0x11 hdr=3D0x00 vendor =3D 'Intel Corporation' class =3D base peripheral none2@pci0:0:8:2: class=3D0x088000 card=3D0x004b003c chip=3D0xd157808= 6 rev=3D0x11 hdr=3D0x00 vendor =3D 'Intel Corporation' class =3D base peripheral none3@pci0:0:8:3: class=3D0x088000 card=3D0x004b003c chip=3D0xd158808= 6 rev=3D0x11 hdr=3D0x00 vendor =3D 'Intel Corporation' class =3D base peripheral none4@pci0:0:16:0: class=3D0x088000 card=3D0x004b003c chip=3D0xd150808= 6 rev=3D0x11 hdr=3D0x00 vendor =3D 'Intel Corporation' class =3D base peripheral none5@pci0:0:16:1: class=3D0x088000 card=3D0x004b003c chip=3D0xd151808= 6 rev=3D0x11 hdr=3D0x00 vendor =3D 'Intel Corporation' class =3D base peripheral none6@pci0:0:22:0: class=3D0x078000 card=3D0x304b103c chip=3D0x3b64808= 6 rev=3D0x06 hdr=3D0x00 vendor =3D 'Intel Corporation' class =3D simple comms none7@pci0:0:22:3: class=3D0x070002 card=3D0x304b103c chip=3D0x3b67808= 6 rev=3D0x06 hdr=3D0x00 vendor =3D 'Intel Corporation' class =3D simple comms subclass =3D UART em0@pci0:0:25:0: class=3D0x020000 card=3D0x304b103c chip=3D0x10ef808= 6 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' class =3D network subclass =3D ethernet ehci0@pci0:0:26:0: class=3D0x0c0320 card=3D0x304b103c chip=3D0x3b3c808= 6 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' class =3D serial bus subclass =3D USB hdac1@pci0:0:27:0: class=3D0x040300 card=3D0x304b103c chip=3D0x3b56808= 6 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' class =3D multimedia subclass =3D HDA pcib2@pci0:0:28:0: class=3D0x060400 card=3D0x304b103c chip=3D0x3b42808= 6 rev=3D0x05 hdr=3D0x01 vendor =3D 'Intel Corporation' class =3D bridge subclass =3D PCI-PCI pcib3@pci0:0:28:4: class=3D0x060400 card=3D0x304b103c chip=3D0x3b4a808= 6 rev=3D0x05 hdr=3D0x01 vendor =3D 'Intel Corporation' class =3D bridge subclass =3D PCI-PCI pcib4@pci0:0:28:6: class=3D0x060400 card=3D0x304b103c chip=3D0x3b4e808= 6 rev=3D0x05 hdr=3D0x01 vendor =3D 'Intel Corporation' class =3D bridge subclass =3D PCI-PCI ehci1@pci0:0:29:0: class=3D0x0c0320 card=3D0x304b103c chip=3D0x3b34808= 6 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' class =3D serial bus subclass =3D USB pcib5@pci0:0:30:0: class=3D0x060401 card=3D0x304b103c chip=3D0x244e808= 6 rev=3D0xa5 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '82801 Family (ICH2/3/4/5/6/7/8/9,63xxESB) Hub Interface to PCI Bridge' class =3D bridge subclass =3D PCI-PCI isab0@pci0:0:31:0: class=3D0x060100 card=3D0x304b103c chip=3D0x3b0a808= 6 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' class =3D bridge subclass =3D PCI-ISA ahci0@pci0:0:31:2: class=3D0x010601 card=3D0x304b103c chip=3D0x3b22808= 6 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'IBEX AHCI Controller(6Port) (Intel Q57 Express)' class =3D mass storage subclass =3D SATA vgapci0@pci0:1:0:0: class=3D0x030000 card=3D0x10021002 chip=3D0x9498100= 2 rev=3D0x00 hdr=3D0x00 vendor =3D 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device =3D 'ATI Radeon HD 4650 (RV730)' class =3D display subclass =3D VGA hdac0@pci0:1:0:1: class=3D0x040300 card=3D0xaa381002 chip=3D0xaa38100= 2 rev=3D0x00 hdr=3D0x00 vendor =3D 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' class =3D multimedia subclass =3D HDA %ifconfig -a lo0: flags=3D8049 metric 0 mtu 16384 options=3D3 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 nd6 options=3D21 vboxnet0: flags=3D8802 metric 0 mtu 1500 ether 0a:00:27:00:00:00 em0: flags=3D8843 metric 0 mtu 1500 options=3D219b ether d4:85:64:b2:aa:f5 inet 172.28.4.104 netmask 0xffff0000 broadcast 172.28.255.255 inet6 fe80::d685:64ff:feb2:aaf5%em0 prefixlen 64 scopeid 0x1 nd6 options=3D29 media: Ethernet autoselect (1000baseT ) status: active %netstat -m 1072/3293/4365 mbufs in use (current/cache/total) 1023/2035/3058/25600 mbuf clusters in use (current/cache/total/max) 1023/1793 mbuf+clusters out of packet secondary zone in use (current/cache) 0/311/311/12800 4k (page size) jumbo clusters in use (current/cache/total/m= ax) 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) 2314K/6137K/8451K 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 > > If you like Olivier I can make a version of em for you that also reverts = the > setup code the way I did for igb, see if that fixes it for you? We can try that if the result will give you a better idea of what's going o= n. > > Thanks for your patience, > > Jack > Thanks for your time --=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-current@FreeBSD.ORG Thu May 5 13:23:40 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88146106566B; Thu, 5 May 2011 13:23:40 +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 2B9688FC0C; Thu, 5 May 2011 13:23:39 +0000 (UTC) Received: by qyk35 with SMTP id 35so3924339qyk.13 for ; Thu, 05 May 2011 06:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=w0Bhdxl0ARgI/Rl5bhfLOPCZQF2xtTvdtJqISoIv8IY=; b=l3SASSjL7YldBc17eXJF2m+0QkzUX9p5dAw3wBEhc6yoj+YRWCXhjIJGklNq62ERaO c4U8N8bQrGAwBRiI7TsTAmjcmrfemkkCokaI38iemQwRShvDr21EJd+GIFR7ofO2eo9D Ht/Q7PhGDMGj83cm1eYsvmwB+2f8MwntCiBKc= 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=FLKtEO55zi4Q8+X2fOnCDuGnjMUx/2rfTZY3e6LghypQygMu0B5eYXIqlMoOPNpGjA B381tu3ZMWOT5MpLlnnv168g1aDvmkqNHOXdNcft5DbM15KJu0rabVlNDwthuQpqAB3N lpOVL+Ehyf4oI49bYhUWgEKUe45MfH8WBM4Rw= MIME-Version: 1.0 Received: by 10.224.136.5 with SMTP id p5mr2282873qat.127.1304601819290; Thu, 05 May 2011 06:23:39 -0700 (PDT) Received: by 10.229.95.19 with HTTP; Thu, 5 May 2011 06:23:39 -0700 (PDT) In-Reply-To: <4DAEAE1B.70207@FreeBSD.org> References: <4DAEAE1B.70207@FreeBSD.org> Date: Thu, 5 May 2011 17:23:39 +0400 Message-ID: From: Sergey Kandaurov To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD-Current Subject: Re: Switch from legacy ata(4) to CAM-based ATA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 13:23:40 -0000 2011/4/20 Alexander Motin : > Hi. > > With 9.0 release approaching quickly, I believe it the best time now to > manage migration from legacy ata(4) ATA to the new CAM-based one. New > ATA code present in the tree for more then a year now, used by many > people and proved it's superior functionality and reliability. The only > major issue with it now is the migration process. Sooner or later we > have to pass it, but due to major UI and API changes we can't do it > after 9.0 release. So I propose to do it the next Sunday (April 24) to > have as much time for troubleshooting as possible. > > I have prepared the following patch to do it: > http://people.freebsd.org/~mav/ata_switch.patch > > I haven't added geom_raid to the kernel configurations because we have > no other GEOM classes there. But tell me if you thing I should. > > If somebody has any problems with new ATA stack, please repeat your > tests with latest HEAD code and contact me if problem is still there. > Next three weeks before BSDCan I am going to dedicate to fixing possibly > remaining issues. > XENHVM uses it's own naming scheme and can name disks as daN or adN, depending on virtual block device id. atapci0/ata0/ata1 devices still present there (such as in Bruce Cran's dmesg), but no any disks attached from it: instead, all of them hung from device/vbd/N. [In a non-XENHVM mode they are attached from ataN channels, as usual.] /* * Translate Linux major/minor to an appropriate name and unit * number. For HVM guests, this allows us to use the same drive names * with blkfront as the emulated drives, easing transition slightly. */ xenbusb_front0: on xenstore0 xenbusb_back0: on xenstore0 xctrl0: on xenstore0 xbd0: 17000MB at device/vbd/768 on xenbusb_front0 xbd0: attaching as ad0 GEOM: ad0s1: geometry does not match label (16h,63s != 255h,63s). xbd1: 3812MB at device/vbd/2048 on xenbusb_front0 xbd1: attaching as da0 xbd2: 114439MB at device/vbd/2064 on xenbusb_front0 xbd2: attaching as da1 Probably, /sys/dev/xen/blkfront/blkfront.c needs updating by s/"ad"/"ada"/g; or such. I believe, xen generates sequential numbers starting from zero (or rather such numbers that can be converted to sequential numbers), similar to what ATA_CAM does. -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Thu May 5 13:24:32 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B5941065673 for ; Thu, 5 May 2011 13:24:32 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id B9C938FC08 for ; Thu, 5 May 2011 13:24:31 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for current@FreeBSD.org with esmtp (envelope-from ) id <1QHyGT-0002Iw-8j>; Thu, 05 May 2011 15:06:45 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) for current@FreeBSD.org with esmtpsa (envelope-from ) id <1QHyGT-0002tp-6u>; Thu, 05 May 2011 15:06:45 +0200 Message-ID: <4DC2A0E5.5040602@zedat.fu-berlin.de> Date: Thu, 05 May 2011 15:06:45 +0200 From: "O. Hartmann" Organization: Freie =?ISO-8859-1?Q?Universit=E4t_Berlin?= User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 References: <201105040107.p4417NTR048534@pozo.com> <4DC0F46C.3020806@FreeBSD.org> <201105041344.p44DiOId032272@pozo.com> <4DC160B9.5060004@FreeBSD.org> In-Reply-To: <4DC160B9.5060004@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: current@FreeBSD.org Subject: Re: Clang error make buildworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 13:24:32 -0000 On 05/04/11 16:20, Dimitry Andric wrote: > On 2011-05-04 15:44, Manfred Antar wrote: > ... >> src.conf: >> >> WITHOUT_DYNAMICROOT=yes >> WITH_IDEA=yes >> .if !defined(CC) || ${CC} == "cc" >> CC=clang >> .endif >> .if !defined(CXX) || ${CXX} == "c++" >> CXX=clang++ >> .endif >> #Don't die on warnings >> NO_WERROR= >> WERROR= > > Aha. Please move the clang-related stuff to make.conf instead, e.g. > this fragment: > > .if !defined(CC) || ${CC} == "cc" > CC=clang > .endif > .if !defined(CXX) || ${CXX} == "c++" > CXX=clang++ > .endif > #Don't die on warnings > NO_WERROR= > WERROR= > On a notebook (DELL Latitude E6510) I tried compiling world with CLANG. So far, so good. It worked. But after rebooting I got a strange misbehaviour of the xdm login window (black/white instead of coloured), but this was only some superficial symptome. The whole system seems to be corrupted. Hitting tab key results like hitting exit in the console. The gcc 4.2.1 system compiler isn't capable of producing binaries, see message below. At this very moment, the box isn't usable anymore, I can't even compile a world with cc (see error below, that was generated by trying to compile a kernel and I'm really confused why cc is used instead of clang). Well, the boxes I reported errors from prior to this are desktop systems with nVidia (Fermi based) graphics boards using a driver BLOB 270.XX.XX which is also used by the notebook. The desktop boxes uses C2D based intel chips, the notebook uses a Core-i5 based chip. All systems got compiled with option CPUTYPE?=native I guess the first compilation with CLANG "destroyed" the base' system compiler, at this moment I'm incapable of switching back. Floating like a dead man in the water. Any suggestions? Regards and thanks in advance, Oliver --- awk -f /usr/src/sys/tools/usbdevs2h.awk /usr/src/sys/dev/usb/usbdevs -h awk -f /usr/src/sys/tools/usbdevs2h.awk /usr/src/sys/dev/usb/usbdevs -d rpcgen -hM /usr/src/sys/kgssapi/gssd.x | grep -v pthread.h > gssd.h cc1: internal compiler error: Bus error: 10 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. rpcgen -c /usr/src/sys/kgssapi/gssd.x -o gssd_xdr.c cc1: internal compiler error: Bus error: 10 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop in /usr/obj/usr/src/sys/MUNIN. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. From owner-freebsd-current@FreeBSD.ORG Thu May 5 13:46:23 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96BE2106564A for ; Thu, 5 May 2011 13:46:23 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 741E08FC12 for ; Thu, 5 May 2011 13:46:23 +0000 (UTC) Received: by pvg11 with SMTP id 11so1273730pvg.13 for ; Thu, 05 May 2011 06:46:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.43.66 with SMTP id u2mr3343364pbl.340.1304603182164; Thu, 05 May 2011 06:46:22 -0700 (PDT) Received: by 10.68.40.4 with HTTP; Thu, 5 May 2011 06:46:21 -0700 (PDT) In-Reply-To: <4DC2A0E5.5040602@zedat.fu-berlin.de> References: <201105040107.p4417NTR048534@pozo.com> <4DC0F46C.3020806@FreeBSD.org> <201105041344.p44DiOId032272@pozo.com> <4DC160B9.5060004@FreeBSD.org> <4DC2A0E5.5040602@zedat.fu-berlin.de> Date: Thu, 5 May 2011 15:46:21 +0200 Message-ID: From: Olivier Smedts To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: Clang error make buildworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 13:46:23 -0000 2011/5/5 O. Hartmann : > On 05/04/11 16:20, Dimitry Andric wrote: >> >> On 2011-05-04 15:44, Manfred Antar wrote: >> ... >>> >>> src.conf: >>> >>> WITHOUT_DYNAMICROOT=3Dyes >>> WITH_IDEA=3Dyes >>> .if !defined(CC) || ${CC} =3D=3D "cc" >>> CC=3Dclang >>> .endif >>> .if !defined(CXX) || ${CXX} =3D=3D "c++" >>> CXX=3Dclang++ >>> .endif >>> #Don't die on warnings >>> NO_WERROR=3D >>> WERROR=3D >> >> Aha. Please move the clang-related stuff to make.conf instead, e.g. >> this fragment: >> >> .if !defined(CC) || ${CC} =3D=3D "cc" >> CC=3Dclang >> .endif >> .if !defined(CXX) || ${CXX} =3D=3D "c++" >> CXX=3Dclang++ >> .endif >> #Don't die on warnings >> NO_WERROR=3D >> WERROR=3D >> > > > On a notebook (DELL Latitude E6510) I tried compiling world with CLANG. S= o > far, so good. It worked. But after rebooting I got a strange misbehaviour= of > the xdm login window (black/white instead of coloured), but this was only > some superficial symptome. The whole system seems to be corrupted. Hittin= g > tab key results like hitting exit in the console. The gcc 4.2.1 system > compiler isn't capable of producing binaries, see message below. At this > very moment, the box isn't usable anymore, I can't even compile a world w= ith > cc (see error below, that was generated by trying to compile a kernel and > I'm really confused why cc is used instead of clang). > > Well, the boxes I reported errors from prior to this are desktop systems > with nVidia (Fermi based) graphics boards using a driver BLOB 270.XX.XX > which is also used by the notebook. > > The desktop boxes uses C2D based intel chips, the notebook uses a Core-i5 > based chip. All systems got compiled with option > > CPUTYPE?=3Dnative Can you try without CPUTYPE "native", or with another value ? "native" is not a supported value in /usr/share/mk/bsd.cpu.mk With gcc I used : CPUTYPE?=3Dcore2 CFLAGS=3D-O2 -pipe -march=3Dnative NO_CPU_CFLAGS=3Dyes COPTFLAGS=3D-O2 -pipe -march=3Dnative NO_CPU_COPTFLAGS=3Dyes So that /usr/share/mk/bsd.cpu.mk could set the right variables and I could set my own "-march" value in CFLAGS for gcc. But now for HEAD (which has a newer gcc and clang) I use : CPUTYPE?=3Dcore2 CFLAGS=3D-O2 -pipe -march=3Dcore2 NO_CPU_CFLAGS=3Dyes COPTFLAGS=3D-O2 -pipe -march=3Dcore2 NO_CPU_COPTFLAGS=3Dyes Because with clang, -march=3Dnative often breaks buildworld, while -march=3Dcore2 is ok. First, try to see if you buildworld is still broken with a different (or empty!) make.conf. > I guess the first compilation with CLANG "destroyed" the base' system > compiler, at this moment I'm incapable of switching back. Floating like a > dead man in the water. > > > Any suggestions? > > Regards and thanks in advance, > Oliver > --- > awk -f /usr/src/sys/tools/usbdevs2h.awk /usr/src/sys/dev/usb/usbdevs -h > awk -f /usr/src/sys/tools/usbdevs2h.awk /usr/src/sys/dev/usb/usbdevs -d > rpcgen -hM /usr/src/sys/kgssapi/gssd.x | grep -v pthread.h > gssd.h > cc1: internal compiler error: Bus error: 10 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > rpcgen -c /usr/src/sys/kgssapi/gssd.x -o gssd_xdr.c > cc1: internal compiler error: Bus error: 10 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/MUNIN. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > _______________________________________________ > 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-current@FreeBSD.ORG Thu May 5 13:50:48 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DC061065670 for ; Thu, 5 May 2011 13:50:48 +0000 (UTC) (envelope-from damjan.marion@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 158A78FC18 for ; Thu, 5 May 2011 13:50:47 +0000 (UTC) Received: by eyg7 with SMTP id 7so879942eyg.13 for ; Thu, 05 May 2011 06:50:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=68zogYXTxKBGkZMoOL1f/tF+adg2xnBzX0t1n2l5xLI=; b=eloznae31EcH3cc+eM/uwaBq1kis7irBRrQMeM2KNUoMhpRQLKcO5uX9SLkhBL9Voi FVwhYLRS1z9kaNbEUnLHhTJikLsypEF68fSmVLEbp70xdpn5xMZ/+zwUZoiE/aoWcnrB 1bWfnzvli8mjCt8oLGB32OSd6SgIHo8mu2ZDs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=QOqsVCc21FHx3E1ee1cx3JFdIJ7MxljQVSqW754Os64QZA8+i5hF5F2OM6czCH4XxW stUMxK/WLxvkZ1zgotWRUe5TWqQRKHTbsWkq740VycdbSoLFuYIQmW+pEWOKQ9y3zboN 2pGSExFsTf/jnMEsTL7nSoDdN6St2vnnUBuyE= Received: by 10.14.124.133 with SMTP id x5mr1179585eeh.41.1304601665482; Thu, 05 May 2011 06:21:05 -0700 (PDT) Received: from [192.168.123.4] (cpe-109-60-66-194.zg3.cable.xnet.hr [109.60.66.194]) by mx.google.com with ESMTPS id x5sm511043eea.0.2011.05.05.06.21.04 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 May 2011 06:21:04 -0700 (PDT) From: Damjan Marion Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 5 May 2011 15:21:04 +0200 Message-Id: <5BEF0D0F-3717-42CE-ADF7-8876558004CA@gmail.com> To: freebsd-current@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: atkbdc broken on current ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 13:50:48 -0000 Hi, I have issue with old HP DL380G3 server. When I use ILO virtual console = to manage server. Seems that 9-CURRENT fails to detect atkbdc. When I boot 8.2-RELEASE it works well. 8.2 dmesg shows: atkbdc0: port 0x60,0x64 irq 1 on acpi0 9.0: atkbdc0: failed to probe at port 0x60 on = isa0 Is this a known issue? Should I enable some additional outputs, like KBDIO_DEBUG? Thanks, Damjan= From owner-freebsd-current@FreeBSD.ORG Thu May 5 13:55:00 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24BE31065670 for ; Thu, 5 May 2011 13:55:00 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [46.28.110.116]) by mx1.freebsd.org (Postfix) with ESMTP id D398E8FC14 for ; Thu, 5 May 2011 13:54:59 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id BD4587F3A8C; Thu, 5 May 2011 15:54:58 +0200 (CEST) Date: Thu, 5 May 2011 15:54:58 +0200 From: Roman Divacky To: Olivier Smedts Message-ID: <20110505135458.GA79622@freebsd.org> References: <201105040107.p4417NTR048534@pozo.com> <4DC0F46C.3020806@FreeBSD.org> <201105041344.p44DiOId032272@pozo.com> <4DC160B9.5060004@FreeBSD.org> <4DC2A0E5.5040602@zedat.fu-berlin.de> 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: "O. Hartmann" , current@freebsd.org Subject: Re: Clang error make buildworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 13:55:00 -0000 > Because with clang, -march=native often breaks buildworld, while > -march=core2 is ok. Can you be more specific about this claim? On what CPU are seeing this breakage? Anyway, can you compile and run on that machine this: http://lev.vlakno.cz/~rdivacky/Host.cpp It's the LLVM CPU autodetection code, it will print the name of your CPU. I wonder whats the difference to "core2". Thank you. roman From owner-freebsd-current@FreeBSD.ORG Thu May 5 14:10:05 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CA2F106566C for ; Thu, 5 May 2011 14:10:05 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 10D4F8FC0C for ; Thu, 5 May 2011 14:10:04 +0000 (UTC) Received: by pwj8 with SMTP id 8so1312472pwj.13 for ; Thu, 05 May 2011 07:10:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.35.228 with SMTP id l4mr3411745pbj.5.1304604604535; Thu, 05 May 2011 07:10:04 -0700 (PDT) Received: by 10.68.40.4 with HTTP; Thu, 5 May 2011 07:10:04 -0700 (PDT) In-Reply-To: <20110505135458.GA79622@freebsd.org> References: <201105040107.p4417NTR048534@pozo.com> <4DC0F46C.3020806@FreeBSD.org> <201105041344.p44DiOId032272@pozo.com> <4DC160B9.5060004@FreeBSD.org> <4DC2A0E5.5040602@zedat.fu-berlin.de> <20110505135458.GA79622@freebsd.org> Date: Thu, 5 May 2011 16:10:04 +0200 Message-ID: From: Olivier Smedts To: Roman Divacky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: Clang error make buildworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 14:10:05 -0000 2011/5/5 Roman Divacky : >> Because with clang, -march=3Dnative often breaks buildworld, while >> -march=3Dcore2 is ok. > > Can you be more specific about this claim? On what CPU are seeing > this breakage? On a Core2 Quad Q9450 and a Core i7 860. I use "core2" on both because that's the most approaching values supported in bsd.cpu.mk and gcc in HEAD. I reverted from "-march=3Dnative" to "-march=3Dcore2" for two reasons, the first beeing that gcc didn't use the right "-mtune" when using "-march=3Dnative" (I think it was using internally "-mtune=3Dgeneric"). I'll try to be more specific if I can find the tests I was using at that time. The second reason is that with "-march=3Dnative", my buildworld often failed with clang, and since I use "-march=3Dcore2" I had no issues. I'll try to buildworld with "-march=3Dnative" and report back. > Anyway, can you compile and run on that machine this: > > =A0 =A0 =A0 =A0http://lev.vlakno.cz/~rdivacky/Host.cpp Compiled with gcc and clang, both output (on one of the two computers I use most) : roman =3D corei7 > It's the LLVM CPU autodetection code, it will print the name of > your CPU. I wonder whats the difference to "core2". > > Thank you. roman Cheers --=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-current@FreeBSD.ORG Thu May 5 14:21:56 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C600D106566B for ; Thu, 5 May 2011 14:21:56 +0000 (UTC) (envelope-from lacombar@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 7A5A78FC17 for ; Thu, 5 May 2011 14:21:56 +0000 (UTC) Received: by iwn33 with SMTP id 33so2598176iwn.13 for ; Thu, 05 May 2011 07:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IRZK51UvsUgLQwHL9eth467bBeoOSswtUyIAvMz4gCM=; b=DcVK5mqnDR/Di64rbtvj1L1T7RSdSLPud48a3U6HZWBrNXOPWx9HPSEr1BZMhsj4Mb dBV+dei5l1YNtpx27FsXhU1c6gNHgSmvAsNlQXZYH4uSZo8oaSrFtqUrme3Bhhpx5rUA Hd9s78XV9BbCAuk3x4/Nei1zBjZYUa7qlOYNM= 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=salMxdOJQtugS/VsiRt78Pvwki1hjPJsNlcY32Yu5nrWX/4tHzm+I9eakdouKnPq50 GrnKtEs4LITF+NT6Knl/cfjHJds5m0TkoXcLshzxbEkAFSEZbnHXkFSXTh3L9EZSMqLU jU5qJmxIjdLC/Nt9wX2vs5xzNzEX6F62DnoFc= MIME-Version: 1.0 Received: by 10.42.150.8 with SMTP id y8mr987984icv.471.1304605315614; Thu, 05 May 2011 07:21:55 -0700 (PDT) Received: by 10.42.167.5 with HTTP; Thu, 5 May 2011 07:21:55 -0700 (PDT) In-Reply-To: References: <4D94A354.9080903@sentex.net> <4DC07013.9070707@gmx.net> <4DC078BD.9080908@gmx.net> Date: Thu, 5 May 2011 10:21:55 -0400 Message-ID: From: Arnaud Lacombe To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Olivier Smedts , FreeBSD current mailing list Subject: Re: problems with em(4) since update to driver 7.2.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 14:21:56 -0000 Hi, On Thu, May 5, 2011 at 2:59 AM, Jack Vogel wrote: > OK, but what this does not explain is why I do not see this if > its so easily reproduced, what causes the failure case, any idea? > It is completely random as it depends on the content of the stack. I spent 3 or 4 hours trying to reproduce it using different approach on different platform, with different version of the code and failed. And once `error' was explicitly colored, it popped up. That's the beauty of error related with uninitialized variable. - Arnaud > As I said, given the code was not feasible for igb anyway I would not > be unhappy about returning to the old way of doing things. > I am not sure what you mean by "old way of doing thing", but I'd guess that the ring only need to be setup on a few occasion, like initialization and MTU transition. I'm not sure either how other driver manage their ring. > Jack > > > On Wed, May 4, 2011 at 11:03 PM, Arnaud Lacombe wrot= e: >> >> Hi, >> >> On Thu, May 5, 2011 at 1:20 AM, Arnaud Lacombe wrot= e: >> > Hi, >> > >> > On Wed, May 4, 2011 at 5:38 PM, Jack Vogel wrote: >> >> I have had my validation engineer busy all day, we have tried both >> >> a 9 kernel as well as 8.2, =A0using the code from HEAD, and we >> >> cannot reproduce this problem. >> >> >> > Actually, it can be trivially reproduced by tainting `error'. As it is >> > uninitialized in HEAD, it's value can be _anything_, so let's mark it >> > as explicitly invalid. >> > >> > diff -u ./if_em.c /data/src/freebsd/em-7.2.2/src/if_em.c >> > --- ./if_em.c =A0 2011-02-18 01:18:23.000000000 -0500 >> > +++ /data/src/freebsd/em-7.2.2/src/if_em.c =A0 =A0 =A02011-05-05 >> > 01:12:01.000000000 -0400 >> > @@ -3912,7 +3912,7 @@ >> > =A0 =A0 =A0 =A0struct =A0adapter =A0 =A0 =A0 =A0 *adapter =3D rxr->ada= pter; >> > =A0 =A0 =A0 =A0struct em_buffer =A0 =A0 =A0 =A0*rxbuf; >> > =A0 =A0 =A0 =A0bus_dma_segment_t =A0 =A0 =A0 seg[1]; >> > - =A0 =A0 =A0 int =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 i, j, nsegs,= error; >> > + =A0 =A0 =A0 int =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 i, j, nsegs,= error =3D -1; >> > >> > The error pointed out in this thread pops up in the next boot. >> > >> I put a call to kdb_enter() at the beginning of the function, helped >> with some textdump I got all the backtrace [0] for all the time >> em_setup_receive_ring() is called. All are exactly the same: >> >> kdb_enter_why(0,c09f6511,f391aaa8,c09be1e2,c09f6511,...) at >> kdb_enter_why+0x3b >> kdb_enter(c09f6511,0,3810,ffffffff,5dc,...) at kdb_enter+0x19 >> em_setup_receive_ring(c3c8d600,c3c8d7a4,c3c96004,310000fa,c3c8d600,...) >> at em_setup_receive_ring+0x22 >> em_setup_receive_structures(c3c96000,f15f2000,38,8100,3,...) at >> em_setup_receive_structures+0x26 >> em_init_locked(c3c96000,0,c09f5de5,414,10000,...) at em_init_locked+0x2f= 2 >> em_ioctl(c3c7d000,80206934,c3ce9d00,c07b7a0b,c3f2a230,...) at >> em_ioctl+0x1c3 >> ifhwioctl(c3f2a230,f391ac34,c07b7a0b,c3f3e3d0,c08df1c0,...) at >> ifhwioctl+0x4b8 >> ifioctl(c3f3e3d0,80206934,c3ce9d00,c3f2a230,c3f2a230,...) at ifioctl+0x8= 2 >> kern_ioctl(c3f2a230,3,80206934,c3ce9d00,c3ce9d00,...) at kern_ioctl+0xa8 >> ioctl(c3f2a230,f391acf8,c,c,f391ad2c,...) at ioctl+0xc5 >> syscall(f391ad38) at syscall+0x17d >> Xint0x80_syscall() at Xint0x80_syscall+0x20 >> --- syscall (54, FreeBSD ELF32, ioctl), eip =3D 0x4816ee23, esp =3D >> 0xbfbfe67c, ebp =3D 0xbfbfe698 --- >> >> This fully explain why the main loop in em_setup_receive_ring() is >> never entered, as we always verify `j =3D=3D rxr->next_to_check' (provid= ed >> that mbuf have been refreshed if some packet were transfered) and >> return the value on the stack. As of now, beside changing the >> call-site of em_setup_receive_ring() to ensure it is never re-entered, >> I'd guess that the patch I sent earlier today, is the only way to >> ensure that no junk is returned. >> >> I'd guess that the driver _is_ able to transmit, if the code was not >> explicitly calling em_stop() upon em_setup_receive_structures() >> failure. >> >> =A0- Arnaud >> >> [0]: I wish that would have been as easy as in Linux, where a WARN() >> call do all the job automatically, but still, I should not hope for >> that much unless I am the one implementing it ... yes, free whining, >> it's 2a.m. ... >> >> > =A0- Arnaud >> > >> >> The data your netstat -m shows suggests to me that what's happening >> >> is somehow setup of the receive ring is running more than once maybe?= ? >> >> >> >> You asked at one point how this could go into STABLE, well, because >> >> not only here at Intel, but at lots of external customers this code h= as >> >> been >> >> used and tested thoroughly. >> >> >> >> I am not calling into question your problem, but until I understand >> >> what it >> >> is I cannot "fix" it :) >> >> >> >> The thing I am guessing right now is the culprit is the setup code, t= he >> >> reason >> >> is that when I ported to the igb driver I found that it did not work = on >> >> our >> >> newer >> >> hardware, and so I went back to the older version of setup for igb. >> >> Now, >> >> even >> >> though I have not seen hardware fail with em, maybe there is some. >> >> >> >> To help me give me a complete pciconf -lv, and if its a namebrand >> >> system >> >> tell me that, including all hardware in it. >> >> >> >> If you like Olivier I can make a version of em for you that also >> >> reverts the >> >> setup code the way I did for igb, see if that fixes it for you? >> >> >> >> Thanks for your patience, >> >> >> >> Jack >> >> _______________________________________________ >> >> freebsd-current@freebsd.org mailing list >> >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> >> To unsubscribe, send any mail to >> >> "freebsd-current-unsubscribe@freebsd.org" >> >> >> > > > From owner-freebsd-current@FreeBSD.ORG Thu May 5 14:32:45 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DFA41065673 for ; Thu, 5 May 2011 14:32:45 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id D8FF08FC08 for ; Thu, 5 May 2011 14:32:44 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1QHzbf-0000Si-U8>; Thu, 05 May 2011 16:32:43 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1QHzbf-0000zc-Qz>; Thu, 05 May 2011 16:32:43 +0200 Message-ID: <4DC2B50B.2090806@zedat.fu-berlin.de> Date: Thu, 05 May 2011 16:32:43 +0200 From: "O. Hartmann" Organization: Freie =?ISO-8859-1?Q?Universit=E4t_Berlin?= User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: Olivier Smedts References: <201105040107.p4417NTR048534@pozo.com> <4DC0F46C.3020806@FreeBSD.org> <201105041344.p44DiOId032272@pozo.com> <4DC160B9.5060004@FreeBSD.org> <4DC2A0E5.5040602@zedat.fu-berlin.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: current@freebsd.org Subject: Re: Clang error make buildworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 14:32:45 -0000 On 05/05/11 15:46, Olivier Smedts wrote: > 2011/5/5 O. Hartmann: >> On 05/04/11 16:20, Dimitry Andric wrote: >>> >>> On 2011-05-04 15:44, Manfred Antar wrote: >>> ... >>>> >>>> src.conf: >>>> >>>> WITHOUT_DYNAMICROOT=yes >>>> WITH_IDEA=yes >>>> .if !defined(CC) || ${CC} == "cc" >>>> CC=clang >>>> .endif >>>> .if !defined(CXX) || ${CXX} == "c++" >>>> CXX=clang++ >>>> .endif >>>> #Don't die on warnings >>>> NO_WERROR= >>>> WERROR= >>> >>> Aha. Please move the clang-related stuff to make.conf instead, e.g. >>> this fragment: >>> >>> .if !defined(CC) || ${CC} == "cc" >>> CC=clang >>> .endif >>> .if !defined(CXX) || ${CXX} == "c++" >>> CXX=clang++ >>> .endif >>> #Don't die on warnings >>> NO_WERROR= >>> WERROR= >>> >> >> >> On a notebook (DELL Latitude E6510) I tried compiling world with CLANG. So >> far, so good. It worked. But after rebooting I got a strange misbehaviour of >> the xdm login window (black/white instead of coloured), but this was only >> some superficial symptome. The whole system seems to be corrupted. Hitting >> tab key results like hitting exit in the console. The gcc 4.2.1 system >> compiler isn't capable of producing binaries, see message below. At this >> very moment, the box isn't usable anymore, I can't even compile a world with >> cc (see error below, that was generated by trying to compile a kernel and >> I'm really confused why cc is used instead of clang). >> >> Well, the boxes I reported errors from prior to this are desktop systems >> with nVidia (Fermi based) graphics boards using a driver BLOB 270.XX.XX >> which is also used by the notebook. >> >> The desktop boxes uses C2D based intel chips, the notebook uses a Core-i5 >> based chip. All systems got compiled with option >> >> CPUTYPE?=native > > Can you try without CPUTYPE "native", or with another value ? > "native" is not a supported value in /usr/share/mk/bsd.cpu.mk > > With gcc I used : > CPUTYPE?=core2 > CFLAGS=-O2 -pipe -march=native > NO_CPU_CFLAGS=yes > COPTFLAGS=-O2 -pipe -march=native > NO_CPU_COPTFLAGS=yes > > So that /usr/share/mk/bsd.cpu.mk could set the right variables and I > could set my own "-march" value in CFLAGS for gcc. > > But now for HEAD (which has a newer gcc and clang) I use : > CPUTYPE?=core2 > CFLAGS=-O2 -pipe -march=core2 > NO_CPU_CFLAGS=yes > COPTFLAGS=-O2 -pipe -march=core2 > NO_CPU_COPTFLAGS=yes > > Because with clang, -march=native often breaks buildworld, while > -march=core2 is ok. > > First, try to see if you buildworld is still broken with a different > (or empty!) make.conf. > Well I would like to to as suggested, but I can not even build a system/kernel anymore. Using clang, the build process dies when it comes to "rpcgen" as shown below, it uses "cc" (fixed) and cc doen't work properly anymore. >> I guess the first compilation with CLANG "destroyed" the base' system >> compiler, at this moment I'm incapable of switching back. Floating like a >> dead man in the water. >> >> >> Any suggestions? >> >> Regards and thanks in advance, >> Oliver >> --- >> awk -f /usr/src/sys/tools/usbdevs2h.awk /usr/src/sys/dev/usb/usbdevs -h >> awk -f /usr/src/sys/tools/usbdevs2h.awk /usr/src/sys/dev/usb/usbdevs -d >> rpcgen -hM /usr/src/sys/kgssapi/gssd.x | grep -v pthread.h> gssd.h >> cc1: internal compiler error: Bus error: 10 >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> rpcgen -c /usr/src/sys/kgssapi/gssd.x -o gssd_xdr.c >> cc1: internal compiler error: Bus error: 10 >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> *** Error code 1 >> >> Stop in /usr/obj/usr/src/sys/MUNIN. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 >> >> Stop in /usr/src. From owner-freebsd-current@FreeBSD.ORG Thu May 5 14:40:58 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 837D9106566B for ; Thu, 5 May 2011 14:40:58 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3F6E68FC14 for ; Thu, 5 May 2011 14:40:57 +0000 (UTC) Received: by iyj12 with SMTP id 12so2642637iyj.13 for ; Thu, 05 May 2011 07:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WeAdxPaO1kYO+lKW5/kxgYfVlgoH6i+R4h6ctpbTNPg=; b=xPk2weuo5qFp18yIw887oNofnEzVmcAA/qyA9MwdQdJIVwMmjDwt3j5scjETo6cIvC Zg+cnYiYmxSKhdF6N0Kcw/F1VCgtPVdVElKV9ArKVMhSKwle5YdWQzBCCWSaAuYznXyF TVmW79hiYxxUBw/bmCOPnzCbfxJ2UD6sikdzM= 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=LiOcfebt9MM7/xc59BJ+mJ9zMcDvw2og9eAx5Fx9MR5YVsVTWJfHUwuvtJSryR6cR9 uB+x+NAMBrUj4ymYN2nnxt3O7XvG3N2rEf+nyM30x+LijUwrh+qVIoOlwWsXJNOqm1+i fKNncd/vGtoNbPez60tff6r2rkS8JcceXzrSw= MIME-Version: 1.0 Received: by 10.42.151.73 with SMTP id d9mr730021icw.2.1304606457669; Thu, 05 May 2011 07:40:57 -0700 (PDT) Received: by 10.42.167.5 with HTTP; Thu, 5 May 2011 07:40:57 -0700 (PDT) In-Reply-To: <20110504070015.GB2700@direwolf> References: <4D94A354.9080903@sentex.net> <4DC07013.9070707@gmx.net> <4DC078BD.9080908@gmx.net> <20110504070015.GB2700@direwolf> Date: Thu, 5 May 2011 10:40:57 -0400 Message-ID: From: Arnaud Lacombe To: Alastair Hogge Content-Type: text/plain; charset=ISO-8859-1 Cc: Olivier Smedts , FreeBSD current mailing list , Jack Vogel , Michael Schmiedgen , Mike Tancsa Subject: Re: problems with em(4) since update to driver 7.2.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 14:40:58 -0000 Hi, On Wed, May 4, 2011 at 3:00 AM, Alastair Hogge wrote: > [.] > I also tried 2x, & 4x 25600 for max mbuff clusters via kern.ipc.nmbclusters. > This didn't help. > For the record, I did the math yestarday, checked the code. By default, a machine with 6 82574L-backed em(4) interfaces, with only 3 used (ie. brought up), initializes and work just fine with as low as 3076 mbuf clusters (1024*3 + 2). It has been transferring about 28k pps or 20Mbps of traffic (ICMP ping flood) since for the last 10h. Here is the `netstat -m' output: # netstat -m 2879/916/3795 mbufs in use (current/cache/total) 2877/199/3076/3076 mbuf clusters in use (current/cache/total/max) 2877/199 mbuf+clusters out of packet secondary zone in use (current/cache) 0/2/2/1537 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/768 9k jumbo clusters in use (current/cache/total/max) 0/0/0/384 16k jumbo clusters in use (current/cache/total/max) 6473K/635K/7108K bytes allocated to network (current/cache/total) 0/540580029/268859859 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/5/6656 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 and, yes, allocation denial has sky-rocketed, but beside that the driver is stable. In that case, the uninitialized issue did not happen when the system booted. The complete machine should be able to initialize properly with 6146 clusters. - Arnaud From owner-freebsd-current@FreeBSD.ORG Thu May 5 15:46:01 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 903C8106566C; Thu, 5 May 2011 15:46:01 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6295A8FC16; Thu, 5 May 2011 15:46:01 +0000 (UTC) Received: by pwj8 with SMTP id 8so1366253pwj.13 for ; Thu, 05 May 2011 08:46:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.14.37 with SMTP id m5mr3305264pbc.474.1304610360382; Thu, 05 May 2011 08:46:00 -0700 (PDT) Received: by 10.68.40.4 with HTTP; Thu, 5 May 2011 08:46:00 -0700 (PDT) In-Reply-To: <20110505135458.GA79622@freebsd.org> References: <201105040107.p4417NTR048534@pozo.com> <4DC0F46C.3020806@FreeBSD.org> <201105041344.p44DiOId032272@pozo.com> <4DC160B9.5060004@FreeBSD.org> <4DC2A0E5.5040602@zedat.fu-berlin.de> <20110505135458.GA79622@freebsd.org> Date: Thu, 5 May 2011 17:46:00 +0200 Message-ID: From: Olivier Smedts To: Roman Divacky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "O. Hartmann" , current@freebsd.org Subject: Re: Clang error make buildworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 15:46:01 -0000 2011/5/5 Roman Divacky : >> Because with clang, -march=3Dnative often breaks buildworld, while >> -march=3Dcore2 is ok. > > Can you be more specific about this claim? On what CPU are seeing > this breakage? Ok, with latest HEAD... %echo | gcc -march=3Dnative -E -v -x c -### - Using built-in specs. Target: amd64-undermydesk-freebsd Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 4.2.2 20070831 prerelease [FreeBSD] "/usr/libexec/cc1" "-E" "-quiet" "-v" "-D_LONGLONG" "-" "-march=3Dcore2" "-mtune=3Dgeneric" With "-march=3Dnative", gcc adds "-mtune=3Dgeneric" while the man pages says "-march=3Dxxx" sets "-mtune=3Dxxx". %echo | gcc -march=3Dcore2 -E -v -x c -### - Using built-in specs. Target: amd64-undermydesk-freebsd Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 4.2.2 20070831 prerelease [FreeBSD] "/usr/libexec/cc1" "-E" "-quiet" "-v" "-D_LONGLONG" "-" "-march=3Dcore2" With "-march=3Dcore2", gcc doesn't add "-mtune=3Dgeneric", so it should use "-mtune=3Dcore2" as suggested by its man page. That's why I use "-march=3Dcore2" for gcc. Now for clang... With "-march=3Dcore2", my buildworld compiles just fine on my Core2 Quad, whereas with "-march=3Dnative" (without -jX) if fails on : =3D=3D=3D> libexec/atrun (all) clang -O2 -pipe -march=3Dnative -fomit-frame-pointer -DATJOB_DIR=3D\"/var/at/jobs/\" -DLFILE=3D\"/var/at/jobs/.lockfile\" -DLOADAVG_MX=3D1.5 -DATSPOOL_DIR=3D\"/var/at/spool\" -DVERSION=3D\"2.9\" -DDAEMON_UID=3D1 -DDAEMON_GID=3D1 -DDEFAULT_BATCH_QUEUE=3D\'E\' -DDEFAULT_AT_QUEUE=3D\'c\' -DPERM_PATH=3D\"/var/at/\" -I/usr/src/libexec/atrun/../../usr.bin/at -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=3Dgnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/libexec/atrun/atrun.c clang -O2 -pipe -march=3Dnative -fomit-frame-pointer -DATJOB_DIR=3D\"/var/at/jobs/\" -DLFILE=3D\"/var/at/jobs/.lockfile\" -DLOADAVG_MX=3D1.5 -DATSPOOL_DIR=3D\"/var/at/spool\" -DVERSION=3D\"2.9\" -DDAEMON_UID=3D1 -DDAEMON_GID=3D1 -DDEFAULT_BATCH_QUEUE=3D\'E\' -DDEFAULT_AT_QUEUE=3D\'c\' -DPERM_PATH=3D\"/var/at/\" -I/usr/src/libexec/atrun/../../usr.bin/at -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=3Dgnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/libexec/atrun/gloadavg.c clang -O2 -pipe -march=3Dnative -fomit-frame-pointer -DATJOB_DIR=3D\"/var/at/jobs/\" -DLFILE=3D\"/var/at/jobs/.lockfile\" -DLOADAVG_MX=3D1.5 -DATSPOOL_DIR=3D\"/var/at/spool\" -DVERSION=3D\"2.9\" -DDAEMON_UID=3D1 -DDAEMON_GID=3D1 -DDEFAULT_BATCH_QUEUE=3D\'E\' -DDEFAULT_AT_QUEUE=3D\'c\' -DPERM_PATH=3D\"/var/at/\" -I/usr/src/libexec/atrun/../../usr.bin/at -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=3Dgnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o atrun atrun.o gloadavg.o -lpam -lutil clang: warning: argument unused during compilation: '-std=3Dgnu99' /usr/obj/usr/src/tmp/usr/lib/crt1.o: In function `_start': /usr/src/lib/csu/amd64/crt1.c:(.text+0x5d): undefined reference to `atexit' /usr/src/lib/csu/amd64/crt1.c:(.text+0x64): undefined reference to `_init_t= ls' /usr/src/lib/csu/amd64/crt1.c:(.text+0x6e): undefined reference to `atexit' /usr/src/lib/csu/amd64/crt1.c:(.text+0x88): undefined reference to `exit' atrun.o: In function `perr': /usr/src/libexec/atrun/atrun.c:(.text+0x65): undefined reference to `strlen= ' /usr/src/libexec/atrun/atrun.c:(.text+0xac): undefined reference to `vwarn' /usr/src/libexec/atrun/atrun.c:(.text+0xb6): undefined reference to `exit' /usr/src/libexec/atrun/atrun.c:(.text+0xd5): undefined reference to `snprin= tf' /usr/src/libexec/atrun/atrun.c:(.text+0xe6): undefined reference to `vsyslo= g' /usr/src/libexec/atrun/atrun.c:(.text+0xf0): undefined reference to `exit' atrun.o: In function `perrx': /usr/src/libexec/atrun/atrun.c:(.text+0x19f): undefined reference to `vwarn= x' /usr/src/libexec/atrun/atrun.c:(.text+0x1a9): undefined reference to `exit' /usr/src/libexec/atrun/atrun.c:(.text+0x1be): undefined reference to `vsysl= og' /usr/src/libexec/atrun/atrun.c:(.text+0x1c8): undefined reference to `exit' atrun.o: In function `main': /usr/src/libexec/atrun/atrun.c:(.text+0x224): undefined reference to `geteu= id' /usr/src/libexec/atrun/atrun.c:(.text+0x239): undefined reference to `geteg= id' /usr/src/libexec/atrun/atrun.c:(.text+0x24a): undefined reference to `seteg= id' /usr/src/libexec/atrun/atrun.c:(.text+0x255): undefined reference to `seteu= id' /usr/src/libexec/atrun/atrun.c:(.text+0x269): undefined reference to `openl= og' /usr/src/libexec/atrun/atrun.c:(.text+0x26f): undefined reference to `opter= r' /usr/src/libexec/atrun/atrun.c:(.text+0x292): undefined reference to `getop= t' /usr/src/libexec/atrun/atrun.c:(.text+0x2ac): undefined reference to `optar= g' /usr/src/libexec/atrun/atrun.c:(.text+0x2bb): undefined reference to `sscan= f' /usr/src/libexec/atrun/atrun.c:(.text+0x2e7): undefined reference to `__std= errp' /usr/src/libexec/atrun/atrun.c:(.text+0x2fb): undefined reference to `fwrit= e' /usr/src/libexec/atrun/atrun.c:(.text+0x305): undefined reference to `exit' /usr/src/libexec/atrun/atrun.c:(.text+0x316): undefined reference to `syslo= g' /usr/src/libexec/atrun/atrun.c:(.text+0x320): undefined reference to `exit' /usr/src/libexec/atrun/atrun.c:(.text+0x32a): undefined reference to `chdir= ' /usr/src/libexec/atrun/atrun.c:(.text+0x349): undefined reference to `opend= ir' /usr/src/libexec/atrun/atrun.c:(.text+0x361): undefined reference to `time' /usr/src/libexec/atrun/atrun.c:(.text+0x3cc): undefined reference to `sscan= f' /usr/src/libexec/atrun/atrun.c:(.text+0x416): undefined reference to `__mb_sb_limit' /usr/src/libexec/atrun/atrun.c:(.text+0x42a): undefined reference to `_CurrentRuneLocale' /usr/src/libexec/atrun/atrun.c:(.text+0x43e): undefined reference to `strcm= p' /usr/src/libexec/atrun/atrun.c:(.text+0x454): undefined reference to `strlc= py' /usr/src/libexec/atrun/atrun.c:(.text+0x463): undefined reference to `__mb_sb_limit' /usr/src/libexec/atrun/atrun.c:(.text+0x4a1): undefined reference to `_CurrentRuneLocale' /usr/src/libexec/atrun/atrun.c:(.text+0x4ea): undefined reference to `unlin= k' /usr/src/libexec/atrun/atrun.c:(.text+0x4f4): undefined reference to `readd= ir' /usr/src/libexec/atrun/atrun.c:(.text+0x50b): undefined reference to `stat' /usr/src/libexec/atrun/atrun.c:(.text+0x54c): undefined reference to `close= log' /usr/src/libexec/atrun/atrun.c:(.text+0x553): undefined reference to `exit' atrun.o: In function `run_file': [...] /usr/src/libexec/atrun/atrun.c:(.text+0xba4): undefined reference to `__stack_chk_fail' /usr/src/libexec/atrun/atrun.c:(.text+0xc90): undefined reference to `exit' /usr/src/libexec/atrun/atrun.c:(.text+0xcb2): undefined reference to `exit' gloadavg.o: In function `gloadavg': /usr/src/libexec/atrun/gloadavg.c:(.text+0xb): undefined reference to `getloadavg' /usr/obj/usr/src/tmp/usr/lib/libutil.so: undefined reference to `stpcpy' /usr/obj/usr/src/tmp/usr/lib/libutil.so: undefined reference to `putchar' /usr/obj/usr/src/tmp/usr/lib/libutil.so: undefined reference to `strcpy' /usr/obj/usr/src/tmp/usr/lib/libutil.so: undefined reference to `warnx' /usr/obj/usr/src/tmp/usr/lib/libpam.so: undefined reference to `__stdoutp' /usr/obj/usr/src/tmp/usr/lib/libutil.so: undefined reference to `getrlimit' /usr/obj/usr/src/tmp/usr/lib/libutil.so: undefined reference to `ioctl' /usr/obj/usr/src/tmp/usr/lib/libpam.so: undefined reference to `dlerror' /usr/obj/usr/src/tmp/usr/lib/libutil.so: undefined reference to `getgid' /usr/obj/usr/src/tmp/usr/lib/libutil.so: undefined reference to `printf' /usr/obj/usr/src/tmp/usr/lib/libutil.so: undefined reference to `mac_is_pre= sent' /usr/obj/usr/src/tmp/usr/lib/libutil.so: undefined reference to `mac_from_t= ext' /usr/obj/usr/src/tmp/usr/lib/libpam.so: undefined reference to `sigemptyset= ' /usr/obj/usr/src/tmp/usr/lib/libutil.so: undefined reference to `strerror' /usr/obj/usr/src/tmp/usr/lib/libutil.so: undefined reference to `__pw_scan' /usr/obj/usr/src/tmp/usr/lib/libutil.so: undefined reference to `memmove' /usr/obj/usr/src/tmp/usr/lib/libpam.so: undefined reference to `__stdinp' /usr/obj/usr/src/tmp/usr/lib/libutil.so: undefined reference to `cpuset_setaffinity' /usr/obj/usr/src/tmp/usr/lib/libutil.so: undefined reference to `getenv' /usr/obj/usr/src/tmp/usr/lib/libutil.so: undefined reference to `fchmod' [...] /usr/obj/usr/src/tmp/usr/lib/libutil.so: undefined reference to `setlogin' /usr/obj/usr/src/tmp/usr/lib/libutil.so: undefined reference to `raise' /usr/obj/usr/src/tmp/usr/lib/libpam.so: undefined reference to `free' /usr/obj/usr/src/tmp/usr/lib/libpam.so: undefined reference to `sigprocmask= ' clang: error: linker command failed with exit code 1 (use -v to see invocat= ion) *** Error code 1 Stop in /usr/src/libexec/atrun. *** Error code 1 Stop in /usr/src/libexec. *** Error code 1 Stop in /usr/src. *** Error code 1 > > Anyway, can you compile and run on that machine this: > > =A0 =A0 =A0 =A0http://lev.vlakno.cz/~rdivacky/Host.cpp > > It's the LLVM CPU autodetection code, it will print the name of > your CPU. I wonder whats the difference to "core2". > > Thank you. roman > --=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-current@FreeBSD.ORG Thu May 5 15:55:54 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CCCC106564A for ; Thu, 5 May 2011 15:55:54 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [46.28.110.116]) by mx1.freebsd.org (Postfix) with ESMTP id 191EE8FC0A for ; Thu, 5 May 2011 15:55:53 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id C86987F385A; Thu, 5 May 2011 17:55:51 +0200 (CEST) Date: Thu, 5 May 2011 17:55:51 +0200 From: Roman Divacky To: Olivier Smedts Message-ID: <20110505155551.GA99006@freebsd.org> References: <201105040107.p4417NTR048534@pozo.com> <4DC0F46C.3020806@FreeBSD.org> <201105041344.p44DiOId032272@pozo.com> <4DC160B9.5060004@FreeBSD.org> <4DC2A0E5.5040602@zedat.fu-berlin.de> <20110505135458.GA79622@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 Cc: "O. Hartmann" , current@freebsd.org Subject: Re: Clang error make buildworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 15:55:54 -0000 > clang -O2 -pipe -march=native -fomit-frame-pointer > -DATJOB_DIR=\"/var/at/jobs/\" -DLFILE=\"/var/at/jobs/.lockfile\" > -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\"/var/at/spool\" -DVERSION=\"2.9\" > -DDAEMON_UID=1 -DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' > -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\"/var/at/\" > -I/usr/src/libexec/atrun/../../usr.bin/at -I/usr/src/libexec/atrun > -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector -Wsystem-headers -Wall > -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c > /usr/src/libexec/atrun/gloadavg.c > clang -O2 -pipe -march=native -fomit-frame-pointer > -DATJOB_DIR=\"/var/at/jobs/\" -DLFILE=\"/var/at/jobs/.lockfile\" > -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\"/var/at/spool\" -DVERSION=\"2.9\" > -DDAEMON_UID=1 -DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' > -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\"/var/at/\" > -I/usr/src/libexec/atrun/../../usr.bin/at -I/usr/src/libexec/atrun > -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector -Wsystem-headers -Wall > -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o atrun atrun.o > gloadavg.o -lpam -lutil > clang: warning: argument unused during compilation: '-std=gnu99' > /usr/obj/usr/src/tmp/usr/lib/crt1.o: In function `_start': > /usr/src/lib/csu/amd64/crt1.c:(.text+0x5d): undefined reference to `atexit' Can you invoke this very same command (ie. linking) with -### and show me? Does it work when you try to link the same .o files without specifying -march=native ? From owner-freebsd-current@FreeBSD.ORG Thu May 5 16:51:38 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CCC31065673; Thu, 5 May 2011 16:51:38 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 210098FC08; Thu, 5 May 2011 16:51:37 +0000 (UTC) Received: by pzk27 with SMTP id 27so1376823pzk.13 for ; Thu, 05 May 2011 09:51:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.14.37 with SMTP id m5mr3391486pbc.474.1304614297454; Thu, 05 May 2011 09:51:37 -0700 (PDT) Received: by 10.68.40.4 with HTTP; Thu, 5 May 2011 09:51:37 -0700 (PDT) In-Reply-To: <20110505155551.GA99006@freebsd.org> References: <201105040107.p4417NTR048534@pozo.com> <4DC0F46C.3020806@FreeBSD.org> <201105041344.p44DiOId032272@pozo.com> <4DC160B9.5060004@FreeBSD.org> <4DC2A0E5.5040602@zedat.fu-berlin.de> <20110505135458.GA79622@freebsd.org> <20110505155551.GA99006@freebsd.org> Date: Thu, 5 May 2011 18:51:37 +0200 Message-ID: From: Olivier Smedts To: Roman Divacky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "O. Hartmann" , current@freebsd.org Subject: Re: Clang error make buildworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 16:51:38 -0000 2011/5/5 Roman Divacky : >> clang -O2 -pipe -march=3Dnative -fomit-frame-pointer >> -DATJOB_DIR=3D\"/var/at/jobs/\" =A0-DLFILE=3D\"/var/at/jobs/.lockfile\" >> -DLOADAVG_MX=3D1.5 -DATSPOOL_DIR=3D\"/var/at/spool\" =A0-DVERSION=3D\"2.= 9\" >> -DDAEMON_UID=3D1 -DDAEMON_GID=3D1 =A0-DDEFAULT_BATCH_QUEUE=3D\'E\' >> -DDEFAULT_AT_QUEUE=3D\'c\' -DPERM_PATH=3D\"/var/at/\" >> -I/usr/src/libexec/atrun/../../usr.bin/at -I/usr/src/libexec/atrun >> -DLOGIN_CAP -DPAM -std=3Dgnu99 -fstack-protector -Wsystem-headers -Wall >> -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c >> /usr/src/libexec/atrun/gloadavg.c >> clang -O2 -pipe -march=3Dnative -fomit-frame-pointer >> -DATJOB_DIR=3D\"/var/at/jobs/\" =A0-DLFILE=3D\"/var/at/jobs/.lockfile\" >> -DLOADAVG_MX=3D1.5 -DATSPOOL_DIR=3D\"/var/at/spool\" =A0-DVERSION=3D\"2.= 9\" >> -DDAEMON_UID=3D1 -DDAEMON_GID=3D1 =A0-DDEFAULT_BATCH_QUEUE=3D\'E\' >> -DDEFAULT_AT_QUEUE=3D\'c\' -DPERM_PATH=3D\"/var/at/\" >> -I/usr/src/libexec/atrun/../../usr.bin/at -I/usr/src/libexec/atrun >> -DLOGIN_CAP -DPAM -std=3Dgnu99 -fstack-protector -Wsystem-headers -Wall >> -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign =A0-o atrun atrun.o >> gloadavg.o -lpam -lutil >> clang: warning: argument unused during compilation: '-std=3Dgnu99' >> /usr/obj/usr/src/tmp/usr/lib/crt1.o: In function `_start': >> /usr/src/lib/csu/amd64/crt1.c:(.text+0x5d): undefined reference to `atex= it' > > > Can you invoke this very same command (ie. linking) with -### and show me= ? > Does it work when you try to link the same .o files without specifying > -march=3Dnative ? I'm going to try. In the meantime, I did other tests on this machine, which is detected by clang as -march=3Dcorei7. Compiling this with the system's clang (which has been compiled with -march=3Dcore2) and -march=3Dcore2 is OK. Compiling this with the system's clang (which has been compiled with -march=3Dcore2) and -march=3Dnative is OK. Compiling this with the bootstrap clang (which has been compiled with -march=3Dnative) and -march=3Dnative FAILS. The problem seems to be inside the clang compiled with -march=3Dnative. Next, I'm going to try with a bootstrap clang compiled with -march=3Dcorei7. --=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-current@FreeBSD.ORG Thu May 5 17:20:04 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B9C8106564A for ; Thu, 5 May 2011 17:20:04 +0000 (UTC) (envelope-from jfvogel@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 DBCA58FC13 for ; Thu, 5 May 2011 17:20:03 +0000 (UTC) Received: by qwc9 with SMTP id 9so2063129qwc.13 for ; Thu, 05 May 2011 10:20:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RL5dmUS4lXRGxBzsTuwLyKFsZQeoD8lmUsaR2woquAI=; b=cYz7w10++sU+PDZkULBThO0SSMpyxKSkKeO8jbgCu6Bd1qOw78Mg4YorEK4YIIy38Z VQccHfCCq690M9zod+Z991t4OIe4PjND1/eN9drIZFU8Xr/+gmlpKylYdteHSD3fRbB7 +3SP6TbgqmQ17lJg57CzulYInXKC6oqim61Mg= 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=CgpA6wCJiLarGj90uIfrTMFhtBhob1G4SBoCMv1JCJFFrZMBHeQwIlJgUFDY6kMF9q MOs8LnRXci6SXbMMmgKH7VCn+4gwhsAwdYRFEgiK3YzcYaltMCmriRsl5xGJVlgvqvFp TDQJJEl8sIgHNs5Y73xlqwMByvAMFTMCaMZOE= MIME-Version: 1.0 Received: by 10.52.76.102 with SMTP id j6mr593068vdw.44.1304616003178; Thu, 05 May 2011 10:20:03 -0700 (PDT) Received: by 10.52.184.169 with HTTP; Thu, 5 May 2011 10:20:03 -0700 (PDT) In-Reply-To: References: <4D94A354.9080903@sentex.net> <4DC07013.9070707@gmx.net> <4DC078BD.9080908@gmx.net> Date: Thu, 5 May 2011 10:20:03 -0700 Message-ID: From: Jack Vogel To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Olivier Smedts , FreeBSD current mailing list Subject: Re: problems with em(4) since update to driver 7.2.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 17:20:04 -0000 On Thu, May 5, 2011 at 7:21 AM, Arnaud Lacombe wrote: > Hi, > > On Thu, May 5, 2011 at 2:59 AM, Jack Vogel wrote: > > OK, but what this does not explain is why I do not see this if > > its so easily reproduced, what causes the failure case, any idea? > > > It is completely random as it depends on the content of the stack. I > spent 3 or 4 hours trying to reproduce it using different approach on > different platform, with different version of the code and failed. And > once `error' was explicitly colored, it popped up. That's the beauty > of error related with uninitialized variable. > > - Arnaud > > > As I said, given the code was not feasible for igb anyway I would not > > be unhappy about returning to the old way of doing things. > > > I am not sure what you mean by "old way of doing thing", but I'd guess > that the ring only need to be setup on a few occasion, like > initialization and MTU transition. I'm not sure either how other > driver manage their ring. > > The old way was as the code is in igb now, on each entry to this setup it would completely wipe the descriptor memory, then release all mbufs, and initialize from scratch. Its only because of this "lazy" reinit, meaning only the range from next_to_refresh to next_to_check is reset, that this problem can happen. For igb the reason this will not work, is it requires you to set E1000_RDH(i) to next_to_check, and in fact, the hardware prohibits the write, its ALWAYS 0 after a reset. The reason for this is that the hardware wishes to manage the head index and not software. Anyway, I see the problematic code path, its only when you skip the while loop altogether. I'm surprised the compiler did not complain about this, its usually so anal. Jack From owner-freebsd-current@FreeBSD.ORG Thu May 5 17:23:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC807106564A for ; Thu, 5 May 2011 17:23:52 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.212.176]) by mx1.freebsd.org (Postfix) with ESMTP id 94C278FC17 for ; Thu, 5 May 2011 17:23:52 +0000 (UTC) Received: by pxi11 with SMTP id 11so1841837pxi.7 for ; Thu, 05 May 2011 10:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=2OfKb2u5TFyS7L5ckHB80WNkrawmOylTrO3GY6sk6zc=; b=jqWQMZuQFhZhrqfwEGiO+cgTLn3yM+QKwSpgpv4a0ee1aT017uBRIQL5u0Ku9gTLM4 4Tai42DZPRnQSuMiAYntqbq0418q/p/zVVF+TekjcaCN4JBkjEx8qaaefg0VNPLhe1EN v6Cn9+5fFIvZEYfo+5k1m3beVl3ZEFty9kpnA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=devG1StQfCKOZ/Bao7kOxo5ajxe4HsnRtqZ9v7+DGt6MImb8eGaKMYo0dqPF592nZv zY+ZygAASFnRU6MBt6Msj4NQJUJOAdk56nDAUMcwv9a86vcpPNq+cbqziygvPhoIKMfE PXbKu4TuHeitnPh2UNFWF5uIlBJ9HNVsGGDso= Received: by 10.68.22.163 with SMTP id e3mr3634190pbf.22.1304616231969; Thu, 05 May 2011 10:23:51 -0700 (PDT) Received: from [192.168.20.5] (c-24-6-49-154.hsd1.ca.comcast.net [24.6.49.154]) by mx.google.com with ESMTPS id e2sm1551988pbk.90.2011.05.05.10.23.49 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 May 2011 10:23:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <20110504090718.GN48734@deviant.kiev.zoral.com.ua> Date: Thu, 5 May 2011 10:23:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9E4C162F-B4EA-4378-A010-3E8D0D23EA93@gmail.com> References: <201105040559.p445xEJ5024585@chez.mckusick.com> <20110504090718.GN48734@deviant.kiev.zoral.com.ua> To: Kostik Belousov X-Mailer: Apple Mail (2.1084) Cc: Kirk McKusick , FreeBSD Current Subject: Re: Nasty non-recursive lockmgr panic on softdep only enabled UFS partition when filesystem full X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 17:23:52 -0000 On May 4, 2011, at 2:07 AM, Kostik Belousov wrote: > On Tue, May 03, 2011 at 11:58:49PM -0700, Garrett Cooper wrote: >> On Tue, May 3, 2011 at 11:42 PM, Garrett Cooper = wrote: >>> On Tue, May 3, 2011 at 10:59 PM, Kirk McKusick = wrote: >>>>> Date: Tue, 3 May 2011 22:40:26 -0700 >>>>> Subject: Nasty non-recursive lockmgr panic on softdep only enabled = UFS >>>>> partition when filesystem full >>>>> From: Garrett Cooper >>>>> To: Jeff Roberson , >>>>> Marshall Kirk McKusick >>>>> Cc: FreeBSD Current >>>>>=20 >>>>> Hi Jeff and Dr. McKusick, >>>>> Ran into this panic when /usr ran out of space doing a make >>>>> universe on amd64/r221219 (it took ~15 minutes for the panic to = occur >>>>> after the filesystem ran out of space -- wasn't quite sure what it = was >>>>> doing at the time): >>>>>=20 >>>>> ... >>>>>=20 >>>>> Let me know what other commands you would like for me to run = in kgdb. >>>>> Thanks, >>>>> -Garrett >>>>=20 >>>> You did not indicate whether you are running an 8.X system or a = 9-current >>>> system. It would be helpful to know that. >>>=20 >>> I've actually been running CURRENT for a few years now, but you're = right -- >>> I didn't mention that part. >>>=20 >>>> Jeff thinks that there may be a potential race in the locking code = for >>>> softdep_request_cleanup. If so, this patch for 9-current should fix = it: >>>>=20 >>>> Index: ffs_softdep.c >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> --- ffs_softdep.c (revision 221385) >>>> +++ ffs_softdep.c (working copy) >>>> @@ -11380,7 +11380,8 @@ >>>> continue; >>>> } >>>> MNT_IUNLOCK(mp); >>>> - if (vget(lvp, LK_EXCLUSIVE | LK_INTERLOCK, = curthread)) { >>>> + if (vget(lvp, LK_EXCLUSIVE | LK_NOWAIT | = LK_INTERLOCK, >>>> + curthread)) { >>>> MNT_ILOCK(mp); >>>> continue; >>>> } >>>>=20 >>>> If you are running an 8.X system, hopefully you will be able to = apply it. >>>=20 >>> I've applied it, rebuilt and installed the kernel, and trying to >>> repro the case again. Will let you know how things go! >>=20 >> Happened again with the change. It's really easy to repro: >>=20 >> 1. Get a filesystem with UFS+SU >> 2. Execute something that does a large number of small writes to a = partition. >> 3. 'dd if=3D/dev/zero of=3DFOO bs=3D10m' on the same partition >>=20 >> The kernel will panic with the issue I discussed above. >> Thanks! >=20 > Jeff' change is required to avoid LORs, but it is not sufficient to > prevent recursion. We must skip the vnode supplied as a parameter to > softdep_request_cleanup(). Theoretically, other vnodes might be also > locked by curthread, thus I think the change below is needed. Try = this. >=20 > diff --git a/sys/ufs/ffs/ffs_softdep.c b/sys/ufs/ffs/ffs_softdep.c > index a6d4441..25fa5d6 100644 > --- a/sys/ufs/ffs/ffs_softdep.c > +++ b/sys/ufs/ffs/ffs_softdep.c > @@ -11380,7 +11380,9 @@ retry: > continue; > } > MNT_IUNLOCK(mp); > - if (vget(lvp, LK_EXCLUSIVE | LK_INTERLOCK, = curthread)) { > + if (VOP_ISLOCKED(lvp) || > + vget(lvp, LK_EXCLUSIVE | LK_INTERLOCK | = LK_NOWAIT, > + curthread)) { > MNT_ILOCK(mp); > continue; > } Ran into the same panic after I applied the patch above with the = repro steps I described before. One thing that I noticed is that the = issue isn't as easy to reproduce unless you add the dd in parallel with = the make operation. Thanks, -Garrett= From owner-freebsd-current@FreeBSD.ORG Thu May 5 17:30:21 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E02F4106564A; Thu, 5 May 2011 17:30:20 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.212.176]) by mx1.freebsd.org (Postfix) with ESMTP id B3C7C8FC19; Thu, 5 May 2011 17:30:20 +0000 (UTC) Received: by pxi11 with SMTP id 11so1846059pxi.7 for ; Thu, 05 May 2011 10:30:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.4.129 with SMTP id k1mr3431581pbk.72.1304616619164; Thu, 05 May 2011 10:30:19 -0700 (PDT) Received: by 10.68.40.4 with HTTP; Thu, 5 May 2011 10:30:19 -0700 (PDT) In-Reply-To: <20110505155551.GA99006@freebsd.org> References: <201105040107.p4417NTR048534@pozo.com> <4DC0F46C.3020806@FreeBSD.org> <201105041344.p44DiOId032272@pozo.com> <4DC160B9.5060004@FreeBSD.org> <4DC2A0E5.5040602@zedat.fu-berlin.de> <20110505135458.GA79622@freebsd.org> <20110505155551.GA99006@freebsd.org> Date: Thu, 5 May 2011 19:30:19 +0200 Message-ID: From: Olivier Smedts To: Roman Divacky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "O. Hartmann" , current@freebsd.org Subject: Re: Clang error make buildworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 17:30:21 -0000 2011/5/5 Roman Divacky : > Can you invoke this very same command (ie. linking) with -### and show me= ? > Does it work when you try to link the same .o files without specifying > -march=3Dnative ? My system has previously been compiled with clang and "-march=3Dcore2". It's a corei7. With "-march=3Dnative" in make.conf, after the failed buildworld I cd in /usr/obj/usr/src/libexec/atrun/ and : # clang -O2 -pipe -march=3Dnative -fomit-frame-pointer -DATJOB_DIR=3D\"/var/at/jobs/\" -DLFILE=3D\"/var/at/jobs/.lockfile\" -DLOADAVG_MX=3D1.5 -DATSPOOL_DIR=3D\"/var/at/spool\" -DVERSION=3D\"2.9\" -DDAEMON_UID=3D1 -DDAEMON_GID=3D1 -DDEFAULT_BATCH_QUEUE=3D\'E\' -DDEFAULT_AT_QUEUE=3D\'c\' -DPERM_PATH=3D\"/var/at/\" -I/usr/src/libexec/atrun/../../usr.bin/at -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=3Dgnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o atrun atrun.o gloadavg.o -lpam -lutil clang: warning: argument unused during compilation: '-std=3Dgnu99' OK # /usr/obj/usr/src/tmp/usr/bin/clang -O2 -pipe -march=3Dnative -fomit-frame-pointer -DATJOB_DIR=3D\"/var/at/jobs/\" -DLFILE=3D\"/var/at/jobs/.lockfile\" -DLOADAVG_MX=3D1.5 -DATSPOOL_DIR=3D\"/var/at/spool\" -DVERSION=3D\"2.9\" -DDAEMON_UID=3D1 -DDAEMON_GID=3D1 -DDEFAULT_BATCH_QUEUE=3D\'E\' -DDEFAULT_AT_QUEUE=3D\'c\' -DPERM_PATH=3D\"/var/at/\" -I/usr/src/libexec/atrun/../../usr.bin/at -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=3Dgnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o atrun atrun.o gloadavg.o -lpam -lutil FAIL (clang: error: linker command failed with exit code 1 (use -v to see invocation)) # /usr/obj/usr/src/tmp/usr/bin/clang -O2 -pipe -march=3Dnative -fomit-frame-pointer -DATJOB_DIR=3D\"/var/at/jobs/\" -DLFILE=3D\"/var/at/jobs/.lockfile\" -DLOADAVG_MX=3D1.5 -DATSPOOL_DIR=3D\"/var/at/spool\" -DVERSION=3D\"2.9\" -DDAEMON_UID=3D1 -DDAEMON_GID=3D1 -DDEFAULT_BATCH_QUEUE=3D\'E\' -DDEFAULT_AT_QUEUE=3D\'c\' -DPERM_PATH=3D\"/var/at/\" -I/usr/src/libexec/atrun/../../usr.bin/at -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=3Dgnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o atrun atrun.o gloadavg.o -lpam -lutil -### FreeBSD clang version 3.0 (trunk 130700) 20110502 Target: x86_64-undermydesk-freebsd9.0 Thread model: posix clang: warning: argument unused during compilation: '-std=3Dgnu99' "/usr/obj/usr/src/tmp/usr/bin/ld" "--eh-frame-hdr" "-dynamic-linker" "/libexec/ld-elf.so.1" "-o" "atrun" "/usr/obj/usr/src/tmp/usr/lib/crt1.o" "/usr/obj/usr/src/tmp/usr/lib/crti.o" "/usr/obj/usr/src/tmp/usr/lib/crtbegin.o" "-L/usr/obj/usr/src/tmp/usr/lib" "atrun.o" "gloadavg.o" "-lpam" "-lutil" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "/usr/obj/usr/src/tmp/usr/lib/crtend.o" "/usr/obj/usr/src/tmp/usr/lib/crtn.o" Using the bootstrap clang (compiled with -march=3Dnative) and trying to compile atrun, this time using -march=3Dcore2 : # /usr/obj/usr/src/tmp/usr/bin/clang -O2 -pipe -march=3Dcore2 -fomit-frame-pointer -DATJOB_DIR=3D\"/var/at/jobs/\" -DLFILE=3D\"/var/at/jobs/.lockfile\" -DLOADAVG_MX=3D1.5 -DATSPOOL_DIR=3D\"/var/at/spool\" -DVERSION=3D\"2.9\" -DDAEMON_UID=3D1 -DDAEMON_GID=3D1 -DDEFAULT_BATCH_QUEUE=3D\'E\' -DDEFAULT_AT_QUEUE=3D\'c\' -DPERM_PATH=3D\"/var/at/\" -I/usr/src/libexec/atrun/../../usr.bin/at -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=3Dgnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o atrun atrun.o gloadavg.o -lpam -lutil FAIL (same error) When trying to compile the "Host.cpp" you provided (which compiled fine with my system's clang and gcc), still with the bootstrap clang : # /usr/obj/usr/src/tmp/usr/bin/clang -v Host.cpp FreeBSD clang version 3.0 (trunk 130700) 20110502 Target: x86_64-undermydesk-freebsd9.0 Thread model: posix "/usr/obj/usr/src/tmp/usr/bin/clang" -cc1 -triple x86_64-undermydesk-freebsd9.0 -emit-obj -mrelax-all -disable-free -main-file-name Host.cpp -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -momit-leaf-frame-pointer -v -resource-dir /usr/obj/usr/src/tmp/usr/bin/../lib/clang/3.0 -fdeprecated-macro -ferror-limit 19 -fmessage-length 236 -fcxx-exceptions -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-6ijoGC.o -x c++ Host.cpp clang -cc1 version 3.0 based upon llvm 3.0svn hosted on x86_64-undermydesk-freebsd9.0 ignoring nonexistent directory "/usr/obj/usr/src/tmp/usr/include/c++/4.2/backward/backward" ignoring nonexistent directory "/usr/obj/usr/src/tmp/usr/bin/../lib/clang/3.0/include" ignoring duplicate directory "/usr/obj/usr/src/tmp/usr/include/c++/4.2" ignoring duplicate directory "/usr/obj/usr/src/tmp/usr/include/c++/4.2/back= ward" ignoring duplicate directory "/usr/obj/usr/src/tmp/usr/include/c++/4.2/back= ward" #include "..." search starts here: #include <...> search starts here: /usr/obj/usr/src/tmp/usr/include/c++/4.2 /usr/obj/usr/src/tmp/usr/include/c++/4.2/backward /usr/obj/usr/src/tmp/usr/include/clang/3.0 /usr/obj/usr/src/tmp/usr/include End of search list. "/usr/obj/usr/src/tmp/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 -o a.out /usr/obj/usr/src/tmp/usr/lib/crt1.o /usr/obj/usr/src/tmp/usr/lib/crti.o /usr/obj/usr/src/tmp/usr/lib/crtbegin.o -L/usr/obj/usr/src/tmp/usr/lib /tmp/cc-6ijoGC.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/obj/usr/src/tmp/usr/lib/crtend.o /usr/obj/usr/src/tmp/usr/lib/crtn.o /usr/obj/usr/src/tmp/usr/lib/crt1.o: In function `_start': /usr/src/lib/csu/amd64/crt1.c:(.text+0x5d): undefined reference to `atexit' /usr/src/lib/csu/amd64/crt1.c:(.text+0x64): undefined reference to `_init_t= ls' /usr/src/lib/csu/amd64/crt1.c:(.text+0x6e): undefined reference to `atexit' /usr/src/lib/csu/amd64/crt1.c:(.text+0x88): undefined reference to `exit' /tmp/cc-6ijoGC.o: In function `__cxx_global_var_init': Host.cpp:(.text+0xc): undefined reference to `std::ios_base::Init::~Init()' Host.cpp:(.text+0x30): undefined reference to `std::ios_base::Init::Init()' Host.cpp:(.text+0x41): undefined reference to `__cxa_atexit' /tmp/cc-6ijoGC.o: In function `getHostCPUName()': Host.cpp:(.text+0xcb): undefined reference to `std::allocator::allocator()' Host.cpp:(.text+0xe3): undefined reference to `std::basic_string, std::allocator >::basic_string(char const*, std::allocator const&)' Host.cpp:(.text+0xf1): undefined reference to `std::allocator::~allocator()' Host.cpp:(.text+0x112): undefined reference to `std::allocator::~allocator()' Host.cpp:(.text+0x2b5): undefined reference to `memcmp' Host.cpp:(.text+0x32a): undefined reference to `std::allocator::allocator()' [...] Host.cpp:(.text+0x13db): undefined reference to `std::allocator::~allocator()' Host.cpp:(.text+0x13ff): undefined reference to `std::allocator::~allocator()' Host.cpp:(.text+0x141a): undefined reference to `std::allocator::allocator()' Host.cpp:(.text+0x1432): undefined reference to `std::basic_string, std::allocator >::basic_string(char const*, std::allocator const&)' Host.cpp:(.text+0x1443): undefined reference to `std::allocator::~allocator()' Host.cpp:(.text+0x1467): undefined reference to `std::allocator::~allocator()' /tmp/cc-6ijoGC.o: In function `main': Host.cpp:(.text+0x15b7): undefined reference to `std::cout' Host.cpp:(.text+0x15c1): undefined reference to `std::basic_ostream >& std::operator<< >(std::basic_ostream >&, char const*)' Host.cpp:(.text+0x15e2): undefined reference to `std::basic_ostream >& std::operator<< , std::allocator >(std::basic_ostream >&, std::basic_string, std::allocator > const&)' Host.cpp:(.text+0x15f9): undefined reference to `std::basic_ostream >& std::operator<< >(std::basic_ostream >&, char const*)' Host.cpp:(.text+0x160b): undefined reference to `std::basic_string, std::allocator >::~basic_string()' Host.cpp:(.text+0x162c): undefined reference to `std::basic_string, std::allocator >::~basic_string()' Host.cpp:(.text+0x1644): undefined reference to `std::terminate()' /tmp/cc-6ijoGC.o:(.eh_frame+0x47): undefined reference to `__gxx_personalit= y_v0' /usr/obj/usr/src/tmp/usr/lib/libgcc_s.so: undefined reference to `memcpy' /usr/obj/usr/src/tmp/usr/lib/libgcc_s.so: undefined reference to `malloc' /usr/obj/usr/src/tmp/usr/lib/libgcc_s.so: undefined reference to `abort' /usr/obj/usr/src/tmp/usr/lib/libgcc_s.so: undefined reference to `dl_iterate_phdr' /usr/obj/usr/src/tmp/usr/lib/libgcc_s.so: undefined reference to `memset' /usr/obj/usr/src/tmp/usr/lib/libgcc_s.so: undefined reference to `strlen' /usr/obj/usr/src/tmp/usr/lib/libgcc_s.so: undefined reference to `free' clang: error: linker command failed with exit code 1 (use -v to see invocat= ion) --=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-current@FreeBSD.ORG Thu May 5 17:36:05 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2961106564A for ; Thu, 5 May 2011 17:36:05 +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 0113D8FC08 for ; Thu, 5 May 2011 17:36:04 +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 p45Ha0an052658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 May 2011 20:36:01 +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 p45Ha091078322; Thu, 5 May 2011 20:36:00 +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 p45Ha0VX078321; Thu, 5 May 2011 20:36:00 +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: Thu, 5 May 2011 20:36:00 +0300 From: Kostik Belousov To: Garrett Cooper Message-ID: <20110505173600.GB48734@deviant.kiev.zoral.com.ua> References: <201105040559.p445xEJ5024585@chez.mckusick.com> <20110504090718.GN48734@deviant.kiev.zoral.com.ua> <9E4C162F-B4EA-4378-A010-3E8D0D23EA93@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sQwJCUUiTMMw/Obe" Content-Disposition: inline In-Reply-To: <9E4C162F-B4EA-4378-A010-3E8D0D23EA93@gmail.com> 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=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS,SUBJECT_FUZZY_TION autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Kirk McKusick , FreeBSD Current Subject: Re: Nasty non-recursive lockmgr panic on softdep only enabled UFS partition when filesystem full X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 17:36:05 -0000 --sQwJCUUiTMMw/Obe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 05, 2011 at 10:23:47AM -0700, Garrett Cooper wrote: > On May 4, 2011, at 2:07 AM, Kostik Belousov wrote: >=20 > > On Tue, May 03, 2011 at 11:58:49PM -0700, Garrett Cooper wrote: > >> On Tue, May 3, 2011 at 11:42 PM, Garrett Cooper w= rote: > >>> On Tue, May 3, 2011 at 10:59 PM, Kirk McKusick wrote: > >>>>> Date: Tue, 3 May 2011 22:40:26 -0700 > >>>>> Subject: Nasty non-recursive lockmgr panic on softdep only enabled = UFS > >>>>> partition when filesystem full > >>>>> From: Garrett Cooper > >>>>> To: Jeff Roberson , > >>>>> Marshall Kirk McKusick > >>>>> Cc: FreeBSD Current > >>>>>=20 > >>>>> Hi Jeff and Dr. McKusick, > >>>>> Ran into this panic when /usr ran out of space doing a make > >>>>> universe on amd64/r221219 (it took ~15 minutes for the panic to occ= ur > >>>>> after the filesystem ran out of space -- wasn't quite sure what it = was > >>>>> doing at the time): > >>>>>=20 > >>>>> ... > >>>>>=20 > >>>>> Let me know what other commands you would like for me to run in= kgdb. > >>>>> Thanks, > >>>>> -Garrett > >>>>=20 > >>>> You did not indicate whether you are running an 8.X system or a 9-cu= rrent > >>>> system. It would be helpful to know that. > >>>=20 > >>> I've actually been running CURRENT for a few years now, but you're ri= ght -- > >>> I didn't mention that part. > >>>=20 > >>>> Jeff thinks that there may be a potential race in the locking code f= or > >>>> softdep_request_cleanup. If so, this patch for 9-current should fix = it: > >>>>=20 > >>>> Index: ffs_softdep.c > >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>> --- ffs_softdep.c (revision 221385) > >>>> +++ ffs_softdep.c (working copy) > >>>> @@ -11380,7 +11380,8 @@ > >>>> continue; > >>>> } > >>>> MNT_IUNLOCK(mp); > >>>> - if (vget(lvp, LK_EXCLUSIVE | LK_INTERLOCK, c= urthread)) { > >>>> + if (vget(lvp, LK_EXCLUSIVE | LK_NOWAIT | LK_= INTERLOCK, > >>>> + curthread)) { > >>>> MNT_ILOCK(mp); > >>>> continue; > >>>> } > >>>>=20 > >>>> If you are running an 8.X system, hopefully you will be able to appl= y it. > >>>=20 > >>> I've applied it, rebuilt and installed the kernel, and trying to > >>> repro the case again. Will let you know how things go! > >>=20 > >> Happened again with the change. It's really easy to repro: > >>=20 > >> 1. Get a filesystem with UFS+SU > >> 2. Execute something that does a large number of small writes to a par= tition. > >> 3. 'dd if=3D/dev/zero of=3DFOO bs=3D10m' on the same partition > >>=20 > >> The kernel will panic with the issue I discussed above. > >> Thanks! > >=20 > > Jeff' change is required to avoid LORs, but it is not sufficient to > > prevent recursion. We must skip the vnode supplied as a parameter to > > softdep_request_cleanup(). Theoretically, other vnodes might be also > > locked by curthread, thus I think the change below is needed. Try this. > >=20 > > diff --git a/sys/ufs/ffs/ffs_softdep.c b/sys/ufs/ffs/ffs_softdep.c > > index a6d4441..25fa5d6 100644 > > --- a/sys/ufs/ffs/ffs_softdep.c > > +++ b/sys/ufs/ffs/ffs_softdep.c > > @@ -11380,7 +11380,9 @@ retry: > > continue; > > } > > MNT_IUNLOCK(mp); > > - if (vget(lvp, LK_EXCLUSIVE | LK_INTERLOCK, curthread)) { > > + if (VOP_ISLOCKED(lvp) || > > + vget(lvp, LK_EXCLUSIVE | LK_INTERLOCK | LK_NOWAIT, > > + curthread)) { > > MNT_ILOCK(mp); > > continue; > > } >=20 > Ran into the same panic after I applied the patch above with the repro s= teps I described before. One thing that I noticed is that the issue isn't a= s easy to reproduce unless you add the dd in parallel with the make operati= on. Well, I misread your original report. Also, there is another issue that is easily reproducable in similar situation. The latest patch is below. diff --git a/sys/sys/mount.h b/sys/sys/mount.h index 231e3d6..f064053 100644 --- a/sys/sys/mount.h +++ b/sys/sys/mount.h @@ -366,6 +366,8 @@ void __mnt_vnode_markerfree(struct vnode **mvp= , struct mount *mp); #define MNT_LAZY 3 /* push data not written by filesystem syncer */ #define MNT_SUSPEND 4 /* Suspend file system after sync */ =20 +#define MNT_WAIT_ADV 0x10000000 /* MNT_WAIT prevent deadlock */ + /* * Generic file handle */ diff --git a/sys/ufs/ffs/ffs_alloc.c b/sys/ufs/ffs/ffs_alloc.c index e60514d..87837cc 100644 --- a/sys/ufs/ffs/ffs_alloc.c +++ b/sys/ufs/ffs/ffs_alloc.c @@ -420,13 +420,13 @@ nospace: */ if (reclaimed =3D=3D 0) { reclaimed =3D 1; - softdep_request_cleanup(fs, vp, cred, FLUSH_BLOCKS_WAIT); - UFS_UNLOCK(ump); if (bp) { + UFS_UNLOCK(ump); brelse(bp); bp =3D NULL; + UFS_LOCK(ump); } - UFS_LOCK(ump); + softdep_request_cleanup(fs, vp, cred, FLUSH_BLOCKS_WAIT); goto retry; } UFS_UNLOCK(ump); diff --git a/sys/ufs/ffs/ffs_extern.h b/sys/ufs/ffs/ffs_extern.h index d819c8a..d12e1dc 100644 --- a/sys/ufs/ffs/ffs_extern.h +++ b/sys/ufs/ffs/ffs_extern.h @@ -141,7 +141,7 @@ void softdep_setup_inofree(struct mount *, struct buf *= , ino_t, void softdep_setup_sbupdate(struct ufsmount *, struct fs *, struct buf *); void *softdep_setup_trunc(struct vnode *vp, off_t length, int flags); void softdep_fsync_mountdev(struct vnode *); -int softdep_sync_metadata(struct vnode *); +int softdep_sync_metadata(struct vnode *, int flags); int softdep_process_worklist(struct mount *, int); int softdep_fsync(struct vnode *); int softdep_waitidle(struct mount *); diff --git a/sys/ufs/ffs/ffs_softdep.c b/sys/ufs/ffs/ffs_softdep.c index a6d4441..0b66e68 100644 --- a/sys/ufs/ffs/ffs_softdep.c +++ b/sys/ufs/ffs/ffs_softdep.c @@ -492,7 +492,7 @@ softdep_flushworklist(oldmnt, countp, td) } =20 int -softdep_sync_metadata(struct vnode *vp) +softdep_sync_metadata(struct vnode *vp, int flags) { =20 return (0); @@ -733,7 +733,7 @@ static void unlinked_inodedep(struct mount *, struct in= odedep *); static void clear_unlinked_inodedep(struct inodedep *); static struct inodedep *first_unlinked_inodedep(struct ufsmount *); static int flush_pagedep_deps(struct vnode *, struct mount *, - struct diraddhd *); + struct diraddhd *, int); static void free_pagedep(struct pagedep *); static int flush_newblk_dep(struct vnode *, struct mount *, ufs_lbn_t); static int flush_inodedep_deps(struct mount *, ino_t); @@ -10662,7 +10662,7 @@ restart: * associated with the file. If any I/O errors occur, they are returned. */ int -softdep_sync_metadata(struct vnode *vp) +softdep_sync_metadata(struct vnode *vp, int flags) { struct pagedep *pagedep; struct allocindir *aip; @@ -10792,7 +10792,8 @@ loop: continue; if ((error =3D flush_pagedep_deps(vp, wk->wk_mp, - &pagedep->pd_diraddhd[i]))) { + &pagedep->pd_diraddhd[i], + flags))) { FREE_LOCK(&lk); goto loop_end; } @@ -11056,10 +11057,11 @@ flush_newblk_dep(vp, mp, lbn) * Called with splbio blocked. */ static int -flush_pagedep_deps(pvp, mp, diraddhdp) +flush_pagedep_deps(pvp, mp, diraddhdp, flags) struct vnode *pvp; struct mount *mp; struct diraddhd *diraddhdp; + int flags; { struct inodedep *inodedep; struct inoref *inoref; @@ -11069,8 +11071,13 @@ flush_pagedep_deps(pvp, mp, diraddhdp) int error =3D 0; struct buf *bp; ino_t inum; + int lkflags; =20 ump =3D VFSTOUFS(mp); + lkflags =3D LK_EXCLUSIVE; + if ((flags & MNT_WAIT_ADV) !=3D 0) + lkflags |=3D LK_NOWAIT; + restart: while ((dap =3D LIST_FIRST(diraddhdp)) !=3D NULL) { /* @@ -11112,7 +11119,7 @@ restart: } if (dap->da_state & MKDIR_BODY) { FREE_LOCK(&lk); - if ((error =3D ffs_vgetf(mp, inum, LK_EXCLUSIVE, &vp, + if ((error =3D ffs_vgetf(mp, inum, lkflags, &vp, FFSV_FORCEINSMQ))) break; error =3D flush_newblk_dep(vp, mp, 0); @@ -11176,7 +11183,7 @@ retry: */ if (dap =3D=3D LIST_FIRST(diraddhdp)) { FREE_LOCK(&lk); - if ((error =3D ffs_vgetf(mp, inum, LK_EXCLUSIVE, &vp, + if ((error =3D ffs_vgetf(mp, inum, lkflags, &vp, FFSV_FORCEINSMQ))) break; error =3D ffs_update(vp, MNT_WAIT); @@ -11379,17 +11386,17 @@ retry: VI_UNLOCK(lvp); continue; } - MNT_IUNLOCK(mp); - if (vget(lvp, LK_EXCLUSIVE | LK_INTERLOCK, curthread)) { - MNT_ILOCK(mp); + if (vget(lvp, LK_EXCLUSIVE | LK_INTERLOCK | LK_NOWAIT, + curthread)) { continue; } + MNT_IUNLOCK(mp); if (lvp->v_vflag & VV_NOSYNC) { /* unlinked */ vput(lvp); MNT_ILOCK(mp); continue; } - (void) ffs_syncvnode(lvp, MNT_WAIT); + (void) ffs_syncvnode(lvp, MNT_WAIT | MNT_WAIT_ADV); vput(lvp); MNT_ILOCK(mp); } diff --git a/sys/ufs/ffs/ffs_vnops.c b/sys/ufs/ffs/ffs_vnops.c index cf6a5a8..c73e2a5 100644 --- a/sys/ufs/ffs/ffs_vnops.c +++ b/sys/ufs/ffs/ffs_vnops.c @@ -216,9 +216,11 @@ ffs_syncvnode(struct vnode *vp, int waitfor) struct bufobj *bo; struct buf *bp; struct buf *nbp; - int s, error, wait, passes, skipmeta; + int s, error, wait, passes, skipmeta, wait_adv; ufs_lbn_t lbn; =20 + wait_adv =3D waitfor & MNT_WAIT_ADV; + waitfor &=3D ~MNT_WAIT_ADV; wait =3D (waitfor =3D=3D MNT_WAIT); lbn =3D lblkno(ip->i_fs, (ip->i_size + ip->i_fs->fs_bsize - 1)); bo =3D &vp->v_bufobj; @@ -328,7 +330,7 @@ loop: * with the vnode has been written. */ splx(s); - if ((error =3D softdep_sync_metadata(vp)) !=3D 0) + if ((error =3D softdep_sync_metadata(vp, wait_adv)) !=3D 0) return (error); s =3D splbio(); =20 --sQwJCUUiTMMw/Obe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk3C4AAACgkQC3+MBN1Mb4i9SQCfQ9R48iy4hvi+sp+42WvpjjCk lI0AoIHZ+R0+wqmTQ05gD3WWZrg+MUO+ =VBOf -----END PGP SIGNATURE----- --sQwJCUUiTMMw/Obe-- From owner-freebsd-current@FreeBSD.ORG Thu May 5 17:41:36 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CF77106564A for ; Thu, 5 May 2011 17:41:36 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [46.28.110.116]) by mx1.freebsd.org (Postfix) with ESMTP id 359398FC12 for ; Thu, 5 May 2011 17:41:35 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id 7F5997F385A; Thu, 5 May 2011 19:41:34 +0200 (CEST) Date: Thu, 5 May 2011 19:41:34 +0200 From: Roman Divacky To: Olivier Smedts Message-ID: <20110505174134.GA7107@freebsd.org> References: <201105040107.p4417NTR048534@pozo.com> <4DC0F46C.3020806@FreeBSD.org> <201105041344.p44DiOId032272@pozo.com> <4DC160B9.5060004@FreeBSD.org> <4DC2A0E5.5040602@zedat.fu-berlin.de> <20110505135458.GA79622@freebsd.org> <20110505155551.GA99006@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 Cc: "O. Hartmann" , current@freebsd.org Subject: Re: Clang error make buildworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 17:41:36 -0000 > # /usr/obj/usr/src/tmp/usr/bin/clang -O2 -pipe -march=native > -fomit-frame-pointer -DATJOB_DIR=\"/var/at/jobs/\" > -DLFILE=\"/var/at/jobs/.lockfile\" -DLOADAVG_MX=1.5 > -DATSPOOL_DIR=\"/var/at/spool\" -DVERSION=\"2.9\" -DDAEMON_UID=1 > -DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' > -DPERM_PATH=\"/var/at/\" -I/usr/src/libexec/atrun/../../usr.bin/at > -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 > -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k > -Wno-uninitialized -Wno-pointer-sign -o atrun atrun.o gloadavg.o -lpam > -lutil > > FAIL (clang: error: linker command failed with exit code 1 (use -v to > see invocation)) Can you run this in gdb and show me backtrace? Also, what version is your binutils? From owner-freebsd-current@FreeBSD.ORG Thu May 5 17:43:04 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF580106564A for ; Thu, 5 May 2011 17:43:04 +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 847878FC1E for ; Thu, 5 May 2011 17:43:04 +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 38D9946B32; Thu, 5 May 2011 13:43:04 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CC1AA8A027; Thu, 5 May 2011 13:43:03 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 5 May 2011 13:43:02 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <5BEF0D0F-3717-42CE-ADF7-8876558004CA@gmail.com> In-Reply-To: <5BEF0D0F-3717-42CE-ADF7-8876558004CA@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105051343.02898.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 05 May 2011 13:43:03 -0400 (EDT) Cc: Damjan Marion Subject: Re: atkbdc broken on current ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 17:43:04 -0000 On Thursday, May 05, 2011 9:21:04 am Damjan Marion wrote: > > Hi, > > I have issue with old HP DL380G3 server. When I use ILO virtual console to manage server. Seems that 9-CURRENT fails to detect atkbdc. > When I boot 8.2-RELEASE it works well. > > 8.2 dmesg shows: > > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > > 9.0: > > atkbdc0: failed to probe at port 0x60 on isa0 > > Is this a known issue? > > Should I enable some additional outputs, like KBDIO_DEBUG? I suspect this is a resource issue stemming from changes I made to the acpi(4) bus driver quite a while ago to make it use rman_reserve_resource(). Can you capture a full verbose dmesg from 9 along with devinfo -rv and devinfo -ur output from 9? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu May 5 18:16:29 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB1B1106566B for ; Thu, 5 May 2011 18:16:29 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9B6978FC0C for ; Thu, 5 May 2011 18:16:29 +0000 (UTC) Received: by pwj8 with SMTP id 8so1445878pwj.13 for ; Thu, 05 May 2011 11:16:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.35.228 with SMTP id l4mr3741954pbj.5.1304619389071; Thu, 05 May 2011 11:16:29 -0700 (PDT) Received: by 10.68.40.4 with HTTP; Thu, 5 May 2011 11:16:28 -0700 (PDT) In-Reply-To: References: <4D94A354.9080903@sentex.net> <4DC07013.9070707@gmx.net> <4DC078BD.9080908@gmx.net> Date: Thu, 5 May 2011 20:16:28 +0200 Message-ID: From: Olivier Smedts To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD current mailing list , Arnaud Lacombe Subject: Re: problems with em(4) since update to driver 7.2.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 18:16:29 -0000 2011/5/5 Jack Vogel : > Anyway, I see the problematic code path, its only when > you skip the while loop altogether. I'm surprised the compiler > did not complain about this, its usually so anal. Could it be related to the compiler (clang) or some optimization flags ? --=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-current@FreeBSD.ORG Thu May 5 18:25:10 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E65891065677 for ; Thu, 5 May 2011 18:25:10 +0000 (UTC) (envelope-from jfvogel@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 8A0A68FC16 for ; Thu, 5 May 2011 18:25:10 +0000 (UTC) Received: by qwc9 with SMTP id 9so2131974qwc.13 for ; Thu, 05 May 2011 11:25:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WVajPLza1MEr6H+w6TZ3IBnJEEd9mdaKUeFZWDAXJBs=; b=YHJ4ZuqbpDDjVAD78eLNWFnASzUjjWnaSj0X0AW6d8WEnYygqti49T+d9X5qBJYgk8 M92Eqc/FCJxzrHF9McbnDfeKV1QQcQbk82GmnbexWOs0v8b6uYU+HTSrdv41wGaixauL oHXHu1PSdhBwPCaCry4U9LnGX+gIy4RVX81t4= 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=acarHZJIds0n0JW86kqQ9dgSgA0ICZKmmE63jNJehIuvrViXoorzLZXiUUN/mBmkIa xijwlL0KEPq8tAkf5Qf/sngR9wo5jmabDSZ+HLbLM+9Z4/5zTrzCQhZY1hObN2+/66vC 2ukzhyvZS1Lop5mQl+bNzoljpGX042E+B/dl8= MIME-Version: 1.0 Received: by 10.52.112.227 with SMTP id it3mr476453vdb.84.1304619909527; Thu, 05 May 2011 11:25:09 -0700 (PDT) Received: by 10.52.184.169 with HTTP; Thu, 5 May 2011 11:25:09 -0700 (PDT) In-Reply-To: References: <4D94A354.9080903@sentex.net> <4DC07013.9070707@gmx.net> <4DC078BD.9080908@gmx.net> Date: Thu, 5 May 2011 11:25:09 -0700 Message-ID: From: Jack Vogel To: Olivier Smedts Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD current mailing list , Arnaud Lacombe Subject: Re: problems with em(4) since update to driver 7.2.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 18:25:11 -0000 Not sure, I wondered if those seeing this had some special sequence of actions they took for granted that is different than what we do in house... In any case, the init really is ultimately a correctness thing, so let's just call it good :) Jack On Thu, May 5, 2011 at 11:16 AM, Olivier Smedts wrote: > 2011/5/5 Jack Vogel : > > Anyway, I see the problematic code path, its only when > > you skip the while loop altogether. I'm surprised the compiler > > did not complain about this, its usually so anal. > > Could it be related to the compiler (clang) or some optimization flags ? > > -- > Olivier Smedts _ > ASCII ribbon campaign ( ) > e-mail: olivier@gid0.org - against HTML email & vCards X > www: http://www.gid0.org - against proprietary attachments / \ > > "Il y a seulement 10 sortes de gens dans le monde : > ceux qui comprennent le binaire, > et ceux qui ne le comprennent pas." > From owner-freebsd-current@FreeBSD.ORG Thu May 5 19:49:50 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75FD410657C4 for ; Thu, 5 May 2011 19:49:50 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 269C08FC1F for ; Thu, 5 May 2011 19:49:49 +0000 (UTC) Received: by vxc34 with SMTP id 34so3553924vxc.13 for ; Thu, 05 May 2011 12:49:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xR9VzUQzJptCC6s4aUw2xEm4y8rQJko4s/brv7ukAXU=; b=Beq+BXQNGY1JLBvr2wjzMZCxsIFqeddVkObI10wN1fGVqzGdmqglYpLSsHmL38k5yS pEx67fQVLnjVBB8qi8eK5Xku2fcnjGw8WSx82g0UQIQ+qKjHfeOSuTJcHquEsjAd2R1B qA0GfZbv/mU6MIFMq1jdtykKBehtcpYs1KWTs= 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=Wy4zIMaEQmV/Wau1wXAO1SveyJy3sgcjMiZKlCL5toTyiK2RXd0ZDTkWXMXWoT/bGw A+qUKaRq58OOAjQ1ZMV2kR+PT497WYXgo6/Z93lDifOI6CXmW7qBlERMuoaK76At7a7n l+EMh0QLGjF2zAkoPM7M40ncASGwIqTNuw1/4= MIME-Version: 1.0 Received: by 10.52.100.10 with SMTP id eu10mr3556966vdb.208.1304624988775; Thu, 05 May 2011 12:49:48 -0700 (PDT) Received: by 10.220.199.130 with HTTP; Thu, 5 May 2011 12:49:48 -0700 (PDT) In-Reply-To: <20110505173600.GB48734@deviant.kiev.zoral.com.ua> References: <201105040559.p445xEJ5024585@chez.mckusick.com> <20110504090718.GN48734@deviant.kiev.zoral.com.ua> <9E4C162F-B4EA-4378-A010-3E8D0D23EA93@gmail.com> <20110505173600.GB48734@deviant.kiev.zoral.com.ua> Date: Thu, 5 May 2011 12:49:48 -0700 Message-ID: From: Garrett Cooper To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kirk McKusick , FreeBSD Current Subject: Re: Nasty non-recursive lockmgr panic on softdep only enabled UFS partition when filesystem full X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 19:49:50 -0000 On Thu, May 5, 2011 at 10:36 AM, Kostik Belousov wrot= e: > On Thu, May 05, 2011 at 10:23:47AM -0700, Garrett Cooper wrote: >> On May 4, 2011, at 2:07 AM, Kostik Belousov wrote: >> >> > On Tue, May 03, 2011 at 11:58:49PM -0700, Garrett Cooper wrote: >> >> On Tue, May 3, 2011 at 11:42 PM, Garrett Cooper = wrote: >> >>> On Tue, May 3, 2011 at 10:59 PM, Kirk McKusick wrote: >> >>>>> Date: Tue, 3 May 2011 22:40:26 -0700 >> >>>>> Subject: Nasty non-recursive lockmgr panic on softdep only enabled= UFS >> >>>>> =A0partition when filesystem full >> >>>>> From: Garrett Cooper >> >>>>> To: Jeff Roberson , >> >>>>> =A0 =A0 =A0 =A0 Marshall Kirk McKusick >> >>>>> Cc: FreeBSD Current >> >>>>> >> >>>>> Hi Jeff and Dr. McKusick, >> >>>>> =A0 =A0 Ran into this panic when /usr ran out of space doing a mak= e >> >>>>> universe on amd64/r221219 (it took ~15 minutes for the panic to oc= cur >> >>>>> after the filesystem ran out of space -- wasn't quite sure what it= was >> >>>>> doing at the time): >> >>>>> >> >>>>> ... >> >>>>> >> >>>>> =A0 =A0 Let me know what other commands you would like for me to r= un in kgdb. >> >>>>> Thanks, >> >>>>> -Garrett >> >>>> >> >>>> You did not indicate whether you are running an 8.X system or a 9-c= urrent >> >>>> system. It would be helpful to know that. >> >>> >> >>> I've actually been running CURRENT for a few years now, but you're r= ight -- >> >>> I didn't mention that part. >> >>> >> >>>> Jeff thinks that there may be a potential race in the locking code = for >> >>>> softdep_request_cleanup. If so, this patch for 9-current should fix= it: >> >>>> >> >>>> Index: ffs_softdep.c >> >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >>>> --- ffs_softdep.c =A0 =A0 =A0 (revision 221385) >> >>>> +++ ffs_softdep.c =A0 =A0 =A0 (working copy) >> >>>> @@ -11380,7 +11380,8 @@ >> >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cont= inue; >> >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >> >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MNT_IUNLOCK(mp); >> >>>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (vget(lvp, LK_EXCL= USIVE | LK_INTERLOCK, curthread)) { >> >>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (vget(lvp, LK_EXCL= USIVE | LK_NOWAIT | LK_INTERLOCK, >> >>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 curthread)) { >> >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MNT_= ILOCK(mp); >> >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cont= inue; >> >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >> >>>> >> >>>> If you are running an 8.X system, hopefully you will be able to app= ly it. >> >>> >> >>> =A0 =A0I've applied it, rebuilt and installed the kernel, and trying= to >> >>> repro the case again. Will let you know how things go! >> >> >> >> =A0 =A0Happened again with the change. It's really easy to repro: >> >> >> >> 1. Get a filesystem with UFS+SU >> >> 2. Execute something that does a large number of small writes to a pa= rtition. >> >> 3. 'dd if=3D/dev/zero of=3DFOO bs=3D10m' on the same partition >> >> >> >> =A0 =A0The kernel will panic with the issue I discussed above. >> >> Thanks! >> > >> > Jeff' change is required to avoid LORs, but it is not sufficient to >> > prevent recursion. We must skip the vnode supplied as a parameter to >> > softdep_request_cleanup(). Theoretically, other vnodes might be also >> > locked by curthread, thus I think the change below is needed. Try this= . >> > >> > diff --git a/sys/ufs/ffs/ffs_softdep.c b/sys/ufs/ffs/ffs_softdep.c >> > index a6d4441..25fa5d6 100644 >> > --- a/sys/ufs/ffs/ffs_softdep.c >> > +++ b/sys/ufs/ffs/ffs_softdep.c >> > @@ -11380,7 +11380,9 @@ retry: >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 continue; >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MNT_IUNLOCK(mp); >> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (vget(lvp, LK_EXCLUSIVE | LK_= INTERLOCK, curthread)) { >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (VOP_ISLOCKED(lvp) || >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 vget(lvp, LK_EXCLUSIVE |= LK_INTERLOCK | LK_NOWAIT, >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 curthread)) { >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MNT_ILOCK(mp); >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 continue; >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } >> >> =A0 =A0 =A0 Ran into the same panic after I applied the patch above with= the repro steps I described before. One thing that I noticed is that the i= ssue isn't as easy to reproduce unless you add the dd in parallel with the = make operation. > > Well, I misread your original report. Also, there is another issue > that is easily reproducable in similar situation. The latest patch > is below. > > diff --git a/sys/sys/mount.h b/sys/sys/mount.h > index 231e3d6..f064053 100644 > --- a/sys/sys/mount.h > +++ b/sys/sys/mount.h > @@ -366,6 +366,8 @@ void =A0 =A0 =A0 =A0 =A0__mnt_vnode_markerfree(struct= vnode **mvp, struct mount *mp); > =A0#define MNT_LAZY =A0 =A0 =A0 3 =A0 =A0 =A0 /* push data not written by= filesystem syncer */ > =A0#define MNT_SUSPEND =A0 =A04 =A0 =A0 =A0 /* Suspend file system after = sync */ > > +#define =A0 =A0 =A0 =A0MNT_WAIT_ADV =A0 =A00x10000000 =A0 =A0 =A0/* MNT_= WAIT prevent deadlock */ > + > =A0/* > =A0* Generic file handle > =A0*/ > diff --git a/sys/ufs/ffs/ffs_alloc.c b/sys/ufs/ffs/ffs_alloc.c > index e60514d..87837cc 100644 > --- a/sys/ufs/ffs/ffs_alloc.c > +++ b/sys/ufs/ffs/ffs_alloc.c > @@ -420,13 +420,13 @@ nospace: > =A0 =A0 =A0 =A0 */ > =A0 =A0 =A0 =A0if (reclaimed =3D=3D 0) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reclaimed =3D 1; > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 softdep_request_cleanup(fs, vp, cred, FLUSH= _BLOCKS_WAIT); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 UFS_UNLOCK(ump); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (bp) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 UFS_UNLOCK(ump); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0brelse(bp); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bp =3D NULL; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 UFS_LOCK(ump); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 UFS_LOCK(ump); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 softdep_request_cleanup(fs, vp, cred, FLUSH= _BLOCKS_WAIT); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto retry; > =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0UFS_UNLOCK(ump); > diff --git a/sys/ufs/ffs/ffs_extern.h b/sys/ufs/ffs/ffs_extern.h > index d819c8a..d12e1dc 100644 > --- a/sys/ufs/ffs/ffs_extern.h > +++ b/sys/ufs/ffs/ffs_extern.h > @@ -141,7 +141,7 @@ void =A0 =A0 =A0 =A0softdep_setup_inofree(struct moun= t *, struct buf *, ino_t, > =A0void =A0 softdep_setup_sbupdate(struct ufsmount *, struct fs *, struct= buf *); > =A0void =A0 *softdep_setup_trunc(struct vnode *vp, off_t length, int flag= s); > =A0void =A0 softdep_fsync_mountdev(struct vnode *); > -int =A0 =A0softdep_sync_metadata(struct vnode *); > +int =A0 =A0softdep_sync_metadata(struct vnode *, int flags); > =A0int =A0 =A0 softdep_process_worklist(struct mount *, int); > =A0int =A0 =A0 softdep_fsync(struct vnode *); > =A0int =A0 =A0softdep_waitidle(struct mount *); > diff --git a/sys/ufs/ffs/ffs_softdep.c b/sys/ufs/ffs/ffs_softdep.c > index a6d4441..0b66e68 100644 > --- a/sys/ufs/ffs/ffs_softdep.c > +++ b/sys/ufs/ffs/ffs_softdep.c > @@ -492,7 +492,7 @@ softdep_flushworklist(oldmnt, countp, td) > =A0} > > =A0int > -softdep_sync_metadata(struct vnode *vp) > +softdep_sync_metadata(struct vnode *vp, int flags) > =A0{ > > =A0 =A0 =A0 =A0return (0); > @@ -733,7 +733,7 @@ static =A0 =A0 =A0void unlinked_inodedep(struct mount= *, struct inodedep *); > =A0static void clear_unlinked_inodedep(struct inodedep *); > =A0static struct inodedep *first_unlinked_inodedep(struct ufsmount *); > =A0static int flush_pagedep_deps(struct vnode *, struct mount *, > - =A0 =A0 =A0 =A0 =A0 struct diraddhd *); > + =A0 =A0 =A0 =A0 =A0 struct diraddhd *, int); > =A0static void free_pagedep(struct pagedep *); > =A0static int flush_newblk_dep(struct vnode *, struct mount *, ufs_lbn_t)= ; > =A0static int flush_inodedep_deps(struct mount *, ino_t); > @@ -10662,7 +10662,7 @@ restart: > =A0* associated with the file. If any I/O errors occur, they are returned= . > =A0*/ > =A0int > -softdep_sync_metadata(struct vnode *vp) > +softdep_sync_metadata(struct vnode *vp, int flags) > =A0{ > =A0 =A0 =A0 =A0struct pagedep *pagedep; > =A0 =A0 =A0 =A0struct allocindir *aip; > @@ -10792,7 +10792,8 @@ loop: > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0continue; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ((error= =3D > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fl= ush_pagedep_deps(vp, wk->wk_mp, > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 &pagedep->pd_diraddhd[i]))) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 &pagedep->pd_diraddhd[i], > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 flags))) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0FREE_LOCK(&lk); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0goto loop_end; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > @@ -11056,10 +11057,11 @@ flush_newblk_dep(vp, mp, lbn) > =A0* Called with splbio blocked. > =A0*/ > =A0static int > -flush_pagedep_deps(pvp, mp, diraddhdp) > +flush_pagedep_deps(pvp, mp, diraddhdp, flags) > =A0 =A0 =A0 =A0struct vnode *pvp; > =A0 =A0 =A0 =A0struct mount *mp; > =A0 =A0 =A0 =A0struct diraddhd *diraddhdp; > + =A0 =A0 =A0 int flags; > =A0{ > =A0 =A0 =A0 =A0struct inodedep *inodedep; > =A0 =A0 =A0 =A0struct inoref *inoref; > @@ -11069,8 +11071,13 @@ flush_pagedep_deps(pvp, mp, diraddhdp) > =A0 =A0 =A0 =A0int error =3D 0; > =A0 =A0 =A0 =A0struct buf *bp; > =A0 =A0 =A0 =A0ino_t inum; > + =A0 =A0 =A0 int lkflags; > > =A0 =A0 =A0 =A0ump =3D VFSTOUFS(mp); > + =A0 =A0 =A0 lkflags =3D LK_EXCLUSIVE; > + =A0 =A0 =A0 if ((flags & MNT_WAIT_ADV) !=3D 0) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 lkflags |=3D LK_NOWAIT; > + > =A0restart: > =A0 =A0 =A0 =A0while ((dap =3D LIST_FIRST(diraddhdp)) !=3D NULL) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* > @@ -11112,7 +11119,7 @@ restart: > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (dap->da_state & MKDIR_BODY) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0FREE_LOCK(&lk); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((error =3D ffs_vgetf(mp= , inum, LK_EXCLUSIVE, &vp, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((error =3D ffs_vgetf(mp= , inum, lkflags, &vp, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0FFSV_FORCEINSMQ))) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0error =3D flush_newblk_dep= (vp, mp, 0); > @@ -11176,7 +11183,7 @@ retry: > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (dap =3D=3D LIST_FIRST(diraddhdp)) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0FREE_LOCK(&lk); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((error =3D ffs_vgetf(mp= , inum, LK_EXCLUSIVE, &vp, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((error =3D ffs_vgetf(mp= , inum, lkflags, &vp, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0FFSV_FORCEINSMQ))) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0error =3D ffs_update(vp, M= NT_WAIT); > @@ -11379,17 +11386,17 @@ retry: > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0VI_UNLOCK(= lvp); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0continue; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MNT_IUNLOCK(mp); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (vget(lvp, LK_EXCLUSIVE = | LK_INTERLOCK, curthread)) { > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MNT_ILOCK(m= p); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (vget(lvp, LK_EXCLUSIVE = | LK_INTERLOCK | LK_NOWAIT, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 curthread)) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0continue; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MNT_IUNLOCK(mp); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (lvp->v_vflag & VV_NOSY= NC) { /* unlinked */ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vput(lvp); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MNT_ILOCK(= mp); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0continue; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (void) ffs_syncvnode(lvp, M= NT_WAIT); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (void) ffs_syncvnode(lvp, M= NT_WAIT | MNT_WAIT_ADV); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vput(lvp); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MNT_ILOCK(mp); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > diff --git a/sys/ufs/ffs/ffs_vnops.c b/sys/ufs/ffs/ffs_vnops.c > index cf6a5a8..c73e2a5 100644 > --- a/sys/ufs/ffs/ffs_vnops.c > +++ b/sys/ufs/ffs/ffs_vnops.c > @@ -216,9 +216,11 @@ ffs_syncvnode(struct vnode *vp, int waitfor) > =A0 =A0 =A0 =A0struct bufobj *bo; > =A0 =A0 =A0 =A0struct buf *bp; > =A0 =A0 =A0 =A0struct buf *nbp; > - =A0 =A0 =A0 int s, error, wait, passes, skipmeta; > + =A0 =A0 =A0 int s, error, wait, passes, skipmeta, wait_adv; > =A0 =A0 =A0 =A0ufs_lbn_t lbn; > > + =A0 =A0 =A0 wait_adv =3D waitfor & MNT_WAIT_ADV; > + =A0 =A0 =A0 waitfor &=3D ~MNT_WAIT_ADV; > =A0 =A0 =A0 =A0wait =3D (waitfor =3D=3D MNT_WAIT); > =A0 =A0 =A0 =A0lbn =3D lblkno(ip->i_fs, (ip->i_size + ip->i_fs->fs_bsize = - 1)); > =A0 =A0 =A0 =A0bo =3D &vp->v_bufobj; > @@ -328,7 +330,7 @@ loop: > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * with the vnode has been written. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0splx(s); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((error =3D softdep_sync_metadata(vp)) != =3D 0) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((error =3D softdep_sync_metadata(vp, wa= it_adv)) !=3D 0) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (error); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0s =3D splbio(); Things look ok with that patch and the one that Jeff provided for the LOR, taking into account your style change with the flag list. Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Thu May 5 20:04:42 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 152F6106566B; Thu, 5 May 2011 20:04:42 +0000 (UTC) (envelope-from mavbsd@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 DF5C58FC19; Thu, 5 May 2011 20:04:40 +0000 (UTC) Received: by fxm11 with SMTP id 11so2474348fxm.13 for ; Thu, 05 May 2011 13:04:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature: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=A9jfSEzOir6DY2HnOzRZokNuel3gRlvftcefQsx4gn8=; b=LGOvip57uhMl1kUopw2Mk1BtBFUnFpzV9S27sc581Dp6vMrkRkY5pYjRyg2noOI2GP +4lelkZJ5StnnSZVHSIrCG0tsZwEzpFNGq51pVlXZux5lyjvdIhPIpEp6Vj642UJa71h VIHcD37/+grrWMSow7paJU9TojuIG01wCAnTc= 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=aynP5IxUlKRKwtTUB8hZFgc87hzI+oz0eVq8PKi0CovXXsX0RDQddSxDIOXwP4cvho lBU479rlHPsLduYciMgqYHqyfJaD3aB55SvJE1Rb6zo7yWmhUKDIvRUTAbFWcmNaZePy wqp9jTJFoq+jn2aY15zkyZhoXFOft6cK5UBX8= Received: by 10.223.85.195 with SMTP id p3mr222535fal.0.1304625879667; Thu, 05 May 2011 13:04:39 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id o17sm863540fal.1.2011.05.05.13.04.37 (version=SSLv3 cipher=OTHER); Thu, 05 May 2011 13:04:38 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DC302B7.7090007@FreeBSD.org> Date: Thu, 05 May 2011 23:04:07 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Julian Elischer References: <4DB620CB.50302@FreeBSD.org> <20110426103741.GA25031@freebsd.org> <4DB8AA4B.1070502@FreeBSD.org> <4DB8F833.7090604@FreeBSD.org> <4DB92143.5010108@freebsd.org> <4DB92215.2060501@FreeBSD.org> In-Reply-To: <4DB92215.2060501@FreeBSD.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Best , Doug Barton , current@freebsd.org, Steve Wills Subject: Re: responsiveness during IO tasks X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 20:04:42 -0000 Alexander Motin wrote: > Julian Elischer wrote: >>> Doug Barton wrote: >>> No problem, just let's hunt things down. I'll wait for that larger post. >>> In meantime, if it is related to eventtimers, it would be good to >>> collect more detailed information. You could try to make timer run >>> during idle (kern.eventtimer.idletick). You could try to switch timer >>> from one-shot to periodic mode (kern.eventtimer.periodic). You could >>> also try to switch to another timer (kern.eventtimer.timer). >> kern.eventtimer.periodic needs to be disabled to run 9.x on xen >> (as of a few months ago) > > Yes, but it needs to be enabled (it is disabled by default). I remember > about it and going to experiment with it nearest time. Problem with Xen HVM freeze in one-shot mode workarounded by r221508. Also, looking on Xen 4.1 sources, seems like problem was already fixed from their side also. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu May 5 20:08:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 012C6106566C; Thu, 5 May 2011 20:08:44 +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 D3CCD8FC18; Thu, 5 May 2011 20:08:43 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id BB02C56166; Thu, 5 May 2011 14:51:06 -0500 (CDT) Date: Thu, 5 May 2011 14:51:06 -0500 From: Mark Linimon To: "O. Hartmann" Message-ID: <20110505195106.GA25920@lonesome.com> References: <4DBDB8D4.6050102@mail.zedat.fu-berlin.de> <4DC04F29.2050401@mail.zedat.fu-berlin.de> <4DC0F98D.3020601@FreeBSD.org> <4DC0FD83.5080504@mail.zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DC0FD83.5080504@mail.zedat.fu-berlin.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Olivier Smedts , freebsd-current@freebsd.org, Dimitry Andric Subject: Re: Building FreeBSD 9.0-CUR/amd64 with CLANG fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 20:08:44 -0000 On Wed, May 04, 2011 at 09:17:23AM +0200, O. Hartmann wrote: > I guess the ports-tree isn't mature for clang. That's correct. mcl From owner-freebsd-current@FreeBSD.ORG Thu May 5 20:17:57 2011 Return-Path: Delivered-To: Current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4570106566C for ; Thu, 5 May 2011 20:17:57 +0000 (UTC) (envelope-from Daan@vehosting.nl) Received: from VM01.VEHosting.nl (VM016.VEHosting.nl [IPv6:2001:1af8:2100:b020::140]) by mx1.freebsd.org (Postfix) with ESMTP id 486D88FC18 for ; Thu, 5 May 2011 20:17:57 +0000 (UTC) Received: from [192.168.45.11] (180-161.ftth.onsbrabantnet.nl [88.159.161.180]) (authenticated bits=0) by VM01.VEHosting.nl (8.14.3/8.13.8) with ESMTP id p45KHuHM006545; Thu, 5 May 2011 22:17:56 +0200 (CEST) (envelope-from Daan@vehosting.nl) From: Daan Vreeken Organization: http://VEHosting.nl/ To: Peter Jeremy Date: Thu, 5 May 2011 22:17:51 +0200 User-Agent: KMail/1.9.10 References: <201105041734.50738.Daan@vehosting.nl> <201105051322.59654.Daan@vehosting.nl> <20110505192802.GA11269@server.vk2pj.dyndns.org> In-Reply-To: <20110505192802.GA11269@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201105052217.51893.Daan@vehosting.nl> x-ve-auth-version: mi-1.1.5 2011-02-07 - Copyright (c) 2008, 2011 - Daan Vreeken - VEHosting x-ve-auth: authenticated as 'pa4dan' on VM01.VEHosting.nl Cc: Current@freebsd.org, Jack Vogel Subject: Re: Interrupt storm with MSI in combination with em1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 20:17:57 -0000 Hi Peter, On Thursday 05 May 2011 21:28:02 Peter Jeremy wrote: > On 2011-May-05 13:22:59 +0200, Daan Vreeken wrote: > >Not yet. I'll reboot the machine later today when I have physical access > > to it to check the BIOS version. I'll keep you informed as soon as I get > > another storm going. > > Depending on the quality of your BIOS (competence of the vendor), you > might find that kenv(8) reports the BIOS version without needing a reboot. > (Look at smbios.bios.* in the output). Great! I didn't know that :) # kenv ... smbios.bios.reldate="07/15/2010" ... smbios.bios.version="0303 " ... smbios.planar.maker="ASUSTeK Computer INC." smbios.planar.product="P7H55-M LX" Version "0402" is the latest and greatest, so it's time to upgrade. According to Asus it "Improves system stability", so let's see if this 'cures' IRQ 16. Thanks, -- Daan Vreeken VEHosting http://VEHosting.nl tel: +31-(0)40-7113050 / +31-(0)6-46210825 KvK nr: 17174380 From owner-freebsd-current@FreeBSD.ORG Thu May 5 20:22:17 2011 Return-Path: Delivered-To: Current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 914A81065686 for ; Thu, 5 May 2011 20:22:17 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3D4B58FC15 for ; Thu, 5 May 2011 20:22:16 +0000 (UTC) Received: by vxc34 with SMTP id 34so3590096vxc.13 for ; Thu, 05 May 2011 13:22:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+WDNGX7Nu7RUjS1EKllm0Mz/JqXOkEW0aNeqq0Pyt/4=; b=IakYk2MnwWM5KQZShtxo5E/fwUEdZWLa+Hb7FwDxZm08gph7h29kWOg7rLgO3B513S NoA/qBlgua0VU33r8oqVRMiJB9Gi83hSeJ0bJYndLv0jF+5/a2b3YOlQskpY7tVcTc8C Q+Wm88TW4xlX2D8HgT1pa7ZdRlquZfWjc9jzE= 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=GNEvnd4zv081/k8qWOeMeL6w0IKolYBf2d12PyplUyx0tcSoRKH3XDpV3OmSvrfjIh hqbKwQCDfkN0RzR2v5opZNLCvzOx72r6bb8TXPhXMVwfjkYp3BBQcW9VZW53wkdPFo5b KyHQJEzw/999LNd19B6eiVOn2AOCM3eALFDhE= MIME-Version: 1.0 Received: by 10.52.111.68 with SMTP id ig4mr108910vdb.4.1304626936015; Thu, 05 May 2011 13:22:16 -0700 (PDT) Received: by 10.52.184.169 with HTTP; Thu, 5 May 2011 13:22:15 -0700 (PDT) In-Reply-To: <201105052217.51893.Daan@vehosting.nl> References: <201105041734.50738.Daan@vehosting.nl> <201105051322.59654.Daan@vehosting.nl> <20110505192802.GA11269@server.vk2pj.dyndns.org> <201105052217.51893.Daan@vehosting.nl> Date: Thu, 5 May 2011 13:22:15 -0700 Message-ID: From: Jack Vogel To: Daan Vreeken Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Current@freebsd.org, Peter Jeremy Subject: Re: Interrupt storm with MSI in combination with em1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 20:22:17 -0000 Cool, thanks for the update! Good luck. Jack On Thu, May 5, 2011 at 1:17 PM, Daan Vreeken wrote: > Hi Peter, > > On Thursday 05 May 2011 21:28:02 Peter Jeremy wrote: > > On 2011-May-05 13:22:59 +0200, Daan Vreeken wrote: > > >Not yet. I'll reboot the machine later today when I have physical access > > > to it to check the BIOS version. I'll keep you informed as soon as I > get > > > another storm going. > > > > Depending on the quality of your BIOS (competence of the vendor), you > > might find that kenv(8) reports the BIOS version without needing a > reboot. > > (Look at smbios.bios.* in the output). > > Great! I didn't know that :) > > # kenv > ... > smbios.bios.reldate="07/15/2010" > ... > smbios.bios.version="0303 " > ... > smbios.planar.maker="ASUSTeK Computer INC." > smbios.planar.product="P7H55-M LX" > > > Version "0402" is the latest and greatest, so it's time to upgrade. > According > to Asus it "Improves system stability", so let's see if this 'cures' IRQ > 16. > > > Thanks, > -- > Daan Vreeken > VEHosting > http://VEHosting.nl > tel: +31-(0)40-7113050 / +31-(0)6-46210825 > KvK nr: 17174380 > From owner-freebsd-current@FreeBSD.ORG Thu May 5 20:33:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C262C1065670 for ; Thu, 5 May 2011 20:33:52 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5A8818FC08 for ; Thu, 5 May 2011 20:33:52 +0000 (UTC) Received: by vxc34 with SMTP id 34so3602623vxc.13 for ; Thu, 05 May 2011 13:33:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=0v0qpCG/kivMlQHnqKtbzA5vaU8Wwdv9NVySuYU08uM=; b=NAeQgzG32u908P7FaKgXwdQWxNkYXueVZd4IbMp6Ly2QoXQmFScfPsgAkDLEuxWsbD TbCWF/pQtViqEmbBtwf1+H6jocDwdJSf81rE7E5vpn3XrAQ42qvr2evMwPwhq/QI5S2P DEbluX4wVHR11nrA9q2O2wDK8v8X35nrccMtQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=I5m63CxBPKNg3tO4gE/EWTsfiZ+HOuZRgt77WTka5ZV9ozOcf/M4obbSraYOe/BjE5 FvjlzbwO8NBiBWmzBFp/ezcRt9MKpTGtM/7tInh6zQcB0ol5Zvbw+kDNId+6zXH4tUBY qkkDrouBy+/o2xEDyf8aJOXu7wSNci1g8plfI= MIME-Version: 1.0 Received: by 10.52.73.65 with SMTP id j1mr95139vdv.248.1304627631294; Thu, 05 May 2011 13:33:51 -0700 (PDT) Received: by 10.220.199.130 with HTTP; Thu, 5 May 2011 13:33:51 -0700 (PDT) Date: Thu, 5 May 2011 13:33:51 -0700 Message-ID: From: Garrett Cooper To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Subject: Processes in swapped out states in recent CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 20:33:52 -0000 I was watching top output on my dev box and I noticed that there are more swapped out processes present on the system, shortly after boot (which doesn't make sense given that I'm not low on resources on the box). Also, the os when I run os.waitpid() in python claims that the child doesn't exist, so I'm wondering if there's an issue with the processes reported via ps, top, etc. I'm noting this because it's a behavior change over my 'stable'-ish workstation, running CURRENT/r220089/amd64, which is spec'ed out the same as the dev box, minus some multimedia hardware. Thanks, -Garrett # uname -a FreeBSD fallout.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r221219M: Thu May 5 12:09:37 PDT 2011 root@fallout.local:/usr/obj/usr/src/sys/FALLOUT amd6 # fstat -p 1832 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root sshd 1832 root / 2 drwxr-xr-x 1024 r root sshd 1832 wd / 2 drwxr-xr-x 1024 r root sshd 1832 text /usr 730118 -r-xr-xr-x 240944 r root sshd 1832 0 /dev 6 crw-rw-rw- null r root sshd 1832 1 /dev 6 crw-rw-rw- null rw root sshd 1832 2 /dev 6 crw-rw-rw- null rw root sshd 1832 3* internet stream tcp fffffe01e56cf000 root sshd 1832 4* pseudo-terminal master pts/1 rw root sshd 1832 5* local stream fffffe0008f79960 <-> fffffe0008f79a50 # fstat -p 149 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root adjkerntz 149 root / 2 drwxr-xr-x 1024 r root adjkerntz 149 wd / 2 drwxr-xr-x 1024 r root adjkerntz 149 text / 329805 -r-xr-xr-x 8792 r root adjkerntz 149 0 /dev 6 crw-rw-rw- null rw root adjkerntz 149 1 /dev 6 crw-rw-rw- null rw root adjkerntz 149 2 /dev 6 crw-rw-rw- null rw # fstat -p 1479 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root syslogd 1479 root / 2 drwxr-xr-x 1024 r root syslogd 1479 wd / 2 drwxr-xr-x 1024 r root syslogd 1479 text /usr 739002 -r-xr-xr-x 39008 r root syslogd 1479 0 /dev 6 crw-rw-rw- null rw root syslogd 1479 1 /dev 6 crw-rw-rw- null rw root syslogd 1479 2 /dev 6 crw-rw-rw- null rw root syslogd 1479 3 /var 353301 -rw------- 4 w root syslogd 1479 4* local dgram fffffe0008cd31e0 root syslogd 1479 5* local dgram fffffe0008cd30f0 root syslogd 1479 6* internet6 dgram udp fffffe0008ced540 root syslogd 1479 7* internet dgram udp fffffe0008ced3f0 root syslogd 1479 8 /dev 29 crw------- klog r root syslogd 1479 10 /var 1389613 -rw-r--r-- 25389 w root syslogd 1479 11 /var 1389579 -rw------- 62 w root syslogd 1479 12 /var 1389572 -rw------- 10164 w root syslogd 1479 13 /var 1389601 -rw-r----- 2814 w root syslogd 1479 14 /var 1389575 -rw-r--r-- 62 w root syslogd 1479 15 /var 1389580 -rw------- 62 w root syslogd 1479 16 /var 1389577 -rw------- 57212 w root syslogd 1479 17 /var 1389606 -rw------- 38046 w root syslogd 1479 18 /var 1389578 -rw-r----- 62 w # fstat -p 1829 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W gcooper sh 1829 root / 2 drwxr-xr-x 1024 r gcooper sh 1829 wd /usr 1884160 drwxr-xr-x 1024 r gcooper sh 1829 text / 212057 -r-xr-xr-x 131784 r gcooper sh 1829 0 /dev 127 crw--w---- pts/0 rw gcooper sh 1829 1 /dev 127 crw--w---- pts/0 rw gcooper sh 1829 2 /dev 127 crw--w---- pts/0 rw gcooper sh 1829 10 /dev 127 crw--w---- pts/0 rw # python -c 'import os; os.waitpid(1825, 0)' Traceback (most recent call last): File "", line 1, in OSError: [Errno 10] No child processes # ps auxww | grep 1825 root 1825 0.0 0.0 47952 0 ?? IWs - 0:00.00 sshd: gcooper [priv] (sshd) root 88213 0.0 0.0 16340 1356 3 S+ 1:25PM 0:00.00 grep 1825 # top -b last pid: 96740; load averages: 1.07, 0.98, 0.92 up 0+01:15:32 13:27:04 50 processes: 2 running, 48 sleeping Mem: 56M Active, 23M Inact, 795M Wired, 1848K Cache, 1237M Buf, 11G Free Swap: 24G Total, 832K Used, 24G Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 1828 gcooper 1 20 0 47952K 3372K select 6 0:02 0.00% sshd 26295 root 1 20 0 9972K 888K kqread 2 0:01 0.00% tail 95888 root 1 52 0 14472K 8092K wait 1 0:00 0.00% make 1729 root 1 20 0 20368K 3000K select 2 0:00 0.00% sendmail 59474 gcooper 1 20 0 47952K 3768K select 7 0:00 0.00% sshd 57339 root 1 52 0 6280K 1168K wait 1 0:00 0.00% make 75210 gcooper 1 20 0 47952K 3816K select 5 0:00 0.00% sshd 82431 root 1 52 0 6280K 1148K wait 2 0:00 0.00% make 94797 root 1 52 0 6280K 1164K wait 2 0:00 0.00% make 59441 root 1 21 0 47952K 3772K sbwait 4 0:00 0.00% sshd 1825 root 1 21 0 47952K 0K sbwait 1 0:00 0.00% 75167 root 1 21 0 47952K 3820K sbwait 1 0:00 0.00% sshd 1832 root 1 20 0 47952K 0K sbwait 1 0:00 0.00% 96738 root 1 72 0 17184K 9756K CPU0 0 0:00 0.00% cc1 1479 root 1 20 0 12228K 1372K select 4 0:00 0.00% syslogd 75237 root 1 20 0 17612K 2424K ttyin 4 0:00 0.00% bash 1835 gcooper 1 20 0 47952K 3284K select 2 0:00 0.00% sshd 57233 root 1 52 0 6280K 756K wait 2 0:00 0.00% make From owner-freebsd-current@FreeBSD.ORG Thu May 5 20:56:06 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C79AF10657DA for ; Thu, 5 May 2011 20:56:06 +0000 (UTC) (envelope-from mavbsd@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 4EED58FC12 for ; Thu, 5 May 2011 20:56:05 +0000 (UTC) Received: by fxm11 with SMTP id 11so2517632fxm.13 for ; Thu, 05 May 2011 13:56:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature: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=I15OTGoYQbSQ3omxBx/ld/JAML1mUGfP3zUuHPWJpC8=; b=iNpbM2rnFl05CvopIoDMX0EevmPHg/rv8S0QPlR6+YfCb2XhSh6+HbNdUBUHdi1zFF m1bw4Tm7LAG/MkUtIYHLEepyJZ6VCfCQ9GGet7boPmAWMFw27bM5SOQaVZgOSGqnDP5p O/E4ftescACIw8xPJOejJBNYOsp0SQgg9A2fc= 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=gQ11YxwWQTDHFq3JE8745AX+Y+4a6aD8bl78s0Z9vfZ69zXR2ROjc8WcXLTWzgJ77/ tz094AohleLIPSWOXMKFm4lmM0P8NLMPPAKD9DgBuVfULKQE9wl6fO401PeMjSSJsZSz OXpOG6gRVzy5m3XUaJKe+YMC7w2mvbc2wYMZw= Received: by 10.223.75.15 with SMTP id w15mr3199345faj.134.1304628964927; Thu, 05 May 2011 13:56:04 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id j11sm869244faa.44.2011.05.05.13.56.03 (version=SSLv3 cipher=OTHER); Thu, 05 May 2011 13:56:04 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DC30EC5.3090703@FreeBSD.org> Date: Thu, 05 May 2011 23:55:33 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Doug Barton References: <4DC25396.1070909@dougbarton.us> In-Reply-To: <4DC25396.1070909@dougbarton.us> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: My problems with stability on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 20:56:07 -0000 Doug Barton wrote: > Alexander suggested some knobs to twist for the timers, and I'll be glad > to do that once he gets back to me with more concrete suggestions now > that he knows more about my specific problems. OK, I am all here. While this post is indeed larger then previous, it is not much more informative. Sorry. :( I see several possibly unrelated problems there: - crashes are always crashes. They should be debugged. - calcru going backwards could have the same roots as lost wall clock time. If there are some problems with timer interrupts, timecounters could wrap unnoticed that will cause random time jumps. - interactivity problems. I can't prove it is unrelated, but have no real ideas now. I would start from most obvious problems. I need to know more about crashes. As usual: how to trigger, stack backtraces, etc. What's about time problems, I would try to collect more data: - show `sysctl kern.eventtimer`, `sysctl kern.timecounter` and verbose dmesg outputs; - what eventtimer is used now and does it helps to switch to another one with kern.eventtimer.timer sysctl? - does the timer runs in periodic or one-shot mode and does it helps to switch to another one? - if full CPU load makes time to stop, try to track what is going on with timer interrupts using `vmstat -i` and `systat -vm 1`. Under full CPU load in one-shot mode you should have stable timer interrupt rate about hz+stathz. - if timer interrupts are not working well, you can build kernel with options KTR options ALQ options KTR_ALQ options KTR_COMPILE=(KTR_SPARE2) options KTR_ENTRIES=131072 options KTR_MASK=(KTR_SPARE2) to track event timers operation and use ktrdump to save the trace when problem exist (preferably when it begins). And let's experiment with fresh CURRENT. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu May 5 21:05:01 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B2E9106566B for ; Thu, 5 May 2011 21:05:01 +0000 (UTC) (envelope-from damjan.marion@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 A72138FC17 for ; Thu, 5 May 2011 21:05:00 +0000 (UTC) Received: by wyf23 with SMTP id 23so2535029wyf.13 for ; Thu, 05 May 2011 14:04:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=YMRvPy70UcUhOeG4G1/FhYHpviQPRlY+cHG6RZbYJ0o=; b=QivwROTr/FEEmOxgLTzHHi6OxL934Vg7TAYVEvOJ1utOUCPVN50YN7ShE9ib6/sOZD 66XhEpWqeMfc3KZ4pHSZhctGD93wCDiQwedAnjb+tGotXl7PoPCnyWgYbZVq1p2ypeq4 vb6v7CRQLe9s7u/5Sl2ojfiXQn33h+HRkGIgs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=dOWNu2+BIvvmk0loK6Ajz66stMN2PqNO9el1Tn2fzNM5pZsSsXTT3Q9O/ARx17UIeS SfmMdu2vXEjnkxyusMhpnZ09Yfni/KlaTtSdAlrW2sJu3k5cmGdLr35mPLdgdjZOYeh+ yxND9yqrmrS81PHvcMmiWc34mw085u9T5F2QY= Received: by 10.227.208.12 with SMTP id ga12mr2961085wbb.68.1304629499391; Thu, 05 May 2011 14:04:59 -0700 (PDT) Received: from [192.168.123.4] (cpe-109-60-66-194.zg3.cable.xnet.hr [109.60.66.194]) by mx.google.com with ESMTPS id bs4sm1592543wbb.52.2011.05.05.14.04.57 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 May 2011 14:04:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Damjan Marion In-Reply-To: <201105051343.02898.jhb@freebsd.org> Date: Thu, 5 May 2011 23:04:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5BEF0D0F-3717-42CE-ADF7-8876558004CA@gmail.com> <201105051343.02898.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1084) Cc: freebsd-current@freebsd.org Subject: Re: atkbdc broken on current ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 21:05:01 -0000 On May 5, 2011, at 7:43 PM, John Baldwin wrote: > On Thursday, May 05, 2011 9:21:04 am Damjan Marion wrote: >>=20 >> Hi, >>=20 >> I have issue with old HP DL380G3 server. When I use ILO virtual = console to=20 > manage server. Seems that 9-CURRENT fails to detect atkbdc. >> When I boot 8.2-RELEASE it works well. >>=20 >> 8.2 dmesg shows: >>=20 >> atkbdc0: port 0x60,0x64 irq 1 on acpi0 >>=20 >> 9.0: >>=20 >> atkbdc0: failed to probe at port 0x60 = on isa0 >>=20 >> Is this a known issue? >>=20 >> Should I enable some additional outputs, like KBDIO_DEBUG? >=20 > I suspect this is a resource issue stemming from changes I made to the = acpi(4)=20 > bus driver quite a while ago to make it use rman_reserve_resource(). = Can you > capture a full verbose dmesg from 9 along with devinfo -rv and devinfo = -ur=20 > output from 9? Here it is: http://web.me.com/dmarion/atkbdc.txt Thanks, Damjan= From owner-freebsd-current@FreeBSD.ORG Thu May 5 21:12:06 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A42B106566C for ; Thu, 5 May 2011 21:12:06 +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 72D998FC08 for ; Thu, 5 May 2011 21:12:05 +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 p45LC1bq069165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 May 2011 00:12:01 +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 p45LC1LW079118; Fri, 6 May 2011 00:12:01 +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 p45LC10I079117; Fri, 6 May 2011 00:12:01 +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, 6 May 2011 00:12:01 +0300 From: Kostik Belousov To: Garrett Cooper Message-ID: <20110505211201.GC48734@deviant.kiev.zoral.com.ua> References: <201105040559.p445xEJ5024585@chez.mckusick.com> <20110504090718.GN48734@deviant.kiev.zoral.com.ua> <9E4C162F-B4EA-4378-A010-3E8D0D23EA93@gmail.com> <20110505173600.GB48734@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Hx7WYMxL4WLyMs5Q" Content-Disposition: inline In-Reply-To: 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=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS,SUBJECT_FUZZY_TION autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Kirk McKusick , FreeBSD Current Subject: Re: Nasty non-recursive lockmgr panic on softdep only enabled UFS partition when filesystem full X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 21:12:06 -0000 --Hx7WYMxL4WLyMs5Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, May 05, 2011 at 12:49:48PM -0700, Garrett Cooper wrote: > Things look ok with that patch and the one that Jeff provided for > the LOR, taking into account your style change with the flag list. > Thanks! I do not understand your response. Jeff' patch was included into the cumulative change I sent you, with slight modification. What 'style change with the flag list' are you referencing to ? --Hx7WYMxL4WLyMs5Q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk3DEqEACgkQC3+MBN1Mb4iXSQCg33DWkLNJpn3B1dwvEO4X1hc2 /YgAoOURLmUqJZlsmQyM1S+Rgzpl/fwp =baXB -----END PGP SIGNATURE----- --Hx7WYMxL4WLyMs5Q-- From owner-freebsd-current@FreeBSD.ORG Thu May 5 21:19:53 2011 Return-Path: Delivered-To: Current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C41B106566C for ; Thu, 5 May 2011 21:19:53 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from fallbackmx07.syd.optusnet.com.au (fallbackmx07.syd.optusnet.com.au [211.29.132.9]) by mx1.freebsd.org (Postfix) with ESMTP id 25CD78FC0C for ; Thu, 5 May 2011 21:19:51 +0000 (UTC) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by fallbackmx07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p45JS9Bf012001 for ; Fri, 6 May 2011 05:28:09 +1000 Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p45JS4cE002956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 May 2011 05:28:06 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id p45JS44X087752; Fri, 6 May 2011 05:28:04 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id p45JS3JD087751; Fri, 6 May 2011 05:28:03 +1000 (EST) (envelope-from peter) Date: Fri, 6 May 2011 05:28:02 +1000 From: Peter Jeremy To: Daan Vreeken Message-ID: <20110505192802.GA11269@server.vk2pj.dyndns.org> References: <201105041734.50738.Daan@vehosting.nl> <201105050127.26358.Daan@vehosting.nl> <201105051322.59654.Daan@vehosting.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MGYHOYXEY6WxJCY8" Content-Disposition: inline In-Reply-To: <201105051322.59654.Daan@vehosting.nl> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Current@freebsd.org Subject: Re: Interrupt storm with MSI in combination with em1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 21:19:53 -0000 --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-May-05 13:22:59 +0200, Daan Vreeken wrote: >Not yet. I'll reboot the machine later today when I have physical access t= o it=20 >to check the BIOS version. I'll keep you informed as soon as I get another= =20 >storm going. Depending on the quality of your BIOS (competence of the vendor), you might find that kenv(8) reports the BIOS version without needing a reboot. (Look at smbios.bios.* in the output). --=20 Peter Jeremy --MGYHOYXEY6WxJCY8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk3C+kIACgkQ/opHv/APuIc5+ACgoNh8l16AYDbdWYE/h34biBQJ vQ4AoIofpBZ6MMJCTAcXW78EavqWE6pN =zdtM -----END PGP SIGNATURE----- --MGYHOYXEY6WxJCY8-- From owner-freebsd-current@FreeBSD.ORG Thu May 5 23:12:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 177C8106564A for ; Thu, 5 May 2011 23:12:52 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by mx1.freebsd.org (Postfix) with ESMTP id DDFA28FC0A for ; Thu, 5 May 2011 23:12:51 +0000 (UTC) Received: from [10.9.200.131] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 05 May 2011 13:12:30 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Thu, 5 May 2011 13:09:08 -0700 From: "David Christensen" To: "freebsd-current@freebsd.org" Date: Thu, 5 May 2011 13:08:56 -0700 Thread-Topic: Using Dtrace for Performance Evaluation Thread-Index: AcwLYENv4nl2+zvAS3+g5KnOcP0f5g== Message-ID: <5D267A3F22FD854F8F48B3D2B523819360D799A42B@IRVEXCHCCR01.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AD9e BLxS BlI2 CHQW DCMR DgT1 DlH+ FPUr FScm FlbO GOWC HI+a HL5w JLbb K8sR K9Vy; 1; ZgByAGUAZQBiAHMAZAAtAGMAdQByAHIAZQBuAHQAQABmAHIAZQBlAGIAcwBkAC4AbwByAGcA; Sosha1_v1; 7; {02A8C881-7D06-446F-A9A3-EFFD7C0B4DB5}; ZABhAHYAaQBkAGMAaABAAGIAcgBvAGEAZABjAG8AbQAuAGMAbwBtAA==; Thu, 05 May 2011 20:08:56 GMT; VQBzAGkAbgBnACAARAB0AHIAYQBjAGUAIABmAG8AcgAgAFAAZQByAGYAbwByAG0AYQBuAGMAZQAgAEUAdgBhAGwAdQBhAHQAaQBvAG4A x-cr-puzzleid: {02A8C881-7D06-446F-A9A3-EFFD7C0B4DB5} acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 61DDDB244NS1418982-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Using Dtrace for Performance Evaluation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 23:12:52 -0000 I was looking at using dtrace to help characterize performance for the new bxe(4) driver but I'm having problems with the very simple task of capturing time spent in a function. The D script I'm using looks like the following: #pragma D option quiet fbt:if_bxe::entry { self->in =3D timestamp; } fbt:if_bxe::return { @callouts[((struct callout *)arg0)->c_func] =3D sum(timestamp - self->in); } tick-10sec { printa("%40a %10@d\n", @callouts); clear(@callouts); printf("\n"); } BEGIN { printf("%40s | %s\n", "function", "nanoseconds per second"); } After building dtrace into the kernel and loading the dtraceall kernel module, when I load my bxe kernel module and run "dtrace -l" to list all supported probes I notice that many functions have an=20 entry probe but no exit probe. This effectively prevents me from calculating timestamps on "fbt:if_bxe::return" probes. Why am I seeing this behavior? Dave From owner-freebsd-current@FreeBSD.ORG Thu May 5 23:33:35 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D46FF106566B; Thu, 5 May 2011 23:33:35 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by mx1.freebsd.org (Postfix) with ESMTP id 8BB1E8FC08; Thu, 5 May 2011 23:33:35 +0000 (UTC) Received: from [10.9.200.131] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 05 May 2011 16:36:42 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Thu, 5 May 2011 16:33:20 -0700 From: "David Christensen" To: "Artem Belevich" Date: Thu, 5 May 2011 16:33:09 -0700 Thread-Topic: Using Dtrace for Performance Evaluation Thread-Index: AcwLe6p564GarEuHQveBOVBDk2ZjcQAAQ3eA Message-ID: <5D267A3F22FD854F8F48B3D2B523819360D799A517@IRVEXCHCCR01.corp.ad.broadcom.com> References: <5D267A3F22FD854F8F48B3D2B523819360D799A42B@IRVEXCHCCR01.corp.ad.broadcom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: A7ws B2Nf FL9g F20c GTGz Gxoq Hb3d IsZ0 MJWc NwDG O/7H PBwf Pvrw SZdE T0NZ VykV; 2; YQByAHQAQABmAHIAZQBlAGIAcwBkAC4AbwByAGcAOwBmAHIAZQBlAGIAcwBkAC0AYwB1AHIAcgBlAG4AdABAAGYAcgBlAGUAYgBzAGQALgBvAHIAZwA=; Sosha1_v1; 7; {A9FB8ACA-FC90-408B-9EC0-771981079C02}; ZABhAHYAaQBkAGMAaABAAGIAcgBvAGEAZABjAG8AbQAuAGMAbwBtAA==; Thu, 05 May 2011 23:33:09 GMT; UgBFADoAIABVAHMAaQBuAGcAIABEAHQAcgBhAGMAZQAgAGYAbwByACAAUABlAHIAZgBvAHIAbQBhAG4AYwBlACAARQB2AGEAbAB1AGEAdABpAG8AbgA= x-cr-puzzleid: {A9FB8ACA-FC90-408B-9EC0-771981079C02} acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 61DDEB004NS1501618-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-current@freebsd.org" Subject: RE: Using Dtrace for Performance Evaluation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 23:33:36 -0000 > > After building dtrace into the kernel and loading the dtraceall > > kernel module, when I load my bxe kernel module and run "dtrace -l" > > to list all supported probes I notice that many functions have an > > entry probe but no exit probe. =A0This effectively prevents me from > > calculating timestamps on "fbt:if_bxe::return" probes. =A0Why am I > > seeing this behavior? >=20 > Tail call optimization could do that to you: > http://en.wikipedia.org/wiki/Tail_call How to disable tail call optimization when building my driver? Dave From owner-freebsd-current@FreeBSD.ORG Thu May 5 23:43:54 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97289106566B for ; Thu, 5 May 2011 23:43:54 +0000 (UTC) (envelope-from artemb@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 4EA558FC0A for ; Thu, 5 May 2011 23:43:54 +0000 (UTC) Received: by qwc9 with SMTP id 9so2399936qwc.13 for ; Thu, 05 May 2011 16:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OZ4IZWKMQMRck9O4jwYz1SIGnL27rev97K27PEwHgRw=; b=qQj7KVeOrRHcpm8PfcYxeU3N3VJBb+IQii0q9tMqZIFBb1CwLw4wH+AN77QaR43SNh rcfbzs5o5r+ElOHIizZi6KYQHZsb1iwJKwyz8jAVl7R5QcyqPnpLP65K1LjmSQSCzH9d I0Xvur32iOz+m+/wEJKRMI+LywvYWu/vqnLvQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=xM/fhpc05Oe1Yogw8rwS0bsrR6fLEr9E4Rlg2nwsDX+sKJG7cDL84V2O+75jrBib9b yDSGbSbJSUgeiYXvjkUs3Wz0fzPeMsMhtz4wQxW4ohidoGbDrCuZM6WoUVkEcVNPwLvO uNgnds35qcATQpFdb0wQunTKIJoS3/w9guEcE= MIME-Version: 1.0 Received: by 10.224.184.140 with SMTP id ck12mr3004933qab.137.1304639033648; Thu, 05 May 2011 16:43:53 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.229.95.140 with HTTP; Thu, 5 May 2011 16:43:53 -0700 (PDT) In-Reply-To: <5D267A3F22FD854F8F48B3D2B523819360D799A517@IRVEXCHCCR01.corp.ad.broadcom.com> References: <5D267A3F22FD854F8F48B3D2B523819360D799A42B@IRVEXCHCCR01.corp.ad.broadcom.com> <5D267A3F22FD854F8F48B3D2B523819360D799A517@IRVEXCHCCR01.corp.ad.broadcom.com> Date: Thu, 5 May 2011 16:43:53 -0700 X-Google-Sender-Auth: QS4uGeawdAPW2Jklo9X-HqqLPm8 Message-ID: From: Artem Belevich To: David Christensen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-current@freebsd.org" Subject: Re: Using Dtrace for Performance Evaluation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 23:43:54 -0000 On Thu, May 5, 2011 at 4:33 PM, David Christensen wr= ote: >> > After building dtrace into the kernel and loading the dtraceall >> > kernel module, when I load my bxe kernel module and run "dtrace -l" >> > to list all supported probes I notice that many functions have an >> > entry probe but no exit probe. =A0This effectively prevents me from >> > calculating timestamps on "fbt:if_bxe::return" probes. =A0Why am I >> > seeing this behavior? >> >> Tail call optimization could do that to you: >> http://en.wikipedia.org/wiki/Tail_call > > How to disable tail call optimization when building my driver? Google is your friend: Either compile with -O0/-O1, or use -fno-optimize-sibling-calls. http://stackoverflow.com/questions/3679435/how-do-i-disable-tailcall-optimi= zations-in-gcc --Artem From owner-freebsd-current@FreeBSD.ORG Thu May 5 23:54:06 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAB5C106564A for ; Thu, 5 May 2011 23:54:06 +0000 (UTC) (envelope-from artemb@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 937808FC12 for ; Thu, 5 May 2011 23:54:06 +0000 (UTC) Received: by qyk27 with SMTP id 27so2537868qyk.13 for ; Thu, 05 May 2011 16:54:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Nk29TOjDUWzMeceaCDxOIpuNiFlO5kxT88jbYnlBL78=; b=LHtWZykYcXley6qr3ajysGwMl3jjMXRjWppf7DpINmhjbwU9IPW5/TUs35J4upVwJp zz/i4EsH7RH2bkkhksj+tdO70yODfUhZcx5vQp0fBZfj8wnmTKa2Tg+EN9B0uDgGcpBH j3kvo1VBkdPgGLMwHXWsJxveU0Pv+HQQmuOuA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=x8BrMzcfmY+30CJsKKAmlMBMm4krHPmn+lZjB/DSuTC970IRAeY2gT0XtZzfXutTdP dWbo16YynQwZ0vtZNdU1rJj86pmyp6WFmgOrjjLoMP9w4v+VRvuVhSGorZY3pIRCuA5P 8x493sNFc9KswDhRDRFeYKwQtJbSnCYynjq5o= MIME-Version: 1.0 Received: by 10.224.213.133 with SMTP id gw5mr3001981qab.187.1304637892289; Thu, 05 May 2011 16:24:52 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.229.95.140 with HTTP; Thu, 5 May 2011 16:24:52 -0700 (PDT) In-Reply-To: <5D267A3F22FD854F8F48B3D2B523819360D799A42B@IRVEXCHCCR01.corp.ad.broadcom.com> References: <5D267A3F22FD854F8F48B3D2B523819360D799A42B@IRVEXCHCCR01.corp.ad.broadcom.com> Date: Thu, 5 May 2011 16:24:52 -0700 X-Google-Sender-Auth: VpjncUVOdAOphGF7M90yHvFeo60 Message-ID: From: Artem Belevich To: David Christensen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-current@freebsd.org" Subject: Re: Using Dtrace for Performance Evaluation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 23:54:06 -0000 On Thu, May 5, 2011 at 1:08 PM, David Christensen wr= ote: > I was looking at using dtrace to help characterize performance > for the new bxe(4) driver but I'm having problems with the very > simple task of capturing time spent in a function. =A0The D script > I'm using looks like the following: > > #pragma D option quiet > > fbt:if_bxe::entry > { > =A0 =A0 =A0 =A0self->in =3D timestamp; > } > > fbt:if_bxe::return > { > > =A0 =A0 =A0 =A0@callouts[((struct callout *)arg0)->c_func] =3D sum(timest= amp - > =A0 =A0 =A0 =A0 =A0 =A0self->in); > } > > tick-10sec > { > =A0 =A0 =A0 =A0printa("%40a %10@d\n", @callouts); > =A0 =A0 =A0 =A0clear(@callouts); > =A0 =A0 =A0 =A0printf("\n"); > } > > BEGIN > { > =A0 =A0 =A0 =A0printf("%40s | %s\n", "function", "nanoseconds per second"= ); > } > > After building dtrace into the kernel and loading the dtraceall > kernel module, when I load my bxe kernel module and run "dtrace -l" > to list all supported probes I notice that many functions have an > entry probe but no exit probe. =A0This effectively prevents me from > calculating timestamps on "fbt:if_bxe::return" probes. =A0Why am I > seeing this behavior? Tail call optimization could do that to you: http://en.wikipedia.org/wiki/Tail_call --Artem > > Dave > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Fri May 6 06:28:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6B8F1065670 for ; Fri, 6 May 2011 06:28:49 +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 87CE18FC0A for ; Fri, 6 May 2011 06:28:49 +0000 (UTC) Received: by qyk35 with SMTP id 35so4748981qyk.13 for ; Thu, 05 May 2011 23:28:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Ss/UB+GleyAoHVm5MIjZPDHFq9BWvQ8+owc1Dxh6aOE=; b=HH7msDY/j31XUC8bUU0qeoGS6BDnL2zs0Wp8SZ5DQD4ewZfZG+b0ueQBxlZZm/bwM+ UQp6BeV8TkAK6qgws6xEIGA8xOVJ6sL9K06GYrLC+W0jp/AYyU0mTEAZpkJvNTByAjJ0 TcG3HDEOQ6J2zr9XKV0yHERA1A9WWI8YvAPV8= 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=lwVx7PIf7fVLxWg5/nK8v5EkTGlBx+tGgX+0qrLf/WEhUPHJn6LqDi9yd9PwRXezyE EIx31M7wM71P4mpkrcVLGRLR+r07Ti00CN6kmb0epdiDNAqsguEnMI1jFqRUG8z/Q/cY 90WBytyYFK6o3IEFX+MNSmUWfQbsstu7/1vGU= MIME-Version: 1.0 Received: by 10.229.41.70 with SMTP id n6mr2221520qce.252.1304663328556; Thu, 05 May 2011 23:28:48 -0700 (PDT) Received: by 10.229.95.19 with HTTP; Thu, 5 May 2011 23:28:48 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 May 2011 10:28:48 +0400 Message-ID: From: Sergey Kandaurov To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: Processes in swapped out states in recent CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 06:28:49 -0000 On 6 May 2011 00:33, Garrett Cooper wrote: > =A0 =A0I was watching top output on my dev box and I noticed that there > are more swapped out processes present on the system, shortly after > boot (which doesn't make sense given that I'm not low on resources on > the box). Also, the os when I run os.waitpid() in python claims that > the child doesn't exist, so I'm wondering if there's an issue with the > processes reported via ps, top, etc. > =A0 =A0I'm noting this because it's a behavior change over my > 'stable'-ish workstation, running CURRENT/r220089/amd64, which is > spec'ed out the same as the dev box, minus some multimedia hardware. > Thanks, > -Garrett > > # uname -a > FreeBSD fallout.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r221219M: Thu > May =A05 12:09:37 PDT 2011 > root@fallout.local:/usr/obj/usr/src/sys/FALLOUT =A0amd6 > # fstat -p 1832 > USER =A0 =A0 CMD =A0 =A0 =A0 =A0 =A0PID =A0 FD MOUNT =A0 =A0 =A0INUM MODE= =A0 =A0 =A0 =A0 SZ|DV R/W > root =A0 =A0 sshd =A0 =A0 =A0 =A01832 root / =A0 =A0 =A0 =A0 =A0 =A0 2 dr= wxr-xr-x =A0 =A01024 =A0r > root =A0 =A0 sshd =A0 =A0 =A0 =A01832 =A0 wd / =A0 =A0 =A0 =A0 =A0 =A0 2 = drwxr-xr-x =A0 =A01024 =A0r > root =A0 =A0 sshd =A0 =A0 =A0 =A01832 text /usr =A0 =A0 730118 -r-xr-xr-x= =A0240944 =A0r > root =A0 =A0 sshd =A0 =A0 =A0 =A01832 =A0 =A00 /dev =A0 =A0 =A0 =A0 =A06 = crw-rw-rw- =A0 =A0null =A0r > root =A0 =A0 sshd =A0 =A0 =A0 =A01832 =A0 =A01 /dev =A0 =A0 =A0 =A0 =A06 = crw-rw-rw- =A0 =A0null rw > root =A0 =A0 sshd =A0 =A0 =A0 =A01832 =A0 =A02 /dev =A0 =A0 =A0 =A0 =A06 = crw-rw-rw- =A0 =A0null rw > root =A0 =A0 sshd =A0 =A0 =A0 =A01832 =A0 =A03* internet stream tcp fffff= e01e56cf000 > root =A0 =A0 sshd =A0 =A0 =A0 =A01832 =A0 =A04* pseudo-terminal master = =A0 =A0 =A0pts/1 rw > root =A0 =A0 sshd =A0 =A0 =A0 =A01832 =A0 =A05* local stream fffffe0008f7= 9960 <-> > fffffe0008f79a50 > # fstat -p 149 > USER =A0 =A0 CMD =A0 =A0 =A0 =A0 =A0PID =A0 FD MOUNT =A0 =A0 =A0INUM MODE= =A0 =A0 =A0 =A0 SZ|DV R/W > root =A0 =A0 adjkerntz =A0 =A0149 root / =A0 =A0 =A0 =A0 =A0 =A0 2 drwxr-= xr-x =A0 =A01024 =A0r > root =A0 =A0 adjkerntz =A0 =A0149 =A0 wd / =A0 =A0 =A0 =A0 =A0 =A0 2 drwx= r-xr-x =A0 =A01024 =A0r > root =A0 =A0 adjkerntz =A0 =A0149 text / =A0 =A0 =A0 =A0329805 -r-xr-xr-x= =A0 =A08792 =A0r > root =A0 =A0 adjkerntz =A0 =A0149 =A0 =A00 /dev =A0 =A0 =A0 =A0 =A06 crw-= rw-rw- =A0 =A0null rw > root =A0 =A0 adjkerntz =A0 =A0149 =A0 =A01 /dev =A0 =A0 =A0 =A0 =A06 crw-= rw-rw- =A0 =A0null rw > root =A0 =A0 adjkerntz =A0 =A0149 =A0 =A02 /dev =A0 =A0 =A0 =A0 =A06 crw-= rw-rw- =A0 =A0null rw > # fstat -p 1479 > USER =A0 =A0 CMD =A0 =A0 =A0 =A0 =A0PID =A0 FD MOUNT =A0 =A0 =A0INUM MODE= =A0 =A0 =A0 =A0 SZ|DV R/W > root =A0 =A0 syslogd =A0 =A0 1479 root / =A0 =A0 =A0 =A0 =A0 =A0 2 drwxr-= xr-x =A0 =A01024 =A0r > root =A0 =A0 syslogd =A0 =A0 1479 =A0 wd / =A0 =A0 =A0 =A0 =A0 =A0 2 drwx= r-xr-x =A0 =A01024 =A0r > root =A0 =A0 syslogd =A0 =A0 1479 text /usr =A0 =A0 739002 -r-xr-xr-x =A0= 39008 =A0r > root =A0 =A0 syslogd =A0 =A0 1479 =A0 =A00 /dev =A0 =A0 =A0 =A0 =A06 crw-= rw-rw- =A0 =A0null rw > root =A0 =A0 syslogd =A0 =A0 1479 =A0 =A01 /dev =A0 =A0 =A0 =A0 =A06 crw-= rw-rw- =A0 =A0null rw > root =A0 =A0 syslogd =A0 =A0 1479 =A0 =A02 /dev =A0 =A0 =A0 =A0 =A06 crw-= rw-rw- =A0 =A0null rw > root =A0 =A0 syslogd =A0 =A0 1479 =A0 =A03 /var =A0 =A0 353301 -rw-------= =A0 =A0 =A0 4 =A0w > root =A0 =A0 syslogd =A0 =A0 1479 =A0 =A04* local dgram fffffe0008cd31e0 > root =A0 =A0 syslogd =A0 =A0 1479 =A0 =A05* local dgram fffffe0008cd30f0 > root =A0 =A0 syslogd =A0 =A0 1479 =A0 =A06* internet6 dgram udp fffffe000= 8ced540 > root =A0 =A0 syslogd =A0 =A0 1479 =A0 =A07* internet dgram udp fffffe0008= ced3f0 > root =A0 =A0 syslogd =A0 =A0 1479 =A0 =A08 /dev =A0 =A0 =A0 =A0 29 crw---= ---- =A0 =A0klog =A0r > root =A0 =A0 syslogd =A0 =A0 1479 =A0 10 /var =A0 =A0 1389613 -rw-r--r-- = =A0 25389 =A0w > root =A0 =A0 syslogd =A0 =A0 1479 =A0 11 /var =A0 =A0 1389579 -rw------- = =A0 =A0 =A062 =A0w > root =A0 =A0 syslogd =A0 =A0 1479 =A0 12 /var =A0 =A0 1389572 -rw------- = =A0 10164 =A0w > root =A0 =A0 syslogd =A0 =A0 1479 =A0 13 /var =A0 =A0 1389601 -rw-r----- = =A0 =A02814 =A0w > root =A0 =A0 syslogd =A0 =A0 1479 =A0 14 /var =A0 =A0 1389575 -rw-r--r-- = =A0 =A0 =A062 =A0w > root =A0 =A0 syslogd =A0 =A0 1479 =A0 15 /var =A0 =A0 1389580 -rw------- = =A0 =A0 =A062 =A0w > root =A0 =A0 syslogd =A0 =A0 1479 =A0 16 /var =A0 =A0 1389577 -rw------- = =A0 57212 =A0w > root =A0 =A0 syslogd =A0 =A0 1479 =A0 17 /var =A0 =A0 1389606 -rw------- = =A0 38046 =A0w > root =A0 =A0 syslogd =A0 =A0 1479 =A0 18 /var =A0 =A0 1389578 -rw-r----- = =A0 =A0 =A062 =A0w > # fstat -p 1829 > USER =A0 =A0 CMD =A0 =A0 =A0 =A0 =A0PID =A0 FD MOUNT =A0 =A0 =A0INUM MODE= =A0 =A0 =A0 =A0 SZ|DV R/W > gcooper =A0sh =A0 =A0 =A0 =A0 =A01829 root / =A0 =A0 =A0 =A0 =A0 =A0 2 dr= wxr-xr-x =A0 =A01024 =A0r > gcooper =A0sh =A0 =A0 =A0 =A0 =A01829 =A0 wd /usr =A0 =A0 1884160 drwxr-x= r-x =A0 =A01024 =A0r > gcooper =A0sh =A0 =A0 =A0 =A0 =A01829 text / =A0 =A0 =A0 =A0212057 -r-xr-= xr-x =A0131784 =A0r > gcooper =A0sh =A0 =A0 =A0 =A0 =A01829 =A0 =A00 /dev =A0 =A0 =A0 =A0127 cr= w--w---- =A0 pts/0 rw > gcooper =A0sh =A0 =A0 =A0 =A0 =A01829 =A0 =A01 /dev =A0 =A0 =A0 =A0127 cr= w--w---- =A0 pts/0 rw > gcooper =A0sh =A0 =A0 =A0 =A0 =A01829 =A0 =A02 /dev =A0 =A0 =A0 =A0127 cr= w--w---- =A0 pts/0 rw > gcooper =A0sh =A0 =A0 =A0 =A0 =A01829 =A0 10 /dev =A0 =A0 =A0 =A0127 crw-= -w---- =A0 pts/0 rw > > # python -c 'import os; os.waitpid(1825, 0)' > Traceback (most recent call last): > =A0File "", line 1, in > OSError: [Errno 10] No child processes But pid 1825 (sshd) is not a child process of the python process , isn't it= ? from waitpid(2): [ECHILD] The calling process has no existing unwaited-for ch= ild processes. Look at /sys/kern/kern_exit.c:kern_wait(). The function returns ECHILD if a specified process was not found among p->p_children children group. > # ps auxww | grep 1825 > root =A0 =A0 1825 =A0 0.0 =A00.0 =A047952 =A0 =A0 =A00 =A0?? =A0IWs =A0- = =A0 =A0 =A0 =A0 0:00.00 > sshd: gcooper [priv] (sshd) > root =A0 =A088213 =A0 0.0 =A00.0 =A016340 =A0 1356 =A0 3 =A0S+ =A0 =A01:2= 5PM =A0 0:00.00 grep 1825 > # top -b > last pid: 96740; =A0load averages: =A01.07, =A00.98, =A00.92 =A0up 0+01:1= 5:32 =A0 =A013:27:04 > 50 processes: =A02 running, 48 sleeping > > Mem: 56M Active, 23M Inact, 795M Wired, 1848K Cache, 1237M Buf, 11G Free > Swap: 24G Total, 832K Used, 24G Free > > > =A0PID USERNAME =A0THR PRI NICE =A0 SIZE =A0 =A0RES STATE =A0 C =A0 TIME = =A0 WCPU > COMMAND > =A01828 gcooper =A0 =A0 1 =A020 =A0 =A00 47952K =A03372K select =A06 =A0 = 0:02 =A00.00% sshd > 26295 root =A0 =A0 =A0 =A01 =A020 =A0 =A00 =A09972K =A0 888K kqread =A02 = =A0 0:01 =A00.00% tail > 95888 root =A0 =A0 =A0 =A01 =A052 =A0 =A00 14472K =A08092K wait =A0 =A01 = =A0 0:00 =A00.00% make > =A01729 root =A0 =A0 =A0 =A01 =A020 =A0 =A00 20368K =A03000K select =A02 = =A0 0:00 =A00.00% sendmail > 59474 gcooper =A0 =A0 1 =A020 =A0 =A00 47952K =A03768K select =A07 =A0 0:= 00 =A00.00% sshd > 57339 root =A0 =A0 =A0 =A01 =A052 =A0 =A00 =A06280K =A01168K wait =A0 =A0= 1 =A0 0:00 =A00.00% make > 75210 gcooper =A0 =A0 1 =A020 =A0 =A00 47952K =A03816K select =A05 =A0 0:= 00 =A00.00% sshd > 82431 root =A0 =A0 =A0 =A01 =A052 =A0 =A00 =A06280K =A01148K wait =A0 =A0= 2 =A0 0:00 =A00.00% make > 94797 root =A0 =A0 =A0 =A01 =A052 =A0 =A00 =A06280K =A01164K wait =A0 =A0= 2 =A0 0:00 =A00.00% make > 59441 root =A0 =A0 =A0 =A01 =A021 =A0 =A00 47952K =A03772K sbwait =A04 = =A0 0:00 =A00.00% sshd > =A01825 root =A0 =A0 =A0 =A01 =A021 =A0 =A00 47952K =A0 =A0 0K sbwait =A0= 1 =A0 0:00 =A00.00% > 75167 root =A0 =A0 =A0 =A01 =A021 =A0 =A00 47952K =A03820K sbwait =A01 = =A0 0:00 =A00.00% sshd > =A01832 root =A0 =A0 =A0 =A01 =A020 =A0 =A00 47952K =A0 =A0 0K sbwait =A0= 1 =A0 0:00 =A00.00% > 96738 root =A0 =A0 =A0 =A01 =A072 =A0 =A00 17184K =A09756K CPU0 =A0 =A00 = =A0 0:00 =A00.00% cc1 > =A01479 root =A0 =A0 =A0 =A01 =A020 =A0 =A00 12228K =A01372K select =A04 = =A0 0:00 =A00.00% syslogd > 75237 root =A0 =A0 =A0 =A01 =A020 =A0 =A00 17612K =A02424K ttyin =A0 4 = =A0 0:00 =A00.00% bash > =A01835 gcooper =A0 =A0 1 =A020 =A0 =A00 47952K =A03284K select =A02 =A0 = 0:00 =A00.00% sshd > 57233 root =A0 =A0 =A0 =A01 =A052 =A0 =A00 =A06280K =A0 756K wait =A0 =A0= 2 =A0 0:00 =A00.00% make --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Fri May 6 06:31:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7379106564A for ; Fri, 6 May 2011 06:31:36 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8FFF18FC0C for ; Fri, 6 May 2011 06:31:36 +0000 (UTC) Received: by vxc34 with SMTP id 34so4184574vxc.13 for ; Thu, 05 May 2011 23:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MGXz85FJ4YmdZ6TOBbjqmYGHKmnJ8LD6ztJ0LjMdKX4=; b=eionPsNMqQVLUYQrUbjd4W+twNkIaPhW0edHEKulZXsGNJpVlgOBXTWhH8j15ZbD7+ uDLVwjhMLF3dVagy4524xA71zIYP2SfUIiDy70nKnL3dJQ2CKGwFz/Bfm4lNplUHTRMw rU2uhscooMcxCgkRoxD3UZNC7Eem8hzutfIN0= 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=OOw4qjM6pnhjUaKHYfHQ8YHRiW7k1DdbfeNYpEE+I5HE+S5nb6kbBe2qD0YxE5LVjC r+nYEAHp3AqmkEyrlf0N89Rs38kewTrRDTOaMBQmZ1ZJj4Fz/YkSpdV4SLDKBdgrLBKn z/s78HJXYVAd5Qxsok/R5+256z/WfV62tCrEA= MIME-Version: 1.0 Received: by 10.52.91.71 with SMTP id cc7mr1222489vdb.288.1304663495775; Thu, 05 May 2011 23:31:35 -0700 (PDT) Received: by 10.220.199.130 with HTTP; Thu, 5 May 2011 23:31:35 -0700 (PDT) In-Reply-To: References: Date: Thu, 5 May 2011 23:31:35 -0700 Message-ID: From: Garrett Cooper To: Sergey Kandaurov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: Processes in swapped out states in recent CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 06:31:36 -0000 On Thu, May 5, 2011 at 11:28 PM, Sergey Kandaurov wrote= : > On 6 May 2011 00:33, Garrett Cooper wrote: >> =A0 =A0I was watching top output on my dev box and I noticed that there >> are more swapped out processes present on the system, shortly after >> boot (which doesn't make sense given that I'm not low on resources on >> the box). Also, the os when I run os.waitpid() in python claims that >> the child doesn't exist, so I'm wondering if there's an issue with the >> processes reported via ps, top, etc. >> =A0 =A0I'm noting this because it's a behavior change over my >> 'stable'-ish workstation, running CURRENT/r220089/amd64, which is >> spec'ed out the same as the dev box, minus some multimedia hardware. >> Thanks, >> -Garrett >> >> # uname -a >> FreeBSD fallout.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r221219M: Thu >> May =A05 12:09:37 PDT 2011 >> root@fallout.local:/usr/obj/usr/src/sys/FALLOUT =A0amd6 >> # fstat -p 1832 >> USER =A0 =A0 CMD =A0 =A0 =A0 =A0 =A0PID =A0 FD MOUNT =A0 =A0 =A0INUM MOD= E =A0 =A0 =A0 =A0 SZ|DV R/W >> root =A0 =A0 sshd =A0 =A0 =A0 =A01832 root / =A0 =A0 =A0 =A0 =A0 =A0 2 d= rwxr-xr-x =A0 =A01024 =A0r >> root =A0 =A0 sshd =A0 =A0 =A0 =A01832 =A0 wd / =A0 =A0 =A0 =A0 =A0 =A0 2= drwxr-xr-x =A0 =A01024 =A0r >> root =A0 =A0 sshd =A0 =A0 =A0 =A01832 text /usr =A0 =A0 730118 -r-xr-xr-= x =A0240944 =A0r >> root =A0 =A0 sshd =A0 =A0 =A0 =A01832 =A0 =A00 /dev =A0 =A0 =A0 =A0 =A06= crw-rw-rw- =A0 =A0null =A0r >> root =A0 =A0 sshd =A0 =A0 =A0 =A01832 =A0 =A01 /dev =A0 =A0 =A0 =A0 =A06= crw-rw-rw- =A0 =A0null rw >> root =A0 =A0 sshd =A0 =A0 =A0 =A01832 =A0 =A02 /dev =A0 =A0 =A0 =A0 =A06= crw-rw-rw- =A0 =A0null rw >> root =A0 =A0 sshd =A0 =A0 =A0 =A01832 =A0 =A03* internet stream tcp ffff= fe01e56cf000 >> root =A0 =A0 sshd =A0 =A0 =A0 =A01832 =A0 =A04* pseudo-terminal master = =A0 =A0 =A0pts/1 rw >> root =A0 =A0 sshd =A0 =A0 =A0 =A01832 =A0 =A05* local stream fffffe0008f= 79960 <-> >> fffffe0008f79a50 >> # fstat -p 149 >> USER =A0 =A0 CMD =A0 =A0 =A0 =A0 =A0PID =A0 FD MOUNT =A0 =A0 =A0INUM MOD= E =A0 =A0 =A0 =A0 SZ|DV R/W >> root =A0 =A0 adjkerntz =A0 =A0149 root / =A0 =A0 =A0 =A0 =A0 =A0 2 drwxr= -xr-x =A0 =A01024 =A0r >> root =A0 =A0 adjkerntz =A0 =A0149 =A0 wd / =A0 =A0 =A0 =A0 =A0 =A0 2 drw= xr-xr-x =A0 =A01024 =A0r >> root =A0 =A0 adjkerntz =A0 =A0149 text / =A0 =A0 =A0 =A0329805 -r-xr-xr-= x =A0 =A08792 =A0r >> root =A0 =A0 adjkerntz =A0 =A0149 =A0 =A00 /dev =A0 =A0 =A0 =A0 =A06 crw= -rw-rw- =A0 =A0null rw >> root =A0 =A0 adjkerntz =A0 =A0149 =A0 =A01 /dev =A0 =A0 =A0 =A0 =A06 crw= -rw-rw- =A0 =A0null rw >> root =A0 =A0 adjkerntz =A0 =A0149 =A0 =A02 /dev =A0 =A0 =A0 =A0 =A06 crw= -rw-rw- =A0 =A0null rw >> # fstat -p 1479 >> USER =A0 =A0 CMD =A0 =A0 =A0 =A0 =A0PID =A0 FD MOUNT =A0 =A0 =A0INUM MOD= E =A0 =A0 =A0 =A0 SZ|DV R/W >> root =A0 =A0 syslogd =A0 =A0 1479 root / =A0 =A0 =A0 =A0 =A0 =A0 2 drwxr= -xr-x =A0 =A01024 =A0r >> root =A0 =A0 syslogd =A0 =A0 1479 =A0 wd / =A0 =A0 =A0 =A0 =A0 =A0 2 drw= xr-xr-x =A0 =A01024 =A0r >> root =A0 =A0 syslogd =A0 =A0 1479 text /usr =A0 =A0 739002 -r-xr-xr-x = =A0 39008 =A0r >> root =A0 =A0 syslogd =A0 =A0 1479 =A0 =A00 /dev =A0 =A0 =A0 =A0 =A06 crw= -rw-rw- =A0 =A0null rw >> root =A0 =A0 syslogd =A0 =A0 1479 =A0 =A01 /dev =A0 =A0 =A0 =A0 =A06 crw= -rw-rw- =A0 =A0null rw >> root =A0 =A0 syslogd =A0 =A0 1479 =A0 =A02 /dev =A0 =A0 =A0 =A0 =A06 crw= -rw-rw- =A0 =A0null rw >> root =A0 =A0 syslogd =A0 =A0 1479 =A0 =A03 /var =A0 =A0 353301 -rw------= - =A0 =A0 =A0 4 =A0w >> root =A0 =A0 syslogd =A0 =A0 1479 =A0 =A04* local dgram fffffe0008cd31e0 >> root =A0 =A0 syslogd =A0 =A0 1479 =A0 =A05* local dgram fffffe0008cd30f0 >> root =A0 =A0 syslogd =A0 =A0 1479 =A0 =A06* internet6 dgram udp fffffe00= 08ced540 >> root =A0 =A0 syslogd =A0 =A0 1479 =A0 =A07* internet dgram udp fffffe000= 8ced3f0 >> root =A0 =A0 syslogd =A0 =A0 1479 =A0 =A08 /dev =A0 =A0 =A0 =A0 29 crw--= ----- =A0 =A0klog =A0r >> root =A0 =A0 syslogd =A0 =A0 1479 =A0 10 /var =A0 =A0 1389613 -rw-r--r--= =A0 25389 =A0w >> root =A0 =A0 syslogd =A0 =A0 1479 =A0 11 /var =A0 =A0 1389579 -rw-------= =A0 =A0 =A062 =A0w >> root =A0 =A0 syslogd =A0 =A0 1479 =A0 12 /var =A0 =A0 1389572 -rw-------= =A0 10164 =A0w >> root =A0 =A0 syslogd =A0 =A0 1479 =A0 13 /var =A0 =A0 1389601 -rw-r-----= =A0 =A02814 =A0w >> root =A0 =A0 syslogd =A0 =A0 1479 =A0 14 /var =A0 =A0 1389575 -rw-r--r--= =A0 =A0 =A062 =A0w >> root =A0 =A0 syslogd =A0 =A0 1479 =A0 15 /var =A0 =A0 1389580 -rw-------= =A0 =A0 =A062 =A0w >> root =A0 =A0 syslogd =A0 =A0 1479 =A0 16 /var =A0 =A0 1389577 -rw-------= =A0 57212 =A0w >> root =A0 =A0 syslogd =A0 =A0 1479 =A0 17 /var =A0 =A0 1389606 -rw-------= =A0 38046 =A0w >> root =A0 =A0 syslogd =A0 =A0 1479 =A0 18 /var =A0 =A0 1389578 -rw-r-----= =A0 =A0 =A062 =A0w >> # fstat -p 1829 >> USER =A0 =A0 CMD =A0 =A0 =A0 =A0 =A0PID =A0 FD MOUNT =A0 =A0 =A0INUM MOD= E =A0 =A0 =A0 =A0 SZ|DV R/W >> gcooper =A0sh =A0 =A0 =A0 =A0 =A01829 root / =A0 =A0 =A0 =A0 =A0 =A0 2 d= rwxr-xr-x =A0 =A01024 =A0r >> gcooper =A0sh =A0 =A0 =A0 =A0 =A01829 =A0 wd /usr =A0 =A0 1884160 drwxr-= xr-x =A0 =A01024 =A0r >> gcooper =A0sh =A0 =A0 =A0 =A0 =A01829 text / =A0 =A0 =A0 =A0212057 -r-xr= -xr-x =A0131784 =A0r >> gcooper =A0sh =A0 =A0 =A0 =A0 =A01829 =A0 =A00 /dev =A0 =A0 =A0 =A0127 c= rw--w---- =A0 pts/0 rw >> gcooper =A0sh =A0 =A0 =A0 =A0 =A01829 =A0 =A01 /dev =A0 =A0 =A0 =A0127 c= rw--w---- =A0 pts/0 rw >> gcooper =A0sh =A0 =A0 =A0 =A0 =A01829 =A0 =A02 /dev =A0 =A0 =A0 =A0127 c= rw--w---- =A0 pts/0 rw >> gcooper =A0sh =A0 =A0 =A0 =A0 =A01829 =A0 10 /dev =A0 =A0 =A0 =A0127 crw= --w---- =A0 pts/0 rw >> >> # python -c 'import os; os.waitpid(1825, 0)' >> Traceback (most recent call last): >> =A0File "", line 1, in >> OSError: [Errno 10] No child processes > > But pid 1825 (sshd) is not a child process of the python process , isn't = it? > > from waitpid(2): > =A0 =A0 [ECHILD] =A0 =A0 =A0 =A0 =A0 The calling process has no existing = unwaited-for child > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0processes. > > Look at /sys/kern/kern_exit.c:kern_wait(). The function returns ECHILD if > a specified process was not found among p->p_children children group. Yeah, good point. I'd have to use kill(, 0) in that case. >> # ps auxww | grep 1825 >> root =A0 =A0 1825 =A0 0.0 =A00.0 =A047952 =A0 =A0 =A00 =A0?? =A0IWs =A0-= =A0 =A0 =A0 =A0 0:00.00 >> sshd: gcooper [priv] (sshd) >> root =A0 =A088213 =A0 0.0 =A00.0 =A016340 =A0 1356 =A0 3 =A0S+ =A0 =A01:= 25PM =A0 0:00.00 grep 1825 >> # top -b >> last pid: 96740; =A0load averages: =A01.07, =A00.98, =A00.92 =A0up 0+01:= 15:32 =A0 =A013:27:04 >> 50 processes: =A02 running, 48 sleeping >> >> Mem: 56M Active, 23M Inact, 795M Wired, 1848K Cache, 1237M Buf, 11G Free >> Swap: 24G Total, 832K Used, 24G Free >> >> >> =A0PID USERNAME =A0THR PRI NICE =A0 SIZE =A0 =A0RES STATE =A0 C =A0 TIME= =A0 WCPU >> COMMAND >> =A01828 gcooper =A0 =A0 1 =A020 =A0 =A00 47952K =A03372K select =A06 =A0= 0:02 =A00.00% sshd >> 26295 root =A0 =A0 =A0 =A01 =A020 =A0 =A00 =A09972K =A0 888K kqread =A02= =A0 0:01 =A00.00% tail >> 95888 root =A0 =A0 =A0 =A01 =A052 =A0 =A00 14472K =A08092K wait =A0 =A01= =A0 0:00 =A00.00% make >> =A01729 root =A0 =A0 =A0 =A01 =A020 =A0 =A00 20368K =A03000K select =A02= =A0 0:00 =A00.00% sendmail >> 59474 gcooper =A0 =A0 1 =A020 =A0 =A00 47952K =A03768K select =A07 =A0 0= :00 =A00.00% sshd >> 57339 root =A0 =A0 =A0 =A01 =A052 =A0 =A00 =A06280K =A01168K wait =A0 = =A01 =A0 0:00 =A00.00% make >> 75210 gcooper =A0 =A0 1 =A020 =A0 =A00 47952K =A03816K select =A05 =A0 0= :00 =A00.00% sshd >> 82431 root =A0 =A0 =A0 =A01 =A052 =A0 =A00 =A06280K =A01148K wait =A0 = =A02 =A0 0:00 =A00.00% make >> 94797 root =A0 =A0 =A0 =A01 =A052 =A0 =A00 =A06280K =A01164K wait =A0 = =A02 =A0 0:00 =A00.00% make >> 59441 root =A0 =A0 =A0 =A01 =A021 =A0 =A00 47952K =A03772K sbwait =A04 = =A0 0:00 =A00.00% sshd >> =A01825 root =A0 =A0 =A0 =A01 =A021 =A0 =A00 47952K =A0 =A0 0K sbwait = =A01 =A0 0:00 =A00.00% >> 75167 root =A0 =A0 =A0 =A01 =A021 =A0 =A00 47952K =A03820K sbwait =A01 = =A0 0:00 =A00.00% sshd >> =A01832 root =A0 =A0 =A0 =A01 =A020 =A0 =A00 47952K =A0 =A0 0K sbwait = =A01 =A0 0:00 =A00.00% >> 96738 root =A0 =A0 =A0 =A01 =A072 =A0 =A00 17184K =A09756K CPU0 =A0 =A00= =A0 0:00 =A00.00% cc1 >> =A01479 root =A0 =A0 =A0 =A01 =A020 =A0 =A00 12228K =A01372K select =A04= =A0 0:00 =A00.00% syslogd >> 75237 root =A0 =A0 =A0 =A01 =A020 =A0 =A00 17612K =A02424K ttyin =A0 4 = =A0 0:00 =A00.00% bash >> =A01835 gcooper =A0 =A0 1 =A020 =A0 =A00 47952K =A03284K select =A02 =A0= 0:00 =A00.00% sshd >> 57233 root =A0 =A0 =A0 =A01 =A052 =A0 =A00 =A06280K =A0 756K wait =A0 = =A02 =A0 0:00 =A00.00% make From owner-freebsd-current@FreeBSD.ORG Fri May 6 08:34:01 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BBCF106564A for ; Fri, 6 May 2011 08:34:01 +0000 (UTC) (envelope-from mavbsd@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 CBF738FC13 for ; Fri, 6 May 2011 08:34:00 +0000 (UTC) Received: by fxm11 with SMTP id 11so2878424fxm.13 for ; Fri, 06 May 2011 01:33:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature: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=Z9W9wsEu/XvSqQ5Q+ouEUDFo8M1Ii8fCC5xpri7rwA0=; b=XrdGXQhyPa5P0qdGoKORKLS9xgtxZ7iEOWlXM0gCalo57Dr6yg0Txf/kFzo9lsWlsL 9lXOmmvHq0KOQeiiUPi3RB7AY2Y4D+XZtEXJDVkl9YOJO4Ve+uhOuEGZ+XfqF+iPmIf5 ZQylI92R60VaaG25Rb+Qq0cxQYWhOYa2jPnWs= 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=GbqF8KMseU8eFgpuHhsfcRRqGBB63q/eWC51crsTfd4qWVS2jmU7V7FhU4kPk+eFhh 5w6l3zwpY0vqQVXdpjy6WEPUnGgq/YoszbjeL4nrup9gPIt/v9GdYPEQVz2+V4MtYWMq M3zqIOUsMSdsRp2ZjkBm7Re9tXsmQ1rC1ebOs= Received: by 10.223.62.194 with SMTP id y2mr3091805fah.123.1304670839688; Fri, 06 May 2011 01:33:59 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id j18sm1002505faa.42.2011.05.06.01.33.57 (version=SSLv3 cipher=OTHER); Fri, 06 May 2011 01:33:58 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DC3B256.8050800@FreeBSD.org> Date: Fri, 06 May 2011 11:33:26 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Sergey Kandaurov References: <4DAEAE1B.70207@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current Subject: Re: Switch from legacy ata(4) to CAM-based ATA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 08:34:01 -0000 Sergey Kandaurov wrote: > XENHVM uses it's own naming scheme and can name disks as daN or adN, > depending on virtual block device id. atapci0/ata0/ata1 devices still present > there (such as in Bruce Cran's dmesg), but no any disks attached from it: > instead, all of them hung from device/vbd/N. > [In a non-XENHVM mode they are attached from ataN channels, as usual.] > > /* > * Translate Linux major/minor to an appropriate name and unit > * number. For HVM guests, this allows us to use the same drive names > * with blkfront as the emulated drives, easing transition slightly. > */ > > xenbusb_front0: on xenstore0 > xenbusb_back0: on xenstore0 > xctrl0: on xenstore0 > xbd0: 17000MB at device/vbd/768 on xenbusb_front0 > xbd0: attaching as ad0 > GEOM: ad0s1: geometry does not match label (16h,63s != 255h,63s). > xbd1: 3812MB at device/vbd/2048 on xenbusb_front0 > xbd1: attaching as da0 > xbd2: 114439MB at device/vbd/2064 on xenbusb_front0 > xbd2: attaching as da1 OK, interesting question. I have built amd64 XENHVM kernel and booted it under Xen 3.2. As result I've got double set of devices, via both atapci0/ata0 and via blkfront: ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: ATA-7 device ada0: Serial Number QM00001 ada0: 16.700MB/s transfers (WDMA2, PIO 8192bytes) ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 ada1 at ata0 bus 0 scbus0 target 1 lun 0 ada1: ATA-7 device ada1: Serial Number QM00002 ada1: 16.700MB/s transfers (WDMA2, PIO 8192bytes) ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad1 xbd0: 476940MB at device/vbd/768 on xenbusb_front0 xbd0: attaching as ad0 xbd1: 476940MB at device/vbd/832 on xenbusb_front0 xbd1: attaching as ad1 Both of them were exported to GEOM. Extra set of adX devices caused error messages. What am I doing wrong and why have I got those duplicates? Was I required to remove non-PV drivers from my kernel? > Probably, /sys/dev/xen/blkfront/blkfront.c needs updating by s/"ad"/"ada"/g; > or such. I believe, xen generates sequential numbers starting from zero > (or rather such numbers that can be converted to sequential numbers), > similar to what ATA_CAM does. According to what I see, blkfront follows ATA_STATIC_ID behavior: if I configure Xen with single slave device (hdb), blkfront reports it as ad1. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri May 6 08:55:04 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66767106566B; Fri, 6 May 2011 08:55:04 +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 5BF8F8FC12; Fri, 6 May 2011 08:55:02 +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 LAA21314; Fri, 06 May 2011 11:55:01 +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 1QIGoP-000D1W-Bh; Fri, 06 May 2011 11:55:01 +0300 Message-ID: <4DC3B764.4030801@FreeBSD.org> Date: Fri, 06 May 2011 11:55:00 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: current@FreeBSD.org, multimedia@FreeBSD.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: Subject: dsp mmap change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 08:55:04 -0000 I would like to ask for a review and/or testing of the following patch: http://people.freebsd.org/~avg/dev_dsp_mmap.diff It's supposed to fix an issue described here: http://lists.freebsd.org/pipermail/freebsd-multimedia/2011-February/011691.html In short, the following pseudo-code should do the right thing: fd = open(/dev/dsp, O_RDWR); mmap(PROT_READ, fd); mmap(PROT_WRITE, fd); Thank you! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri May 6 09:04:55 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B2EE106564A for ; Fri, 6 May 2011 09:04:55 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id DCC8D8FC19 for ; Fri, 6 May 2011 09:04:54 +0000 (UTC) Received: from outgoing.leidinger.net (p5B1556E7.dip.t-dialin.net [91.21.86.231]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id C5298844010; Fri, 6 May 2011 11:04:40 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::2:102]) by outgoing.leidinger.net (Postfix) with ESMTP id 0CF27120D; Fri, 6 May 2011 11:04:38 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id p4694a1B039941; Fri, 6 May 2011 11:04:36 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Fri, 06 May 2011 11:04:36 +0200 Message-ID: <20110506110436.167568wcm6sjlt44@webmail.leidinger.net> Date: Fri, 06 May 2011 11:04:36 +0200 From: Alexander Leidinger To: David Christensen References: <5D267A3F22FD854F8F48B3D2B523819360D799A42B@IRVEXCHCCR01.corp.ad.broadcom.com> In-Reply-To: <5D267A3F22FD854F8F48B3D2B523819360D799A42B@IRVEXCHCCR01.corp.ad.broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.6) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: C5298844010.AFC04 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=0.6, required 6, autolearn=disabled, J_CHICKENPOX_39 0.60) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1305277481.75589@r05LN6H7pcPsYrVCIAaszQ X-EBL-Spam-Status: No Cc: "freebsd-current@freebsd.org" Subject: Re: Using Dtrace for Performance Evaluation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 09:04:55 -0000 Quoting David Christensen (from Thu, 5 May 2011 13:08:56 -0700): > I was looking at using dtrace to help characterize performance > for the new bxe(4) driver but I'm having problems with the very > simple task of capturing time spent in a function. The D script > I'm using looks like the following: > > #pragma D option quiet > > fbt:if_bxe::entry > { > self->in = timestamp; > } > > fbt:if_bxe::return > { > > @callouts[((struct callout *)arg0)->c_func] = sum(timestamp - > self->in); > } > > tick-10sec > { > printa("%40a %10@d\n", @callouts); > clear(@callouts); > printf("\n"); > } > > BEGIN > { > printf("%40s | %s\n", "function", "nanoseconds per second"); > } I think there is a more easy way of doing this. I have a script which wants to do some statistics too (depends upon local changes, but it's about the D code, not the providers used), it does this: ---snip--- #pragma D option dynvarsize=32m linuxulator*:::entry { self->time[probefunc] = vtimestamp; @calls[probeprov, execname, probefunc] = count(); } linuxulator*:::return /self->time[probefunc] != 0/ { this->timediff = self->time[probefunc] - vtimestamp; @stats[probeprov, execname, probefunc] = quantize(this->timediff); @longest[probeprov, probefunc] = max(this->timediff); self->time[probefunc] = 0; } END { printf("Number of calls per provider/application/kernel function:"); printa(@calls); printf("CPU-timing statistics per provider/application/kernel function (in ns):"); printa(@stats); printf("Longest running (CPU-time!) functions per provider (in ns):"); printa(@longest); } ---snip--- In your case you can forget about probeprov, but the probefunc should be more convenient to use than the casting and dereferencing you do. The constraint for the return is there to prevent problems in case one starts the tracing when a CPU is inbetween entry and return. Bye, Alexander. -- There is a multi-legged creature crawling on your shoulder. -- Spock, "A Taste of Armageddon", stardate 3193.9 http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Fri May 6 09:08:39 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9556106566B; Fri, 6 May 2011 09:08:39 +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 7079D8FC0C; Fri, 6 May 2011 09:08:39 +0000 (UTC) Received: by qwc9 with SMTP id 9so2640888qwc.13 for ; Fri, 06 May 2011 02:08:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ebTgSJgstI6SyGFSmLbKFiYfivhyHaUSHJR8OfXzF2E=; b=cBuKNLy7p89sqIdQVYxgB51/Dnm5rykDpwxnimIxI79WNBE4IkBaclzTk49+gLDy21 yihUnK7Q/k+GIVKRNXddo0nEy2J20aRoso9BXcdzuwTAg68aRgvaPTV5RuMQRGNCDPUl Nj3cAbFdP5HwAOK0RxQxNbOc1NjiYmoi52P8Y= 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=oE0qIuoXDrpViV5xsJ6lF9nRfbq5UqZmJZdzB3sEp6fnPwCmbpR0UvRL7PX0zrLJlA bzZi/ufUYw3w/6bldE0AZLcVDMfYcxPGtgX06wi6pfvT0EofGy+mv1XDrylXsvA6Lol9 O0TczODIVzrgkyR5dWCXtTtilaNPg5SBn5yYo= MIME-Version: 1.0 Received: by 10.229.112.21 with SMTP id u21mr2335623qcp.62.1304672918573; Fri, 06 May 2011 02:08:38 -0700 (PDT) Received: by 10.229.95.19 with HTTP; Fri, 6 May 2011 02:08:38 -0700 (PDT) In-Reply-To: <4DC3B256.8050800@FreeBSD.org> References: <4DAEAE1B.70207@FreeBSD.org> <4DC3B256.8050800@FreeBSD.org> Date: Fri, 6 May 2011 13:08:38 +0400 Message-ID: From: Sergey Kandaurov To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-Current Subject: Re: Switch from legacy ata(4) to CAM-based ATA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 09:08:40 -0000 On 6 May 2011 12:33, Alexander Motin wrote: > Sergey Kandaurov wrote: >> XENHVM uses it's own naming scheme and can name disks as daN or adN, >> depending on virtual block device id. atapci0/ata0/ata1 devices still pr= esent >> there (such as in Bruce Cran's dmesg), but no any disks attached from it= : >> instead, all of them hung from device/vbd/N. >> [In a non-XENHVM mode they are attached from ataN channels, as usual.] >> >> /* >> =A0* Translate Linux major/minor to an appropriate name and unit >> =A0* number. For HVM guests, this allows us to use the same drive names >> =A0* with blkfront as the emulated drives, easing transition slightly. >> =A0*/ >> >> xenbusb_front0: on xenstore0 >> xenbusb_back0: on xenstore0 >> xctrl0: on xenstore0 >> xbd0: 17000MB at device/vbd/768 on xenbusb_front0 >> xbd0: attaching as ad0 >> GEOM: ad0s1: geometry does not match label (16h,63s !=3D 255h,63s). >> xbd1: 3812MB at device/vbd/2048 on xenbusb_front0 >> xbd1: attaching as da0 >> xbd2: 114439MB at device/vbd/2064 on xenbusb_fron= t0 >> xbd2: attaching as da1 > > OK, interesting question. I have built amd64 XENHVM kernel and booted it > under Xen 3.2. As result I've got double set of devices, via both > atapci0/ata0 and via blkfront: > > ada0 at ata0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-7 device > ada0: Serial Number QM00001 > ada0: 16.700MB/s transfers (WDMA2, PIO 8192bytes) > ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > ada0: Previously was known as ad0 > ada1 at ata0 bus 0 scbus0 target 1 lun 0 > ada1: ATA-7 device > ada1: Serial Number QM00002 > ada1: 16.700MB/s transfers (WDMA2, PIO 8192bytes) > ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > ada1: Previously was known as ad1 > xbd0: 476940MB at device/vbd/768 on xenbusb_front0 > xbd0: attaching as ad0 > xbd1: 476940MB at device/vbd/832 on xenbusb_front0 > xbd1: attaching as ad1 > Both of them were exported to GEOM. Extra set of adX devices caused > error messages. What am I doing wrong and why have I got those > duplicates? Was I required to remove non-PV drivers from my kernel? Doh. This corresponds to errors omitted unintentionally in my previous mail= . This is right after "xbd2: attaching as da1": da0 at sym0 bus 0 scbus2 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 3.300MB/s transfers da0: Command Queueing enabled da0: 3812MB (7807527 512 byte sectors: 255H 63S/T 485C) can't re-use a leaf (led)! g_dev_taste: make_dev_p() failed (gp->name=3Dda0, error=3D17) da1 at sym0 bus 0 scbus2 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 3.300MB/s transfers da1: Command Queueing enabled da1: 114439MB (234372222 512 byte sectors: 255H 63S/T 14588C) can't re-use a leaf (led)! g_dev_taste: make_dev_p() failed (gp->name=3Dda1, error=3D17) No ada devices detected though. --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Fri May 6 09:17:13 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45D7E106564A for ; Fri, 6 May 2011 09:17:13 +0000 (UTC) (envelope-from mavbsd@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 C00358FC18 for ; Fri, 6 May 2011 09:17:12 +0000 (UTC) Received: by fxm11 with SMTP id 11so2932078fxm.13 for ; Fri, 06 May 2011 02:17:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature: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=ZIgtE3bAfsaE/BZeTssiMzIa6qIiFErXT4BasR1FAAA=; b=MkOkakORQ/q7Pns/NLyUSnKVwx8PXZYWU6niXb4x9tMVexf9RZCOMMxZyJIE/V6kcU RlLoOzz0S2TNsZxo+yYPPTvrfYubvku0I29DMcjV52HvqvfDPiNLC75S2Z4DZGv3IluO EJHSK5No3D3JLZfM9gVqyfExzoY9E9FCuSLgE= 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=P2SWK36vY75K6xkiiLBdLc7Wa2h51XMGl/rISbhgxr2is4aFTPC9xc9SiMZGZO5yTZ 38e/TFEVWeIZ914qb5wPvqMihsWKWey0CJuf7pivC7UgQcX92wCJ/3IcZvcH6tXThjWa U61M1d52tpmngpCN6evHNrM/pQVmdlAxD90Rg= Received: by 10.223.1.201 with SMTP id 9mr2504647fag.91.1304673431693; Fri, 06 May 2011 02:17:11 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 9sm1019497fat.15.2011.05.06.02.17.10 (version=SSLv3 cipher=OTHER); Fri, 06 May 2011 02:17:11 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DC3BC76.4000102@FreeBSD.org> Date: Fri, 06 May 2011 12:16:38 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Sergey Kandaurov References: <4DAEAE1B.70207@FreeBSD.org> <4DC3B256.8050800@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current Subject: Re: Switch from legacy ata(4) to CAM-based ATA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 09:17:13 -0000 Sergey Kandaurov wrote: > On 6 May 2011 12:33, Alexander Motin wrote: >> Sergey Kandaurov wrote: >>> XENHVM uses it's own naming scheme and can name disks as daN or adN, >>> depending on virtual block device id. atapci0/ata0/ata1 devices still present >>> there (such as in Bruce Cran's dmesg), but no any disks attached from it: >>> instead, all of them hung from device/vbd/N. >>> [In a non-XENHVM mode they are attached from ataN channels, as usual.] >>> >>> /* >>> * Translate Linux major/minor to an appropriate name and unit >>> * number. For HVM guests, this allows us to use the same drive names >>> * with blkfront as the emulated drives, easing transition slightly. >>> */ >>> >>> xenbusb_front0: on xenstore0 >>> xenbusb_back0: on xenstore0 >>> xctrl0: on xenstore0 >>> xbd0: 17000MB at device/vbd/768 on xenbusb_front0 >>> xbd0: attaching as ad0 >>> GEOM: ad0s1: geometry does not match label (16h,63s != 255h,63s). >>> xbd1: 3812MB at device/vbd/2048 on xenbusb_front0 >>> xbd1: attaching as da0 >>> xbd2: 114439MB at device/vbd/2064 on xenbusb_front0 >>> xbd2: attaching as da1 >> OK, interesting question. I have built amd64 XENHVM kernel and booted it >> under Xen 3.2. As result I've got double set of devices, via both >> atapci0/ata0 and via blkfront: >> >> ada0 at ata0 bus 0 scbus0 target 0 lun 0 >> ada0: ATA-7 device >> ada0: Serial Number QM00001 >> ada0: 16.700MB/s transfers (WDMA2, PIO 8192bytes) >> ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) >> ada0: Previously was known as ad0 >> ada1 at ata0 bus 0 scbus0 target 1 lun 0 >> ada1: ATA-7 device >> ada1: Serial Number QM00002 >> ada1: 16.700MB/s transfers (WDMA2, PIO 8192bytes) >> ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) >> ada1: Previously was known as ad1 >> xbd0: 476940MB at device/vbd/768 on xenbusb_front0 >> xbd0: attaching as ad0 >> xbd1: 476940MB at device/vbd/832 on xenbusb_front0 >> xbd1: attaching as ad1 >> Both of them were exported to GEOM. Extra set of adX devices caused >> error messages. What am I doing wrong and why have I got those >> duplicates? Was I required to remove non-PV drivers from my kernel? > > Doh. This corresponds to errors omitted unintentionally in my previous mail. > This is right after "xbd2: attaching as da1": > > da0 at sym0 bus 0 scbus2 target 0 lun 0 > da0: Fixed Direct Access SCSI-3 device > da0: 3.300MB/s transfers > da0: Command Queueing enabled > da0: 3812MB (7807527 512 byte sectors: 255H 63S/T 485C) > can't re-use a leaf (led)! > g_dev_taste: make_dev_p() failed (gp->name=da0, error=17) > da1 at sym0 bus 0 scbus2 target 1 lun 0 > da1: Fixed Direct Access SCSI-3 device > da1: 3.300MB/s transfers > da1: Command Queueing enabled > da1: 114439MB (234372222 512 byte sectors: 255H 63S/T 14588C) > can't re-use a leaf (led)! > g_dev_taste: make_dev_p() failed (gp->name=da1, error=17) > > No ada devices detected though. But you have duplicate daX here. It is just the same, except that you have different Xen configuration -- disks configured as SCSI instead of ATA. So the question is the same: how this supposed to work? To me, that double detection problem seems much more significant then names change. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri May 6 13:32:09 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 542AC106566C; Fri, 6 May 2011 13:32:09 +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 C53388FC0C; Fri, 6 May 2011 13:32:08 +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 p46DW4HA062044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 May 2011 16:32:04 +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 p46DW4it083861; Fri, 6 May 2011 16:32:04 +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 p46DW4AK083860; Fri, 6 May 2011 16:32:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 6 May 2011 16:32:04 +0300 From: Kostik Belousov To: Andriy Gapon Message-ID: <20110506133204.GE48734@deviant.kiev.zoral.com.ua> References: <4DC3B764.4030801@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oW7sRvnhM3o6r0iO" Content-Disposition: inline In-Reply-To: <4DC3B764.4030801@FreeBSD.org> 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=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, 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: current@freebsd.org, multimedia@freebsd.org Subject: Re: dsp mmap change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 13:32:09 -0000 --oW7sRvnhM3o6r0iO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 06, 2011 at 11:55:00AM +0300, Andriy Gapon wrote: >=20 > I would like to ask for a review and/or testing of the following patch: > http://people.freebsd.org/~avg/dev_dsp_mmap.diff >=20 > It's supposed to fix an issue described here: > http://lists.freebsd.org/pipermail/freebsd-multimedia/2011-February/01169= 1.html >=20 > In short, the following pseudo-code should do the right thing: > fd =3D open(/dev/dsp, O_RDWR); > mmap(PROT_READ, fd); > mmap(PROT_WRITE, fd); >=20 > Thank you! I think that you have to call PCM_GIANT_LEAVE() when returning EINVAL on the vm_pager_alloc() failure. Your patch hardcodes an assumption that sndbufs are always contiguous. I was unable to convince myself that this is true. --oW7sRvnhM3o6r0iO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk3D+FMACgkQC3+MBN1Mb4hSCwCg3jrBuja6zxUakMlfEtxo0K8R XGUAn1l+mZr+eJeH7cGIbdTnue9PvPZS =nIgf -----END PGP SIGNATURE----- --oW7sRvnhM3o6r0iO-- From owner-freebsd-current@FreeBSD.ORG Fri May 6 13:38:04 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6379B106564A; Fri, 6 May 2011 13:38:04 +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 7B5DE8FC1E; Fri, 6 May 2011 13:38:03 +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 QAA24557; Fri, 06 May 2011 16:38:00 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DC3F9B8.3030505@FreeBSD.org> Date: Fri, 06 May 2011 16:38:00 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Kostik Belousov References: <4DC3B764.4030801@FreeBSD.org> <20110506133204.GE48734@deviant.kiev.zoral.com.ua> In-Reply-To: <20110506133204.GE48734@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org, multimedia@FreeBSD.org Subject: Re: dsp mmap change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 13:38:04 -0000 on 06/05/2011 16:32 Kostik Belousov said the following: > On Fri, May 06, 2011 at 11:55:00AM +0300, Andriy Gapon wrote: >> >> I would like to ask for a review and/or testing of the following patch: >> http://people.freebsd.org/~avg/dev_dsp_mmap.diff >> >> It's supposed to fix an issue described here: >> http://lists.freebsd.org/pipermail/freebsd-multimedia/2011-February/011691.html >> >> In short, the following pseudo-code should do the right thing: >> fd = open(/dev/dsp, O_RDWR); >> mmap(PROT_READ, fd); >> mmap(PROT_WRITE, fd); >> >> Thank you! > > I think that you have to call PCM_GIANT_LEAVE() when returning > EINVAL on the vm_pager_alloc() failure. Yes, thank you. > Your patch hardcodes an assumption that sndbufs are always > contiguous. I was unable to convince myself that this is true. I think that this should be true for the case when DMA is used? But, yes, very good point. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri May 6 13:43:14 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EF9D1065672; Fri, 6 May 2011 13:43:14 +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 6E9B28FC17; Fri, 6 May 2011 13:43: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 QAA24633; Fri, 06 May 2011 16:43:11 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DC3FAEE.7020807@FreeBSD.org> Date: Fri, 06 May 2011 16:43:10 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Kostik Belousov References: <4DC3B764.4030801@FreeBSD.org> <20110506133204.GE48734@deviant.kiev.zoral.com.ua> <4DC3F9B8.3030505@FreeBSD.org> In-Reply-To: <4DC3F9B8.3030505@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org, multimedia@FreeBSD.org Subject: Re: dsp mmap change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 13:43:14 -0000 on 06/05/2011 16:38 Andriy Gapon said the following: > on 06/05/2011 16:32 Kostik Belousov said the following: >> Your patch hardcodes an assumption that sndbufs are always >> contiguous. I was unable to convince myself that this is true. > > I think that this should be true for the case when DMA is used? > But, yes, very good point. I've updated the patch in place. Should this work better? Thank you. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri May 6 13:51:18 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6588C106566B for ; Fri, 6 May 2011 13:51:18 +0000 (UTC) (envelope-from inyaoo@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 DC80D8FC13 for ; Fri, 6 May 2011 13:51:17 +0000 (UTC) Received: by fxm11 with SMTP id 11so3278246fxm.13 for ; Fri, 06 May 2011 06:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=7snulbTTifCMNnujUMCo3E3+DFWrbQCL3xoEl+r4MXI=; b=XPg4QkGpQKfpTl7067ImSiedeWaQNJZfHIok/AMsJXOPTpQfuoxbiq+ZLhoHyZHopf Fe0jtSuiorm7oGCipxH/NsYJbcOc5C0zvvUqaRdoEmlxTPzSUpbCbA6FkAWcVG/XIPq0 t9fsJAvo688E/TX4IRaq2syNK3iYODDazAde4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=cyt2g9GKrAA0iBzPg1s9AhRMjRCNTU9R5QVZJK77fT7Z1lBQgxElCSOtEGzjOx/2uX 5Q2wMtaheo0xJg0qlAbVyn4P2q7dS4CBgLwjWoTpfRgK+dnPoLqNZSN1ZwvRBpck6jCV OEKyEzOijZtM6D8jlbmt9iYZhQs/dQ1KuiWb4= Received: by 10.223.86.130 with SMTP id s2mr1610841fal.115.1304689876676; Fri, 06 May 2011 06:51:16 -0700 (PDT) Received: from localhost (raidz.torservers.net [46.19.138.242]) by mx.google.com with ESMTPS id l1sm2042280bkl.1.2011.05.06.06.51.10 (version=SSLv3 cipher=OTHER); Fri, 06 May 2011 06:51:13 -0700 (PDT) From: Pan Tsu To: Olivier Smedts References: <201105040107.p4417NTR048534@pozo.com> <4DC0F46C.3020806@FreeBSD.org> <201105041344.p44DiOId032272@pozo.com> <4DC160B9.5060004@FreeBSD.org> <4DC2A0E5.5040602@zedat.fu-berlin.de> <20110505135458.GA79622@freebsd.org> Date: Fri, 06 May 2011 17:50:58 +0400 In-Reply-To: (Olivier Smedts's message of "Thu, 5 May 2011 17:46:00 +0200") Message-ID: <86liykgcot.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-current@freebsd.org Subject: Re: Clang error make buildworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 13:51:18 -0000 Olivier Smedts writes: > 2011/5/5 Roman Divacky : >>> Because with clang, -march=native often breaks buildworld, while >>> -march=core2 is ok. >> >> Can you be more specific about this claim? On what CPU are seeing >> this breakage? > > Ok, with latest HEAD... > > %echo | gcc -march=native -E -v -x c -### - > Using built-in specs. > Target: amd64-undermydesk-freebsd > Configured with: FreeBSD/amd64 system compiler > Thread model: posix > gcc version 4.2.2 20070831 prerelease [FreeBSD] > "/usr/libexec/cc1" "-E" "-quiet" "-v" "-D_LONGLONG" "-" > "-march=core2" "-mtune=generic" > > With "-march=native", gcc adds "-mtune=generic" while the man pages > says "-march=xxx" sets "-mtune=xxx". No longer true for `-march=native' on more recent GCC versions. $ gcc46 -v -march=native foo.c |& fgrep cc1 # C2D E8400 ...-march=core2 -mcx16 -msahf -msse4.1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144 -mtune=core2... $ gcc46 -v -march=core2 foo.c |& fgrep cc1 ...-march=core2... $ clang -v -march=native foo.c |& grep -o -- '-target-cpu \w*' -target-cpu penryn From owner-freebsd-current@FreeBSD.ORG Fri May 6 14:04:35 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CC36106566B; Fri, 6 May 2011 14:04:35 +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 759BA8FC19; Fri, 6 May 2011 14:04:33 +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 p46E4URm064363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 May 2011 17:04:30 +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 p46E4Up3084048; Fri, 6 May 2011 17:04:30 +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 p46E4SSY084047; Fri, 6 May 2011 17:04:28 +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, 6 May 2011 17:04:28 +0300 From: Kostik Belousov To: Andriy Gapon Message-ID: <20110506140428.GF48734@deviant.kiev.zoral.com.ua> References: <4DC3B764.4030801@FreeBSD.org> <20110506133204.GE48734@deviant.kiev.zoral.com.ua> <4DC3F9B8.3030505@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cClFwTGwHXbya3Sb" Content-Disposition: inline In-Reply-To: <4DC3F9B8.3030505@FreeBSD.org> 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=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, 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: current@freebsd.org, multimedia@freebsd.org Subject: Re: dsp mmap change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 14:04:35 -0000 --cClFwTGwHXbya3Sb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 06, 2011 at 04:38:00PM +0300, Andriy Gapon wrote: > on 06/05/2011 16:32 Kostik Belousov said the following: > > On Fri, May 06, 2011 at 11:55:00AM +0300, Andriy Gapon wrote: > >> > >> I would like to ask for a review and/or testing of the following patch: > >> http://people.freebsd.org/~avg/dev_dsp_mmap.diff > >> > >> It's supposed to fix an issue described here: > >> http://lists.freebsd.org/pipermail/freebsd-multimedia/2011-February/01= 1691.html > >> > >> In short, the following pseudo-code should do the right thing: > >> fd =3D open(/dev/dsp, O_RDWR); > >> mmap(PROT_READ, fd); > >> mmap(PROT_WRITE, fd); > >> > >> Thank you! > >=20 > > I think that you have to call PCM_GIANT_LEAVE() when returning > > EINVAL on the vm_pager_alloc() failure. >=20 > Yes, thank you. >=20 > > Your patch hardcodes an assumption that sndbufs are always > > contiguous. I was unable to convince myself that this is true. >=20 > I think that this should be true for the case when DMA is used? In the current driver, yes, but there is nothing that theoretically prevents scatter-gather from be used. > But, yes, very good point. Updated patch looks fine (for me). --cClFwTGwHXbya3Sb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk3D/+sACgkQC3+MBN1Mb4iZQACbBSmAOBM+GEy667CErS+1DF4e iWgAoOzaWmk3vaQqsrAEDN1cV65xmfoh =UCoQ -----END PGP SIGNATURE----- --cClFwTGwHXbya3Sb-- From owner-freebsd-current@FreeBSD.ORG Fri May 6 15:02:49 2011 Return-Path: Delivered-To: Current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90154106568A for ; Fri, 6 May 2011 15:02:49 +0000 (UTC) (envelope-from Daan@vehosting.nl) Received: from VM01.VEHosting.nl (VM016.VEHosting.nl [IPv6:2001:1af8:2100:b020::140]) by mx1.freebsd.org (Postfix) with ESMTP id E132C8FC17 for ; Fri, 6 May 2011 15:02:48 +0000 (UTC) Received: from [192.168.72.11] (124-54.bbned.dsl.internl.net [92.254.54.124]) (authenticated bits=0) by VM01.VEHosting.nl (8.14.3/8.13.8) with ESMTP id p46F2khh017986; Fri, 6 May 2011 17:02:46 +0200 (CEST) (envelope-from Daan@vehosting.nl) From: Daan Vreeken Organization: http://VEHosting.nl/ To: Jack Vogel Date: Fri, 6 May 2011 17:02:42 +0200 User-Agent: KMail/1.9.10 References: <201105041734.50738.Daan@vehosting.nl> <201105052217.51893.Daan@vehosting.nl> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201105061702.43073.Daan@vehosting.nl> x-ve-auth-version: mi-1.1.5 2011-02-07 - Copyright (c) 2008, 2011 - Daan Vreeken - VEHosting x-ve-auth: authenticated as 'pa4dan' on VM01.VEHosting.nl Cc: Current@freebsd.org, Peter Jeremy Subject: Re: Interrupt storm with MSI in combination with em1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 15:02:49 -0000 On Thursday 05 May 2011 22:22:15 Jack Vogel wrote: > On Thu, May 5, 2011 at 1:17 PM, Daan Vreeken wrote: > > Hi Peter, > > > > On Thursday 05 May 2011 21:28:02 Peter Jeremy wrote: > > > On 2011-May-05 13:22:59 +0200, Daan Vreeken wrote: > > > >Not yet. I'll reboot the machine later today when I have physical > > > > access to it to check the BIOS version. I'll keep you informed as > > > > soon as I get another storm going. > > > > > > Depending on the quality of your BIOS (competence of the vendor), you > > > might find that kenv(8) reports the BIOS version without needing a > > > reboot. > > > (Look at smbios.bios.* in the output). ... > > smbios.bios.version="0303 " ... > > Version "0402" is the latest and greatest, so it's time to upgrade. > > According > > to Asus it "Improves system stability", so let's see if this 'cures' IRQ > > 16. > > Cool, thanks for the update! Good luck. I've updated the BIOS and let the machine run for a couple of hours with MSI/MSIX enabled. After 3 hours of uptime I see the storm again. Here are the first couple of lines of output of "top -S" : last pid: 33218; load averages: 0.47, 0.35, 0.33 up 0+03:52:1016:42:52 317 processes: 6 running, 289 sleeping, 22 waiting CPU: 0.4% user, 0.0% nice, 0.5% system, 11.6% interrupt, 87.5% idle Mem: 280M Active, 176M Inact, 1797M Wired, 8572K Cache, 32M Buf, 5545M Free Swap: 500M Total, 500M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 4 171 ki31 0K 64K CPU0 0 893:17 351.95% idle 12 root 23 -80 - 0K 368K WAIT 2 18:37 50.39% intr One core is spending half it's time handling interrupts. /var/log/messages doesn't show any new message since the storm started. "vmstat -i" now shows : # vmstat -i interrupt total rate irq3: uart1 917384 63 --> irq16: ehci0 809547235 55608 irq23: ehci1 1751385 120 cpu0:timer 16380717 1125 irq256: em0:rx 0 1651907 113 irq257: em0:tx 0 1495708 102 irq258: em0:link 3 0 irq259: em1:rx 0 397227 27 irq260: em1:tx 0 257865 17 irq261: em1:link 6 0 irq262: re0 10549 0 irq263: ahci0 290926 19 cpu1:timer 1160008 79 cpu3:timer 763939 52 cpu2:timer 4120133 283 irq272: hdac0 819282 56 Total 839564274 57670 Apart from spending far too much time handling interrupts, the machine works fine, so I'll let it run in case anyone wants me to try something on it. As a next step to try to isolate the problem I could create a kernel with MSI/MSIX enabled, but with a modified 'em' driver so it doesn't try to attach the MSI/MSIX interrupts to see if the problem is really related to the network cards or not. If anyone has a better idea, I'm all ears :) Regards, -- Daan Vreeken VEHosting http://VEHosting.nl tel: +31-(0)40-7113050 / +31-(0)6-46210825 KvK nr: 17174380 From owner-freebsd-current@FreeBSD.ORG Fri May 6 15:31:14 2011 Return-Path: Delivered-To: Current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E31E2106566B for ; Fri, 6 May 2011 15:31:14 +0000 (UTC) (envelope-from prvs=1107585b49=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 6EB208FC1B for ; Fri, 6 May 2011 15:31:14 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Fri, 06 May 2011 16:20:18 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Fri, 06 May 2011 16:20:18 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50013207404.msg for ; Fri, 06 May 2011 16:20:17 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1107585b49=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: Current@freebsd.org Message-ID: From: "Steven Hartland" To: "Daan Vreeken" , "Jack Vogel" References: <201105041734.50738.Daan@vehosting.nl><201105052217.51893.Daan@vehosting.nl> <201105061702.43073.Daan@vehosting.nl> Date: Fri, 6 May 2011 16:20:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 Cc: Current@freebsd.org, Peter Jeremy Subject: Re: Interrupt storm with MSI in combination with em1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 15:31:15 -0000 ----- Original Message ----- From: "Daan Vreeken" > > # vmstat -i > interrupt total rate > irq3: uart1 917384 63 > --> irq16: ehci0 809547235 55608 Have you tried removing USB from the kernel? USB seems to be a common course of this behaviour and here at least removing it from the kernel fixes in all cases assuming you don't need it for something? ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Fri May 6 15:32:17 2011 Return-Path: Delivered-To: Current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82E111065679 for ; Fri, 6 May 2011 15:32:17 +0000 (UTC) (envelope-from Daan@vehosting.nl) Received: from VM01.VEHosting.nl (VM016.VEHosting.nl [IPv6:2001:1af8:2100:b020::140]) by mx1.freebsd.org (Postfix) with ESMTP id 18BC78FC16 for ; Fri, 6 May 2011 15:32:16 +0000 (UTC) Received: from [192.168.72.11] (124-54.bbned.dsl.internl.net [92.254.54.124]) (authenticated bits=0) by VM01.VEHosting.nl (8.14.3/8.13.8) with ESMTP id p46FWFwo018270; Fri, 6 May 2011 17:32:15 +0200 (CEST) (envelope-from Daan@vehosting.nl) From: Daan Vreeken Organization: http://VEHosting.nl/ To: "Steven Hartland" Date: Fri, 6 May 2011 17:32:12 +0200 User-Agent: KMail/1.9.10 References: <201105041734.50738.Daan@vehosting.nl> <201105061702.43073.Daan@vehosting.nl> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201105061732.12418.Daan@vehosting.nl> x-ve-auth-version: mi-1.1.5 2011-02-07 - Copyright (c) 2008, 2011 - Daan Vreeken - VEHosting x-ve-auth: authenticated as 'pa4dan' on VM01.VEHosting.nl Cc: Jack Vogel , Peter Jeremy , Current@freebsd.org Subject: Re: Interrupt storm with MSI in combination with em1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 15:32:17 -0000 Hi Steven, On Friday 06 May 2011 17:20:15 Steven Hartland wrote: > From: "Daan Vreeken" > > > # vmstat -i > > interrupt total rate > > irq3: uart1 917384 63 > > --> irq16: ehci0 809547235 55608 > > Have you tried removing USB from the kernel? > > USB seems to be a common course of this behaviour and here at least > removing it from the kernel fixes in all cases assuming you don't > need it for something? No, I haven't tried that yet. I could disable USB to run some tests, but I'll eventually need it enabled again. I'll wait for a couple of hours to see if anyone can come up with a test to run on the machine while the interrupt is still storming. After that I'll reboot it with USB disabled. Thanks, -- Daan Vreeken VEHosting http://VEHosting.nl tel: +31-(0)40-7113050 / +31-(0)6-46210825 KvK nr: 17174380 From owner-freebsd-current@FreeBSD.ORG Fri May 6 15:36:55 2011 Return-Path: Delivered-To: Current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5212F106564A for ; Fri, 6 May 2011 15:36:55 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 044F58FC1E for ; Fri, 6 May 2011 15:36:54 +0000 (UTC) Received: by vxc34 with SMTP id 34so4788375vxc.13 for ; Fri, 06 May 2011 08:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QcTV0NfzdxURPhoIjUOD062mm6C8CEI9BUCBmYLonhU=; b=ucZBgc6okiXxp2LBd2UM7uDXL5T4iGwbIFbZ+FmLQKKjH05DmPyGCziUg+WqWXqr6t yeS1cBrReo3kyJ49f/8y4T9ujjOqM2l5wSDH5a9oLjjV2ccIqHOvrl93zZHMNDX7Xyt/ tcmZUHRFzNQmk6haQeezCHuFhGwvrAVKXMFcs= 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=VHL071xsQvpM/HVmHxNWHfgBgCGt0OWCiDli2HtSnzYaWUPnR/Y7iJ6dFJ995Krole lVm/PNNMp27hnQ9rGW5pMRjjsFWchTagZ+wvi9U0AW4SfhWZCXJN3dVl9XHg/OtMsXeX QLuMvn4nfq0kCTvObZmGfyv4uc/cfE714Mryo= MIME-Version: 1.0 Received: by 10.52.18.14 with SMTP id s14mr4815775vdd.164.1304696212837; Fri, 06 May 2011 08:36:52 -0700 (PDT) Received: by 10.52.184.169 with HTTP; Fri, 6 May 2011 08:36:52 -0700 (PDT) In-Reply-To: <201105061732.12418.Daan@vehosting.nl> References: <201105041734.50738.Daan@vehosting.nl> <201105061702.43073.Daan@vehosting.nl> <201105061732.12418.Daan@vehosting.nl> Date: Fri, 6 May 2011 08:36:52 -0700 Message-ID: From: Jack Vogel To: Daan Vreeken Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Steven Hartland , Current@freebsd.org, Peter Jeremy Subject: Re: Interrupt storm with MSI in combination with em1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 15:36:55 -0000 I don't see why you are blaming em, you can see its on MSIX vectors that are NOT storming, its something with USB as noted. Trying to disable em from using MSIX is in exactly the wrong direction IMHO. Jack On Fri, May 6, 2011 at 8:32 AM, Daan Vreeken wrote: > Hi Steven, > > On Friday 06 May 2011 17:20:15 Steven Hartland wrote: > > From: "Daan Vreeken" > > > > > # vmstat -i > > > interrupt total rate > > > irq3: uart1 917384 63 > > > --> irq16: ehci0 809547235 55608 > > > > Have you tried removing USB from the kernel? > > > > USB seems to be a common course of this behaviour and here at least > > removing it from the kernel fixes in all cases assuming you don't > > need it for something? > > No, I haven't tried that yet. I could disable USB to run some tests, but > I'll > eventually need it enabled again. > I'll wait for a couple of hours to see if anyone can come up with a test to > run on the machine while the interrupt is still storming. After that I'll > reboot it with USB disabled. > > > Thanks, > -- > Daan Vreeken > VEHosting > http://VEHosting.nl > tel: +31-(0)40-7113050 / +31-(0)6-46210825 > KvK nr: 17174380 > From owner-freebsd-current@FreeBSD.ORG Fri May 6 15:46:54 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68DFF1065670 for ; Fri, 6 May 2011 15:46:54 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 201168FC14 for ; Fri, 6 May 2011 15:46:54 +0000 (UTC) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p46FkojI053804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 May 2011 11:46:50 -0400 (EDT) (envelope-from mike@sentex.net) Received: from pyroxene.sentex.ca ([IPv6:2607:f3e0:0:3::18]) by smtp2.sentex.ca (8.14.4/8.14.4) with ESMTP id p46Fko5V033692; Fri, 6 May 2011 11:46:50 -0400 (EDT) (envelope-from mike@sentex.net) Received: from [192.168.43.26] (saphire3.sentex.ca [192.168.43.26]) by pyroxene.sentex.ca (8.14.4/8.14.3) with ESMTP id p46FknWn063182; Fri, 6 May 2011 11:46:50 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <4DC417E1.8010405@sentex.net> Date: Fri, 06 May 2011 11:46:41 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Daan Vreeken References: <201105041734.50738.Daan@vehosting.nl> <201105052217.51893.Daan@vehosting.nl> <201105061702.43073.Daan@vehosting.nl> In-Reply-To: <201105061702.43073.Daan@vehosting.nl> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.67 on 64.7.153.18 Cc: FreeBSD current mailing list Subject: Re: Interrupt storm with MSI in combination with em1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 15:46:54 -0000 On 5/6/2011 11:02 AM, Daan Vreeken wrote: > One core is spending half it's time handling interrupts. > /var/log/messages doesn't show any new message since the storm > started. "vmstat -i" now shows : > > # vmstat -i > interrupt total rate > irq3: uart1 917384 63 > --> irq16: ehci0 809547235 55608 > > Apart from spending far too much time handling interrupts, the machine works > fine, so I'll let it run in case anyone wants me to try something on it. > Do you have any usb devices plugged in ? ie what does usbconfig show ? Also, what USB settings do you have in the BIOS ? I would try disabling usb legacy mode and and things like 80-64 translation. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-current@FreeBSD.ORG Fri May 6 16:11:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84D5F1065672; Fri, 6 May 2011 16:11:36 +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 5F4A68FC1A; Fri, 6 May 2011 16:11: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 EF2E646B3C; Fri, 6 May 2011 12:11:35 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 89FEC8A01B; Fri, 6 May 2011 12:11:35 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org, multimedia@freebsd.org Date: Fri, 6 May 2011 09:00:08 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <4DC3B764.4030801@FreeBSD.org> In-Reply-To: <4DC3B764.4030801@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105060900.08672.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 06 May 2011 12:11:35 -0400 (EDT) Cc: Andriy Gapon Subject: Re: dsp mmap change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 16:11:36 -0000 On Friday, May 06, 2011 4:55:00 am Andriy Gapon wrote: > > I would like to ask for a review and/or testing of the following patch: > http://people.freebsd.org/~avg/dev_dsp_mmap.diff > > It's supposed to fix an issue described here: > http://lists.freebsd.org/pipermail/freebsd-multimedia/2011- February/011691.html > > In short, the following pseudo-code should do the right thing: > fd = open(/dev/dsp, O_RDWR); > mmap(PROT_READ, fd); > mmap(PROT_WRITE, fd); Are the buffers statically allocated? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri May 6 16:11:38 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A56091065677 for ; Fri, 6 May 2011 16:11:38 +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 7CD348FC12 for ; Fri, 6 May 2011 16:11:38 +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 3284546B59; Fri, 6 May 2011 12:11:38 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BDFC98A02B; Fri, 6 May 2011 12:11:37 -0400 (EDT) From: John Baldwin To: Damjan Marion Date: Fri, 6 May 2011 11:47:33 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <5BEF0D0F-3717-42CE-ADF7-8876558004CA@gmail.com> <201105051343.02898.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105061147.33766.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 06 May 2011 12:11:37 -0400 (EDT) Cc: freebsd-current@freebsd.org Subject: Re: atkbdc broken on current ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 16:11:38 -0000 On Thursday, May 05, 2011 5:04:54 pm Damjan Marion wrote: > > On May 5, 2011, at 7:43 PM, John Baldwin wrote: > > > On Thursday, May 05, 2011 9:21:04 am Damjan Marion wrote: > >> > >> Hi, > >> > >> I have issue with old HP DL380G3 server. When I use ILO virtual console to > > manage server. Seems that 9-CURRENT fails to detect atkbdc. > >> When I boot 8.2-RELEASE it works well. > >> > >> 8.2 dmesg shows: > >> > >> atkbdc0: port 0x60,0x64 irq 1 on acpi0 > >> > >> 9.0: > >> > >> atkbdc0: failed to probe at port 0x60 on isa0 > >> > >> Is this a known issue? > >> > >> Should I enable some additional outputs, like KBDIO_DEBUG? > > > > I suspect this is a resource issue stemming from changes I made to the acpi(4) > > bus driver quite a while ago to make it use rman_reserve_resource(). Can you > > capture a full verbose dmesg from 9 along with devinfo -rv and devinfo -ur > > output from 9? > > Here it is: > > http://web.me.com/dmarion/atkbdc.txt Ohh, hmm. Your BIOS has done "odd" things: isab0 pnpinfo vendor=0x1166 device=0x0201 subvendor=0x1166 subdevice=0x0201 class=0x060100 at slot=15 function=0 handle=\_SB_.PCI0.IBRG isa0 I/O ports: 0x0-0xf 0x20-0x21 0x40-0x43 0x60 0x61 0x64 0x80-0x8f 0xa0-0xa1 0xc0-0xdf 0x4d6 Still, I don't know how the ISA bus is actually allocating resources. Can you add some code to the x86 nexus driver to drop into kdb when it receives a SYS_RES_IOPORT allocation request from "isa0" and get a stack trace from DDB and reply with the trace? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri May 6 16:14:49 2011 Return-Path: Delivered-To: Current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B69A01065672 for ; Fri, 6 May 2011 16:14:49 +0000 (UTC) (envelope-from Daan@vehosting.nl) Received: from VM01.VEHosting.nl (VM016.VEHosting.nl [IPv6:2001:1af8:2100:b020::140]) by mx1.freebsd.org (Postfix) with ESMTP id 307618FC25 for ; Fri, 6 May 2011 16:14:49 +0000 (UTC) Received: from [192.168.72.11] (124-54.bbned.dsl.internl.net [92.254.54.124]) (authenticated bits=0) by VM01.VEHosting.nl (8.14.3/8.13.8) with ESMTP id p46GElfY018709; Fri, 6 May 2011 18:14:47 +0200 (CEST) (envelope-from Daan@vehosting.nl) From: Daan Vreeken Organization: http://VEHosting.nl/ To: Jack Vogel Date: Fri, 6 May 2011 18:14:43 +0200 User-Agent: KMail/1.9.10 References: <201105041734.50738.Daan@vehosting.nl> <201105061732.12418.Daan@vehosting.nl> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201105061814.44231.Daan@vehosting.nl> x-ve-auth-version: mi-1.1.5 2011-02-07 - Copyright (c) 2008, 2011 - Daan Vreeken - VEHosting x-ve-auth: authenticated as 'pa4dan' on VM01.VEHosting.nl Cc: Steven Hartland , Current@freebsd.org, Peter Jeremy Subject: Re: Interrupt storm with MSI in combination with em1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 16:14:49 -0000 Hi Jack, On Friday 06 May 2011 17:36:52 Jack Vogel wrote: > On Fri, May 6, 2011 at 8:32 AM, Daan Vreeken wrote: > > Hi Steven, > > > > On Friday 06 May 2011 17:20:15 Steven Hartland wrote: > > > From: "Daan Vreeken" > > > > > > > # vmstat -i > > > > interrupt total rate > > > > irq3: uart1 917384 63 > > > > --> irq16: ehci0 809547235 55608 > > > > > > Have you tried removing USB from the kernel? > > > > > > USB seems to be a common course of this behaviour and here at least > > > removing it from the kernel fixes in all cases assuming you don't > > > need it for something? > > > > No, I haven't tried that yet. I could disable USB to run some tests, but > > I'll > > eventually need it enabled again. > > I'll wait for a couple of hours to see if anyone can come up with a test > > to run on the machine while the interrupt is still storming. After that > > I'll reboot it with USB disabled. > > I don't see why you are blaming em, you can see its on MSIX vectors > that are NOT storming, its something with USB as noted. Trying to > disable em from using MSIX is in exactly the wrong direction IMHO. I'm not blaming this on 'em' per se. The only thing I've noticed in the tests that I've done so far is that I haven't seen the storms with MSI/MSIX disabled. With respect to the devices on IRQ 16, disabling MSI/MSIX only seems to change the way interrupts are delivered to the em0/em1 cards. (This is what made me suspect the 'em' driver.) At this moment all devices on IRQ 16 (including the PCI bridge itself) could be the source of the problem. I'm just trying to find a way to isolate the problem, either by finding a way to proof it is NOT device X, or by finding a way to proof it IS device Y. I'll reboot the machine in a couple of minutes with USB disabled. Regards, -- Daan Vreeken VEHosting http://VEHosting.nl tel: +31-(0)40-7113050 / +31-(0)6-46210825 KvK nr: 17174380 From owner-freebsd-current@FreeBSD.ORG Fri May 6 16:21:50 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B0EF106564A; Fri, 6 May 2011 16:21:50 +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 811878FC12; Fri, 6 May 2011 16:21:49 +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 TAA26448; Fri, 06 May 2011 19:21:46 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DC4201A.9050909@FreeBSD.org> Date: Fri, 06 May 2011 19:21:46 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: John Baldwin References: <4DC3B764.4030801@FreeBSD.org> <201105060900.08672.jhb@freebsd.org> In-Reply-To: <201105060900.08672.jhb@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, multimedia@FreeBSD.org Subject: Re: dsp mmap change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 16:21:50 -0000 on 06/05/2011 16:00 John Baldwin said the following: > On Friday, May 06, 2011 4:55:00 am Andriy Gapon wrote: >> >> I would like to ask for a review and/or testing of the following patch: >> http://people.freebsd.org/~avg/dev_dsp_mmap.diff >> >> It's supposed to fix an issue described here: >> http://lists.freebsd.org/pipermail/freebsd-multimedia/2011- > February/011691.html >> >> In short, the following pseudo-code should do the right thing: >> fd = open(/dev/dsp, O_RDWR); >> mmap(PROT_READ, fd); >> mmap(PROT_WRITE, fd); > > Are the buffers statically allocated? My reading of code indicates that the buffers are allocated on a sound driver attach and freed when it's detaching. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri May 6 18:02:27 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AB841065670 for ; Fri, 6 May 2011 18:02:27 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id CEF408FC0C for ; Fri, 6 May 2011 18:02:26 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id C63F51E002C7; Fri, 6 May 2011 19:45:01 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.4/8.14.3) with ESMTP id p46HgitM003848; Fri, 6 May 2011 19:42:44 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.4/8.14.3/Submit) id p46HgiFp003847; Fri, 6 May 2011 19:42:44 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Fri, 6 May 2011 19:42:44 +0200 To: Andriy Gapon Message-ID: <20110506174244.GA3644@triton8.kn-bremen.de> References: <4DC3B764.4030801@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DC3B764.4030801@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@FreeBSD.org, multimedia@FreeBSD.org Subject: Re: dsp mmap change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 18:02:27 -0000 On Fri, May 06, 2011 at 11:55:00AM +0300, Andriy Gapon wrote: > > I would like to ask for a review and/or testing of the following patch: > http://people.freebsd.org/~avg/dev_dsp_mmap.diff > > It's supposed to fix an issue described here: > http://lists.freebsd.org/pipermail/freebsd-multimedia/2011-February/011691.html > > In short, the following pseudo-code should do the right thing: > fd = open(/dev/dsp, O_RDWR); > mmap(PROT_READ, fd); > mmap(PROT_WRITE, fd); > > Thank you! Working here with skype 2.1.0.81 and pulseaudio without (and also still with) disabline mmap for the mic. Very nice! :) Note: I had to disable the checkbox `Allow Skype to automatically adjust my mixer levels', else it records garbage at least with my mic. (that is one of a webcam.) Thanx, Juergen From owner-freebsd-current@FreeBSD.ORG Fri May 6 20:19:40 2011 Return-Path: Delivered-To: Current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 876C2106566B; Fri, 6 May 2011 20:19:40 +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 5BF778FC13; Fri, 6 May 2011 20:19:40 +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 D280646B23; Fri, 6 May 2011 16:19:39 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 335DE8A01B; Fri, 6 May 2011 16:19:39 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 6 May 2011 16:14:29 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <201105041734.50738.Daan@vehosting.nl> <201105061732.12418.Daan@vehosting.nl> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105061614.29502.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 06 May 2011 16:19:39 -0400 (EDT) Cc: Daan Vreeken , Steven Hartland , Jack Vogel , Peter Jeremy , Current@freebsd.org Subject: Re: Interrupt storm with MSI in combination with em1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 20:19:40 -0000 On Friday, May 06, 2011 11:36:52 am Jack Vogel wrote: > I don't see why you are blaming em, you can see its on MSIX vectors > that are NOT storming, its something with USB as noted. Trying to > disable em from using MSIX is in exactly the wrong direction IMHO. In the past Intel host bridges have exhibited very brain damaged behavior where em interrupts could trigger false interrupts on USB controllers. These host bridges did this because they assumed that if the interrupt line was masked in the I/O APIC, then the OS must be using the 8259A PICs and not the I/O APICs, so it would forward the interrupt down to the 8259A's in the ICH, and the effect was to trigger an interrupt on the line shared with the USB controllers creating phantom USB interrupts for each em(4) interrupt. FreeBSD triggered this because when using INTx and not using Scott's INTR_FAST changes, the kernel would mask em(4)'s interrupt in the I/O APIC which triggered the buggy behavior in the bridge. If for some reason em(4) is asserting both the INTx interrupt and the MSI-X interrupt now, then since the INTx interrupt is not enabled in FreeBSD, the I/O APIC pin will be masked and any INTx assertions would trigger similar phantom interrupts if this bridge was similarly broken. So given that, is there any chance that em(4) could still be asserting its INTx line (or the simulated INTx line rather) when MSI-X is being used? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri May 6 20:19:40 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 876C2106566B; Fri, 6 May 2011 20:19:40 +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 5BF778FC13; Fri, 6 May 2011 20:19:40 +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 D280646B23; Fri, 6 May 2011 16:19:39 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 335DE8A01B; Fri, 6 May 2011 16:19:39 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 6 May 2011 16:14:29 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <201105041734.50738.Daan@vehosting.nl> <201105061732.12418.Daan@vehosting.nl> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105061614.29502.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 06 May 2011 16:19:39 -0400 (EDT) Cc: Daan Vreeken , Steven Hartland , Jack Vogel , Peter Jeremy , Current@freebsd.org Subject: Re: Interrupt storm with MSI in combination with em1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 20:19:40 -0000 On Friday, May 06, 2011 11:36:52 am Jack Vogel wrote: > I don't see why you are blaming em, you can see its on MSIX vectors > that are NOT storming, its something with USB as noted. Trying to > disable em from using MSIX is in exactly the wrong direction IMHO. In the past Intel host bridges have exhibited very brain damaged behavior where em interrupts could trigger false interrupts on USB controllers. These host bridges did this because they assumed that if the interrupt line was masked in the I/O APIC, then the OS must be using the 8259A PICs and not the I/O APICs, so it would forward the interrupt down to the 8259A's in the ICH, and the effect was to trigger an interrupt on the line shared with the USB controllers creating phantom USB interrupts for each em(4) interrupt. FreeBSD triggered this because when using INTx and not using Scott's INTR_FAST changes, the kernel would mask em(4)'s interrupt in the I/O APIC which triggered the buggy behavior in the bridge. If for some reason em(4) is asserting both the INTx interrupt and the MSI-X interrupt now, then since the INTx interrupt is not enabled in FreeBSD, the I/O APIC pin will be masked and any INTx assertions would trigger similar phantom interrupts if this bridge was similarly broken. So given that, is there any chance that em(4) could still be asserting its INTx line (or the simulated INTx line rather) when MSI-X is being used? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri May 6 20:19:41 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66FDD106566C; Fri, 6 May 2011 20:19:41 +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 3D49C8FC14; Fri, 6 May 2011 20:19:41 +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 E683A46B42; Fri, 6 May 2011 16:19:40 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8262F8A027; Fri, 6 May 2011 16:19:40 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 6 May 2011 16:16:40 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <4DC3B764.4030801@FreeBSD.org> <4DC3F9B8.3030505@FreeBSD.org> <20110506140428.GF48734@deviant.kiev.zoral.com.ua> In-Reply-To: <20110506140428.GF48734@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201105061616.41145.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 06 May 2011 16:19:40 -0400 (EDT) Cc: Kostik Belousov , multimedia@freebsd.org, current@freebsd.org, Andriy Gapon Subject: Re: dsp mmap change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 20:19:41 -0000 On Friday, May 06, 2011 10:04:28 am Kostik Belousov wrote: > On Fri, May 06, 2011 at 04:38:00PM +0300, Andriy Gapon wrote: > > on 06/05/2011 16:32 Kostik Belousov said the following: > > > On Fri, May 06, 2011 at 11:55:00AM +0300, Andriy Gapon wrote: > > >> > > >> I would like to ask for a review and/or testing of the following patch: > > >> http://people.freebsd.org/~avg/dev_dsp_mmap.diff > > >> > > >> It's supposed to fix an issue described here: > > >> http://lists.freebsd.org/pipermail/freebsd-multimedia/2011- February/011691.html > > >> > > >> In short, the following pseudo-code should do the right thing: > > >> fd = open(/dev/dsp, O_RDWR); > > >> mmap(PROT_READ, fd); > > >> mmap(PROT_WRITE, fd); > > >> > > >> Thank you! > > > > > > I think that you have to call PCM_GIANT_LEAVE() when returning > > > EINVAL on the vm_pager_alloc() failure. > > > > Yes, thank you. > > > > > Your patch hardcodes an assumption that sndbufs are always > > > contiguous. I was unable to convince myself that this is true. > > > > I think that this should be true for the case when DMA is used? > In the current driver, yes, but there is nothing that theoretically > prevents scatter-gather from be used. You could "fix" this by creating an sglist (via sglist_build()) and an OBJT_SG VM object that the d_mmap_single callback returned. I wish there was a cleaner way to just create a VM object and populate it with pages though, and then use vm_map_insert() to map it into the kernel rather than the more roundabout method of OBJT_SG. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri May 6 20:19:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66FDD106566C; Fri, 6 May 2011 20:19:41 +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 3D49C8FC14; Fri, 6 May 2011 20:19:41 +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 E683A46B42; Fri, 6 May 2011 16:19:40 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8262F8A027; Fri, 6 May 2011 16:19:40 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 6 May 2011 16:16:40 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <4DC3B764.4030801@FreeBSD.org> <4DC3F9B8.3030505@FreeBSD.org> <20110506140428.GF48734@deviant.kiev.zoral.com.ua> In-Reply-To: <20110506140428.GF48734@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201105061616.41145.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 06 May 2011 16:19:40 -0400 (EDT) Cc: Kostik Belousov , multimedia@freebsd.org, current@freebsd.org, Andriy Gapon Subject: Re: dsp mmap change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 20:19:41 -0000 On Friday, May 06, 2011 10:04:28 am Kostik Belousov wrote: > On Fri, May 06, 2011 at 04:38:00PM +0300, Andriy Gapon wrote: > > on 06/05/2011 16:32 Kostik Belousov said the following: > > > On Fri, May 06, 2011 at 11:55:00AM +0300, Andriy Gapon wrote: > > >> > > >> I would like to ask for a review and/or testing of the following patch: > > >> http://people.freebsd.org/~avg/dev_dsp_mmap.diff > > >> > > >> It's supposed to fix an issue described here: > > >> http://lists.freebsd.org/pipermail/freebsd-multimedia/2011- February/011691.html > > >> > > >> In short, the following pseudo-code should do the right thing: > > >> fd = open(/dev/dsp, O_RDWR); > > >> mmap(PROT_READ, fd); > > >> mmap(PROT_WRITE, fd); > > >> > > >> Thank you! > > > > > > I think that you have to call PCM_GIANT_LEAVE() when returning > > > EINVAL on the vm_pager_alloc() failure. > > > > Yes, thank you. > > > > > Your patch hardcodes an assumption that sndbufs are always > > > contiguous. I was unable to convince myself that this is true. > > > > I think that this should be true for the case when DMA is used? > In the current driver, yes, but there is nothing that theoretically > prevents scatter-gather from be used. You could "fix" this by creating an sglist (via sglist_build()) and an OBJT_SG VM object that the d_mmap_single callback returned. I wish there was a cleaner way to just create a VM object and populate it with pages though, and then use vm_map_insert() to map it into the kernel rather than the more roundabout method of OBJT_SG. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri May 6 20:28:50 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34C5C1065673 for ; Fri, 6 May 2011 20:28:50 +0000 (UTC) (envelope-from yr.retarded@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id E56AF8FC13 for ; Fri, 6 May 2011 20:28:49 +0000 (UTC) Received: by ywf7 with SMTP id 7so1666444ywf.13 for ; Fri, 06 May 2011 13:28:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:cc:content-type:content-transfer-encoding; bh=mrpmgh3vFuyTCYO9uxM9AJbPJmXtuHCEIj2sLyyXXFo=; b=RrGLFc1UoQCpoN8UHTCux17RQjVwDJM0LxNKMvnaHsetBWgwRncw4sjSpvi3DJzELL Fo8nQGJ0ZHVdUnMfaCkxRY0AWYqVQ8gyf3uAjaSabgLN+gyH4J2zrPPCJqjGMoDd0Uqe 5XENl8EGSU/d99PF+i8Pz99HwiHHCB4GGL6zU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type:content-transfer-encoding; b=HYAs940ugRkF3Wjbx9wmrmEB3rWgleSam5MPEdKeQb+I1EztgUxsi2aMCoG3XIDW7g Aam7bFyhUJJ5+jRWIEtTY7u5K2eDb3BWWNjvSgnKVm1ihUDDuypSi2ta7Q83y/hMJFHc l/mbP/b/V3KHQqR2XkGYkB+YJugLFWb6x4BpU= MIME-Version: 1.0 Received: by 10.150.62.8 with SMTP id k8mr3663475yba.92.1304711863766; Fri, 06 May 2011 12:57:43 -0700 (PDT) Received: by 10.146.83.20 with HTTP; Fri, 6 May 2011 12:57:43 -0700 (PDT) In-Reply-To: <4DC07535.4050809@freebsd.org> References: <4DC07535.4050809@freebsd.org> Date: Fri, 6 May 2011 14:57:43 -0500 Message-ID: From: Chris Ruiz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: firewire debugging X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 20:28:50 -0000 On Tue, May 3, 2011 at 4:35 PM, Julian Elischer wrote: > does anyone know if there is a limitation on firewire debugging on a mach= ine > with > 4GB or memory? I've successfully used firewire dcons on amd64 with 8GB of RAM. > I have 1394 {a,b} cards. =A0does it make a difference? Shouldn't make a difference. > also, the firewire card on one machine stops it from booting.. > > is there a way to disable it during boot other than recompiling the kerne= l > without firewire? Not sure, since I've never ran into this problem. Hope this helps, Chris Ruiz From owner-freebsd-current@FreeBSD.ORG Fri May 6 20:53:48 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AECEA106564A for ; Fri, 6 May 2011 20:53:48 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 556C98FC08 for ; Fri, 6 May 2011 20:53:47 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEABNfxE2DaFvO/2dsb2JhbACEU6JCs3OQeYEqhF8Ej1iOcA X-IronPort-AV: E=Sophos;i="4.64,328,1301889600"; d="scan'208";a="122392684" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 06 May 2011 16:30:49 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id EFE4FB3F2C for ; Fri, 6 May 2011 16:30:48 -0400 (EDT) Date: Fri, 6 May 2011 16:30:48 -0400 (EDT) From: Rick Macklem To: FreeBSD Current Message-ID: <1153983332.1135134.1304713848912.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Subject: Heads Up: after r221543 you need a fresh make depend X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 20:53:48 -0000 Since r221543 moves nfs_kdtrace.h, you'll need to do a fresh make cleandepend; make depend to update your kernel dependencies. rick From owner-freebsd-current@FreeBSD.ORG Sat May 7 00:19:38 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D0071065675; Sat, 7 May 2011 00:19:38 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.212.176]) by mx1.freebsd.org (Postfix) with ESMTP id C61548FC16; Sat, 7 May 2011 00:19:37 +0000 (UTC) Received: by pxi11 with SMTP id 11so2912431pxi.7 for ; Fri, 06 May 2011 17:19:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:date:to:cc:subject:message-id:reply-to :mail-followup-to:mime-version:content-type:content-disposition :user-agent:organization:x-operation-sytem; bh=i/t6uZ/ItU2N7+8WDVS213OsuUwwcNo2q9ZJWVtcvkI=; b=xmT223unNvKsronFS3lYx40lOww56APJ5wYiLPhr8mfKQoZZ2rQca3tJJSRIPisqGz soKcC0tuHQmTjXKZfoO/mjdo/oEOHDCEvUtMaPm6FYwh4EvIAH4jSHKJxuo+atgp2f49 JYrAZV3cciBSzUWyuyIWh93F1NMQKfN5EcDgQ= 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 :mime-version:content-type:content-disposition:user-agent :organization:x-operation-sytem; b=lHns402J/oJrZyhBX/0ZNYAPgzFoMIzI3b59TEQQyG/1BxQqDQhwa9+/OwqLejczh1 K82kL7MiJuBPDwdy/TdQTazm6UL0XUFVFbbvcgzo23nN0AHgB+5518RZrAqWLcow58U6 p/THDzLs7mJuV9TRe1new1acwDGAqXiVcwfgM= Received: by 10.142.62.39 with SMTP id k39mr2142157wfa.179.1304727577257; Fri, 06 May 2011 17:19:37 -0700 (PDT) Received: from weongyo ([174.35.1.224]) by mx.google.com with ESMTPS id p10sm4775120wfl.21.2011.05.06.17.19.34 (version=SSLv3 cipher=OTHER); Fri, 06 May 2011 17:19:36 -0700 (PDT) Received: by weongyo (sSMTP sendmail emulation); Fri, 06 May 2011 17:19:50 -0700 From: Weongyo Jeong Date: Fri, 6 May 2011 17:19:50 -0700 To: freebsd-current@freebsd.org Message-ID: <20110507001950.GC36896@weongyo> Mail-Followup-To: freebsd-current@freebsd.org, freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: freebsd-net@freebsd.org Subject: [CFT] Early Retransmit for TCP (rfc5827) patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 00:19:38 -0000 --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello all, I'd like to send another patch to support RFC5827 in TCP stack which could be found at: http://people.freebsd.org/~weongyo/patch_20110506_rfc5827.diff This patch supports all Early Retransmit logics (Byte-Based Early Retransmit and Segment-Based Early Retransmit) when net.inet.tcp.rfc5827 sysctl knob is turned on. Please note that Segment-Based Early Retransmit logic is separated using khelp module because it adds additional operations and requires variable spaces to track segment boundaries on the right side window. So if the khelp module is loaded, it's a preference but if not the default logic is `Byte-Based Early Retransmit'. I implemented based on DragonflyBSD's implementation but it looked it's not same with RFC specification what I thought so I changed most of parts. In my test environments it looks it's working correctly. Please review and test my work and tell me if you have any concerns and questions. regards, Weongyo Jeong --J/dobhs11T7y2rNN Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="patch_20110506_rfc5827.diff" Index: usr.bin/netstat/inet.c =================================================================== --- usr.bin/netstat/inet.c (revision 221564) +++ usr.bin/netstat/inet.c (working copy) @@ -622,6 +622,7 @@ "\t\t%lu data packet%s (%lu byte%s) retransmitted\n"); p(tcps_sndrexmitbad, "\t\t%lu data packet%s unnecessarily retransmitted\n"); + p(tcps_sndearlyrexmit, "\t%lu packet%s early retransmitted\n"); p(tcps_mturesent, "\t\t%lu resend%s initiated by MTU discovery\n"); p2a(tcps_sndacks, tcps_delack, "\t\t%lu ack-only packet%s (%lu delayed)\n"); Index: share/man/man4/Makefile =================================================================== --- share/man/man4/Makefile (revision 221564) +++ share/man/man4/Makefile (working copy) @@ -140,6 +140,7 @@ gpib.4 \ gre.4 \ h_ertt.4 \ + h_tcper.4 \ harp.4 \ hatm.4 \ hfa.4 \ Index: share/man/man4/h_tcper.4 =================================================================== --- share/man/man4/h_tcper.4 (revision 0) +++ share/man/man4/h_tcper.4 (revision 0) @@ -0,0 +1,60 @@ +.\" +.\" Copyright (c) 2011 Weongyo Jeong +.\" All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND +.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR +.\" ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +.\" SUCH DAMAGE. +.\" +.\" $FreeBSD: share/man/man4/h_ertt.4 218912 2011-02-21 11:56:11Z lstewart $ +.\" +.Dd May 4, 2011 +.Dt h_tcper 9 +.Os +.Sh NAME +.Nm h_tcper +.Nd Segment Boundary Tracker Khelp module +.Sh SYNOPSIS +.In netinet/khelp/h_tcper.h +.Sh DESCRIPTION +The +.Nm +Khelp module works within the +.Xr khelp 9 +framework to provide TCP with a per-connection, segment boundary tracker. +It's to form an understanding as to how many actual segments have been +transmitted, but not acknowledged. +Its implementation is done by the sender by tracking the boundaries of +the four segments on the right side of the current window. +.Sh SEE ALSO +.Xr hhook 9 , +.Xr khelp 9 +.Sh HISTORY +The +.Nm +module first appeared in +.Fx 9.0 . +The module was first released in 2011 by Weongyo Jeong +.Sh AUTHORS +.An -nosplit +The +.Nm +Khelp module and this manual page were written by +.An Weongyo Jeong Aq weongyo@freebsd.org . Index: sys/netinet/tcp_input.c =================================================================== --- sys/netinet/tcp_input.c (revision 221564) +++ sys/netinet/tcp_input.c (working copy) @@ -55,6 +55,7 @@ #include #include #include +#include #include #include #include /* for proc0 declaration */ @@ -101,6 +102,7 @@ #ifdef TCPDEBUG #include #endif /* TCPDEBUG */ +#include #ifdef IPSEC #include @@ -161,6 +163,11 @@ &VNET_NAME(tcp_abc_l_var), 2, "Cap the max cwnd increment during slow-start to this number of segments"); +VNET_DEFINE(int, tcp_do_rfc5827) = 0; +SYSCTL_VNET_INT(_net_inet_tcp, OID_AUTO, rfc5827, CTLFLAG_RW, + &VNET_NAME(tcp_do_rfc5827), 0, + "Enable RFC 5827 (Early Retransmit)"); + SYSCTL_NODE(_net_inet_tcp, OID_AUTO, ecn, CTLFLAG_RW, 0, "TCP ECN"); VNET_DEFINE(int, tcp_do_ecn) = 0; @@ -260,6 +267,63 @@ } } +static int +tcp_getrexmtthresh(struct tcpcb *tp) +{ +#define iceildiv(n, d) (((n) + (d) - 1) / (d)) + struct inpcb *inp = tp->t_inpcb; + struct socket *so = inp->inp_socket; + struct tcper *te; + uint32_t oseg, ownd, sent; + int32_t tcper_id; + int ER_thresh; + + if (!V_tcp_do_rfc5827) + goto def; + if ((sent = tp->snd_max - tp->snd_una) == 0) + goto def; + + tcper_id = khelp_get_id("tcper"); + if (tcper_id > 0) { + /* + * Segment-Based Early Retransmit + */ + te = khelp_get_osd(tp->osd, tcper_id); + KASSERT(te != NULL, ("%s: te is NULL", __func__)); + oseg = te->numseg; + if (oseg > 0 && oseg < 4 && + (sent == so->so_snd.sb_cc || tp->snd_wnd == 0)) { + ER_thresh = oseg - 1; + if ((tp->t_flags & TF_SACK_PERMIT) == 0 || + tcp_sack_oseg(tp, te->segb, te->sege, + TCP_ER_MAXSEGB, ER_thresh)) { + TCPSTAT_INC(tcps_sndearlyrexmit); + return (ER_thresh); + } + } + goto def; + } + + /* + * Byte-Based Early Retransmit + */ + ownd = sent; + if (ownd < (4 * tp->t_maxseg) && + (sent == so->so_snd.sb_cc || tp->snd_wnd == 0)) { + ER_thresh = iceildiv(ownd, tp->t_maxseg) - 1; + if (((tp->t_flags & TF_SACK_PERMIT) == 0 || + ownd <= tp->t_maxseg || + tcp_sack_ownd(tp, ownd - tp->t_maxseg)) && + tp->t_dupacks + 1 >= ER_thresh) { + TCPSTAT_INC(tcps_sndearlyrexmit); + return (ER_thresh); + } + } +def: + return (tcprexmtthresh); +#undef iceildiv +} + /* * CC wrapper hook functions */ @@ -2372,6 +2436,10 @@ if (SEQ_LEQ(th->th_ack, tp->snd_una)) { if (tlen == 0 && tiwin == tp->snd_wnd) { + int rexmtthresh; + + rexmtthresh = tcp_getrexmtthresh(tp); + TCPSTAT_INC(tcps_rcvdupack); /* * If we have outstanding data (other than @@ -2403,7 +2471,7 @@ if (!tcp_timer_active(tp, TT_REXMT) || th->th_ack != tp->snd_una) tp->t_dupacks = 0; - else if (++tp->t_dupacks > tcprexmtthresh || + else if (++tp->t_dupacks > rexmtthresh || IN_FASTRECOVERY(tp->t_flags)) { cc_ack_received(tp, th, CC_DUPACK); if ((tp->t_flags & TF_SACK_PERMIT) && @@ -2427,7 +2495,7 @@ tp->snd_cwnd += tp->t_maxseg; (void) tcp_output(tp); goto drop; - } else if (tp->t_dupacks == tcprexmtthresh) { + } else if (tp->t_dupacks == rexmtthresh) { tcp_seq onxt = tp->snd_nxt; /* Index: sys/netinet/tcp_var.h =================================================================== --- sys/netinet/tcp_var.h (revision 221564) +++ sys/netinet/tcp_var.h (working copy) @@ -493,6 +493,9 @@ u_long tcps_sig_err_sigopt; /* No signature expected by socket */ u_long tcps_sig_err_nosigopt; /* No signature provided by segment */ + /* Early Retransmit */ + u_long tcps_sndearlyrexmit; /* early Fast Retransmissions */ + u_long _pad[12]; /* 6 UTO, 6 TBD */ }; @@ -610,6 +613,7 @@ VNET_DECLARE(int, ss_fltsz_local); VNET_DECLARE(int, tcp_do_rfc3465); VNET_DECLARE(int, tcp_abc_l_var); +VNET_DECLARE(int, tcp_do_rfc5827); #define V_tcb VNET(tcb) #define V_tcbinfo VNET(tcbinfo) #define V_tcpstat VNET(tcpstat) @@ -622,6 +626,7 @@ #define V_ss_fltsz_local VNET(ss_fltsz_local) #define V_tcp_do_rfc3465 VNET(tcp_do_rfc3465) #define V_tcp_abc_l_var VNET(tcp_abc_l_var) +#define V_tcp_do_rfc5827 VNET(tcp_do_rfc5827) VNET_DECLARE(int, tcp_do_sack); /* SACK enabled/disabled */ VNET_DECLARE(int, tcp_sc_rst_sock_fail); /* RST on sock alloc failure */ @@ -726,6 +731,9 @@ struct sackhole *tcp_sack_output(struct tcpcb *tp, int *sack_bytes_rexmt); void tcp_sack_partialack(struct tcpcb *, struct tcphdr *); void tcp_free_sackholes(struct tcpcb *tp); +boolean_t tcp_sack_ownd(struct tcpcb *tp, uint32_t amount); +boolean_t tcp_sack_oseg(struct tcpcb *tp, tcp_seq *seqb, tcp_seq *sege, + uint32_t numseq, uint32_t amount); int tcp_newreno(struct tcpcb *, struct tcphdr *); u_long tcp_seq_subtract(u_long, u_long ); Index: sys/netinet/khelp/h_tcper.c =================================================================== --- sys/netinet/khelp/h_tcper.c (revision 0) +++ sys/netinet/khelp/h_tcper.c (revision 0) @@ -0,0 +1,182 @@ +/*- + * Copyright (c) 2011 Weongyo Jeong + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD: sys/netinet/khelp/h_ertt.c 217806 2011-01-24 23:08:38Z lstewart $"); + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include +#include +#include +#include + +#include + +static int +tcper_input(int hhook_type, int hhook_id, void *udata, void *ctx_data, + void *hdata, struct osd *hosd) +{ + struct tcper *te; + struct tcp_hhook_data *thdp; + struct tcpcb *tp; + struct tcphdr *th; + int i; + + KASSERT(ctx_data != NULL, ("%s: ctx_data is NULL!", __func__)); + KASSERT(hdata != NULL, ("%s: hdata is NULL!", __func__)); + + te = (struct tcper *)hdata; + thdp = ctx_data; + tp = thdp->tp; + th = thdp->th; + + INP_WLOCK_ASSERT(tp->t_inpcb); + + if ((te->flags & TCP_ER_HAVEONE) == 0) + return (0); + + for (i = 0; i < TCP_ER_MAXSEGB; i++) { + if (SEQ_GT(th->th_ack, te->segb[i])) { + if (te->segb[i] == te->max) { + te->max = tp->snd_una; + te->flags &= ~TCP_ER_HAVEONE; + } + if (te->segb[i] != te->sege[i]) + te->numseg--; + te->segb[i] = tp->snd_una; + te->sege[i] = tp->snd_una; + } + } + return (0); +} + +static int +tcper_output(int hhook_type, int hhook_id, void *udata, void *ctx_data, + void *hdata, struct osd *hosd) +{ + struct tcper *te; + struct tcp_hhook_data *thdp; + struct tcpcb *tp; + struct tcphdr *th; + tcp_seq seq, tmpseq; + long len; + int i; + + KASSERT(ctx_data != NULL, ("%s: ctx_data is NULL!", __func__)); + KASSERT(hdata != NULL, ("%s: hdata is NULL!", __func__)); + + te = (struct tcper *)hdata; + thdp = ctx_data; + tp = thdp->tp; + th = thdp->th; + len = thdp->len; + seq = ntohl(th->th_seq); + + INP_WLOCK_ASSERT(tp->t_inpcb); + + if ((te->flags & TCP_ER_HAVEONE) == 0) { + for (i = 0; i < TCP_ER_MAXSEGB - 1; i++) { + te->segb[i] = tp->snd_una; + te->sege[i] = tp->snd_una; + } + te->flags |= TCP_ER_HAVEONE; + goto update; + } + if (SEQ_LEQ(seq, te->max)) + return (0); + /* + * XXX PLEASE FIX ME TO BE SMARTER. + * There'd be better algorithms not to swap twice or other approaches. + */ + for (i = 0; i < TCP_ER_MAXSEGB - 1; i++) { + /* swap segb[i] and segb[i + 1] */ + tmpseq = te->segb[i]; + te->segb[i] = te->segb[i + 1]; + te->segb[i + 1] = tmpseq; + /* swap sege[i] and sege[i + 1] */ + tmpseq = te->sege[i]; + te->sege[i] = te->sege[i + 1]; + te->sege[i + 1] = tmpseq; + } +update: + te->segb[TCP_ER_MAXSEGB - 1] = seq; + te->sege[TCP_ER_MAXSEGB - 1] = seq + len; + te->max = seq; + if (len > 0) { + /* + * XXX Increases or Decreases only the packet length is larger + * than zero. It means we ASSUME that only a packet + * (length > 0) is considered as a outstanding segment. + */ + te->numseg++; + } + return (0); +} + +static int +tcper_ctor(void *mem, int size, void *arg, int flags) +{ + struct tcper *te = mem; + + te->flags = 0; + te->numseg = 0; + return (0); +} + +static struct helper tcper_helper = { + .h_flags = HELPER_NEEDS_OSD, + .h_classes = HELPER_CLASS_TCP +}; + +/* Define the helper hook info required by ERTT. */ +static struct hookinfo tcper_hooks[] = { + { + .hook_type = HHOOK_TYPE_TCP, + .hook_id = HHOOK_TCP_EST_IN, + .hook_udata = NULL, + .hook_func = &tcper_input + }, + { + .hook_type = HHOOK_TYPE_TCP, + .hook_id = HHOOK_TCP_EST_OUT, + .hook_udata = NULL, + .hook_func = &tcper_output + } +}; + +KHELP_DECLARE_MOD_UMA(tcper, &tcper_helper, tcper_hooks, 1, + sizeof(struct tcper), tcper_ctor, NULL); Property changes on: sys/netinet/khelp/h_tcper.c ___________________________________________________________________ Added: svn:mime-type + text/plain Added: svn:keywords + Id Added: svn:eol-style + native Index: sys/netinet/khelp/h_tcper.h =================================================================== --- sys/netinet/khelp/h_tcper.h (revision 0) +++ sys/netinet/khelp/h_tcper.h (revision 0) @@ -0,0 +1,42 @@ +/*- + * Copyright (c) 2011 Weongyo Jeong + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD: sys/netinet/khelp/h_ertt.h 217806 2011-01-24 23:08:38Z lstewart $ + */ + +#ifndef _NETINET_KHELP_H_RFC5827_ +#define _NETINET_KHELP_H_RFC5827_ + +struct tcper { +#define TCP_ER_MAXSEGB 4 + uint32_t flags; +#define TCP_ER_HAVEONE 0x00000001 /* set if at least one seg in */ + tcp_seq segb[TCP_ER_MAXSEGB]; + tcp_seq sege[TCP_ER_MAXSEGB]; + tcp_seq max; + int numseg; +}; + +#endif Property changes on: sys/netinet/khelp/h_tcper.h ___________________________________________________________________ Added: svn:mime-type + text/plain Added: svn:keywords + Id Added: svn:eol-style + native Index: sys/netinet/tcp_sack.c =================================================================== --- sys/netinet/tcp_sack.c (revision 221564) +++ sys/netinet/tcp_sack.c (working copy) @@ -684,3 +684,54 @@ return; tp->snd_nxt = tp->snd_fack; } + +/* + * True if at least "amount" bytes has been SACKed. + * Used by Early Retransmit. + */ +boolean_t +tcp_sack_ownd(struct tcpcb *tp, uint32_t amount) +{ + struct sackhole *p; + uint32_t ackedbyte; + + ackedbyte = tp->snd_fack - tp->snd_una; + TAILQ_FOREACH(p, &tp->snd_holes, scblink) { + KASSERT(ackedbyte >= p->end - p->start, + ("%s: assert failed", __func__)); + ackedbyte -= p->end - p->start; + } + if (ackedbyte >= amount) + return (TRUE); + return (FALSE); +} + +/* + * True if at least "amount" segments has been SACKed. + * Used by Early Retransmit. + */ +boolean_t +tcp_sack_oseg(struct tcpcb *tp, tcp_seq *segb, tcp_seq *sege, uint32_t numseq, + uint32_t amount) +{ + struct sackhole *p; + int segment_sacked = 0, i, inhole; + + for (i = 0; i < numseq; i++) { + inhole = 0; + TAILQ_FOREACH(p, &tp->snd_holes, scblink) { + if (SEQ_GEQ(segb[i], p->start) && + SEQ_LEQ(sege[i], p->end)) { + inhole = 1; + break; + } + } + if (inhole) + continue; + if (SEQ_GT(segb[i], tp->snd_fack)) + continue; + if (++segment_sacked >= amount) + return (TRUE); + } + return (FALSE); +} Index: sys/modules/khelp/h_tcper/Makefile =================================================================== --- sys/modules/khelp/h_tcper/Makefile (revision 0) +++ sys/modules/khelp/h_tcper/Makefile (revision 0) @@ -0,0 +1,9 @@ +# $FreeBSD: sys/modules/khelp/h_ertt/Makefile 217806 2011-01-24 23:08:38Z lstewart $ + +.include + +.PATH: ${.CURDIR}/../../../netinet/khelp +KMOD= h_tcper +SRCS= h_tcper.h h_tcper.c + +.include Property changes on: sys/modules/khelp/h_tcper/Makefile ___________________________________________________________________ Added: svn:mime-type + text/plain Added: svn:keywords + Id Added: svn:eol-style + native Index: sys/modules/khelp/Makefile =================================================================== --- sys/modules/khelp/Makefile (revision 221564) +++ sys/modules/khelp/Makefile (working copy) @@ -1,5 +1,5 @@ # $FreeBSD$ -SUBDIR= h_ertt +SUBDIR= h_ertt h_tcper .include --J/dobhs11T7y2rNN-- From owner-freebsd-current@FreeBSD.ORG Sat May 7 04:16:07 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54AE5106566B; Sat, 7 May 2011 04:16: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 16BE48FC12; Sat, 7 May 2011 04:16:06 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p474G5lx066977; Sat, 7 May 2011 00:16:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p474G5Xs066948; Sat, 7 May 2011 04:16:05 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 7 May 2011 04:16:05 GMT Message-Id: <201105070416.p474G5Xs066948@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: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 04:16:07 -0000 TB --- 2011-05-07 02:10:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-07 02:10:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-05-07 02:10:00 - cleaning the object tree TB --- 2011-05-07 02:10:24 - cvsupping the source tree TB --- 2011-05-07 02:10:24 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-05-07 02:10:40 - building world TB --- 2011-05-07 02:10:40 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-07 02:10:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-07 02:10:40 - TARGET=pc98 TB --- 2011-05-07 02:10:40 - TARGET_ARCH=i386 TB --- 2011-05-07 02:10:40 - TZ=UTC TB --- 2011-05-07 02:10:40 - __MAKE_CONF=/dev/null TB --- 2011-05-07 02:10:40 - cd /src TB --- 2011-05-07 02:10:40 - /usr/bin/make -B buildworld >>> World build started on Sat May 7 02:10:41 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat May 7 04:06:56 UTC 2011 TB --- 2011-05-07 04:06:56 - generating LINT kernel config TB --- 2011-05-07 04:06:56 - cd /src/sys/pc98/conf TB --- 2011-05-07 04:06:56 - /usr/bin/make -B LINT TB --- 2011-05-07 04:06:56 - building LINT kernel TB --- 2011-05-07 04:06:56 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-07 04:06:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-07 04:06:56 - TARGET=pc98 TB --- 2011-05-07 04:06:56 - TARGET_ARCH=i386 TB --- 2011-05-07 04:06:56 - TZ=UTC TB --- 2011-05-07 04:06:56 - __MAKE_CONF=/dev/null TB --- 2011-05-07 04:06:56 - cd /src TB --- 2011-05-07 04:06:56 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat May 7 04:06:56 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/wi/if_wi_pci.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/xe/if_xe.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/xe/if_xe_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/xl/if_xl.c cc1: warnings being treated as errors /src/sys/dev/xl/if_xl.c: In function 'xl_poll_locked': /src/sys/dev/xl/if_xl.c:2383: warning: implicit declaration of function 'xl_stats_update_locked' /src/sys/dev/xl/if_xl.c:2383: warning: nested extern declaration of 'xl_stats_update_locked' *** Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-05-07 04:16:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-05-07 04:16:05 - ERROR: failed to build lint kernel TB --- 2011-05-07 04:16:05 - 6060.48 user 1036.01 system 7564.26 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat May 7 04:18:08 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0FFC106564A; Sat, 7 May 2011 04:18:08 +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 C23D58FC19; Sat, 7 May 2011 04:18:08 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p474I8HH085609; Sat, 7 May 2011 00:18:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p474I89Z085586; Sat, 7 May 2011 04:18:08 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 7 May 2011 04:18:08 GMT Message-Id: <201105070418.p474I89Z085586@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: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 04:18:09 -0000 TB --- 2011-05-07 02:10:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-07 02:10:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-05-07 02:10:00 - cleaning the object tree TB --- 2011-05-07 02:10:28 - cvsupping the source tree TB --- 2011-05-07 02:10:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-05-07 02:10:41 - building world TB --- 2011-05-07 02:10:41 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-07 02:10:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-07 02:10:41 - TARGET=i386 TB --- 2011-05-07 02:10:41 - TARGET_ARCH=i386 TB --- 2011-05-07 02:10:41 - TZ=UTC TB --- 2011-05-07 02:10:41 - __MAKE_CONF=/dev/null TB --- 2011-05-07 02:10:41 - cd /src TB --- 2011-05-07 02:10:41 - /usr/bin/make -B buildworld >>> World build started on Sat May 7 02:10:42 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat May 7 04:07:08 UTC 2011 TB --- 2011-05-07 04:07:08 - generating LINT kernel config TB --- 2011-05-07 04:07:08 - cd /src/sys/i386/conf TB --- 2011-05-07 04:07:08 - /usr/bin/make -B LINT TB --- 2011-05-07 04:07:08 - building LINT kernel TB --- 2011-05-07 04:07:08 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-07 04:07:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-07 04:07:08 - TARGET=i386 TB --- 2011-05-07 04:07:08 - TARGET_ARCH=i386 TB --- 2011-05-07 04:07:08 - TZ=UTC TB --- 2011-05-07 04:07:08 - __MAKE_CONF=/dev/null TB --- 2011-05-07 04:07:08 - cd /src TB --- 2011-05-07 04:07:08 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat May 7 04:07:08 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ld -b binary -d -warn-common -r -d -o wpifw.fwo wpi.fw cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/xe/if_xe.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/xe/if_xe_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/xl/if_xl.c cc1: warnings being treated as errors /src/sys/dev/xl/if_xl.c: In function 'xl_poll_locked': /src/sys/dev/xl/if_xl.c:2383: warning: implicit declaration of function 'xl_stats_update_locked' /src/sys/dev/xl/if_xl.c:2383: warning: nested extern declaration of 'xl_stats_update_locked' *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-05-07 04:18:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-05-07 04:18:07 - ERROR: failed to build lint kernel TB --- 2011-05-07 04:18:07 - 6186.30 user 1032.59 system 7686.92 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat May 7 04:52:58 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DF2C106566C; Sat, 7 May 2011 04:52:58 +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 6C6E88FC08; Sat, 7 May 2011 04:52:57 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p474qv7f097719; Sat, 7 May 2011 00:52:57 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p474qvuw097711; Sat, 7 May 2011 04:52:57 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 7 May 2011 04:52:57 GMT Message-Id: <201105070452.p474qvuw097711@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: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 04:52:58 -0000 TB --- 2011-05-07 02:10:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-07 02:10:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-05-07 02:10:00 - cleaning the object tree TB --- 2011-05-07 02:10:28 - cvsupping the source tree TB --- 2011-05-07 02:10:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-05-07 02:15:53 - building world TB --- 2011-05-07 02:15:53 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-07 02:15:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-07 02:15:53 - TARGET=amd64 TB --- 2011-05-07 02:15:53 - TARGET_ARCH=amd64 TB --- 2011-05-07 02:15:53 - TZ=UTC TB --- 2011-05-07 02:15:53 - __MAKE_CONF=/dev/null TB --- 2011-05-07 02:15:53 - cd /src TB --- 2011-05-07 02:15:53 - /usr/bin/make -B buildworld >>> World build started on Sat May 7 02:15:53 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat May 7 04:42:52 UTC 2011 TB --- 2011-05-07 04:42:53 - generating LINT kernel config TB --- 2011-05-07 04:42:54 - cd /src/sys/amd64/conf TB --- 2011-05-07 04:42:54 - /usr/bin/make -B LINT TB --- 2011-05-07 04:42:54 - building LINT kernel TB --- 2011-05-07 04:42:54 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-07 04:42:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-07 04:42:54 - TARGET=amd64 TB --- 2011-05-07 04:42:54 - TARGET_ARCH=amd64 TB --- 2011-05-07 04:42:54 - TZ=UTC TB --- 2011-05-07 04:42:54 - __MAKE_CONF=/dev/null TB --- 2011-05-07 04:42:54 - cd /src TB --- 2011-05-07 04:42:54 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat May 7 04:42:54 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ld -b binary -d -warn-common -r -d -o wpifw.fwo wpi.fw cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/xe/if_xe.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/xe/if_xe_pccard.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/xl/if_xl.c cc1: warnings being treated as errors /src/sys/dev/xl/if_xl.c: In function 'xl_poll_locked': /src/sys/dev/xl/if_xl.c:2383: warning: implicit declaration of function 'xl_stats_update_locked' /src/sys/dev/xl/if_xl.c:2383: warning: nested extern declaration of 'xl_stats_update_locked' *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-05-07 04:52:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-05-07 04:52:56 - ERROR: failed to build lint kernel TB --- 2011-05-07 04:52:56 - 7471.64 user 1357.16 system 9775.87 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sat May 7 05:06:43 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C52C4106566B; Sat, 7 May 2011 05:06:43 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.212.176]) by mx1.freebsd.org (Postfix) with ESMTP id 87F618FC0A; Sat, 7 May 2011 05:06:43 +0000 (UTC) Received: by pxi11 with SMTP id 11so3029895pxi.7 for ; Fri, 06 May 2011 22:06:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:date:to:cc:subject:message-id:reply-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=oulK1o3WU4mZOOOnuUT6WkwCVirH0eA5LoAzPTnWT2U=; b=Z6siRkuv+skPWNxAu03tLr8Gz/596kh92CXhZ/9YFHh4fK25WHzkAPnryG3kzk8WYU xGapG0NlpKFTSQn7HW2xBJQdqJJguqVHp6asLCMx5EWtIIaLeMuT1Gf7W/vwNrhgD2fw CFhYXzplrLh1j12bMeuyrb/trJ4ZXx5OMXOIE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=FD5aStKLzPAEEomuTabcT0RkZaiA5F8h2FOnDs6tUub3P/fMvQyCd+xOhAsHzJltR+ rOb7hr/Hy7FNDAx3Ci37Q+I3wjoFUB6WSLGFvkFh0JXpaJEV8EsMyq1mdFBDFeP3G0mV bpoJl6TlRPkSUO0HvxIBC1US4eaOLfBpO3OFc= Received: by 10.68.58.7 with SMTP id m7mr5931977pbq.420.1304743303593; Fri, 06 May 2011 21:41:43 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id x6sm1601616pbx.86.2011.05.06.21.41.41 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 May 2011 21:41:42 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 06 May 2011 21:41:00 -0700 From: YongHyeon PYUN Date: Fri, 6 May 2011 21:41:00 -0700 To: FreeBSD Tinderbox Message-ID: <20110507044100.GA19995@michelle.cdnetworks.com> References: <201105070418.p474I89Z085586@freebsd-current.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201105070418.p474I89Z085586@freebsd-current.sentex.ca> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org, i386@freebsd.org Subject: Re: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 05:06:43 -0000 On Sat, May 07, 2011 at 04:18:08AM +0000, FreeBSD Tinderbox wrote: > TB --- 2011-05-07 02:10:00 - tinderbox 2.7 running on freebsd-current.sentex.ca > TB --- 2011-05-07 02:10:00 - starting HEAD tinderbox run for i386/i386 > TB --- 2011-05-07 02:10:00 - cleaning the object tree > TB --- 2011-05-07 02:10:28 - cvsupping the source tree > TB --- 2011-05-07 02:10:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile > TB --- 2011-05-07 02:10:41 - building world > TB --- 2011-05-07 02:10:41 - MAKEOBJDIRPREFIX=/obj > TB --- 2011-05-07 02:10:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-05-07 02:10:41 - TARGET=i386 > TB --- 2011-05-07 02:10:41 - TARGET_ARCH=i386 > TB --- 2011-05-07 02:10:41 - TZ=UTC > TB --- 2011-05-07 02:10:41 - __MAKE_CONF=/dev/null > TB --- 2011-05-07 02:10:41 - cd /src > TB --- 2011-05-07 02:10:41 - /usr/bin/make -B buildworld > >>> World build started on Sat May 7 02:10:42 UTC 2011 > >>> Rebuilding the temporary build tree > >>> stage 1.1: legacy release compatibility shims > >>> stage 1.2: bootstrap tools > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3: cross tools > >>> stage 4.1: building includes > >>> stage 4.2: building libraries > >>> stage 4.3: make dependencies > >>> stage 4.4: building everything > >>> World build completed on Sat May 7 04:07:08 UTC 2011 > TB --- 2011-05-07 04:07:08 - generating LINT kernel config > TB --- 2011-05-07 04:07:08 - cd /src/sys/i386/conf > TB --- 2011-05-07 04:07:08 - /usr/bin/make -B LINT > TB --- 2011-05-07 04:07:08 - building LINT kernel > TB --- 2011-05-07 04:07:08 - MAKEOBJDIRPREFIX=/obj > TB --- 2011-05-07 04:07:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-05-07 04:07:08 - TARGET=i386 > TB --- 2011-05-07 04:07:08 - TARGET_ARCH=i386 > TB --- 2011-05-07 04:07:08 - TZ=UTC > TB --- 2011-05-07 04:07:08 - __MAKE_CONF=/dev/null > TB --- 2011-05-07 04:07:08 - cd /src > TB --- 2011-05-07 04:07:08 - /usr/bin/make -B buildkernel KERNCONF=LINT > >>> Kernel build for LINT started on Sat May 7 04:07:08 UTC 2011 > >>> stage 1: configuring the kernel > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3.1: making dependencies > >>> stage 3.2: building everything > [...] > ld -b binary -d -warn-common -r -d -o wpifw.fwo wpi.fw > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/xe/if_xe.c > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/xe/if_xe_pccard.c > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/xl/if_xl.c > cc1: warnings being treated as errors > /src/sys/dev/xl/if_xl.c: In function 'xl_poll_locked': > /src/sys/dev/xl/if_xl.c:2383: warning: implicit declaration of function 'xl_stats_update_locked' > /src/sys/dev/xl/if_xl.c:2383: warning: nested extern declaration of 'xl_stats_update_locked' > *** Error code 1 Sorry for the breakage. Should be fixed now. From owner-freebsd-current@FreeBSD.ORG Sat May 7 08:15:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA236106564A for ; Sat, 7 May 2011 08:15:16 +0000 (UTC) (envelope-from yuri.pankov@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5A3818FC08 for ; Sat, 7 May 2011 08:15:16 +0000 (UTC) Received: by bwz12 with SMTP id 12so4405879bwz.13 for ; Sat, 07 May 2011 01:15:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:x-authentication-warning:date:from:to:subject :message-id:mime-version:content-type:content-disposition:user-agent; bh=XUdYjNUHCMqVfhNOwTNxAsbkXo0R/+5BctzrRVhLdFc=; b=E1wDU9HuZu9fapPhi0x0zclAMhrhi5RUJnkSTM23wSLdfxRSURWMvm68uPAJPFIEwN f6TUvK2S/eYZqAH6/sVj92M4x7A+KbWULYFx6WjYIMugk7nPwl6rSOU45nwvTC/oyd2O nxo9I5rZj4NqUMtCLQRc/8lGpLF0BT8HZURsU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-authentication-warning:date:from:to:subject:message-id :mime-version:content-type:content-disposition:user-agent; b=RD+FkYHpBmn5KNPCx7Xl97MPJvSmtVsqH6Yq6nC+AEJD64ailzerp6Wn1ezJED11jf TzezbkFqV5wydwHFtnaNeSmiaQWGMz+kIw8CuUuA1mhdbVKzkSZBKWwHTre16GhFVNei Cz5ErClfikCy9m6bhmypU7AOdhB4X2ELPCp3s= Received: by 10.204.24.4 with SMTP id t4mr1643176bkb.109.1304754350224; Sat, 07 May 2011 00:45:50 -0700 (PDT) Received: from procyon.xvoid.org ([213.132.76.142]) by mx.google.com with ESMTPS id d11sm2434585bka.7.2011.05.07.00.45.48 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 07 May 2011 00:45:49 -0700 (PDT) Received: from procyon.xvoid.org (yuri@procyon.xvoid.org [IPv6:::1]) by procyon.xvoid.org (8.14.4/8.14.4) with ESMTP id p477jlex017907 for ; Sat, 7 May 2011 11:45:47 +0400 (MSD) (envelope-from yuri.pankov@gmail.com) Received: (from yuri@localhost) by procyon.xvoid.org (8.14.4/8.14.4/Submit) id p477jlmI017906 for freebsd-current@freebsd.org; Sat, 7 May 2011 11:45:47 +0400 (MSD) (envelope-from yuri.pankov@gmail.com) X-Authentication-Warning: procyon.xvoid.org: yuri set sender to yuri.pankov@gmail.com using -f Date: Sat, 7 May 2011 11:45:47 +0400 From: Yuri Pankov To: freebsd-current@freebsd.org Message-ID: <20110507074547.GE1222@procyon.xvoid.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: sendmail tries to resolve IPv6:::1 specified in submit.mc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 08:15:16 -0000 Hi, I'm getting weird problem on recent -CURRENT - sendmail is trying to resolve 'IPv6:::1' specified in /etc/mail/`hostname`.submit.mc: FEATURE(`msp', `[IPv6:::1]')dnl tcpdump: 3802+ A? ipv6:::1.xvoid.org. (36) 3802 NXDomain* 0/1/0 (100) 3803+ A? ipv6:::1.lab.xvoid.org. (40) 3803 NXDomain* 0/1/0 (108) 3804+ A? ipv6:::1. (26) 3804 ServFail 0/0/0 (26) 3804+ A? ipv6:::1. (26) 3804 ServFail 0/0/0 (26) IPv6 is configured and is working except for this problem. Sendmail on 8.2-RELEASE is working fine with the same submit.mc contents. Any hints? TIA, Yuri From owner-freebsd-current@FreeBSD.ORG Sat May 7 09:22:02 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 2BC4A1065674; Sat, 7 May 2011 09:22:02 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id E6FFB1504E7; Sat, 7 May 2011 09:22:00 +0000 (UTC) Message-ID: <4DC50F37.5050603@FreeBSD.org> Date: Sat, 07 May 2011 02:21:59 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org, Alexander Motin X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: My problems with stability on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 09:22:02 -0000 On 05/05/2011 13:55, Alexander Motin wrote: > Doug Barton wrote: >> Alexander suggested some knobs to twist for the timers, and I'll be glad >> to do that once he gets back to me with more concrete suggestions now >> that he knows more about my specific problems. > > OK, I am all here. While this post is indeed larger then previous, it is > not much more informative. Sorry. :( I understand. > I see several possibly unrelated problems there: > - crashes are always crashes. They should be debugged. > - calcru going backwards could have the same roots as lost wall clock > time. I think you're right about that. What usually happens when the load maxes out is that the system visibly freezes for a minute or 2, and when it comes back to life the log is flooded with calcru messages. If it stays up long enough after that the wall clock drift becomes noticeable. This is in spite of running ntpd. > If there are some problems with timer interrupts, timecounters > could wrap unnoticed that will cause random time jumps. > - interactivity problems. I can't prove it is unrelated, but have no > real ideas now. > > I would start from most obvious problems. I need to know more about > crashes. As usual: how to trigger, stack backtraces, etc. Triggering is easy, I can start a buildworld with -j2, and a build of ports/www/firefox with FORCE_MAKE_JOBS, and within 30 minutes the system will reboot. I posted a panic message relative to r220282, (-current archives, 4/4) but kib said it didn't make any sense. Usually I don't get a panic at all. > What's about time problems, I would try to collect more data: > - show `sysctl kern.eventtimer`, `sysctl kern.timecounter` and verbose > dmesg outputs; http://people.freebsd.org/~dougb/dougb-current-r221566.txt > - what eventtimer is used now and does it helps to switch to another > one with kern.eventtimer.timer sysctl? When I was trying to track down the problems last summer I vaguely remember trying RTC, but eventually we realized that the real problem was throttling, so I stopped specifying RTC and let it go back to the default. What do you suggest I try? > - does the timer runs in periodic or one-shot mode and does it helps to > switch to another one? How could I tell, and how would I switch? > - if full CPU load makes time to stop, try to track what is going on > with timer interrupts using `vmstat -i` and `systat -vm 1`. Under full > CPU load in one-shot mode you should have stable timer interrupt rate > about hz+stathz. Ok, I'll do that tomorrow, tired now. > - if timer interrupts are not working well, you can build kernel with > options KTR > options ALQ > options KTR_ALQ > options KTR_COMPILE=(KTR_SPARE2) > options KTR_ENTRIES=131072 > options KTR_MASK=(KTR_SPARE2) > to track event timers operation and use ktrdump to save the trace when > problem exist (preferably when it begins). > > And let's experiment with fresh CURRENT. Done and done. I'm up to r221566, and I added those options to my kernel config. I ran ktrdump -cH -o ktrdumpfile and posted the results here: http://people.freebsd.org/~dougb/ktrdumpfile.txt This was shortly after boot, with no load. Not sure if it helps, but there you go. Thanks again for your help, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Sat May 7 09:37:30 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D53C1065670 for ; Sat, 7 May 2011 09:37:30 +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 E6F7F8FC08 for ; Sat, 7 May 2011 09:37:29 +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 MAA05925 for ; Sat, 07 May 2011 12:37:28 +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 1QIdx1-0004BB-Vj for current@FreeBSD.org; Sat, 07 May 2011 12:37:27 +0300 Message-ID: <4DC512D6.9070904@FreeBSD.org> Date: Sat, 07 May 2011 12:37:26 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: current@FreeBSD.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: Subject: COUNT_IPIS vs CPU_FOREACH X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 09:37:30 -0000 I believe that the following change is needed to fix COUNT_IPIS option. Right now it seems to be a noop. mp_ipi_intrcnt: CPU_FOREACH can't be used this early ... because all_cpus is not set yet. diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c index 33bb424..3d957ec 100644 --- a/sys/amd64/amd64/mp_machdep.c +++ b/sys/amd64/amd64/mp_machdep.c @@ -1687,7 +1687,7 @@ mp_ipi_intrcnt(void *dummy) char buf[64]; int i; - CPU_FOREACH(i) { + for (i = 0; i <= mp_maxid; i++) { snprintf(buf, sizeof(buf), "cpu%d:invltlb", i); intrcnt_add(buf, &ipi_invltlb_counts[i]); snprintf(buf, sizeof(buf), "cpu%d:invlrng", i); -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat May 7 09:42:51 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C56AF106566B for ; Sat, 7 May 2011 09:42:51 +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 178658FC0A for ; Sat, 7 May 2011 09:42:50 +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 MAA05968 for ; Sat, 07 May 2011 12:42:49 +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 1QIe2D-0004BJ-5d for current@FreeBSD.org; Sat, 07 May 2011 12:42:49 +0300 Message-ID: <4DC51418.40604@FreeBSD.org> Date: Sat, 07 May 2011 12:42:48 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: current@FreeBSD.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: Subject: pls review: remove dtrace_gethrtime_init_sync X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 09:42:51 -0000 I couldn't think of any purpose for the code under CHECK_SYNC. So I'd like to just drop it. dtrace_gethrtime_init: remove some useless code diff --git a/sys/cddl/dev/dtrace/amd64/dtrace_subr.c b/sys/cddl/dev/dtrace/amd64/dtrace_subr.c index a44334a..f59fad3 100644 --- a/sys/cddl/dev/dtrace/amd64/dtrace_subr.c +++ b/sys/cddl/dev/dtrace/amd64/dtrace_subr.c @@ -359,26 +359,6 @@ static uint32_t nsec_scale; #define SCALE_SHIFT 28 static void -dtrace_gethrtime_init_sync(void *arg) -{ -#ifdef CHECK_SYNC - /* - * Delay this function from returning on one - * of the CPUs to check that the synchronisation - * works. - */ - uintptr_t cpu = (uintptr_t) arg; - - if (cpu == curcpu) { - int i; - for (i = 0; i < 1000000000; i++) - tgt_cpu_tsc = rdtsc(); - tgt_cpu_tsc = 0; - } -#endif -} - -static void dtrace_gethrtime_init_cpu(void *arg) { uintptr_t cpu = (uintptr_t) arg; @@ -434,7 +414,7 @@ dtrace_gethrtime_init(void *arg) pc = pcpu_find(i); map = PCPU_GET(cpumask) | pc->pc_cpumask; - smp_rendezvous_cpus(map, dtrace_gethrtime_init_sync, + smp_rendezvous_cpus(map, NULL, dtrace_gethrtime_init_cpu, smp_no_rendevous_barrier, (void *)(uintptr_t) i); diff --git a/sys/cddl/dev/dtrace/i386/dtrace_subr.c b/sys/cddl/dev/dtrace/i386/dtrace_subr.c index 2ef21f8..d4177a4 100644 --- a/sys/cddl/dev/dtrace/i386/dtrace_subr.c +++ b/sys/cddl/dev/dtrace/i386/dtrace_subr.c @@ -359,26 +359,6 @@ static uint32_t nsec_scale; #define SCALE_SHIFT 28 static void -dtrace_gethrtime_init_sync(void *arg) -{ -#ifdef CHECK_SYNC - /* - * Delay this function from returning on one - * of the CPUs to check that the synchronisation - * works. - */ - uintptr_t cpu = (uintptr_t) arg; - - if (cpu == curcpu) { - int i; - for (i = 0; i < 1000000000; i++) - tgt_cpu_tsc = rdtsc(); - tgt_cpu_tsc = 0; - } -#endif -} - -static void dtrace_gethrtime_init_cpu(void *arg) { uintptr_t cpu = (uintptr_t) arg; @@ -434,7 +414,7 @@ dtrace_gethrtime_init(void *arg) pc = pcpu_find(i); map = PCPU_GET(cpumask) | pc->pc_cpumask; - smp_rendezvous_cpus(map, dtrace_gethrtime_init_sync, + smp_rendezvous_cpus(map, NULL, dtrace_gethrtime_init_cpu, smp_no_rendevous_barrier, (void *)(uintptr_t) i); -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat May 7 09:43:54 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1257A106564A for ; Sat, 7 May 2011 09:43:54 +0000 (UTC) (envelope-from mavbsd@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 923848FC19 for ; Sat, 7 May 2011 09:43:53 +0000 (UTC) Received: by fxm11 with SMTP id 11so3910772fxm.13 for ; Sat, 07 May 2011 02:43:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature: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=off4wsxqojwuRZgOQhahcIs8KM1f1nzkYtxcV+EMmbE=; b=bA7EQ2J8od5WFEdfzyiKtPUlynZKv/mDym5d0I7zkQD/EzXl+g1UKfBkTIjpHnMX0J xfw2p4hl5DR8zaCNEj4RLGUYIkT3LVSqH6yKHbQagWuywLtVypCK2EVAoqMRZDCop8Ub nSrvhcyL2OYRSLFe7cbECq74O3e84XFp38Tvc= 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=XGkxVvHrB+3hNwIgGyX9lJAg0tzKVA/VFWRnOUlNw+SHNCmuoAh9bESf1ybnIajLo8 J9C58zJhk3UyTorV87H3GOzgvrhBL73rvgqdRcVOOLSkmDFAcFMl4r5/Dy0JRJhYJ9cA fBJ0zbgw79GEr1rZXMAmXKQ8S5QL7OZR24ADw= Received: by 10.223.24.153 with SMTP id v25mr1617842fab.29.1304761432550; Sat, 07 May 2011 02:43:52 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 6sm1333598fae.13.2011.05.07.02.43.50 (version=SSLv3 cipher=OTHER); Sat, 07 May 2011 02:43:51 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DC51434.3000501@FreeBSD.org> Date: Sat, 07 May 2011 12:43:16 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Doug Barton References: <4DC25396.1070909@dougbarton.us> <4DC30EC5.3090703@FreeBSD.org> <4DC50804.6000809@dougbarton.us> In-Reply-To: <4DC50804.6000809@dougbarton.us> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: My problems with stability on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 09:43:54 -0000 Doug Barton wrote: > On 05/05/2011 13:55, Alexander Motin wrote: >> I see several possibly unrelated problems there: >> - crashes are always crashes. They should be debugged. >> - calcru going backwards could have the same roots as lost wall clock >> time. > > I think you're right about that. What usually happens when the load > maxes out is that the system visibly freezes for a minute or 2, and when > it comes back to life the log is flooded with calcru messages. If it > stays up long enough after that the wall clock drift becomes noticeable. > This is in spite of running ntpd. These system freezes are very suspicious. Most time counters need only few seconds to overflow, some even less. So freeze for few minutes will easily overflow most of them. So the freezes are probably the cause of time problems, but the question now is what the cause of freezes. You should try to investigate what is going on during freezes. Does the system do anything, are there any interrupts working (`vmstat -i` just before and after), are there any interrupt storms, etc? >> If there are some problems with timer interrupts, timecounters >> could wrap unnoticed that will cause random time jumps. >> - interactivity problems. I can't prove it is unrelated, but have no >> real ideas now. >> >> I would start from most obvious problems. I need to know more about >> crashes. As usual: how to trigger, stack backtraces, etc. > > Triggering is easy, I can start a buildworld with -j2, and a build of > ports/www/firefox with FORCE_MAKE_JOBS, and within 30 minutes the system > will reboot. I posted a panic message relative to r220282, (-current > archives, 4/4) but kib said it didn't make any sense. Usually I don't > get a panic at all. Could you hint me the thread? >> What's about time problems, I would try to collect more data: >> - show `sysctl kern.eventtimer`, `sysctl kern.timecounter` and verbose >> dmesg outputs; > > http://people.freebsd.org/~dougb/dougb-current-r221566.txt > >> - what eventtimer is used now and does it helps to switch to another >> one with kern.eventtimer.timer sysctl? > > When I was trying to track down the problems last summer I vaguely > remember trying RTC, but eventually we realized that the real problem > was throttling, so I stopped specifying RTC and let it go back to the > default. What do you suggest I try? As I see, now you are using HPET (chosen automatically). I would try switch to the LAPIC. Just make sure to disable C-states if you are enabled them to be sure that LAPIC timer won't stop. >> - does the timer runs in periodic or one-shot mode and does it helps to >> switch to another one? > > How could I tell, and how would I switch? `sysctl kern.eventtimer.periodic`. And read eventtimers(4) please. >> - if full CPU load makes time to stop, try to track what is going on >> with timer interrupts using `vmstat -i` and `systat -vm 1`. Under full >> CPU load in one-shot mode you should have stable timer interrupt rate >> about hz+stathz. > > Ok, I'll do that tomorrow, tired now. > >> - if timer interrupts are not working well, you can build kernel with >> options KTR >> options ALQ >> options KTR_ALQ >> options KTR_COMPILE=(KTR_SPARE2) >> options KTR_ENTRIES=131072 >> options KTR_MASK=(KTR_SPARE2) >> to track event timers operation and use ktrdump to save the trace when >> problem exist (preferably when it begins). >> >> And let's experiment with fresh CURRENT. > > Done and done. I'm up to r221566, and I added those options to my kernel > config. I ran ktrdump -cH -o ktrdumpfile and posted the results here: > http://people.freebsd.org/~dougb/ktrdumpfile.txt This was shortly after > boot, with no load. Not sure if it helps, but there you go. Dump looks fine, but I need dump specifically for the time of the problem. As soon as time probably can't be trusted here, it would be nice to make dump as localized as possible: clear buffer with `sysctl debug.ktr.clear=1`, trigger freeze for few seconds, stop collecting with `sysctl debug.ktr.mask=0` and do the dump. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sat May 7 09:58:14 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEA79106564A for ; Sat, 7 May 2011 09:58:14 +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 21C078FC08 for ; Sat, 7 May 2011 09:58:13 +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 MAA06091 for ; Sat, 07 May 2011 12:58:12 +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 1QIeH6-0004Bq-Bg for current@FreeBSD.org; Sat, 07 May 2011 12:58:12 +0300 Message-ID: <4DC517B3.8050502@FreeBSD.org> Date: Sat, 07 May 2011 12:58:11 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: current@FreeBSD.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: Subject: bitcount32: replace lengthy comment with SWAR reference X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 09:58:14 -0000 I think that the SWAR reference should be more concise and should lead an interested reader to more information on the topic (and more up-to-date as well). bitcount32: replace lengthy comment with SWAR reference diff --git a/sys/sys/systm.h b/sys/sys/systm.h index 48bb33c..5218988 100644 --- a/sys/sys/systm.h +++ b/sys/sys/systm.h @@ -383,44 +383,8 @@ int alloc_unrl(struct unrhdr *uh); void free_unr(struct unrhdr *uh, u_int item); /* - * This is about as magic as it gets. fortune(1) has got similar code - * for reversing bits in a word. Who thinks up this stuff?? - * - * Yes, it does appear to be consistently faster than: - * while (i = ffs(m)) { - * m >>= i; - * bits++; - * } - * and - * while (lsb = (m & -m)) { // This is magic too - * m &= ~lsb; // or: m ^= lsb - * bits++; - * } - * Both of these latter forms do some very strange things on gcc-3.1 with - * -mcpu=pentiumpro and/or -march=pentiumpro and/or -O or -O2. - * There is probably an SSE or MMX popcnt instruction. - * - * I wonder if this should be in libkern? - * - * XXX Stop the presses! Another one: - * static __inline u_int32_t - * popcnt1(u_int32_t v) - * { - * v -= ((v >> 1) & 0x55555555); - * v = (v & 0x33333333) + ((v >> 2) & 0x33333333); - * v = (v + (v >> 4)) & 0x0F0F0F0F; - * return (v * 0x01010101) >> 24; - * } - * The downside is that it has a multiply. With a pentium3 with - * -mcpu=pentiumpro and -march=pentiumpro then gcc-3.1 will use - * an imull, and in that case it is faster. In most other cases - * it appears slightly slower. - * - * Another variant (also from fortune): - * #define BITCOUNT(x) (((BX_(x)+(BX_(x)>>4)) & 0x0F0F0F0F) % 255) - * #define BX_(x) ((x) - (((x)>>1)&0x77777777) \ - * - (((x)>>2)&0x33333333) \ - * - (((x)>>3)&0x11111111)) + * Population count algorithm using SWAR approach + * - "SIMD Within A Register". */ static __inline uint32_t bitcount32(uint32_t x) -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat May 7 10:11:05 2011 Return-Path: Delivered-To: current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id B61121065670; Sat, 7 May 2011 10:11:05 +0000 (UTC) Date: Sat, 7 May 2011 10:11:05 +0000 From: Alexander Best To: FreeBSD Tinderbox Message-ID: <20110507101105.GA32422@freebsd.org> References: <201105070452.p474qvuw097711@freebsd-current.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201105070452.p474qvuw097711@freebsd-current.sentex.ca> Cc: amd64@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 10:11:05 -0000 On Sat May 7 11, FreeBSD Tinderbox wrote: > TB --- 2011-05-07 02:10:00 - tinderbox 2.7 running on freebsd-current.sentex.ca > TB --- 2011-05-07 02:10:00 - starting HEAD tinderbox run for amd64/amd64 > TB --- 2011-05-07 02:10:00 - cleaning the object tree > TB --- 2011-05-07 02:10:28 - cvsupping the source tree > TB --- 2011-05-07 02:10:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile > TB --- 2011-05-07 02:15:53 - building world > TB --- 2011-05-07 02:15:53 - MAKEOBJDIRPREFIX=/obj > TB --- 2011-05-07 02:15:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-05-07 02:15:53 - TARGET=amd64 > TB --- 2011-05-07 02:15:53 - TARGET_ARCH=amd64 > TB --- 2011-05-07 02:15:53 - TZ=UTC > TB --- 2011-05-07 02:15:53 - __MAKE_CONF=/dev/null > TB --- 2011-05-07 02:15:53 - cd /src > TB --- 2011-05-07 02:15:53 - /usr/bin/make -B buildworld > >>> World build started on Sat May 7 02:15:53 UTC 2011 > >>> Rebuilding the temporary build tree > >>> stage 1.1: legacy release compatibility shims > >>> stage 1.2: bootstrap tools > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3: cross tools > >>> stage 4.1: building includes > >>> stage 4.2: building libraries > >>> stage 4.3: make dependencies > >>> stage 4.4: building everything > >>> stage 5.1: building 32 bit shim libraries > >>> World build completed on Sat May 7 04:42:52 UTC 2011 > TB --- 2011-05-07 04:42:53 - generating LINT kernel config > TB --- 2011-05-07 04:42:54 - cd /src/sys/amd64/conf > TB --- 2011-05-07 04:42:54 - /usr/bin/make -B LINT > TB --- 2011-05-07 04:42:54 - building LINT kernel > TB --- 2011-05-07 04:42:54 - MAKEOBJDIRPREFIX=/obj > TB --- 2011-05-07 04:42:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-05-07 04:42:54 - TARGET=amd64 > TB --- 2011-05-07 04:42:54 - TARGET_ARCH=amd64 > TB --- 2011-05-07 04:42:54 - TZ=UTC > TB --- 2011-05-07 04:42:54 - __MAKE_CONF=/dev/null > TB --- 2011-05-07 04:42:54 - cd /src > TB --- 2011-05-07 04:42:54 - /usr/bin/make -B buildkernel KERNCONF=LINT > >>> Kernel build for LINT started on Sat May 7 04:42:54 UTC 2011 > >>> stage 1: configuring the kernel > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3.1: making dependencies > >>> stage 3.2: building everything > [...] > ld -b binary -d -warn-common -r -d -o wpifw.fwo wpi.fw > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/xe/if_xe.c > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/xe/if_xe_pccard.c > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/xl/if_xl.c could somebody explain, why only on amd64 the default COPTFLAGS are -O2 -frename-registers (even with DEBUG set)? judging from gcc(1) expecially -frename-registers makes debugging very hard. cheers. alex > cc1: warnings being treated as errors > /src/sys/dev/xl/if_xl.c: In function 'xl_poll_locked': > /src/sys/dev/xl/if_xl.c:2383: warning: implicit declaration of function 'xl_stats_update_locked' > /src/sys/dev/xl/if_xl.c:2383: warning: nested extern declaration of 'xl_stats_update_locked' > *** Error code 1 > > Stop in /obj/src/sys/LINT. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2011-05-07 04:52:56 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2011-05-07 04:52:56 - ERROR: failed to build lint kernel > TB --- 2011-05-07 04:52:56 - 7471.64 user 1357.16 system 9775.87 real > > > http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full -- a13x From owner-freebsd-current@FreeBSD.ORG Sat May 7 10:11:19 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0DEF1065672 for ; Sat, 7 May 2011 10:11:19 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 678EE8FC14 for ; Sat, 7 May 2011 10:11:19 +0000 (UTC) Received: by iyj12 with SMTP id 12so4610159iyj.13 for ; Sat, 07 May 2011 03:11:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=cmA+NSxLpridimY9+mOmI5NnChRV/U73feUDqzfLY4E=; b=CSVWfQCHaHNrmhGtAVDTk9/UUuw7RDfn3aC1masskv8yJSqwThOsPM0upVZzltDZBY 5jYahrdr14mAJmIWM8+nGIIDlysdUJnr5XjEz5yrHQuEYeln5aHbzMEZznyl7/Mn+7Wi jfVyvF4PMXJ305fziW7Jo1FBRWxJrYNbK3W9o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=F2MazawZrM7U5X6XDWozDZmCFozLb84lTzEflVovJbiox4NmF2BzkKgCVIjzccx6gP tepBSLfKVP/15ps0cEHTpnKv/OW9CpHkdfqGXRUJ97naQcu9WXYibXwdY0AqcnnRQ3WX 3IomniuV9PO8cdHvT2747+bOexFZs88Fr6dzg= Received: by 10.42.151.138 with SMTP id e10mr3952889icw.251.1304763078449; Sat, 07 May 2011 03:11:18 -0700 (PDT) Received: from DataIX.net (adsl-99-190-84-116.dsl.klmzmi.sbcglobal.net [99.190.84.116]) by mx.google.com with ESMTPS id gy41sm1696302ibb.56.2011.05.07.03.11.16 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 07 May 2011 03:11:17 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p47ABDuf030700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 May 2011 06:11:14 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p47ABDM2030699; Sat, 7 May 2011 06:11:13 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Sat, 7 May 2011 06:11:12 -0400 From: Jason Hellenthal To: Yuri Pankov Message-ID: <20110507101112.GA2734@DataIX.net> References: <20110507074547.GE1222@procyon.xvoid.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline In-Reply-To: <20110507074547.GE1222@procyon.xvoid.org> X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: freebsd-current@freebsd.org Subject: Re: sendmail tries to resolve IPv6:::1 specified in submit.mc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 10:11:19 -0000 --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Yuri, On Sat, May 07, 2011 at 11:45:47AM +0400, Yuri Pankov wrote: >Hi, > >I'm getting weird problem on recent -CURRENT - sendmail is trying to >resolve 'IPv6:::1' specified in /etc/mail/`hostname`.submit.mc: > >FEATURE(`msp', `[IPv6:::1]')dnl > >tcpdump: >3802+ A? ipv6:::1.xvoid.org. (36) >3802 NXDomain* 0/1/0 (100) >3803+ A? ipv6:::1.lab.xvoid.org. (40) >3803 NXDomain* 0/1/0 (108) >3804+ A? ipv6:::1. (26) >3804 ServFail 0/0/0 (26) >3804+ A? ipv6:::1. (26) >3804 ServFail 0/0/0 (26) > >IPv6 is configured and is working except for this problem. Sendmail >on 8.2-RELEASE is working fine with the same submit.mc contents. > >Any hints? > Yuri by default this is set to [127.0.0.1] as denoted by: http://svn.freebsd.org/base/head/etc/sendmail/freebsd.submit.mc I believe it has been this way for a very long time. If for some reason=20 that you changed the value your self and you would like to revert back to= =20 defaults you can remove `hostname`.mc & `hostname`.submit.mc and re-run=20 make(1) in the /etc/mail directory to give you a default config. The comment in that file reads: dnl If you use IPv6 only, change [127.0.0.1] to [IPv6:::1] --=20 Regards, (jhell) Jason Hellenthal --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNxRq/AAoJEJBXh4mJ2FR+RkUIAIAjxQksU1tmY8U4YwWdraMm P+fcgEqhbzFfDUKQUjEvep/C/SbPPtRy+R1rS8tkkcEBUex0/2KmE8ijJGLVcTlS e/DfBCMIMrjKsSoHKfHZxFh3pzlB+pVz+N0a6NsOpNZIyasoeeFnBksQLqyaJFto GIUWozxoTC6m7VSBz+CzcrqM4XE/+umcG3YehKUh67N9ML3gL9bJ803fLc9rcoVm bXtnqC/RJrR/+XgHYzPwqdpLDfcRny0VubN7sQK72YwgEFmJkV6uUXbbwJuyPQ2K cNIA+DkEFapmSkpY+YZT/9jt2Qzpqi+2egbGP7kaMgx9hANhkzNK443zyKTaHY8= =xspH -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X-- From owner-freebsd-current@FreeBSD.ORG Sat May 7 10:16:42 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1EE6106564A for ; Sat, 7 May 2011 10:16:42 +0000 (UTC) (envelope-from yuri.pankov@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1B9498FC12 for ; Sat, 7 May 2011 10:16:41 +0000 (UTC) Received: by mail-bw0-f54.google.com with SMTP id 12so4454064bwz.13 for ; Sat, 07 May 2011 03:16:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:x-authentication-warning:date:from:to:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=MBL8Vs3G2IcjZyDyB4G9EzHu8SFhCvmqFUW8zu0eVIM=; b=b5rUrO5jOKAdusxIdhP3KB2Ol1jkrAIno++wemhUINeDAD+rc1RvESpYgP6lAJOeUV a48QzIegikWTHKk8Uiry/7wQc6TjXjIp/DzSHNbtrWrLXm6Ton9PyHl93XC3YOHdP2ch enRhu25F+mNCkkQjKG49lFyP2/yRo70AdIlzo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-authentication-warning:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; b=pPbRf2MtFKqJGyUoe6o+Zqf14503yGKN2Jv0ExWNKtjunOO/cghhoYnq2tGhPO7+xb EnaLRPBiUY3UIv1hQVlNp8DeEYFUaggmDTA6JrtlruyomEi3A05gnrE5s5SlVWZL1HZR XOYEvZldWHU1XNyF7R77Db10ilqjW2FmRfvdc= Received: by 10.204.16.216 with SMTP id p24mr1907701bka.5.1304763401113; Sat, 07 May 2011 03:16:41 -0700 (PDT) Received: from procyon.xvoid.org ([213.132.76.142]) by mx.google.com with ESMTPS id d11sm2495032bka.7.2011.05.07.03.16.39 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 07 May 2011 03:16:40 -0700 (PDT) Received: from procyon.xvoid.org (yuri@procyon.xvoid.org [IPv6:::1]) by procyon.xvoid.org (8.14.4/8.14.4) with ESMTP id p47AGb6B018301; Sat, 7 May 2011 14:16:37 +0400 (MSD) (envelope-from yuri.pankov@gmail.com) Received: (from yuri@localhost) by procyon.xvoid.org (8.14.4/8.14.4/Submit) id p47AGbMX018300; Sat, 7 May 2011 14:16:37 +0400 (MSD) (envelope-from yuri.pankov@gmail.com) X-Authentication-Warning: procyon.xvoid.org: yuri set sender to yuri.pankov@gmail.com using -f Date: Sat, 7 May 2011 14:16:37 +0400 From: Yuri Pankov To: Jason Hellenthal Message-ID: <20110507101637.GF1222@procyon.xvoid.org> References: <20110507074547.GE1222@procyon.xvoid.org> <20110507101112.GA2734@DataIX.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110507101112.GA2734@DataIX.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: Re: sendmail tries to resolve IPv6:::1 specified in submit.mc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 10:16:42 -0000 On Sat, May 07, 2011 at 06:11:12AM -0400, Jason Hellenthal wrote: > > Yuri, > > > On Sat, May 07, 2011 at 11:45:47AM +0400, Yuri Pankov wrote: > >Hi, > > > >I'm getting weird problem on recent -CURRENT - sendmail is trying to > >resolve 'IPv6:::1' specified in /etc/mail/`hostname`.submit.mc: > > > >FEATURE(`msp', `[IPv6:::1]')dnl > > > >tcpdump: > >3802+ A? ipv6:::1.xvoid.org. (36) > >3802 NXDomain* 0/1/0 (100) > >3803+ A? ipv6:::1.lab.xvoid.org. (40) > >3803 NXDomain* 0/1/0 (108) > >3804+ A? ipv6:::1. (26) > >3804 ServFail 0/0/0 (26) > >3804+ A? ipv6:::1. (26) > >3804 ServFail 0/0/0 (26) > > > >IPv6 is configured and is working except for this problem. Sendmail > >on 8.2-RELEASE is working fine with the same submit.mc contents. > > > >Any hints? > > > > Yuri by default this is set to [127.0.0.1] as denoted by: > http://svn.freebsd.org/base/head/etc/sendmail/freebsd.submit.mc > > I believe it has been this way for a very long time. If for some reason > that you changed the value your self and you would like to revert back to > defaults you can remove `hostname`.mc & `hostname`.submit.mc and re-run > make(1) in the /etc/mail directory to give you a default config. > > The comment in that file reads: > dnl If you use IPv6 only, change [127.0.0.1] to [IPv6:::1] Err, sure, but that's not what I'm asking. [127.0.0.1] works on both 8.2 and -CURRENT, however [IPv6:::1] doesn't work for me on -CURRENT, while working in 8.2. I can't find any related changes and checked almost everything I could think of in my configuration, so I'm asking for hints *why* sendmail doesn't accept [IPv6:::1] as correct address and tries to resolve it. Yuri From owner-freebsd-current@FreeBSD.ORG Sat May 7 10:47:54 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20388106566C; Sat, 7 May 2011 10:47:54 +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 A96A58FC15; Sat, 7 May 2011 10:47:53 +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 p47AlmpT057621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 May 2011 13:47:49 +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 p47Almtd000217; Sat, 7 May 2011 13:47:48 +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 p47Almfw000216; Sat, 7 May 2011 13:47:48 +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: Sat, 7 May 2011 13:47:48 +0300 From: Kostik Belousov To: Andriy Gapon Message-ID: <20110507104748.GL48734@deviant.kiev.zoral.com.ua> References: <4DC517B3.8050502@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0uEakrcbPVGl0QO8" Content-Disposition: inline In-Reply-To: <4DC517B3.8050502@FreeBSD.org> 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=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, 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: current@freebsd.org Subject: Re: bitcount32: replace lengthy comment with SWAR reference X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 10:47:54 -0000 --0uEakrcbPVGl0QO8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 07, 2011 at 12:58:11PM +0300, Andriy Gapon wrote: >=20 > I think that the SWAR reference should be more concise and should lead an > interested reader to more information on the topic (and more up-to-date a= s well). >=20 SWAR acronim seems to be a wikipedia invention. Without the abbreviation, the trimmed down comment looks better, IMHO. > bitcount32: replace lengthy comment with SWAR reference >=20 > diff --git a/sys/sys/systm.h b/sys/sys/systm.h > index 48bb33c..5218988 100644 > --- a/sys/sys/systm.h > +++ b/sys/sys/systm.h > @@ -383,44 +383,8 @@ int alloc_unrl(struct unrhdr *uh); > void free_unr(struct unrhdr *uh, u_int item); >=20 > /* > - * This is about as magic as it gets. fortune(1) has got similar code > - * for reversing bits in a word. Who thinks up this stuff?? > - * > - * Yes, it does appear to be consistently faster than: > - * while (i =3D ffs(m)) { > - * m >>=3D i; > - * bits++; > - * } > - * and > - * while (lsb =3D (m & -m)) { // This is magic too > - * m &=3D ~lsb; // or: m ^=3D lsb > - * bits++; > - * } > - * Both of these latter forms do some very strange things on gcc-3.1 with > - * -mcpu=3Dpentiumpro and/or -march=3Dpentiumpro and/or -O or -O2. > - * There is probably an SSE or MMX popcnt instruction. > - * > - * I wonder if this should be in libkern? > - * > - * XXX Stop the presses! Another one: > - * static __inline u_int32_t > - * popcnt1(u_int32_t v) > - * { > - * v -=3D ((v >> 1) & 0x55555555); > - * v =3D (v & 0x33333333) + ((v >> 2) & 0x33333333); > - * v =3D (v + (v >> 4)) & 0x0F0F0F0F; > - * return (v * 0x01010101) >> 24; > - * } > - * The downside is that it has a multiply. With a pentium3 with > - * -mcpu=3Dpentiumpro and -march=3Dpentiumpro then gcc-3.1 will use > - * an imull, and in that case it is faster. In most other cases > - * it appears slightly slower. > - * > - * Another variant (also from fortune): > - * #define BITCOUNT(x) (((BX_(x)+(BX_(x)>>4)) & 0x0F0F0F0F) % 255) > - * #define BX_(x) ((x) - (((x)>>1)&0x77777777) \ > - * - (((x)>>2)&0x33333333) \ > - * - (((x)>>3)&0x11111111)) > + * Population count algorithm using SWAR approach > + * - "SIMD Within A Register". > */ > static __inline uint32_t > bitcount32(uint32_t x) >=20 > --=20 > 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" --0uEakrcbPVGl0QO8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk3FI1QACgkQC3+MBN1Mb4hPHQCguv3I3v9VvfF/Q+DxEROefVhl DhoAniVOV+GDTawpjoToPhwHgDWLfAV0 =V6ki -----END PGP SIGNATURE----- --0uEakrcbPVGl0QO8-- From owner-freebsd-current@FreeBSD.ORG Sat May 7 11:27:20 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2E04106564A for ; Sat, 7 May 2011 11:27:20 +0000 (UTC) (envelope-from root@free.fr) Received: from smtpfb2-g21.free.fr (smtpfb2-g21.free.fr [212.27.42.10]) by mx1.freebsd.org (Postfix) with ESMTP id 647B98FC0A for ; Sat, 7 May 2011 11:27:18 +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 F2B7ACA9A06 for ; Sat, 7 May 2011 13:11:42 +0200 (CEST) Received: from free.fr (unknown [82.235.65.2]) by smtp5-g21.free.fr (Postfix) with ESMTP id 918E9D4818A for ; Sat, 7 May 2011 13:11:36 +0200 (CEST) From: Raoul To: freebsd-current@freebsd.org Date: Sat, 07 May 2011 13:12:53 +0200 Sender: root@free.fr Message-Id: <20110507111136.918E9D4818A@smtp5-g21.free.fr> Subject: BCM4321 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 11:27:20 -0000 Hi all, Is the BCM4321 wireless driver working on Head? short story: hardware: nvidia (Apple macmini) OS: Head from yesterday r211493m; Drivers loaded: bwn_lp_ucode, if_bwn, siba_bwn. ifconfig -l nfe0 fwe0 fwip0 lo0 ... Best regards Raoul rmgls@free.fr From owner-freebsd-current@FreeBSD.ORG Sat May 7 17:36:02 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 467471065678 for ; Sat, 7 May 2011 17:36:02 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id D1BA78FC1C for ; Sat, 7 May 2011 17:36:01 +0000 (UTC) Received: by vxc34 with SMTP id 34so6026126vxc.13 for ; Sat, 07 May 2011 10:36:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=7HcAtwmBwCYreRvcIZmihK8XW07Cne3M8VBQpxcmdDI=; b=qW+RM2RvZCMlfNJx5YUyNMx/sIlfstq/sj/axfUE69fH6opz7U46Rar1+zy9k2vOoV 0QeQ504cT1x+kzrjDACzn6wzaScSvbxqkq2LxnjOc3+kZxhwRHkFT3Vta8IE+VlhdCPR At6QF3259e31OHoM+XwHRjWeWiEYupukoLHZk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=oVMgOcjgRJkClBY+fPVcREfXEvtB19zCLT0PIU7WQCVYCAg/Rpi/e06ugg5dYW9qYC zfTQMF2OKMcBplZLu8imYzrQRrvauZDVGqs5nOMxT9tBHFl4Dil90c0BUbNzualOXXzw S6cR9oY+6vbUDM8acaEQp9n8CNQVCvb2Aav1A= MIME-Version: 1.0 Received: by 10.52.76.10 with SMTP id g10mr2920711vdw.252.1304789760974; Sat, 07 May 2011 10:36:00 -0700 (PDT) Received: by 10.220.201.136 with HTTP; Sat, 7 May 2011 10:36:00 -0700 (PDT) Date: Sat, 7 May 2011 10:36:00 -0700 Message-ID: From: Garrett Cooper To: Ed Schouten Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current Subject: panic: Assertion tib != NULL failed at /usr/src/sys/kern/tty_inq.c:459 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 17:36:02 -0000 Hi Ed, Ran into this panic with the machine idle for a day or so. There's some funky pointer problem going on based on the iostat output. The big difference in my kernel is the ffs code change that kib provided a couple of days ago, but apart from that the kernel is basically stock. Thanks, -Garrett # uname -a FreeBSD fallout.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r221219M: Thu May 5 12:09:37 PDT 2011 root@fallout.local:/usr/obj/usr/src/sys/FALLOUT amd64 Unread portion of the kernel message buffer: panic: Assertion tib != NULL failed at /usr/src/sys/kern/tty_inq.c:459 cpuid = 4 KDB: enter: panic Dumping 1341 out of 12269 MB:..2%..11%..21%..32%..41%..51%..61%..71%..82%..91% Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/FALLOUT.r221219/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/if_re.ko...Reading symbols from /boot/FALLOUT.r221219/if_re.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_re.ko Reading symbols from /boot/kernel/aio.ko...Reading symbols from /boot/FALLOUT.r221219/aio.ko.symbols...done. done. Loaded symbols for /boot/kernel/aio.ko Reading symbols from /boot/kernel/nfsd.ko...Reading symbols from /boot/FALLOUT.r221219/nfsd.ko.symbols...done. done. Loaded symbols for /boot/kernel/nfsd.ko Reading symbols from /boot/kernel/nfscommon.ko...Reading symbols from /boot/FALLOUT.r221219/nfscommon.ko.symbols...done. done. Loaded symbols for /boot/kernel/nfscommon.ko Reading symbols from /boot/kernel/nfssvc.ko...Reading symbols from /boot/FALLOUT.r221219/nfssvc.ko.symbols...done. done. Loaded symbols for /boot/kernel/nfssvc.ko Reading symbols from /boot/kernel/krpc.ko...Reading symbols from /boot/FALLOUT.r221219/krpc.ko.symbols...done. done. Loaded symbols for /boot/kernel/krpc.ko Reading symbols from /boot/kernel/nfslock.ko...Reading symbols from /boot/FALLOUT.r221219/nfslock.ko.symbols...done. done. Loaded symbols for /boot/kernel/nfslock.ko Reading symbols from /boot/kernel/nfslockd.ko...Reading symbols from /boot/FALLOUT.r221219/nfslockd.ko.symbols...done. done. Loaded symbols for /boot/kernel/nfslockd.ko #0 doadump () at pcpu.h:224 224 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:224 #1 0xffffffff802a9e2c in db_fncall (dummy1=Variable "dummy1" is not available. ) at /usr/src/sys/ddb/db_command.c:548 #2 0xffffffff802aa161 in db_command (last_cmdp=0xffffffff808b67c0, cmd_table=Variable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #3 0xffffffff802aa3a9 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xffffffff802ac337 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 #5 0xffffffff803f2948 in kdb_trap (type=3, code=0, tf=0xffffff80000f27e0) at /usr/src/sys/kern/subr_kdb.c:533 #6 0xffffffff8055d375 in trap (frame=0xffffff80000f27e0) at /usr/src/sys/amd64/amd64/trap.c:590 #7 0xffffffff805484c3 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 #8 0xffffffff803f27af in kdb_enter (why=0xffffffff805daeaf "panic", msg=0xa
) at cpufunc.h:63 #9 0xffffffff803bf76f in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:584 #10 0xffffffff80417673 in ttyinq_line_iterate (ti=Variable "ti" is not available. ) at /usr/src/sys/kern/tty_inq.c:459 #11 0xffffffff8041ac4a in ttydisc_rint (tp=0xfffffe00086a6c00, c=18 '\022', flags=Variable "flags" is not available. ) at /usr/src/sys/kern/tty_ttydisc.c:987 #12 0xffffffff8030ee18 in sckbdevent (thiskbd=0xfffffe0002b86a00, event=Variable "event" is not available. ) at /usr/src/sys/dev/syscons/syscons.c:744 #13 0xffffffff802e1711 in kbdmux_intr (kbd=0xfffffe0002b86a00, arg=Variable "arg" is not available. ) at /usr/src/sys/dev/kbdmux/kbdmux.c:549 #14 0xffffffff802e1c76 in kbdmux_kbd_intr (xkbd=Variable "xkbd" is not available. ) at /usr/src/sys/dev/kbdmux/kbdmux.c:208 #15 0xffffffff803fedac in taskqueue_run_locked (queue=0xfffffe0002c25380) at /usr/src/sys/kern/subr_taskqueue.c:306 #16 0xffffffff803feee9 in taskqueue_run (queue=0xfffffe0002c25380) at /usr/src/sys/kern/subr_taskqueue.c:320 #17 0xffffffff80398bd6 in intr_event_execute_handlers (p=Variable "p" is not available. ) at /usr/src/sys/kern/kern_intr.c:1257 #18 0xffffffff803999b7 in ithread_loop (arg=0xfffffe0002b58300) at /usr/src/sys/kern/kern_intr.c:1270 #19 0xffffffff80396252 in fork_exit ( callout=0xffffffff80399908 , arg=0xfffffe0002b58300, frame=0xffffff80000f2c50) at /usr/src/sys/kern/kern_fork.c:920 #20 0xffffffff805489ee in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:603 #21 0x0000000000000000 in ?? () #22 0x0000000000000000 in ?? () #23 0x0000000000000001 in ?? () #24 0x0000000000000000 in ?? () #25 0x0000000000000000 in ?? () #26 0x0000000000000000 in ?? () #27 0x0000000000000000 in ?? () #28 0x0000000000000000 in ?? () #29 0x0000000000000000 in ?? () #30 0x0000000000000000 in ?? () #31 0x0000000000000000 in ?? () #32 0x0000000000000000 in ?? () #33 0x0000000000000000 in ?? () #34 0x0000000000000000 in ?? () #35 0x0000000000000000 in ?? () #36 0x0000000000000000 in ?? () #37 0x0000000000000000 in ?? () #38 0x0000000000000000 in ?? () #39 0x0000000000000000 in ?? () #40 0x0000000000000000 in ?? () #41 0x0000000000000000 in ?? () #42 0x0000000000000000 in ?? () #43 0x0000000000000000 in ?? () #44 0x0000000000000000 in ?? () #45 0xfffffe0002c29ce8 in ?? () #46 0x0000000000000000 in ?? () #47 0x0000000000000000 in ?? () #48 0xfffffe0002b6a460 in ?? () #49 0xffffff80000f2b40 in ?? () #50 0xffffff80000f2ae8 in ?? () #51 0xfffffe0002c298c0 in ?? () #52 0xffffffff803e6e6d in sched_switch (td=0xfffffe0002b58300, newtd=0xffffffff80399908, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/sched_ule.c:1848 Previous frame inner to this frame (corrupt stack?) (kgdb) ... iostat iostat: kvm_read(_tk_nin): invalid address (0x0) iostat: disabling TTY statistics From owner-freebsd-current@FreeBSD.ORG Sat May 7 19:16:32 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 590331065672; Sat, 7 May 2011 19:16:32 +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 CFBDD8FC08; Sat, 7 May 2011 19:16:31 +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 p47JGQ3N088554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 May 2011 22:16:26 +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 p47JGQ39004553; Sat, 7 May 2011 22:16:26 +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 p47JGQUN004552; Sat, 7 May 2011 22:16:26 +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: Sat, 7 May 2011 22:16:25 +0300 From: Kostik Belousov To: John Baldwin Message-ID: <20110507191625.GQ48734@deviant.kiev.zoral.com.ua> References: <4DC3B764.4030801@FreeBSD.org> <4DC3F9B8.3030505@FreeBSD.org> <20110506140428.GF48734@deviant.kiev.zoral.com.ua> <201105061616.41145.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HevQWRStXZ0Cpw2M" Content-Disposition: inline In-Reply-To: <201105061616.41145.jhb@freebsd.org> 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.6 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: multimedia@freebsd.org, freebsd-current@freebsd.org, current@freebsd.org, Andriy Gapon Subject: Re: dsp mmap change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 19:16:32 -0000 --HevQWRStXZ0Cpw2M Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 06, 2011 at 04:16:40PM -0400, John Baldwin wrote: > On Friday, May 06, 2011 10:04:28 am Kostik Belousov wrote: > > On Fri, May 06, 2011 at 04:38:00PM +0300, Andriy Gapon wrote: > > > on 06/05/2011 16:32 Kostik Belousov said the following: > > > > On Fri, May 06, 2011 at 11:55:00AM +0300, Andriy Gapon wrote: > > > >> > > > >> I would like to ask for a review and/or testing of the following p= atch: > > > >> http://people.freebsd.org/~avg/dev_dsp_mmap.diff > > > >> > > > >> It's supposed to fix an issue described here: > > > >> http://lists.freebsd.org/pipermail/freebsd-multimedia/2011- > February/011691.html > > > >> > > > >> In short, the following pseudo-code should do the right thing: > > > >> fd =3D open(/dev/dsp, O_RDWR); > > > >> mmap(PROT_READ, fd); > > > >> mmap(PROT_WRITE, fd); > > > >> > > > >> Thank you! > > > >=20 > > > > I think that you have to call PCM_GIANT_LEAVE() when returning > > > > EINVAL on the vm_pager_alloc() failure. > > >=20 > > > Yes, thank you. > > >=20 > > > > Your patch hardcodes an assumption that sndbufs are always > > > > contiguous. I was unable to convince myself that this is true. > > >=20 > > > I think that this should be true for the case when DMA is used? > > In the current driver, yes, but there is nothing that theoretically > > prevents scatter-gather from be used. >=20 > You could "fix" this by creating an sglist (via sglist_build()) and an > OBJT_SG VM object that the d_mmap_single callback returned. I wish there > was a cleaner way to just create a VM object and populate it with pages > though, and then use vm_map_insert() to map it into the kernel rather > than the more roundabout method of OBJT_SG. You cannot have one page inserted into two vm objects. Contigmalloc() inserts the allocated pages into kernel_object. --HevQWRStXZ0Cpw2M Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk3FmokACgkQC3+MBN1Mb4iDLwCgps2E+M4fO+/UnaXayuKxu/z5 WbkAn3TzyN2mZ0VfdXxLQuCfM0ozqtbo =xWwZ -----END PGP SIGNATURE----- --HevQWRStXZ0Cpw2M-- From owner-freebsd-current@FreeBSD.ORG Sat May 7 19:16:32 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 590331065672; Sat, 7 May 2011 19:16:32 +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 CFBDD8FC08; Sat, 7 May 2011 19:16:31 +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 p47JGQ3N088554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 May 2011 22:16:26 +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 p47JGQ39004553; Sat, 7 May 2011 22:16:26 +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 p47JGQUN004552; Sat, 7 May 2011 22:16:26 +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: Sat, 7 May 2011 22:16:25 +0300 From: Kostik Belousov To: John Baldwin Message-ID: <20110507191625.GQ48734@deviant.kiev.zoral.com.ua> References: <4DC3B764.4030801@FreeBSD.org> <4DC3F9B8.3030505@FreeBSD.org> <20110506140428.GF48734@deviant.kiev.zoral.com.ua> <201105061616.41145.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HevQWRStXZ0Cpw2M" Content-Disposition: inline In-Reply-To: <201105061616.41145.jhb@freebsd.org> 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.6 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: multimedia@freebsd.org, freebsd-current@freebsd.org, current@freebsd.org, Andriy Gapon Subject: Re: dsp mmap change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 19:16:32 -0000 --HevQWRStXZ0Cpw2M Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 06, 2011 at 04:16:40PM -0400, John Baldwin wrote: > On Friday, May 06, 2011 10:04:28 am Kostik Belousov wrote: > > On Fri, May 06, 2011 at 04:38:00PM +0300, Andriy Gapon wrote: > > > on 06/05/2011 16:32 Kostik Belousov said the following: > > > > On Fri, May 06, 2011 at 11:55:00AM +0300, Andriy Gapon wrote: > > > >> > > > >> I would like to ask for a review and/or testing of the following p= atch: > > > >> http://people.freebsd.org/~avg/dev_dsp_mmap.diff > > > >> > > > >> It's supposed to fix an issue described here: > > > >> http://lists.freebsd.org/pipermail/freebsd-multimedia/2011- > February/011691.html > > > >> > > > >> In short, the following pseudo-code should do the right thing: > > > >> fd =3D open(/dev/dsp, O_RDWR); > > > >> mmap(PROT_READ, fd); > > > >> mmap(PROT_WRITE, fd); > > > >> > > > >> Thank you! > > > >=20 > > > > I think that you have to call PCM_GIANT_LEAVE() when returning > > > > EINVAL on the vm_pager_alloc() failure. > > >=20 > > > Yes, thank you. > > >=20 > > > > Your patch hardcodes an assumption that sndbufs are always > > > > contiguous. I was unable to convince myself that this is true. > > >=20 > > > I think that this should be true for the case when DMA is used? > > In the current driver, yes, but there is nothing that theoretically > > prevents scatter-gather from be used. >=20 > You could "fix" this by creating an sglist (via sglist_build()) and an > OBJT_SG VM object that the d_mmap_single callback returned. I wish there > was a cleaner way to just create a VM object and populate it with pages > though, and then use vm_map_insert() to map it into the kernel rather > than the more roundabout method of OBJT_SG. You cannot have one page inserted into two vm objects. Contigmalloc() inserts the allocated pages into kernel_object. --HevQWRStXZ0Cpw2M Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk3FmokACgkQC3+MBN1Mb4iDLwCgps2E+M4fO+/UnaXayuKxu/z5 WbkAn3TzyN2mZ0VfdXxLQuCfM0ozqtbo =xWwZ -----END PGP SIGNATURE----- --HevQWRStXZ0Cpw2M-- From owner-freebsd-current@FreeBSD.ORG Sat May 7 20:22:08 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BEBB106566B; Sat, 7 May 2011 20:22:08 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 3015D8FC12; Sat, 7 May 2011 20:22:08 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 7F80A3F7C6; Sat, 7 May 2011 22:22:06 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: <20110507104748.GL48734@deviant.kiev.zoral.com.ua> Date: Sat, 7 May 2011 22:22:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DC517B3.8050502@FreeBSD.org> <20110507104748.GL48734@deviant.kiev.zoral.com.ua> To: Kostik Belousov X-Mailer: Apple Mail (2.1084) Cc: current@freebsd.org, Andriy Gapon Subject: Re: bitcount32: replace lengthy comment with SWAR reference X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 20:22:08 -0000 Am 07.05.2011 um 12:47 schrieb Kostik Belousov: > On Sat, May 07, 2011 at 12:58:11PM +0300, Andriy Gapon wrote: >>=20 >> I think that the SWAR reference should be more concise and should = lead an >> interested reader to more information on the topic (and more = up-to-date as well). >>=20 > SWAR acronim seems to be a wikipedia invention. Without the = abbreviation, > the trimmed down comment looks better, IMHO. How about a proper reference, for example Warren's Hackers Delight (p. = 65)? Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Sat May 7 20:59:22 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B62F1065674 for ; Sat, 7 May 2011 20:59:22 +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 A0ABE8FC1A for ; Sat, 7 May 2011 20:59:21 +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 XAA10699; Sat, 07 May 2011 23:59:17 +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 1QIoar-0004Xw-K3; Sat, 07 May 2011 23:59:17 +0300 Message-ID: <4DC5B2A4.60603@FreeBSD.org> Date: Sat, 07 May 2011 23:59:16 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Stefan Bethke References: <4DC517B3.8050502@FreeBSD.org> <20110507104748.GL48734@deviant.kiev.zoral.com.ua> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , current@FreeBSD.org Subject: Re: bitcount32: replace lengthy comment with SWAR reference X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 20:59:22 -0000 on 07/05/2011 23:22 Stefan Bethke said the following: > > Am 07.05.2011 um 12:47 schrieb Kostik Belousov: > >> On Sat, May 07, 2011 at 12:58:11PM +0300, Andriy Gapon wrote: >>> >>> I think that the SWAR reference should be more concise and should lead an >>> interested reader to more information on the topic (and more up-to-date as well). >>> >> SWAR acronim seems to be a wikipedia invention. Without the abbreviation, >> the trimmed down comment looks better, IMHO. > > How about a proper reference, for example Warren's Hackers Delight (p. 65)? Hm, what makes that reference proper or more (most) proper? My top google results for SWAR seem to point to materials created by inventors of the algorithm. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat May 7 21:19:17 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F553106566C; Sat, 7 May 2011 21:19:17 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 345B68FC13; Sat, 7 May 2011 21:19:17 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 0620C4101F; Sat, 7 May 2011 23:19:15 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: <4DC5B2A4.60603@FreeBSD.org> Date: Sat, 7 May 2011 23:19:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4A9DD4AC-94CF-4AA5-AB17-8597CB6EB394@lassitu.de> References: <4DC517B3.8050502@FreeBSD.org> <20110507104748.GL48734@deviant.kiev.zoral.com.ua> <4DC5B2A4.60603@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1084) Cc: Kostik Belousov , current@FreeBSD.org Subject: Re: bitcount32: replace lengthy comment with SWAR reference X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 21:19:17 -0000 Am 07.05.2011 um 22:59 schrieb Andriy Gapon: > on 07/05/2011 23:22 Stefan Bethke said the following: >>=20 >> Am 07.05.2011 um 12:47 schrieb Kostik Belousov: >>=20 >>> On Sat, May 07, 2011 at 12:58:11PM +0300, Andriy Gapon wrote: >>>>=20 >>>> I think that the SWAR reference should be more concise and should = lead an >>>> interested reader to more information on the topic (and more = up-to-date as well). >>>>=20 >>> SWAR acronim seems to be a wikipedia invention. Without the = abbreviation, >>> the trimmed down comment looks better, IMHO. >>=20 >> How about a proper reference, for example Warren's Hackers Delight = (p. 65)? >=20 > Hm, what makes that reference proper or more (most) proper? > My top google results for SWAR seem to point to materials created by = inventors > of the algorithm. Your google-fu is clearly superior. It took me a couple tries to find = the page you're refering to. http://aggregate.org/MAGIC/#Population%20Count%20%28Ones%20Count%29 Why not put a link in there directly? I just prefer a reference I can = actually look up over an acronym that (by itself) cannot easily be = resolved. The algorithm itself seems to predate SWAR significantly: according to = Hackers Delight, it was described in /Combinatorial Algorithms: Theory = and Pratice/ in 77. The code in systm.h appears to be a slightly less optimized version of = the algorithm presented in SWAR or Hacker's Delight. Stefan=20 --=20 Stefan Bethke Fon +49 151 14070811