From owner-freebsd-current@FreeBSD.ORG Sun Aug 25 00:24:43 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5D683B04; Sun, 25 Aug 2013 00:24:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 231632CB1; Sun, 25 Aug 2013 00:24:42 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r7P0OfKW009914; Sat, 24 Aug 2013 20:24:41 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r7P0OfFO009911; Sun, 25 Aug 2013 00:24:41 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 25 Aug 2013 00:24:41 GMT Message-Id: <201308250024.r7P0OfFO009911@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 , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 00:24:43 -0000 TB --- 2013-08-24 23:04:44 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-24 23:04:44 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-08-24 23:04:44 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-08-24 23:04:45 - cleaning the object tree TB --- 2013-08-24 23:04:45 - /usr/local/bin/svn stat /src TB --- 2013-08-24 23:04:48 - At svn revision 254801 TB --- 2013-08-24 23:04:49 - building world TB --- 2013-08-24 23:04:49 - CROSS_BUILD_TESTING=YES TB --- 2013-08-24 23:04:49 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-24 23:04:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-24 23:04:49 - SRCCONF=/dev/null TB --- 2013-08-24 23:04:49 - TARGET=sparc64 TB --- 2013-08-24 23:04:49 - TARGET_ARCH=sparc64 TB --- 2013-08-24 23:04:49 - TZ=UTC TB --- 2013-08-24 23:04:49 - __MAKE_CONF=/dev/null TB --- 2013-08-24 23:04:49 - cd /src TB --- 2013-08-24 23:04:49 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Aug 24 23:04:56 UTC 2013 >>> 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 Aug 25 00:14:56 UTC 2013 TB --- 2013-08-25 00:14:56 - generating LINT kernel config TB --- 2013-08-25 00:14:56 - cd /src/sys/sparc64/conf TB --- 2013-08-25 00:14:56 - /usr/bin/make -B LINT TB --- 2013-08-25 00:14:56 - cd /src/sys/sparc64/conf TB --- 2013-08-25 00:14:56 - /usr/sbin/config -m LINT TB --- 2013-08-25 00:14:56 - building LINT kernel TB --- 2013-08-25 00:14:56 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 00:14:56 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 00:14:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 00:14:56 - SRCCONF=/dev/null TB --- 2013-08-25 00:14:56 - TARGET=sparc64 TB --- 2013-08-25 00:14:56 - TARGET_ARCH=sparc64 TB --- 2013-08-25 00:14:56 - TZ=UTC TB --- 2013-08-25 00:14:56 - __MAKE_CONF=/dev/null TB --- 2013-08-25 00:14:56 - cd /src TB --- 2013-08-25 00:14:56 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Aug 25 00:14:56 UTC 2013 >>> 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 -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/vxge/vxgehal/vxgehal-virtualpath.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 -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/vxge/vxgehal/vxgehal-channel.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 -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/vxge/vxgehal/vxgehal-fifo.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 -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/watchdog/watchdog.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 -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/wb/if_wb.c cc1: warnings being treated as errors /src/sys/dev/wb/if_wb.c: In function 'wb_newbuf': /src/sys/dev/wb/if_wb.c:850: warning: passing argument 4 of 'm_extadd' from incompatible pointer type *** Error code 1 Stop. bmake[1]: stopped in /obj/sparc64.sparc64/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-25 00:24:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-25 00:24:41 - ERROR: failed to build LINT kernel TB --- 2013-08-25 00:24:41 - 3684.96 user 684.16 system 4796.83 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sun Aug 25 00:33:34 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 75B11D35; Sun, 25 Aug 2013 00:33:34 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 498DD2D21; Sun, 25 Aug 2013 00:33:34 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r7P0XXVH032494; Sat, 24 Aug 2013 20:33:33 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r7P0XXI1032492; Sun, 25 Aug 2013 00:33:33 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 25 Aug 2013 00:33:33 GMT Message-Id: <201308250033.r7P0XXI1032492@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 , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 00:33:34 -0000 TB --- 2013-08-24 21:04:52 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-24 21:04:52 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-08-24 21:04:52 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-08-24 21:04:52 - cleaning the object tree TB --- 2013-08-24 21:04:52 - /usr/local/bin/svn stat /src TB --- 2013-08-24 21:05:02 - At svn revision 254801 TB --- 2013-08-24 21:05:03 - building world TB --- 2013-08-24 21:05:03 - CROSS_BUILD_TESTING=YES TB --- 2013-08-24 21:05:03 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-24 21:05:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-24 21:05:03 - SRCCONF=/dev/null TB --- 2013-08-24 21:05:03 - TARGET=pc98 TB --- 2013-08-24 21:05:03 - TARGET_ARCH=i386 TB --- 2013-08-24 21:05:03 - TZ=UTC TB --- 2013-08-24 21:05:03 - __MAKE_CONF=/dev/null TB --- 2013-08-24 21:05:03 - cd /src TB --- 2013-08-24 21:05:03 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Aug 24 21:05:11 UTC 2013 >>> 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 Aug 25 00:22:27 UTC 2013 TB --- 2013-08-25 00:22:27 - generating LINT kernel config TB --- 2013-08-25 00:22:27 - cd /src/sys/pc98/conf TB --- 2013-08-25 00:22:27 - /usr/bin/make -B LINT TB --- 2013-08-25 00:22:27 - cd /src/sys/pc98/conf TB --- 2013-08-25 00:22:27 - /usr/sbin/config -m LINT TB --- 2013-08-25 00:22:27 - building LINT kernel TB --- 2013-08-25 00:22:27 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 00:22:27 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 00:22:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 00:22:27 - SRCCONF=/dev/null TB --- 2013-08-25 00:22:27 - TARGET=pc98 TB --- 2013-08-25 00:22:27 - TARGET_ARCH=i386 TB --- 2013-08-25 00:22:27 - TZ=UTC TB --- 2013-08-25 00:22:27 - __MAKE_CONF=/dev/null TB --- 2013-08-25 00:22:27 - cd /src TB --- 2013-08-25 00:22:27 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Aug 25 00:22:27 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /src/sys/sys/mbuf.h:687:50: note: expanded from macro 'MEXTADD' (void )m_extadd((m), (caddr_t)(buf), (size), (free), (arg1), (arg2),\ ^~~~~~ /src/sys/sys/mbuf.h:825:14: note: passing argument to parameter here void (*)(struct mbuf *, void *, void *), void *, void *, ^ 1 error generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/pc98.i386/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-25 00:33:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-25 00:33:33 - ERROR: failed to build LINT kernel TB --- 2013-08-25 00:33:33 - 10190.46 user 1483.54 system 12521.05 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sun Aug 25 01:13:47 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0326F2AB; Sun, 25 Aug 2013 01:13:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BEB0E2EAF; Sun, 25 Aug 2013 01:13:46 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r7P1DjYC043143; Sat, 24 Aug 2013 21:13:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r7P1DjhA043142; Sun, 25 Aug 2013 01:13:45 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 25 Aug 2013 01:13:45 GMT Message-Id: <201308250113.r7P1DjhA043142@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 , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 01:13:47 -0000 TB --- 2013-08-24 22:29:46 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-24 22:29:46 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-08-24 22:29:46 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-08-24 22:29:46 - cleaning the object tree TB --- 2013-08-24 22:31:03 - /usr/local/bin/svn stat /src TB --- 2013-08-24 22:31:28 - At svn revision 254801 TB --- 2013-08-24 22:31:29 - building world TB --- 2013-08-24 22:31:29 - CROSS_BUILD_TESTING=YES TB --- 2013-08-24 22:31:29 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-24 22:31:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-24 22:31:29 - SRCCONF=/dev/null TB --- 2013-08-24 22:31:29 - TARGET=powerpc TB --- 2013-08-24 22:31:29 - TARGET_ARCH=powerpc TB --- 2013-08-24 22:31:29 - TZ=UTC TB --- 2013-08-24 22:31:29 - __MAKE_CONF=/dev/null TB --- 2013-08-24 22:31:29 - cd /src TB --- 2013-08-24 22:31:29 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Aug 24 22:31:36 UTC 2013 >>> 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 Aug 25 01:07:34 UTC 2013 TB --- 2013-08-25 01:07:34 - generating LINT kernel config TB --- 2013-08-25 01:07:34 - cd /src/sys/powerpc/conf TB --- 2013-08-25 01:07:34 - /usr/bin/make -B LINT TB --- 2013-08-25 01:07:34 - cd /src/sys/powerpc/conf TB --- 2013-08-25 01:07:34 - /usr/sbin/config -m LINT TB --- 2013-08-25 01:07:34 - building LINT kernel TB --- 2013-08-25 01:07:34 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 01:07:34 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 01:07:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 01:07:34 - SRCCONF=/dev/null TB --- 2013-08-25 01:07:34 - TARGET=powerpc TB --- 2013-08-25 01:07:34 - TARGET_ARCH=powerpc TB --- 2013-08-25 01:07:34 - TZ=UTC TB --- 2013-08-25 01:07:34 - __MAKE_CONF=/dev/null TB --- 2013-08-25 01:07:34 - cd /src TB --- 2013-08-25 01:07:34 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Aug 25 01:07:34 UTC 2013 >>> 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 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/vxge/vxgehal/vxgehal-virtualpath.c cc -c -O -pipe -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 -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/vxge/vxgehal/vxgehal-channel.c cc -c -O -pipe -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 -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/vxge/vxgehal/vxgehal-fifo.c cc -c -O -pipe -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 -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/watchdog/watchdog.c cc -c -O -pipe -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 -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/wb/if_wb.c cc1: warnings being treated as errors /src/sys/dev/wb/if_wb.c: In function 'wb_newbuf': /src/sys/dev/wb/if_wb.c:850: warning: passing argument 4 of 'm_extadd' from incompatible pointer type *** Error code 1 Stop. bmake[1]: stopped in /obj/powerpc.powerpc/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-25 01:13:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-25 01:13:45 - ERROR: failed to build LINT kernel TB --- 2013-08-25 01:13:45 - 8365.43 user 1081.03 system 9839.75 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Aug 25 02:25:05 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 49460CCF; Sun, 25 Aug 2013 02:25:05 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 113592183; Sun, 25 Aug 2013 02:25:04 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r7P2P3B4067171; Sat, 24 Aug 2013 22:25:03 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r7P2P3ND067170; Sun, 25 Aug 2013 02:25:03 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 25 Aug 2013 02:25:03 GMT Message-Id: <201308250225.r7P2P3ND067170@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 , , Subject: [head tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 02:25:05 -0000 TB --- 2013-08-24 23:04:23 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-24 23:04:23 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-08-24 23:04:23 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-08-24 23:04:24 - cleaning the object tree TB --- 2013-08-24 23:04:24 - /usr/local/bin/svn stat /src TB --- 2013-08-24 23:04:27 - At svn revision 254801 TB --- 2013-08-24 23:04:28 - building world TB --- 2013-08-24 23:04:28 - CROSS_BUILD_TESTING=YES TB --- 2013-08-24 23:04:28 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-24 23:04:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-24 23:04:28 - SRCCONF=/dev/null TB --- 2013-08-24 23:04:28 - TARGET=powerpc TB --- 2013-08-24 23:04:28 - TARGET_ARCH=powerpc64 TB --- 2013-08-24 23:04:28 - TZ=UTC TB --- 2013-08-24 23:04:28 - __MAKE_CONF=/dev/null TB --- 2013-08-24 23:04:28 - cd /src TB --- 2013-08-24 23:04:28 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Aug 24 23:04:35 UTC 2013 >>> 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 Aug 25 02:07:18 UTC 2013 TB --- 2013-08-25 02:07:18 - generating LINT kernel config TB --- 2013-08-25 02:07:18 - cd /src/sys/powerpc/conf TB --- 2013-08-25 02:07:18 - /usr/bin/make -B LINT TB --- 2013-08-25 02:07:18 - cd /src/sys/powerpc/conf TB --- 2013-08-25 02:07:18 - /usr/sbin/config -m LINT TB --- 2013-08-25 02:07:18 - skipping LINT kernel TB --- 2013-08-25 02:07:18 - cd /src/sys/powerpc/conf TB --- 2013-08-25 02:07:18 - /usr/sbin/config -m GENERIC TB --- 2013-08-25 02:07:18 - skipping GENERIC kernel TB --- 2013-08-25 02:07:18 - cd /src/sys/powerpc/conf TB --- 2013-08-25 02:07:18 - /usr/sbin/config -m GENERIC64 TB --- 2013-08-25 02:07:18 - building GENERIC64 kernel TB --- 2013-08-25 02:07:18 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 02:07:18 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 02:07:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 02:07:18 - SRCCONF=/dev/null TB --- 2013-08-25 02:07:18 - TARGET=powerpc TB --- 2013-08-25 02:07:18 - TARGET_ARCH=powerpc64 TB --- 2013-08-25 02:07:18 - TZ=UTC TB --- 2013-08-25 02:07:18 - __MAKE_CONF=/dev/null TB --- 2013-08-25 02:07:18 - cd /src TB --- 2013-08-25 02:07:18 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64 >>> Kernel build for GENERIC64 started on Sun Aug 25 02:07:18 UTC 2013 >>> 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 -Bshareable -d -warn-common -o if_vx.ko.debug if_vx.kld objcopy --only-keep-debug if_vx.ko.debug if_vx.ko.symbols objcopy --strip-debug --add-gnu-debuglink=if_vx.ko.symbols if_vx.ko.debug if_vx.ko ===> wb (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/wb/../../dev/wb/if_wb.c cc1: warnings being treated as errors /src/sys/modules/wb/../../dev/wb/if_wb.c: In function 'wb_newbuf': /src/sys/modules/wb/../../dev/wb/if_wb.c:850: warning: passing argument 4 of 'm_extadd' from incompatible pointer type *** Error code 1 Stop. bmake[3]: stopped in /src/sys/modules/wb *** Error code 1 Stop. bmake[2]: stopped in /src/sys/modules *** Error code 1 Stop. bmake[1]: stopped in /obj/powerpc.powerpc64/src/sys/GENERIC64 *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-25 02:25:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-25 02:25:03 - ERROR: failed to build GENERIC64 kernel TB --- 2013-08-25 02:25:03 - 10641.75 user 1321.07 system 12039.91 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Aug 25 02:48:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9B878EC1 for ; Sun, 25 Aug 2013 02:48:22 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 495352224 for ; Sun, 25 Aug 2013 02:48:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:References:Message-ID:In-Reply-To:Subject:To:Sender:From:Date; bh=hbwjWe3KA+YT/8tdEBT6UAi5wWBosBD6jMWfk0PnilI=; b=nZOXSq0Yu+xuFEyNPz3RAVYzHFy3ldTnmbQc0/vFfkl9vv8eLnDtX6HyK4yTCbUTbJWjtgcsQa4HM3L1Lm6dWdrH2te0Nm6Pifaels3NBnA9iztxGm++TCfXapjJ8kSjut9auESdwBSZl/epFzHk1DFkwKKci8fSdivf9icFy7o=; Received: from cpe-72-182-93-216.austin.res.rr.com ([72.182.93.216]:23628 helo=borg) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VDQNF-000GEV-Il for freebsd-current@freebsd.org; Sat, 24 Aug 2013 21:48:20 -0500 Date: Sat, 24 Aug 2013 21:48:14 -0500 (CDT) From: Larry Rosenman Sender: ler@borg To: freebsd-current@freebsd.org Subject: Re: 2 crashes.... (today's -CURRENT) In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Aug 2013 02:48:22 -0000 And another: borg.lerctr.org dumped core - see /var/crash/vmcore.2 Sat Aug 24 20:29:48 CDT 2013 FreeBSD borg.lerctr.org 10.0-CURRENT FreeBSD 10.0-CURRENT #32 r254807: Sat Aug 24 16:52:42 CDT 2013 root@borg.lerctr.org:/usr/obj/usr/src/sys/BORG-DTRACE amd64 panic: sorele GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: panic: sorele cpuid = 6 Uptime: 2h44m44s Dumping 3107 out of 64480 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel/zfs.ko.symbols...done. Loaded symbols for /boot/kernel/zfs.ko.symbols Reading symbols from /boot/kernel/acl_nfs4.ko.symbols...done. Loaded symbols for /boot/kernel/acl_nfs4.ko.symbols Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. Loaded symbols for /boot/kernel/opensolaris.ko.symbols Reading symbols from /boot/kernel/linux.ko.symbols...done. Loaded symbols for /boot/kernel/linux.ko.symbols Reading symbols from /boot/kernel/snd_envy24ht.ko.symbols...done. Loaded symbols for /boot/kernel/snd_envy24ht.ko.symbols Reading symbols from /boot/kernel/snd_spicds.ko.symbols...done. Loaded symbols for /boot/kernel/snd_spicds.ko.symbols Reading symbols from /boot/kernel/sound.ko.symbols...done. Loaded symbols for /boot/kernel/sound.ko.symbols Reading symbols from /boot/kernel/snd_hda.ko.symbols...done. Loaded symbols for /boot/kernel/snd_hda.ko.symbols Reading symbols from /boot/kernel/coretemp.ko.symbols...done. Loaded symbols for /boot/kernel/coretemp.ko.symbols Reading symbols from /boot/kernel/ichsmb.ko.symbols...done. Loaded symbols for /boot/kernel/ichsmb.ko.symbols Reading symbols from /boot/kernel/smbus.ko.symbols...done. Loaded symbols for /boot/kernel/smbus.ko.symbols Reading symbols from /boot/kernel/ichwd.ko.symbols...done. Loaded symbols for /boot/kernel/ichwd.ko.symbols Reading symbols from /boot/kernel/cpuctl.ko.symbols...done. Loaded symbols for /boot/kernel/cpuctl.ko.symbols Reading symbols from /boot/kernel/crypto.ko.symbols...done. Loaded symbols for /boot/kernel/crypto.ko.symbols Reading symbols from /boot/kernel/cryptodev.ko.symbols...done. Loaded symbols for /boot/kernel/cryptodev.ko.symbols Reading symbols from /boot/kernel/dtraceall.ko.symbols...done. Loaded symbols for /boot/kernel/dtraceall.ko.symbols Reading symbols from /boot/kernel/profile.ko.symbols...done. Loaded symbols for /boot/kernel/profile.ko.symbols Reading symbols from /boot/kernel/cyclic.ko.symbols...done. Loaded symbols for /boot/kernel/cyclic.ko.symbols Reading symbols from /boot/kernel/dtrace.ko.symbols...done. Loaded symbols for /boot/kernel/dtrace.ko.symbols Reading symbols from /boot/kernel/systrace_freebsd32.ko.symbols...done. Loaded symbols for /boot/kernel/systrace_freebsd32.ko.symbols Reading symbols from /boot/kernel/systrace.ko.symbols...done. Loaded symbols for /boot/kernel/systrace.ko.symbols Reading symbols from /boot/kernel/sdt.ko.symbols...done. Loaded symbols for /boot/kernel/sdt.ko.symbols Reading symbols from /boot/kernel/lockstat.ko.symbols...done. Loaded symbols for /boot/kernel/lockstat.ko.symbols Reading symbols from /boot/kernel/fasttrap.ko.symbols...done. Loaded symbols for /boot/kernel/fasttrap.ko.symbols Reading symbols from /boot/kernel/fbt.ko.symbols...done. Loaded symbols for /boot/kernel/fbt.ko.symbols Reading symbols from /boot/kernel/dtnfscl.ko.symbols...done. Loaded symbols for /boot/kernel/dtnfscl.ko.symbols Reading symbols from /boot/kernel/dtmalloc.ko.symbols...done. Loaded symbols for /boot/kernel/dtmalloc.ko.symbols Reading symbols from /boot/kernel/dtio.ko.symbols...done. Loaded symbols for /boot/kernel/dtio.ko.symbols Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. Loaded symbols for /boot/kernel/fdescfs.ko.symbols Reading symbols from /boot/kernel/uhid.ko.symbols...done. Loaded symbols for /boot/kernel/uhid.ko.symbols Reading symbols from /boot/kernel/ums.ko.symbols...done. Loaded symbols for /boot/kernel/ums.ko.symbols #0 doadump (textdump=) at pcpu.h:236 236 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=) at pcpu.h:236 #1 0xffffffff80523aa0 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0xffffffff80523e27 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:754 #3 0xffffffff80593222 in soclose (so=) at /usr/src/sys/kern/uipc_socket.c:853 #4 0xffffffff804dd689 in _fdrop (fp=0xfffff800200a6190, td=0x0) at file.h:341 #5 0xffffffff804dffa7 in closef (fp=, td=) at /usr/src/sys/kern/kern_descrip.c:2268 #6 0xffffffff804ddae5 in closefp (fdp=0xfffff800200d7800, fd=, fp=0xfffff800200a6190, td=0xfffff80020898000, holdleaders=) at /usr/src/sys/kern/kern_descrip.c:1140 #7 0xffffffff80789f27 in amd64_syscall (td=0xfffff80020898000, traced=0) at subr_syscall.c:134 #8 0xffffffff8077350b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 #9 0x000000000044f75a in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) On Sat, 24 Aug 2013, Larry Rosenman wrote: > Both full core.txt's are available at: > > http://www.lerctr.org/~ler/FreeBSD/ > > > borg.lerctr.org dumped core - see /var/crash/vmcore.0 > > Sat Aug 24 17:35:31 CDT 2013 > > FreeBSD borg.lerctr.org 10.0-CURRENT FreeBSD 10.0-CURRENT #32 r254807: Sat > Aug 24 16:52:42 CDT 2013 > root@borg.lerctr.org:/usr/obj/usr/src/sys/BORG-DTRACE amd64 > > panic: page fault > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = resume, IOPL = 0 > current process = 21 (racctd) > trap number = 12 > panic: page fault > cpuid = 3 > Uptime: 15m10s > Dumping 3216 out of 64480 > MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% > > Reading symbols from /boot/kernel/zfs.ko.symbols...done. > Loaded symbols for /boot/kernel/zfs.ko.symbols > Reading symbols from /boot/kernel/acl_nfs4.ko.symbols...done. > Loaded symbols for /boot/kernel/acl_nfs4.ko.symbols > Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. > Loaded symbols for /boot/kernel/opensolaris.ko.symbols > Reading symbols from /boot/kernel/linux.ko.symbols...done. > Loaded symbols for /boot/kernel/linux.ko.symbols > Reading symbols from /boot/kernel/snd_envy24ht.ko.symbols...done. > Loaded symbols for /boot/kernel/snd_envy24ht.ko.symbols > Reading symbols from /boot/kernel/snd_spicds.ko.symbols...done. > Loaded symbols for /boot/kernel/snd_spicds.ko.symbols > Reading symbols from /boot/kernel/sound.ko.symbols...done. > Loaded symbols for /boot/kernel/sound.ko.symbols > Reading symbols from /boot/kernel/snd_hda.ko.symbols...done. > Loaded symbols for /boot/kernel/snd_hda.ko.symbols > Reading symbols from /boot/kernel/coretemp.ko.symbols...done. > Loaded symbols for /boot/kernel/coretemp.ko.symbols > Reading symbols from /boot/kernel/ichsmb.ko.symbols...done. > Loaded symbols for /boot/kernel/ichsmb.ko.symbols > Reading symbols from /boot/kernel/smbus.ko.symbols...done. > Loaded symbols for /boot/kernel/smbus.ko.symbols > Reading symbols from /boot/kernel/ichwd.ko.symbols...done. > Loaded symbols for /boot/kernel/ichwd.ko.symbols > Reading symbols from /boot/kernel/cpuctl.ko.symbols...done. > Loaded symbols for /boot/kernel/cpuctl.ko.symbols > Reading symbols from /boot/kernel/crypto.ko.symbols...done. > Loaded symbols for /boot/kernel/crypto.ko.symbols > Reading symbols from /boot/kernel/cryptodev.ko.symbols...done. > Loaded symbols for /boot/kernel/cryptodev.ko.symbols > Reading symbols from /boot/kernel/dtraceall.ko.symbols...done. > Loaded symbols for /boot/kernel/dtraceall.ko.symbols > Reading symbols from /boot/kernel/profile.ko.symbols...done. > Loaded symbols for /boot/kernel/profile.ko.symbols > Reading symbols from /boot/kernel/cyclic.ko.symbols...done. > Loaded symbols for /boot/kernel/cyclic.ko.symbols > Reading symbols from /boot/kernel/dtrace.ko.symbols...done. > Loaded symbols for /boot/kernel/dtrace.ko.symbols > Reading symbols from /boot/kernel/systrace_freebsd32.ko.symbols...done. > Loaded symbols for /boot/kernel/systrace_freebsd32.ko.symbols > Reading symbols from /boot/kernel/systrace.ko.symbols...done. > Loaded symbols for /boot/kernel/systrace.ko.symbols > Reading symbols from /boot/kernel/sdt.ko.symbols...done. > Loaded symbols for /boot/kernel/sdt.ko.symbols > Reading symbols from /boot/kernel/lockstat.ko.symbols...done. > Loaded symbols for /boot/kernel/lockstat.ko.symbols > Reading symbols from /boot/kernel/fasttrap.ko.symbols...done. > Loaded symbols for /boot/kernel/fasttrap.ko.symbols > Reading symbols from /boot/kernel/fbt.ko.symbols...done. > Loaded symbols for /boot/kernel/fbt.ko.symbols > Reading symbols from /boot/kernel/dtnfscl.ko.symbols...done. > Loaded symbols for /boot/kernel/dtnfscl.ko.symbols > Reading symbols from /boot/kernel/dtmalloc.ko.symbols...done. > Loaded symbols for /boot/kernel/dtmalloc.ko.symbols > Reading symbols from /boot/kernel/dtio.ko.symbols...done. > Loaded symbols for /boot/kernel/dtio.ko.symbols > Reading symbols from /boot/modules/nvidia.ko...done. > Loaded symbols for /boot/modules/nvidia.ko > Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. > Loaded symbols for /boot/kernel/fdescfs.ko.symbols > Reading symbols from /boot/kernel/uhid.ko.symbols...done. > Loaded symbols for /boot/kernel/uhid.ko.symbols > Reading symbols from /boot/kernel/ums.ko.symbols...done. > Loaded symbols for /boot/kernel/ums.ko.symbols > #0 doadump (textdump=) at pcpu.h:236 > 236 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=) at pcpu.h:236 > #1 0xffffffff80523aa0 in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:447 > #2 0xffffffff80523e27 in panic (fmt=) > at /usr/src/sys/kern/kern_shutdown.c:754 > #3 0xffffffff8078962a in trap_fatal (frame=, > eva=) at /usr/src/sys/amd64/amd64/trap.c:873 > #4 0xffffffff80789a25 in trap_pfault (frame=0x0, usermode=0) > at /usr/src/sys/amd64/amd64/trap.c:731 > #5 0xffffffff80789022 in trap (frame=0xfffffe100d0f7a10) > at /usr/src/sys/amd64/amd64/trap.c:463 > #6 0xffffffff80773222 in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:232 > #7 0xffffffff8050c651 in thread_lock_flags_ (td=0xfffff80128283000, opts=0, > file=0xffffffff8087b9c8 "/usr/src/sys/kern/kern_resource.c", line=2) > at /usr/src/sys/kern/kern_mutex.c:637 > #8 0xffffffff8051fc63 in ruxagg (p=0xfffff801283694b8, > td=0xfffff80128283000) > at /usr/src/sys/kern/kern_resource.c:1063 > #9 0xffffffff8051a6fb in racctd () at /usr/src/sys/kern/kern_racct.c:1135 > #10 0xffffffff804f118a in fork_exit (callout=0xffffffff8051a400 , > arg=0x0, frame=0xfffffe100d0f7c00) at /usr/src/sys/kern/kern_fork.c:989 > #11 0xffffffff8077375e in fork_trampoline () > at /usr/src/sys/amd64/amd64/exception.S:606 > #12 0x0000000000000000 in ?? () > Current language: auto; currently minimal > (kgdb) > > > borg.lerctr.org dumped core - see /var/crash/vmcore.1 > > Sat Aug 24 17:42:01 CDT 2013 > > FreeBSD borg.lerctr.org 10.0-CURRENT FreeBSD 10.0-CURRENT #32 r254807: Sat > Aug 24 16:52:42 CDT 2013 > root@borg.lerctr.org:/usr/obj/usr/src/sys/BORG-DTRACE amd64 > > panic: page fault > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > current process = 9 (pagedaemon) > trap number = 12 > panic: page fault > cpuid = 1 > Uptime: 4m43s > Dumping 2638 out of 64480 > MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% > > Reading symbols from /boot/kernel/zfs.ko.symbols...done. > Loaded symbols for /boot/kernel/zfs.ko.symbols > Reading symbols from /boot/kernel/acl_nfs4.ko.symbols...done. > Loaded symbols for /boot/kernel/acl_nfs4.ko.symbols > Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. > Loaded symbols for /boot/kernel/opensolaris.ko.symbols > Reading symbols from /boot/kernel/linux.ko.symbols...done. > Loaded symbols for /boot/kernel/linux.ko.symbols > Reading symbols from /boot/kernel/snd_envy24ht.ko.symbols...done. > Loaded symbols for /boot/kernel/snd_envy24ht.ko.symbols > Reading symbols from /boot/kernel/snd_spicds.ko.symbols...done. > Loaded symbols for /boot/kernel/snd_spicds.ko.symbols > Reading symbols from /boot/kernel/sound.ko.symbols...done. > Loaded symbols for /boot/kernel/sound.ko.symbols > Reading symbols from /boot/kernel/snd_hda.ko.symbols...done. > Loaded symbols for /boot/kernel/snd_hda.ko.symbols > Reading symbols from /boot/kernel/coretemp.ko.symbols...done. > Loaded symbols for /boot/kernel/coretemp.ko.symbols > Reading symbols from /boot/kernel/ichsmb.ko.symbols...done. > Loaded symbols for /boot/kernel/ichsmb.ko.symbols > Reading symbols from /boot/kernel/smbus.ko.symbols...done. > Loaded symbols for /boot/kernel/smbus.ko.symbols > Reading symbols from /boot/kernel/ichwd.ko.symbols...done. > Loaded symbols for /boot/kernel/ichwd.ko.symbols > Reading symbols from /boot/kernel/cpuctl.ko.symbols...done. > Loaded symbols for /boot/kernel/cpuctl.ko.symbols > Reading symbols from /boot/kernel/crypto.ko.symbols...done. > Loaded symbols for /boot/kernel/crypto.ko.symbols > Reading symbols from /boot/kernel/cryptodev.ko.symbols...done. > Loaded symbols for /boot/kernel/cryptodev.ko.symbols > Reading symbols from /boot/kernel/dtraceall.ko.symbols...done. > Loaded symbols for /boot/kernel/dtraceall.ko.symbols > Reading symbols from /boot/kernel/profile.ko.symbols...done. > Loaded symbols for /boot/kernel/profile.ko.symbols > Reading symbols from /boot/kernel/cyclic.ko.symbols...done. > Loaded symbols for /boot/kernel/cyclic.ko.symbols > Reading symbols from /boot/kernel/dtrace.ko.symbols...done. > Loaded symbols for /boot/kernel/dtrace.ko.symbols > Reading symbols from /boot/kernel/systrace_freebsd32.ko.symbols...done. > Loaded symbols for /boot/kernel/systrace_freebsd32.ko.symbols > Reading symbols from /boot/kernel/systrace.ko.symbols...done. > Loaded symbols for /boot/kernel/systrace.ko.symbols > Reading symbols from /boot/kernel/sdt.ko.symbols...done. > Loaded symbols for /boot/kernel/sdt.ko.symbols > Reading symbols from /boot/kernel/lockstat.ko.symbols...done. > Loaded symbols for /boot/kernel/lockstat.ko.symbols > Reading symbols from /boot/kernel/fasttrap.ko.symbols...done. > Loaded symbols for /boot/kernel/fasttrap.ko.symbols > Reading symbols from /boot/kernel/fbt.ko.symbols...done. > Loaded symbols for /boot/kernel/fbt.ko.symbols > Reading symbols from /boot/kernel/dtnfscl.ko.symbols...done. > Loaded symbols for /boot/kernel/dtnfscl.ko.symbols > Reading symbols from /boot/kernel/dtmalloc.ko.symbols...done. > Loaded symbols for /boot/kernel/dtmalloc.ko.symbols > Reading symbols from /boot/kernel/dtio.ko.symbols...done. > Loaded symbols for /boot/kernel/dtio.ko.symbols > Reading symbols from /boot/modules/nvidia.ko...done. > Loaded symbols for /boot/modules/nvidia.ko > Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. > Loaded symbols for /boot/kernel/fdescfs.ko.symbols > Reading symbols from /boot/kernel/uhid.ko.symbols...done. > Loaded symbols for /boot/kernel/uhid.ko.symbols > Reading symbols from /boot/kernel/ums.ko.symbols...done. > Loaded symbols for /boot/kernel/ums.ko.symbols > #0 doadump (textdump=) at pcpu.h:236 > 236 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=) at pcpu.h:236 > #1 0xffffffff80523aa0 in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:447 > #2 0xffffffff80523e27 in panic (fmt=) > at /usr/src/sys/kern/kern_shutdown.c:754 > #3 0xffffffff8078962a in trap_fatal (frame=, > eva=) at /usr/src/sys/amd64/amd64/trap.c:873 > #4 0xffffffff80789a25 in trap_pfault (frame=0x0, usermode=0) > at /usr/src/sys/amd64/amd64/trap.c:731 > #5 0xffffffff80789022 in trap (frame=0xfffffe100d0d99c0) > at /usr/src/sys/amd64/amd64/trap.c:463 > #6 0xffffffff80773222 in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:232 > #7 0xffffffff8050c584 in _mtx_trylock_flags_ (c=0x18, opts=0, file=0x0, > line=269833360) at /usr/src/sys/kern/kern_mutex.c:330 > #8 0xffffffff80784682 in pmap_ts_referenced (m=0xfffff80faacbf6c8) > at /usr/src/sys/amd64/amd64/pmap.c:4936 > #9 0xffffffff8071616a in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:1360 > #10 0xffffffff804f118a in fork_exit (callout=0xffffffff80715070 , > arg=0x0, frame=0xfffffe100d0d9c00) at /usr/src/sys/kern/kern_fork.c:989 > #11 0xffffffff8077375e in fork_trampoline () > at /usr/src/sys/amd64/amd64/exception.S:606 > #12 0x0000000000000000 in ?? () > Current language: auto; currently minimal > (kgdb) > > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Sun Aug 25 05:51:45 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2623734C; Sun, 25 Aug 2013 05:51:45 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E54BF2997; Sun, 25 Aug 2013 05:51:44 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r7P5phx4078704; Sun, 25 Aug 2013 01:51:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r7P5phtY078694; Sun, 25 Aug 2013 05:51:43 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 25 Aug 2013 05:51:43 GMT Message-Id: <201308250551.r7P5phtY078694@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 , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 05:51:45 -0000 TB --- 2013-08-25 02:30:25 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-25 02:30:25 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-08-25 02:30:25 - starting HEAD tinderbox run for arm/arm TB --- 2013-08-25 02:30:25 - cleaning the object tree TB --- 2013-08-25 02:36:57 - /usr/local/bin/svn stat /src TB --- 2013-08-25 02:37:00 - At svn revision 254824 TB --- 2013-08-25 02:37:01 - building world TB --- 2013-08-25 02:37:01 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 02:37:01 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 02:37:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 02:37:01 - SRCCONF=/dev/null TB --- 2013-08-25 02:37:01 - TARGET=arm TB --- 2013-08-25 02:37:01 - TARGET_ARCH=arm TB --- 2013-08-25 02:37:01 - TZ=UTC TB --- 2013-08-25 02:37:01 - __MAKE_CONF=/dev/null TB --- 2013-08-25 02:37:01 - cd /src TB --- 2013-08-25 02:37:01 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Aug 25 02:37:09 UTC 2013 >>> 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 Aug 25 05:39:54 UTC 2013 TB --- 2013-08-25 05:39:54 - generating LINT kernel config TB --- 2013-08-25 05:39:54 - cd /src/sys/arm/conf TB --- 2013-08-25 05:39:54 - /usr/bin/make -B LINT TB --- 2013-08-25 05:39:54 - cd /src/sys/arm/conf TB --- 2013-08-25 05:39:54 - /usr/sbin/config -m LINT TB --- 2013-08-25 05:39:54 - building LINT kernel TB --- 2013-08-25 05:39:54 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 05:39:54 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 05:39:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 05:39:54 - SRCCONF=/dev/null TB --- 2013-08-25 05:39:54 - TARGET=arm TB --- 2013-08-25 05:39:54 - TARGET_ARCH=arm TB --- 2013-08-25 05:39:54 - TZ=UTC TB --- 2013-08-25 05:39:54 - __MAKE_CONF=/dev/null TB --- 2013-08-25 05:39:54 - cd /src TB --- 2013-08-25 05:39:54 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Aug 25 05:39:55 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /src/sys/sys/mbuf.h:760:50: note: expanded from macro 'MEXTADD' (void )m_extadd((m), (caddr_t)(buf), (size), (free), (arg1), (arg2),\ ^~~~~~ /src/sys/sys/mbuf.h:898:14: note: passing argument to parameter here void (*)(struct mbuf *, void *, void *), void *, void *, ^ 1 error generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-25 05:51:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-25 05:51:43 - ERROR: failed to build LINT kernel TB --- 2013-08-25 05:51:43 - 9180.37 user 1670.27 system 12077.28 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Sun Aug 25 06:05:26 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 13A76536; Sun, 25 Aug 2013 06:05:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DB6972A0F; Sun, 25 Aug 2013 06:05:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r7P65OxG059877; Sun, 25 Aug 2013 02:05:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r7P65O2K059876; Sun, 25 Aug 2013 06:05:24 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 25 Aug 2013 06:05:24 GMT Message-Id: <201308250605.r7P65O2K059876@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 , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 06:05:26 -0000 TB --- 2013-08-25 02:30:25 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-25 02:30:25 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-08-25 02:30:25 - starting HEAD tinderbox run for i386/i386 TB --- 2013-08-25 02:30:25 - cleaning the object tree TB --- 2013-08-25 02:37:36 - /usr/local/bin/svn stat /src TB --- 2013-08-25 02:37:39 - At svn revision 254824 TB --- 2013-08-25 02:37:40 - building world TB --- 2013-08-25 02:37:40 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 02:37:40 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 02:37:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 02:37:40 - SRCCONF=/dev/null TB --- 2013-08-25 02:37:40 - TARGET=i386 TB --- 2013-08-25 02:37:40 - TARGET_ARCH=i386 TB --- 2013-08-25 02:37:40 - TZ=UTC TB --- 2013-08-25 02:37:40 - __MAKE_CONF=/dev/null TB --- 2013-08-25 02:37:40 - cd /src TB --- 2013-08-25 02:37:40 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Aug 25 02:37:47 UTC 2013 >>> 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 Aug 25 05:50:22 UTC 2013 TB --- 2013-08-25 05:50:22 - generating LINT kernel config TB --- 2013-08-25 05:50:22 - cd /src/sys/i386/conf TB --- 2013-08-25 05:50:22 - /usr/bin/make -B LINT TB --- 2013-08-25 05:50:22 - cd /src/sys/i386/conf TB --- 2013-08-25 05:50:22 - /usr/sbin/config -m LINT TB --- 2013-08-25 05:50:22 - building LINT kernel TB --- 2013-08-25 05:50:22 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 05:50:22 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 05:50:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 05:50:22 - SRCCONF=/dev/null TB --- 2013-08-25 05:50:22 - TARGET=i386 TB --- 2013-08-25 05:50:22 - TARGET_ARCH=i386 TB --- 2013-08-25 05:50:22 - TZ=UTC TB --- 2013-08-25 05:50:22 - __MAKE_CONF=/dev/null TB --- 2013-08-25 05:50:22 - cd /src TB --- 2013-08-25 05:50:22 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Aug 25 05:50:22 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /src/sys/sys/mbuf.h:760:50: note: expanded from macro 'MEXTADD' (void )m_extadd((m), (caddr_t)(buf), (size), (free), (arg1), (arg2),\ ^~~~~~ /src/sys/sys/mbuf.h:898:14: note: passing argument to parameter here void (*)(struct mbuf *, void *, void *), void *, void *, ^ 1 error generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/i386.i386/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-25 06:05:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-25 06:05:24 - ERROR: failed to build LINT kernel TB --- 2013-08-25 06:05:24 - 10073.10 user 1757.05 system 12899.06 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sun Aug 25 06:39:35 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BB8189A7; Sun, 25 Aug 2013 06:39:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8B8282B3E; Sun, 25 Aug 2013 06:39:35 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r7P6dYHf030300; Sun, 25 Aug 2013 02:39:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r7P6dYtM030283; Sun, 25 Aug 2013 06:39:34 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 25 Aug 2013 06:39:34 GMT Message-Id: <201308250639.r7P6dYtM030283@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 , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 06:39:35 -0000 TB --- 2013-08-25 02:30:25 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-25 02:30:25 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-08-25 02:30:25 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-08-25 02:30:25 - cleaning the object tree TB --- 2013-08-25 02:37:58 - /usr/local/bin/svn stat /src TB --- 2013-08-25 02:38:01 - At svn revision 254824 TB --- 2013-08-25 02:38:02 - building world TB --- 2013-08-25 02:38:02 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 02:38:02 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 02:38:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 02:38:02 - SRCCONF=/dev/null TB --- 2013-08-25 02:38:02 - TARGET=amd64 TB --- 2013-08-25 02:38:02 - TARGET_ARCH=amd64 TB --- 2013-08-25 02:38:02 - TZ=UTC TB --- 2013-08-25 02:38:02 - __MAKE_CONF=/dev/null TB --- 2013-08-25 02:38:02 - cd /src TB --- 2013-08-25 02:38:02 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Aug 25 02:38:09 UTC 2013 >>> 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 Aug 25 06:26:25 UTC 2013 TB --- 2013-08-25 06:26:25 - generating LINT kernel config TB --- 2013-08-25 06:26:25 - cd /src/sys/amd64/conf TB --- 2013-08-25 06:26:25 - /usr/bin/make -B LINT TB --- 2013-08-25 06:26:25 - cd /src/sys/amd64/conf TB --- 2013-08-25 06:26:25 - /usr/sbin/config -m LINT TB --- 2013-08-25 06:26:25 - building LINT kernel TB --- 2013-08-25 06:26:25 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 06:26:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 06:26:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 06:26:25 - SRCCONF=/dev/null TB --- 2013-08-25 06:26:25 - TARGET=amd64 TB --- 2013-08-25 06:26:25 - TARGET_ARCH=amd64 TB --- 2013-08-25 06:26:25 - TZ=UTC TB --- 2013-08-25 06:26:25 - __MAKE_CONF=/dev/null TB --- 2013-08-25 06:26:25 - cd /src TB --- 2013-08-25 06:26:25 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Aug 25 06:26:25 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /src/sys/sys/mbuf.h:760:50: note: expanded from macro 'MEXTADD' (void )m_extadd((m), (caddr_t)(buf), (size), (free), (arg1), (arg2),\ ^~~~~~ /src/sys/sys/mbuf.h:898:14: note: passing argument to parameter here void (*)(struct mbuf *, void *, void *), void *, void *, ^ 1 error generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/amd64.amd64/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-25 06:39:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-25 06:39:34 - ERROR: failed to build LINT kernel TB --- 2013-08-25 06:39:34 - 11512.39 user 2137.95 system 14948.77 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sun Aug 25 06:57:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0E84AEB7 for ; Sun, 25 Aug 2013 06:57:03 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BA8A32C20 for ; Sun, 25 Aug 2013 06:57:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:References:Message-ID:In-Reply-To:Subject:To:Sender:From:Date; bh=vmAsgcwSYWpyhLRQEwiDRV3g9bt8B1F1OXPsEBRseQU=; b=bUVhDGLQgqFXpUiEYuDaLNujHk7BRPeDPRNVlCD/JxsQxL1r7hHqnYzbi/HJbFVDZft8kKBn8qJ7rFAO8EhGqPUio4266DgMCFagPU+b+7tTDhv8DYM8LA4CnPTWOJzDvVj4O8O9HD0QHCX3gPXovmETFomeqjcSdsSP0xTshZA=; Received: from cpe-72-182-93-216.austin.res.rr.com ([72.182.93.216]:50759 helo=borg) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VDUFt-000Hyk-Mv for freebsd-current@freebsd.org; Sun, 25 Aug 2013 01:57:01 -0500 Date: Sun, 25 Aug 2013 01:56:55 -0500 (CDT) From: Larry Rosenman Sender: ler@borg To: freebsd-current@freebsd.org Subject: Re: 2 crashes.... (today's -CURRENT) In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Aug 2013 06:57:03 -0000 And a 4th: borg.lerctr.org dumped core - see /var/crash/vmcore.3 Sun Aug 25 01:52:10 CDT 2013 FreeBSD borg.lerctr.org 10.0-CURRENT FreeBSD 10.0-CURRENT #32 r254807: Sat Aug 24 16:52:42 CDT 2013 root@borg.lerctr.org:/usr/obj/usr/src/sys/BORG-DTRACE amd64 panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0x100 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff8081c2cc stack pointer = 0x28:0xfffffe100d75a6b0 frame pointer = 0x28:0xfffffe100d75a6e0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 3335 (exim-4.80.1-2) trap number = 12 panic: page fault cpuid = 3 Uptime: 5h17m5s Dumping 7102 out of 64480 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel/zfs.ko.symbols...done. Loaded symbols for /boot/kernel/zfs.ko.symbols Reading symbols from /boot/kernel/acl_nfs4.ko.symbols...done. Loaded symbols for /boot/kernel/acl_nfs4.ko.symbols Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. Loaded symbols for /boot/kernel/opensolaris.ko.symbols Reading symbols from /boot/kernel/linux.ko.symbols...done. Loaded symbols for /boot/kernel/linux.ko.symbols Reading symbols from /boot/kernel/snd_envy24ht.ko.symbols...done. Loaded symbols for /boot/kernel/snd_envy24ht.ko.symbols Reading symbols from /boot/kernel/snd_spicds.ko.symbols...done. Loaded symbols for /boot/kernel/snd_spicds.ko.symbols Reading symbols from /boot/kernel/sound.ko.symbols...done. Loaded symbols for /boot/kernel/sound.ko.symbols Reading symbols from /boot/kernel/snd_hda.ko.symbols...done. Loaded symbols for /boot/kernel/snd_hda.ko.symbols Reading symbols from /boot/kernel/coretemp.ko.symbols...done. Loaded symbols for /boot/kernel/coretemp.ko.symbols Reading symbols from /boot/kernel/ichsmb.ko.symbols...done. Loaded symbols for /boot/kernel/ichsmb.ko.symbols Reading symbols from /boot/kernel/smbus.ko.symbols...done. Loaded symbols for /boot/kernel/smbus.ko.symbols Reading symbols from /boot/kernel/ichwd.ko.symbols...done. Loaded symbols for /boot/kernel/ichwd.ko.symbols Reading symbols from /boot/kernel/cpuctl.ko.symbols...done. Loaded symbols for /boot/kernel/cpuctl.ko.symbols Reading symbols from /boot/kernel/crypto.ko.symbols...done. Loaded symbols for /boot/kernel/crypto.ko.symbols Reading symbols from /boot/kernel/cryptodev.ko.symbols...done. Loaded symbols for /boot/kernel/cryptodev.ko.symbols Reading symbols from /boot/kernel/dtraceall.ko.symbols...done. Loaded symbols for /boot/kernel/dtraceall.ko.symbols Reading symbols from /boot/kernel/profile.ko.symbols...done. Loaded symbols for /boot/kernel/profile.ko.symbols Reading symbols from /boot/kernel/cyclic.ko.symbols...done. Loaded symbols for /boot/kernel/cyclic.ko.symbols Reading symbols from /boot/kernel/dtrace.ko.symbols...done. Loaded symbols for /boot/kernel/dtrace.ko.symbols Reading symbols from /boot/kernel/systrace_freebsd32.ko.symbols...done. Loaded symbols for /boot/kernel/systrace_freebsd32.ko.symbols Reading symbols from /boot/kernel/systrace.ko.symbols...done. Loaded symbols for /boot/kernel/systrace.ko.symbols Reading symbols from /boot/kernel/sdt.ko.symbols...done. Loaded symbols for /boot/kernel/sdt.ko.symbols Reading symbols from /boot/kernel/lockstat.ko.symbols...done. Loaded symbols for /boot/kernel/lockstat.ko.symbols Reading symbols from /boot/kernel/fasttrap.ko.symbols...done. Loaded symbols for /boot/kernel/fasttrap.ko.symbols Reading symbols from /boot/kernel/fbt.ko.symbols...done. Loaded symbols for /boot/kernel/fbt.ko.symbols Reading symbols from /boot/kernel/dtnfscl.ko.symbols...done. Loaded symbols for /boot/kernel/dtnfscl.ko.symbols Reading symbols from /boot/kernel/dtmalloc.ko.symbols...done. Loaded symbols for /boot/kernel/dtmalloc.ko.symbols Reading symbols from /boot/kernel/dtio.ko.symbols...done. Loaded symbols for /boot/kernel/dtio.ko.symbols Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. Loaded symbols for /boot/kernel/fdescfs.ko.symbols Reading symbols from /boot/kernel/uhid.ko.symbols...done. Loaded symbols for /boot/kernel/uhid.ko.symbols Reading symbols from /boot/kernel/ums.ko.symbols...done. Loaded symbols for /boot/kernel/ums.ko.symbols #0 doadump (textdump=) at pcpu.h:236 236 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=) at pcpu.h:236 #1 0xffffffff80523aa0 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0xffffffff80523e27 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:754 #3 0xffffffff8078962a in trap_fatal (frame=, eva=) at /usr/src/sys/amd64/amd64/trap.c:873 #4 0xffffffff80789a25 in trap_pfault (frame=0x0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:731 #5 0xffffffff80789022 in trap (frame=0xfffffe100d75a600) at /usr/src/sys/amd64/amd64/trap.c:463 #6 0xffffffff80773222 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #7 0xffffffff8081c2cc in VOP_LOCK1_APV (vop=, a=0xfffffe100d75a6f0) at vnode_if.c:2082 #8 0xffffffff805cb733 in _vn_lock (vp=0xfffff8024add7000, flags=, file=0xffffffff80884f7d "/usr/src/sys/kern/vfs_subr.c", line=2099) at vnode_if.h:859 #9 0xffffffff805bcc8a in vget (vp=0xfffff8024add7000, flags=2097408, td=0xfffff806c93a0000) at /usr/src/sys/kern/vfs_subr.c:2099 #10 0xffffffff805a9ad2 in cache_lookup (dvp=0xfffff8001f2c8938, vpp=0xfffffe100d75aa28, cnp=0xfffffe100d75aa50, tsp=0x0, ticksp=0x0) at /usr/src/sys/kern/vfs_cache.c:674 #11 0xffffffff805aac71 in vfs_cache_lookup (ap=) at /usr/src/sys/kern/vfs_cache.c:1033 #12 0xffffffff8081a492 in VOP_LOOKUP_APV (vop=, a=) at vnode_if.c:129 #13 0xffffffff805b2f3b in lookup (ndp=0xfffffe100d75a9d8) at vnode_if.h:54 #14 0xffffffff805b26d4 in namei (ndp=0xfffffe100d75a9d8) at /usr/src/sys/kern/vfs_lookup.c:293 #15 0xffffffff805c3eb6 in kern_chdir (td=0xfffff806c93a0000, path=0xfffffe100d75a6f0 "?{?\200????", pathseg=2156416893) at /usr/src/sys/kern/vfs_syscalls.c:796 #16 0xffffffff80789f27 in amd64_syscall (td=0xfffff806c93a0000, traced=0) at subr_syscall.c:134 #17 0xffffffff8077350b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 #18 0x000000080280290a in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) On Sat, 24 Aug 2013, Larry Rosenman wrote: > And another: > > borg.lerctr.org dumped core - see /var/crash/vmcore.2 > > Sat Aug 24 20:29:48 CDT 2013 > > FreeBSD borg.lerctr.org 10.0-CURRENT FreeBSD 10.0-CURRENT #32 r254807: Sat > Aug 24 16:52:42 CDT 2013 > root@borg.lerctr.org:/usr/obj/usr/src/sys/BORG-DTRACE amd64 > > panic: sorele > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > panic: sorele > cpuid = 6 > Uptime: 2h44m44s > Dumping 3107 out of 64480 > MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% > > Reading symbols from /boot/kernel/zfs.ko.symbols...done. > Loaded symbols for /boot/kernel/zfs.ko.symbols > Reading symbols from /boot/kernel/acl_nfs4.ko.symbols...done. > Loaded symbols for /boot/kernel/acl_nfs4.ko.symbols > Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. > Loaded symbols for /boot/kernel/opensolaris.ko.symbols > Reading symbols from /boot/kernel/linux.ko.symbols...done. > Loaded symbols for /boot/kernel/linux.ko.symbols > Reading symbols from /boot/kernel/snd_envy24ht.ko.symbols...done. > Loaded symbols for /boot/kernel/snd_envy24ht.ko.symbols > Reading symbols from /boot/kernel/snd_spicds.ko.symbols...done. > Loaded symbols for /boot/kernel/snd_spicds.ko.symbols > Reading symbols from /boot/kernel/sound.ko.symbols...done. > Loaded symbols for /boot/kernel/sound.ko.symbols > Reading symbols from /boot/kernel/snd_hda.ko.symbols...done. > Loaded symbols for /boot/kernel/snd_hda.ko.symbols > Reading symbols from /boot/kernel/coretemp.ko.symbols...done. > Loaded symbols for /boot/kernel/coretemp.ko.symbols > Reading symbols from /boot/kernel/ichsmb.ko.symbols...done. > Loaded symbols for /boot/kernel/ichsmb.ko.symbols > Reading symbols from /boot/kernel/smbus.ko.symbols...done. > Loaded symbols for /boot/kernel/smbus.ko.symbols > Reading symbols from /boot/kernel/ichwd.ko.symbols...done. > Loaded symbols for /boot/kernel/ichwd.ko.symbols > Reading symbols from /boot/kernel/cpuctl.ko.symbols...done. > Loaded symbols for /boot/kernel/cpuctl.ko.symbols > Reading symbols from /boot/kernel/crypto.ko.symbols...done. > Loaded symbols for /boot/kernel/crypto.ko.symbols > Reading symbols from /boot/kernel/cryptodev.ko.symbols...done. > Loaded symbols for /boot/kernel/cryptodev.ko.symbols > Reading symbols from /boot/kernel/dtraceall.ko.symbols...done. > Loaded symbols for /boot/kernel/dtraceall.ko.symbols > Reading symbols from /boot/kernel/profile.ko.symbols...done. > Loaded symbols for /boot/kernel/profile.ko.symbols > Reading symbols from /boot/kernel/cyclic.ko.symbols...done. > Loaded symbols for /boot/kernel/cyclic.ko.symbols > Reading symbols from /boot/kernel/dtrace.ko.symbols...done. > Loaded symbols for /boot/kernel/dtrace.ko.symbols > Reading symbols from /boot/kernel/systrace_freebsd32.ko.symbols...done. > Loaded symbols for /boot/kernel/systrace_freebsd32.ko.symbols > Reading symbols from /boot/kernel/systrace.ko.symbols...done. > Loaded symbols for /boot/kernel/systrace.ko.symbols > Reading symbols from /boot/kernel/sdt.ko.symbols...done. > Loaded symbols for /boot/kernel/sdt.ko.symbols > Reading symbols from /boot/kernel/lockstat.ko.symbols...done. > Loaded symbols for /boot/kernel/lockstat.ko.symbols > Reading symbols from /boot/kernel/fasttrap.ko.symbols...done. > Loaded symbols for /boot/kernel/fasttrap.ko.symbols > Reading symbols from /boot/kernel/fbt.ko.symbols...done. > Loaded symbols for /boot/kernel/fbt.ko.symbols > Reading symbols from /boot/kernel/dtnfscl.ko.symbols...done. > Loaded symbols for /boot/kernel/dtnfscl.ko.symbols > Reading symbols from /boot/kernel/dtmalloc.ko.symbols...done. > Loaded symbols for /boot/kernel/dtmalloc.ko.symbols > Reading symbols from /boot/kernel/dtio.ko.symbols...done. > Loaded symbols for /boot/kernel/dtio.ko.symbols > Reading symbols from /boot/modules/nvidia.ko...done. > Loaded symbols for /boot/modules/nvidia.ko > Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. > Loaded symbols for /boot/kernel/fdescfs.ko.symbols > Reading symbols from /boot/kernel/uhid.ko.symbols...done. > Loaded symbols for /boot/kernel/uhid.ko.symbols > Reading symbols from /boot/kernel/ums.ko.symbols...done. > Loaded symbols for /boot/kernel/ums.ko.symbols > #0 doadump (textdump=) at pcpu.h:236 > 236 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=) at pcpu.h:236 > #1 0xffffffff80523aa0 in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:447 > #2 0xffffffff80523e27 in panic (fmt=) > at /usr/src/sys/kern/kern_shutdown.c:754 > #3 0xffffffff80593222 in soclose (so=) > at /usr/src/sys/kern/uipc_socket.c:853 > #4 0xffffffff804dd689 in _fdrop (fp=0xfffff800200a6190, td=0x0) at > file.h:341 > #5 0xffffffff804dffa7 in closef (fp=, > td=) at /usr/src/sys/kern/kern_descrip.c:2268 > #6 0xffffffff804ddae5 in closefp (fdp=0xfffff800200d7800, > fd=, fp=0xfffff800200a6190, td=0xfffff80020898000, > holdleaders=) > at /usr/src/sys/kern/kern_descrip.c:1140 > #7 0xffffffff80789f27 in amd64_syscall (td=0xfffff80020898000, traced=0) > at subr_syscall.c:134 > #8 0xffffffff8077350b in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:391 > #9 0x000000000044f75a in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > (kgdb) > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Sun Aug 25 07:13:18 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 888633DC; Sun, 25 Aug 2013 07:13:18 +0000 (UTC) (envelope-from rpaulo@FreeBSD.org) Received: from felyko.com (felyko.com [IPv6:2607:f2f8:a528::3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id 6B4532CE0; Sun, 25 Aug 2013 07:13:18 +0000 (UTC) Received: from [IPv6:2601:9:4d00:119:a180:f63e:28b5:8b94] (unknown [IPv6:2601:9:4d00:119:a180:f63e:28b5:8b94]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id 4CBDB39821; Sun, 25 Aug 2013 00:13:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: GCC withdraw From: Rui Paulo In-Reply-To: <20130824230615.GA55855@troutmask.apl.washington.edu> Date: Sun, 25 Aug 2013 00:13:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2F47D95A-C350-4D9C-A4CB-B331BF87EF80@FreeBSD.org> References: <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> <20130824115158.GA88999@zxy.spb.ru> <20130824154217.GE3796@zxy.spb.ru> <20130824224204.GH3796@zxy.spb.ru> <20130824230615.GA55855@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.1508) Cc: FreeBSD Current , David Chisnall , toolchain@freebsd.org, Slawa Olhovchenkov , "Sam Fourman Jr." , Boris Samorodov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Aug 2013 07:13:18 -0000 On 24 Aug 2013, at 16:06, Steve Kargl = wrote: > On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote: >> On 24 Aug 2013, at 23:42, Slawa Olhovchenkov wrote: >>=20 >>> And i found PR about clang and mplayer: ports/176272 >>> This PR contains log with build error log. >>=20 >> Please file clang bugs at http://llvm.org/bugs/ >>=20 >=20 > As if this is going to help. >=20 > http://llvm.org/bugs/show_bug.cgi?id=3D8532 >=20 > 2 years, 9 month and counting. Irrelevant to the discussion since the base system GCC has the same = problem. -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Sun Aug 25 07:22:19 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 54DC9764; Sun, 25 Aug 2013 07:22:19 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 0BA252D6B; Sun, 25 Aug 2013 07:22:18 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1VDUgS-00050u-FN; Sun, 25 Aug 2013 11:24:24 +0400 Date: Sun, 25 Aug 2013 11:24:24 +0400 From: Slawa Olhovchenkov To: Rui Paulo Subject: Re: GCC withdraw Message-ID: <20130825072424.GI3796@zxy.spb.ru> References: <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> <20130824115158.GA88999@zxy.spb.ru> <20130824154217.GE3796@zxy.spb.ru> <20130824224204.GH3796@zxy.spb.ru> <20130824230615.GA55855@troutmask.apl.washington.edu> <2F47D95A-C350-4D9C-A4CB-B331BF87EF80@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2F47D95A-C350-4D9C-A4CB-B331BF87EF80@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: FreeBSD Current , David Chisnall , toolchain@freebsd.org, Steve Kargl , "Sam Fourman Jr." , Boris Samorodov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Aug 2013 07:22:19 -0000 On Sun, Aug 25, 2013 at 12:13:15AM -0700, Rui Paulo wrote: > On 24 Aug 2013, at 16:06, Steve Kargl wrote: > > > On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote: > >> On 24 Aug 2013, at 23:42, Slawa Olhovchenkov wrote: > >> > >>> And i found PR about clang and mplayer: ports/176272 > >>> This PR contains log with build error log. > >> > >> Please file clang bugs at http://llvm.org/bugs/ > >> > > > > As if this is going to help. > > > > http://llvm.org/bugs/show_bug.cgi?id=8532 > > > > 2 years, 9 month and counting. > > > Irrelevant to the discussion since the base system GCC has the same problem. How about ports/180564? And llvm community known about this issue: http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2013-July/259146.html From owner-freebsd-current@FreeBSD.ORG Sun Aug 25 07:23:53 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B60558B1; Sun, 25 Aug 2013 07:23:53 +0000 (UTC) (envelope-from rpaulo@FreeBSD.org) Received: from felyko.com (felyko.com [174.136.100.2]) by mx1.freebsd.org (Postfix) with ESMTP id 9A8B42D8B; Sun, 25 Aug 2013 07:23:53 +0000 (UTC) Received: from [IPv6:2601:9:4d00:119:a180:f63e:28b5:8b94] (unknown [IPv6:2601:9:4d00:119:a180:f63e:28b5:8b94]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id EDFED39821; Sun, 25 Aug 2013 00:23:46 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: GCC withdraw From: Rui Paulo In-Reply-To: <20130825072424.GI3796@zxy.spb.ru> Date: Sun, 25 Aug 2013 00:23:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4E8FB8C9-F685-43E5-B810-B2609E679273@FreeBSD.org> References: <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> <20130824115158.GA88999@zxy.spb.ru> <20130824154217.GE3796@zxy.spb.ru> <20130824224204.GH3796@zxy.spb.ru> <20130824230615.GA55855@troutmask.apl.washington.edu> <2F47D95A-C350-4D9C-A4CB-B331BF87EF80@FreeBSD.org> <20130825072424.GI3796@zxy.spb.ru> To: Slawa Olhovchenkov X-Mailer: Apple Mail (2.1508) Cc: FreeBSD Current , David Chisnall , toolchain@freebsd.org, Steve Kargl , "Sam Fourman Jr." , Boris Samorodov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Aug 2013 07:23:53 -0000 On 25 Aug 2013, at 00:24, Slawa Olhovchenkov wrote: > On Sun, Aug 25, 2013 at 12:13:15AM -0700, Rui Paulo wrote: >=20 >> On 24 Aug 2013, at 16:06, Steve Kargl = wrote: >>=20 >>> On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote: >>>> On 24 Aug 2013, at 23:42, Slawa Olhovchenkov = wrote: >>>>=20 >>>>> And i found PR about clang and mplayer: ports/176272 >>>>> This PR contains log with build error log. >>>>=20 >>>> Please file clang bugs at http://llvm.org/bugs/ >>>>=20 >>>=20 >>> As if this is going to help. >>>=20 >>> http://llvm.org/bugs/show_bug.cgi?id=3D8532 >>>=20 >>> 2 years, 9 month and counting. >>=20 >>=20 >> Irrelevant to the discussion since the base system GCC has the same = problem. >=20 > How about ports/180564? > And llvm community known about this issue: > = http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2013-July/259146.htm= l Have you tried submitting that directly to mplayer? -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Sun Aug 25 07:23:56 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 19F809AB; Sun, 25 Aug 2013 07:23:56 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A0A822D8C; Sun, 25 Aug 2013 07:23:55 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id c10so3319081ieb.17 for ; Sun, 25 Aug 2013 00:23:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=I8G1C6xISk0AUk1/Bmr3Y0TMAe5jRZqqdrIiW4aQqLc=; b=Nyk8rxTRem1V3X0I4i9paouR3ecBiEVy766M7lVxGdCulSkE/rJX82TACbn603oDYp stnLDhnesGnBIXEfl140/k+RHTE3A+BUftZjHUN3NyBZC098bEp46K92WQ/MIsPAoGlb YM5PDrV7J1pGFLIGpuVvbWimheWM6djIfMm0mHj1QNjSf5M46yOuEtOa0G5SQMX4RSHJ tCyR4juv/w8CkaaRXbBTbjRll5ZT4XqD9QlV8zP7lCTd9P26ecLUy4Ufx/Qhb+AlTNwr ezPKb8XKnafYrYlE6we2agGLCKXZ2bFe4XRY5Mv1x81DvXYJAeoZcTcjttdsjHmzmb6j XaMQ== MIME-Version: 1.0 X-Received: by 10.50.128.36 with SMTP id nl4mr3071505igb.38.1377415435034; Sun, 25 Aug 2013 00:23:55 -0700 (PDT) Received: by 10.50.209.38 with HTTP; Sun, 25 Aug 2013 00:23:54 -0700 (PDT) In-Reply-To: <20130824224204.GH3796@zxy.spb.ru> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> <20130824115158.GA88999@zxy.spb.ru> <20130824154217.GE3796@zxy.spb.ru> <20130824224204.GH3796@zxy.spb.ru> Date: Sun, 25 Aug 2013 02:23:54 -0500 Message-ID: Subject: Re: GCC withdraw From: Scot Hetzel To: Slawa Olhovchenkov Content-Type: text/plain; charset=ISO-8859-1 Cc: "Sam Fourman Jr." , toolchain@freebsd.org, David Chisnall , Boris Samorodov , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Aug 2013 07:23:56 -0000 On Sat, Aug 24, 2013 at 5:42 PM, Slawa Olhovchenkov wrote: > On Sat, Aug 24, 2013 at 07:42:17PM +0400, Slawa Olhovchenkov wrote: > >> On Sat, Aug 24, 2013 at 01:10:46PM +0100, David Chisnall wrote: >> >> > On 24 Aug 2013, at 12:51, Slawa Olhovchenkov wrote: >> > >> > > Oh, I remember. mplayer on i386 can't be builded witch clang -- clang >> > > don't understand inlined asm. >> > >> > Clang supports inline asm. If there is some specific inline asm >> > syntax that clang does not recognise, then please will you point me >> > to the relevant LLVM bug report and I will investigate it. >> >> Sorry, I don't know about clang/llvm bug reports, I just try to build >> mplayer with Win32 codecs support on FreeBSD-10/i386. >> >> And currenly (in rev r315041) building by clang disabled in ports tree. > > And i found PR about clang and mplayer: ports/176272 > This PR contains log with build error log. PR176272 is form mplayer-1.1.r20120721_2, and was closed due to the issue was fixed by updating the port to a more recent version. Mplayer is currently mplayer-1.1.r20130308, do you still see the same issues with clang? -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. From owner-freebsd-current@FreeBSD.ORG Sun Aug 25 07:51:05 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5DA11DD9; Sun, 25 Aug 2013 07:51:05 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 16D852EB4; Sun, 25 Aug 2013 07:51:05 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1VDV8J-0005SZ-3n; Sun, 25 Aug 2013 11:53:11 +0400 Date: Sun, 25 Aug 2013 11:53:11 +0400 From: Slawa Olhovchenkov To: Scot Hetzel Subject: Re: GCC withdraw Message-ID: <20130825075311.GJ3796@zxy.spb.ru> References: <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> <20130824115158.GA88999@zxy.spb.ru> <20130824154217.GE3796@zxy.spb.ru> <20130824224204.GH3796@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: "Sam Fourman Jr." , toolchain@freebsd.org, David Chisnall , Boris Samorodov , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Aug 2013 07:51:05 -0000 On Sun, Aug 25, 2013 at 02:23:54AM -0500, Scot Hetzel wrote: > On Sat, Aug 24, 2013 at 5:42 PM, Slawa Olhovchenkov wrote: > > On Sat, Aug 24, 2013 at 07:42:17PM +0400, Slawa Olhovchenkov wrote: > > > >> On Sat, Aug 24, 2013 at 01:10:46PM +0100, David Chisnall wrote: > >> > >> > On 24 Aug 2013, at 12:51, Slawa Olhovchenkov wrote: > >> > > >> > > Oh, I remember. mplayer on i386 can't be builded witch clang -- clang > >> > > don't understand inlined asm. > >> > > >> > Clang supports inline asm. If there is some specific inline asm > >> > syntax that clang does not recognise, then please will you point me > >> > to the relevant LLVM bug report and I will investigate it. > >> > >> Sorry, I don't know about clang/llvm bug reports, I just try to build > >> mplayer with Win32 codecs support on FreeBSD-10/i386. > >> > >> And currenly (in rev r315041) building by clang disabled in ports tree. > > > > And i found PR about clang and mplayer: ports/176272 > > This PR contains log with build error log. > > PR176272 is form mplayer-1.1.r20120721_2, and was closed due to the > issue was fixed by updating the port to a more recent version. > > Mplayer is currently mplayer-1.1.r20130308, do you still see the same > issues with clang? Now issues as in ports/180564. Not same, but very close ('ran out of registers during register allocation' in other place). From owner-freebsd-current@FreeBSD.ORG Sun Aug 25 07:52:19 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9440FF11; Sun, 25 Aug 2013 07:52:19 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 4A6ED2EC5; Sun, 25 Aug 2013 07:52:19 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1VDV9U-0005Ui-Tj; Sun, 25 Aug 2013 11:54:24 +0400 Date: Sun, 25 Aug 2013 11:54:24 +0400 From: Slawa Olhovchenkov To: Rui Paulo Subject: Re: GCC withdraw Message-ID: <20130825075424.GK3796@zxy.spb.ru> References: <20130824115158.GA88999@zxy.spb.ru> <20130824154217.GE3796@zxy.spb.ru> <20130824224204.GH3796@zxy.spb.ru> <20130824230615.GA55855@troutmask.apl.washington.edu> <2F47D95A-C350-4D9C-A4CB-B331BF87EF80@FreeBSD.org> <20130825072424.GI3796@zxy.spb.ru> <4E8FB8C9-F685-43E5-B810-B2609E679273@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E8FB8C9-F685-43E5-B810-B2609E679273@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: FreeBSD Current , David Chisnall , toolchain@freebsd.org, Steve Kargl , "Sam Fourman Jr." , Boris Samorodov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Aug 2013 07:52:19 -0000 On Sun, Aug 25, 2013 at 12:23:45AM -0700, Rui Paulo wrote: > On 25 Aug 2013, at 00:24, Slawa Olhovchenkov wrote: > > > On Sun, Aug 25, 2013 at 12:13:15AM -0700, Rui Paulo wrote: > > > >> On 24 Aug 2013, at 16:06, Steve Kargl wrote: > >> > >>> On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote: > >>>> On 24 Aug 2013, at 23:42, Slawa Olhovchenkov wrote: > >>>> > >>>>> And i found PR about clang and mplayer: ports/176272 > >>>>> This PR contains log with build error log. > >>>> > >>>> Please file clang bugs at http://llvm.org/bugs/ > >>>> > >>> > >>> As if this is going to help. > >>> > >>> http://llvm.org/bugs/show_bug.cgi?id=8532 > >>> > >>> 2 years, 9 month and counting. > >> > >> > >> Irrelevant to the discussion since the base system GCC has the same problem. > > > > How about ports/180564? > > And llvm community known about this issue: > > http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2013-July/259146.html > > > Have you tried submitting that directly to mplayer? No, I don't know about mplayer bug database and mplayer's support FreeBSD-current as target. From owner-freebsd-current@FreeBSD.ORG Sun Aug 25 07:58:37 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 76116144; Sun, 25 Aug 2013 07:58:37 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3B9872EFB; Sun, 25 Aug 2013 07:58:37 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r7P7wawb090170; Sun, 25 Aug 2013 03:58:36 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r7P7waxM090169; Sun, 25 Aug 2013 07:58:36 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 25 Aug 2013 07:58:36 GMT Message-Id: <201308250758.r7P7waxM090169@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 , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 07:58:37 -0000 TB --- 2013-08-25 06:05:25 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-25 06:05:25 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-08-25 06:05:25 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-08-25 06:05:25 - cleaning the object tree TB --- 2013-08-25 06:06:36 - /usr/local/bin/svn stat /src TB --- 2013-08-25 06:06:39 - At svn revision 254824 TB --- 2013-08-25 06:06:40 - building world TB --- 2013-08-25 06:06:40 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 06:06:40 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 06:06:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 06:06:40 - SRCCONF=/dev/null TB --- 2013-08-25 06:06:40 - TARGET=ia64 TB --- 2013-08-25 06:06:40 - TARGET_ARCH=ia64 TB --- 2013-08-25 06:06:40 - TZ=UTC TB --- 2013-08-25 06:06:40 - __MAKE_CONF=/dev/null TB --- 2013-08-25 06:06:40 - cd /src TB --- 2013-08-25 06:06:40 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Aug 25 06:06:47 UTC 2013 >>> 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 Aug 25 07:45:44 UTC 2013 TB --- 2013-08-25 07:45:44 - generating LINT kernel config TB --- 2013-08-25 07:45:44 - cd /src/sys/ia64/conf TB --- 2013-08-25 07:45:44 - /usr/bin/make -B LINT TB --- 2013-08-25 07:45:44 - cd /src/sys/ia64/conf TB --- 2013-08-25 07:45:44 - /usr/sbin/config -m LINT TB --- 2013-08-25 07:45:44 - building LINT kernel TB --- 2013-08-25 07:45:44 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 07:45:44 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 07:45:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 07:45:44 - SRCCONF=/dev/null TB --- 2013-08-25 07:45:44 - TARGET=ia64 TB --- 2013-08-25 07:45:44 - TARGET_ARCH=ia64 TB --- 2013-08-25 07:45:44 - TZ=UTC TB --- 2013-08-25 07:45:44 - __MAKE_CONF=/dev/null TB --- 2013-08-25 07:45:44 - cd /src TB --- 2013-08-25 07:45:44 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Aug 25 07:45:44 UTC 2013 >>> 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 -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/vxge/vxgehal/vxgehal-virtualpath.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 -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/vxge/vxgehal/vxgehal-channel.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 -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/vxge/vxgehal/vxgehal-fifo.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 -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/watchdog/watchdog.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 -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/wb/if_wb.c cc1: warnings being treated as errors /src/sys/dev/wb/if_wb.c: In function 'wb_newbuf': /src/sys/dev/wb/if_wb.c:850: warning: passing argument 4 of 'm_extadd' from incompatible pointer type *** Error code 1 Stop. bmake[1]: stopped in /obj/ia64.ia64/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-25 07:58:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-25 07:58:36 - ERROR: failed to build LINT kernel TB --- 2013-08-25 07:58:36 - 5268.75 user 913.23 system 6790.91 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sun Aug 25 08:15:59 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 45BDF5E4; Sun, 25 Aug 2013 08:15:59 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D4A7A2FCE; Sun, 25 Aug 2013 08:15:58 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r7P8FvO2079453; Sun, 25 Aug 2013 04:15:57 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r7P8FvoP079448; Sun, 25 Aug 2013 08:15:57 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 25 Aug 2013 08:15:57 GMT Message-Id: <201308250815.r7P8FvoP079448@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 , , Subject: [head tinderbox] failure on mips64/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 08:15:59 -0000 TB --- 2013-08-25 06:55:55 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-25 06:55:55 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-08-25 06:55:55 - starting HEAD tinderbox run for mips64/mips TB --- 2013-08-25 06:55:55 - cleaning the object tree TB --- 2013-08-25 06:56:48 - /usr/local/bin/svn stat /src TB --- 2013-08-25 06:56:51 - At svn revision 254824 TB --- 2013-08-25 06:56:52 - building world TB --- 2013-08-25 06:56:52 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 06:56:52 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 06:56:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 06:56:52 - SRCCONF=/dev/null TB --- 2013-08-25 06:56:52 - TARGET=mips TB --- 2013-08-25 06:56:52 - TARGET_ARCH=mips64 TB --- 2013-08-25 06:56:52 - TZ=UTC TB --- 2013-08-25 06:56:52 - __MAKE_CONF=/dev/null TB --- 2013-08-25 06:56:52 - cd /src TB --- 2013-08-25 06:56:52 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Aug 25 06:56:59 UTC 2013 >>> 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 Aug 25 08:00:49 UTC 2013 TB --- 2013-08-25 08:00:49 - cd /src/sys/mips/conf TB --- 2013-08-25 08:00:49 - /usr/sbin/config -m ADM5120 TB --- 2013-08-25 08:00:49 - skipping ADM5120 kernel TB --- 2013-08-25 08:00:49 - cd /src/sys/mips/conf TB --- 2013-08-25 08:00:49 - /usr/sbin/config -m ALCHEMY TB --- 2013-08-25 08:00:49 - skipping ALCHEMY kernel TB --- 2013-08-25 08:00:49 - cd /src/sys/mips/conf TB --- 2013-08-25 08:00:49 - /usr/sbin/config -m AP121 TB --- 2013-08-25 08:00:49 - skipping AP121 kernel TB --- 2013-08-25 08:00:49 - cd /src/sys/mips/conf TB --- 2013-08-25 08:00:49 - /usr/sbin/config -m AP91 TB --- 2013-08-25 08:00:49 - skipping AP91 kernel TB --- 2013-08-25 08:00:49 - cd /src/sys/mips/conf TB --- 2013-08-25 08:00:49 - /usr/sbin/config -m AP93 TB --- 2013-08-25 08:00:49 - skipping AP93 kernel TB --- 2013-08-25 08:00:49 - cd /src/sys/mips/conf TB --- 2013-08-25 08:00:49 - /usr/sbin/config -m AP94 TB --- 2013-08-25 08:00:49 - skipping AP94 kernel TB --- 2013-08-25 08:00:49 - cd /src/sys/mips/conf TB --- 2013-08-25 08:00:49 - /usr/sbin/config -m AP96 TB --- 2013-08-25 08:00:49 - skipping AP96 kernel TB --- 2013-08-25 08:00:49 - cd /src/sys/mips/conf TB --- 2013-08-25 08:00:49 - /usr/sbin/config -m AR71XX_BASE TB --- 2013-08-25 08:00:49 - skipping AR71XX_BASE kernel TB --- 2013-08-25 08:00:49 - cd /src/sys/mips/conf TB --- 2013-08-25 08:00:49 - /usr/sbin/config -m AR724X_BASE TB --- 2013-08-25 08:00:49 - skipping AR724X_BASE kernel TB --- 2013-08-25 08:00:49 - cd /src/sys/mips/conf TB --- 2013-08-25 08:00:49 - /usr/sbin/config -m AR91XX_BASE TB --- 2013-08-25 08:00:49 - skipping AR91XX_BASE kernel TB --- 2013-08-25 08:00:49 - cd /src/sys/mips/conf TB --- 2013-08-25 08:00:49 - /usr/sbin/config -m AR933X_BASE TB --- 2013-08-25 08:00:49 - skipping AR933X_BASE kernel TB --- 2013-08-25 08:00:49 - cd /src/sys/mips/conf TB --- 2013-08-25 08:00:49 - /usr/sbin/config -m AR934X_BASE TB --- 2013-08-25 08:00:49 - skipping AR934X_BASE kernel TB --- 2013-08-25 08:00:49 - cd /src/sys/mips/conf TB --- 2013-08-25 08:00:49 - /usr/sbin/config -m BERI_DE4_MDROOT TB --- 2013-08-25 08:00:49 - building BERI_DE4_MDROOT kernel TB --- 2013-08-25 08:00:49 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 08:00:49 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 08:00:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 08:00:49 - SRCCONF=/dev/null TB --- 2013-08-25 08:00:49 - TARGET=mips TB --- 2013-08-25 08:00:49 - TARGET_ARCH=mips64 TB --- 2013-08-25 08:00:49 - TZ=UTC TB --- 2013-08-25 08:00:49 - __MAKE_CONF=/dev/null TB --- 2013-08-25 08:00:49 - cd /src TB --- 2013-08-25 08:00:49 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_MDROOT >>> Kernel build for BERI_DE4_MDROOT started on Sun Aug 25 08:00:49 UTC 2013 >>> 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 BERI_DE4_MDROOT completed on Sun Aug 25 08:03:14 UTC 2013 TB --- 2013-08-25 08:03:14 - cd /src/sys/mips/conf TB --- 2013-08-25 08:03:14 - /usr/sbin/config -m BERI_DE4_SDROOT TB --- 2013-08-25 08:03:14 - building BERI_DE4_SDROOT kernel TB --- 2013-08-25 08:03:14 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 08:03:14 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 08:03:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 08:03:14 - SRCCONF=/dev/null TB --- 2013-08-25 08:03:14 - TARGET=mips TB --- 2013-08-25 08:03:14 - TARGET_ARCH=mips64 TB --- 2013-08-25 08:03:14 - TZ=UTC TB --- 2013-08-25 08:03:14 - __MAKE_CONF=/dev/null TB --- 2013-08-25 08:03:14 - cd /src TB --- 2013-08-25 08:03:14 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_SDROOT >>> Kernel build for BERI_DE4_SDROOT started on Sun Aug 25 08:03:14 UTC 2013 >>> 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 BERI_DE4_SDROOT completed on Sun Aug 25 08:05:38 UTC 2013 TB --- 2013-08-25 08:05:38 - cd /src/sys/mips/conf TB --- 2013-08-25 08:05:38 - /usr/sbin/config -m BERI_SIM_MDROOT TB --- 2013-08-25 08:05:38 - building BERI_SIM_MDROOT kernel TB --- 2013-08-25 08:05:38 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 08:05:38 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 08:05:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 08:05:38 - SRCCONF=/dev/null TB --- 2013-08-25 08:05:38 - TARGET=mips TB --- 2013-08-25 08:05:38 - TARGET_ARCH=mips64 TB --- 2013-08-25 08:05:38 - TZ=UTC TB --- 2013-08-25 08:05:38 - __MAKE_CONF=/dev/null TB --- 2013-08-25 08:05:38 - cd /src TB --- 2013-08-25 08:05:38 - /usr/bin/make -B buildkernel KERNCONF=BERI_SIM_MDROOT >>> Kernel build for BERI_SIM_MDROOT started on Sun Aug 25 08:05:38 UTC 2013 >>> 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 BERI_SIM_MDROOT completed on Sun Aug 25 08:07:55 UTC 2013 TB --- 2013-08-25 08:07:55 - cd /src/sys/mips/conf TB --- 2013-08-25 08:07:55 - /usr/sbin/config -m BERI_TEMPLATE TB --- 2013-08-25 08:07:55 - building BERI_TEMPLATE kernel TB --- 2013-08-25 08:07:55 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 08:07:55 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 08:07:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 08:07:55 - SRCCONF=/dev/null TB --- 2013-08-25 08:07:55 - TARGET=mips TB --- 2013-08-25 08:07:55 - TARGET_ARCH=mips64 TB --- 2013-08-25 08:07:55 - TZ=UTC TB --- 2013-08-25 08:07:55 - __MAKE_CONF=/dev/null TB --- 2013-08-25 08:07:55 - cd /src TB --- 2013-08-25 08:07:55 - /usr/bin/make -B buildkernel KERNCONF=BERI_TEMPLATE >>> Kernel build for BERI_TEMPLATE started on Sun Aug 25 08:07:56 UTC 2013 >>> 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 BERI_TEMPLATE completed on Sun Aug 25 08:10:14 UTC 2013 TB --- 2013-08-25 08:10:14 - cd /src/sys/mips/conf TB --- 2013-08-25 08:10:14 - /usr/sbin/config -m CARAMBOLA2 TB --- 2013-08-25 08:10:14 - skipping CARAMBOLA2 kernel TB --- 2013-08-25 08:10:14 - cd /src/sys/mips/conf TB --- 2013-08-25 08:10:14 - /usr/sbin/config -m DB120 TB --- 2013-08-25 08:10:14 - skipping DB120 kernel TB --- 2013-08-25 08:10:14 - cd /src/sys/mips/conf TB --- 2013-08-25 08:10:14 - /usr/sbin/config -m DIR-825 TB --- 2013-08-25 08:10:14 - skipping DIR-825 kernel TB --- 2013-08-25 08:10:14 - cd /src/sys/mips/conf TB --- 2013-08-25 08:10:14 - /usr/sbin/config -m ENH200 TB --- 2013-08-25 08:10:14 - skipping ENH200 kernel TB --- 2013-08-25 08:10:14 - cd /src/sys/mips/conf TB --- 2013-08-25 08:10:14 - /usr/sbin/config -m GXEMUL TB --- 2013-08-25 08:10:14 - building GXEMUL kernel TB --- 2013-08-25 08:10:14 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 08:10:14 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 08:10:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 08:10:14 - SRCCONF=/dev/null TB --- 2013-08-25 08:10:14 - TARGET=mips TB --- 2013-08-25 08:10:14 - TARGET_ARCH=mips64 TB --- 2013-08-25 08:10:14 - TZ=UTC TB --- 2013-08-25 08:10:14 - __MAKE_CONF=/dev/null TB --- 2013-08-25 08:10:14 - cd /src TB --- 2013-08-25 08:10:14 - /usr/bin/make -B buildkernel KERNCONF=GXEMUL >>> Kernel build for GXEMUL started on Sun Aug 25 08:10:14 UTC 2013 >>> 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 GXEMUL completed on Sun Aug 25 08:12:15 UTC 2013 TB --- 2013-08-25 08:12:15 - cd /src/sys/mips/conf TB --- 2013-08-25 08:12:15 - /usr/sbin/config -m IDT TB --- 2013-08-25 08:12:15 - skipping IDT kernel TB --- 2013-08-25 08:12:15 - cd /src/sys/mips/conf TB --- 2013-08-25 08:12:15 - /usr/sbin/config -m MALTA TB --- 2013-08-25 08:12:15 - skipping MALTA kernel TB --- 2013-08-25 08:12:15 - cd /src/sys/mips/conf TB --- 2013-08-25 08:12:15 - /usr/sbin/config -m MALTA64 TB --- 2013-08-25 08:12:15 - skipping MALTA64 kernel TB --- 2013-08-25 08:12:15 - cd /src/sys/mips/conf TB --- 2013-08-25 08:12:15 - /usr/sbin/config -m OCTEON1 TB --- 2013-08-25 08:12:15 - building OCTEON1 kernel TB --- 2013-08-25 08:12:15 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 08:12:15 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 08:12:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 08:12:15 - SRCCONF=/dev/null TB --- 2013-08-25 08:12:15 - TARGET=mips TB --- 2013-08-25 08:12:15 - TARGET_ARCH=mips64 TB --- 2013-08-25 08:12:15 - TZ=UTC TB --- 2013-08-25 08:12:15 - __MAKE_CONF=/dev/null TB --- 2013-08-25 08:12:15 - cd /src TB --- 2013-08-25 08:12:15 - /usr/bin/make -B buildkernel KERNCONF=OCTEON1 >>> Kernel build for OCTEON1 started on Sun Aug 25 08:12:15 UTC 2013 >>> 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 -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=octeon -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/dev/vr/if_vr.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 -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=octeon -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/dev/vx/if_vx.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 -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=octeon -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/dev/vx/if_vx_pci.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 -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=octeon -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/dev/watchdog/watchdog.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 -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=octeon -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/dev/wb/if_wb.c cc1: warnings being treated as errors /src/sys/dev/wb/if_wb.c: In function 'wb_newbuf': /src/sys/dev/wb/if_wb.c:850: warning: passing argument 4 of 'm_extadd' from incompatible pointer type *** Error code 1 Stop. bmake[1]: stopped in /obj/mips.mips64/src/sys/OCTEON1 *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-25 08:15:57 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-25 08:15:57 - ERROR: failed to build OCTEON1 kernel TB --- 2013-08-25 08:15:57 - 3420.05 user 748.40 system 4802.20 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips64-mips.full From owner-freebsd-current@FreeBSD.ORG Sun Aug 25 08:43:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 20DDEAA2; Sun, 25 Aug 2013 08:43:42 +0000 (UTC) (envelope-from hps@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id CE122214C; Sun, 25 Aug 2013 08:43:41 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta.bitpro.no (Postfix) with ESMTP id ED1E97A352; Sun, 25 Aug 2013 10:43:33 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id B53448EFECD; Sun, 25 Aug 2013 10:43:45 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGh1tbsCFEfw; Sun, 25 Aug 2013 10:43:45 +0200 (CEST) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) by mail.lockless.no (Postfix) with ESMTPSA id 212968EFECC; Sun, 25 Aug 2013 10:43:45 +0200 (CEST) Message-ID: <5219C3FF.1070509@bitfrost.no> Date: Sun, 25 Aug 2013 10:44:47 +0200 From: Hans Petter Selasky Organization: Bitfrost A/S User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130522 Thunderbird/17.0.6 MIME-Version: 1.0 To: George Mitchell Subject: Re: ulpt can't attach Lexmark E120 References: <5105527F.3010708@m5p.com> <201301271915.47712.hselasky@c2i.net> <510570C1.1060607@m5p.com> <201301272007.30682.hselasky@c2i.net> <5105AB16.2000607@m5p.com> <5215F4DF.6000305@m5p.com> <5215F743.8060403@bitfrost.no> <5216ACE5.7000500@m5p.com> <5216FE9F.2030608@bitfrost.no> <52174378.2020101@m5p.com> <521801E5.9000309@m5p.com> <52184F59.5080100@bitfrost.no> <5218F993.9050504@m5p.com> In-Reply-To: <5218F993.9050504@m5p.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Aug 2013 08:43:42 -0000 On 08/24/13 20:21, George Mitchell wrote: > > Setting hw.usb.dwc_otg.debug to any value greater than 0 generates an > unending stream of debug output and effectively locks up the chip > scrolling the output on the display. Perhaps there are some specific > debug messages I could put in ... -- George Hi, Can you try this patch: http://svnweb.freebsd.org/changeset/base/254828 --HPS From owner-freebsd-current@FreeBSD.ORG Sun Aug 25 09:24:09 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 18501276; Sun, 25 Aug 2013 09:24:09 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E03A72313; Sun, 25 Aug 2013 09:24:08 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r7P9O7I9083405; Sun, 25 Aug 2013 05:24:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r7P9O7a1083402; Sun, 25 Aug 2013 09:24:07 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 25 Aug 2013 09:24:07 GMT Message-Id: <201308250924.r7P9O7a1083402@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 , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 09:24:09 -0000 TB --- 2013-08-25 05:51:43 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-25 05:51:43 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-08-25 05:51:43 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-08-25 05:51:43 - cleaning the object tree TB --- 2013-08-25 05:53:05 - /usr/local/bin/svn stat /src TB --- 2013-08-25 05:53:13 - At svn revision 254824 TB --- 2013-08-25 05:53:14 - building world TB --- 2013-08-25 05:53:14 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 05:53:14 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 05:53:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 05:53:14 - SRCCONF=/dev/null TB --- 2013-08-25 05:53:14 - TARGET=pc98 TB --- 2013-08-25 05:53:14 - TARGET_ARCH=i386 TB --- 2013-08-25 05:53:14 - TZ=UTC TB --- 2013-08-25 05:53:14 - __MAKE_CONF=/dev/null TB --- 2013-08-25 05:53:14 - cd /src TB --- 2013-08-25 05:53:14 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Aug 25 05:53:23 UTC 2013 >>> 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 Aug 25 09:12:19 UTC 2013 TB --- 2013-08-25 09:12:20 - generating LINT kernel config TB --- 2013-08-25 09:12:20 - cd /src/sys/pc98/conf TB --- 2013-08-25 09:12:20 - /usr/bin/make -B LINT TB --- 2013-08-25 09:12:20 - cd /src/sys/pc98/conf TB --- 2013-08-25 09:12:20 - /usr/sbin/config -m LINT TB --- 2013-08-25 09:12:20 - building LINT kernel TB --- 2013-08-25 09:12:20 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 09:12:20 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 09:12:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 09:12:20 - SRCCONF=/dev/null TB --- 2013-08-25 09:12:20 - TARGET=pc98 TB --- 2013-08-25 09:12:20 - TARGET_ARCH=i386 TB --- 2013-08-25 09:12:20 - TZ=UTC TB --- 2013-08-25 09:12:20 - __MAKE_CONF=/dev/null TB --- 2013-08-25 09:12:20 - cd /src TB --- 2013-08-25 09:12:20 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Aug 25 09:12:20 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /src/sys/sys/mbuf.h:760:50: note: expanded from macro 'MEXTADD' (void )m_extadd((m), (caddr_t)(buf), (size), (free), (arg1), (arg2),\ ^~~~~~ /src/sys/sys/mbuf.h:898:14: note: passing argument to parameter here void (*)(struct mbuf *, void *, void *), void *, void *, ^ 1 error generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/pc98.i386/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-25 09:24:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-25 09:24:07 - ERROR: failed to build LINT kernel TB --- 2013-08-25 09:24:07 - 10202.73 user 1407.87 system 12744.07 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sun Aug 25 10:09:16 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4D5D166B; Sun, 25 Aug 2013 10:09:16 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 18F65251D; Sun, 25 Aug 2013 10:09:15 +0000 (UTC) Received: from [192.168.0.2] (cpc27-cmbg15-2-0-cust235.5-4.cable.virginmedia.com [86.27.188.236]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r7PA92QG021103 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 25 Aug 2013 10:09:03 GMT (envelope-from theraven@freebsd.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: GCC withdraw From: David Chisnall In-Reply-To: <20130824230615.GA55855@troutmask.apl.washington.edu> Date: Sun, 25 Aug 2013 11:08:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1C36387A-B744-4E05-892E-AE2581D7E1ED@freebsd.org> References: <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> <20130824115158.GA88999@zxy.spb.ru> <20130824154217.GE3796@zxy.spb.ru> <20130824224204.GH3796@zxy.spb.ru> <20130824230615.GA55855@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.1508) Cc: "Sam Fourman Jr." , toolchain@freebsd.org, Boris Samorodov , FreeBSD Current , Slawa Olhovchenkov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Aug 2013 10:09:16 -0000 On 25 Aug 2013, at 00:06, Steve Kargl = wrote: > On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote: >> On 24 Aug 2013, at 23:42, Slawa Olhovchenkov wrote: >>=20 >>> And i found PR about clang and mplayer: ports/176272 >>> This PR contains log with build error log. >>=20 >> Please file clang bugs at http://llvm.org/bugs/ >>=20 >=20 > As if this is going to help. >=20 > http://llvm.org/bugs/show_bug.cgi?id=3D8532 >=20 > 2 years, 9 month and counting. This bug relates to a corner case in complex floating point support, = which GCC in base doesn't get right either, and which affects a tiny = proportion of users and which comes with a hypothetical test case but no = evidence that any real-world code is affected by it. If you have some = real-world code that is compiled correctly by GCC but incorrectly by = clang as a result of this, then please update the bug. Oh, and it's worth noting that clang, as an extension, supports using = initialiser lists to create complex values and so this particular case = is trivial to avoid if you use this feature, which you will if you = create complex numbers using the macro that the C specification = introduced specifically to avoid this case. =20 David From owner-freebsd-current@FreeBSD.ORG Sun Aug 25 10:37:13 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E8236C65; Sun, 25 Aug 2013 10:37:12 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AEDBC2657; Sun, 25 Aug 2013 10:37:12 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r7PAbBxT070399; Sun, 25 Aug 2013 06:37:11 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r7PAbB2R070383; Sun, 25 Aug 2013 10:37:11 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 25 Aug 2013 10:37:11 GMT Message-Id: <201308251037.r7PAbB2R070383@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 , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 10:37:13 -0000 TB --- 2013-08-25 09:24:08 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-25 09:24:08 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-08-25 09:24:08 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-08-25 09:24:08 - cleaning the object tree TB --- 2013-08-25 09:25:11 - /usr/local/bin/svn stat /src TB --- 2013-08-25 09:25:17 - At svn revision 254824 TB --- 2013-08-25 09:25:18 - building world TB --- 2013-08-25 09:25:18 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 09:25:18 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 09:25:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 09:25:18 - SRCCONF=/dev/null TB --- 2013-08-25 09:25:18 - TARGET=sparc64 TB --- 2013-08-25 09:25:18 - TARGET_ARCH=sparc64 TB --- 2013-08-25 09:25:18 - TZ=UTC TB --- 2013-08-25 09:25:18 - __MAKE_CONF=/dev/null TB --- 2013-08-25 09:25:18 - cd /src TB --- 2013-08-25 09:25:18 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Aug 25 09:25:25 UTC 2013 >>> 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 Aug 25 10:28:57 UTC 2013 TB --- 2013-08-25 10:28:57 - generating LINT kernel config TB --- 2013-08-25 10:28:57 - cd /src/sys/sparc64/conf TB --- 2013-08-25 10:28:57 - /usr/bin/make -B LINT TB --- 2013-08-25 10:28:57 - cd /src/sys/sparc64/conf TB --- 2013-08-25 10:28:57 - /usr/sbin/config -m LINT TB --- 2013-08-25 10:28:57 - building LINT kernel TB --- 2013-08-25 10:28:57 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 10:28:57 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 10:28:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 10:28:57 - SRCCONF=/dev/null TB --- 2013-08-25 10:28:57 - TARGET=sparc64 TB --- 2013-08-25 10:28:57 - TARGET_ARCH=sparc64 TB --- 2013-08-25 10:28:57 - TZ=UTC TB --- 2013-08-25 10:28:57 - __MAKE_CONF=/dev/null TB --- 2013-08-25 10:28:57 - cd /src TB --- 2013-08-25 10:28:57 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Aug 25 10:28:57 UTC 2013 >>> 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 -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/vxge/vxgehal/vxgehal-virtualpath.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 -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/vxge/vxgehal/vxgehal-channel.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 -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/vxge/vxgehal/vxgehal-fifo.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 -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/watchdog/watchdog.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 -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/wb/if_wb.c cc1: warnings being treated as errors /src/sys/dev/wb/if_wb.c: In function 'wb_newbuf': /src/sys/dev/wb/if_wb.c:850: warning: passing argument 4 of 'm_extadd' from incompatible pointer type *** Error code 1 Stop. bmake[1]: stopped in /obj/sparc64.sparc64/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-25 10:37:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-25 10:37:11 - ERROR: failed to build LINT kernel TB --- 2013-08-25 10:37:11 - 3625.84 user 638.20 system 4383.19 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sun Aug 25 10:41:49 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3F7E5DB9; Sun, 25 Aug 2013 10:41:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 066592695; Sun, 25 Aug 2013 10:41:47 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r7PAfl7u087102; Sun, 25 Aug 2013 06:41:47 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r7PAfllB087101; Sun, 25 Aug 2013 10:41:47 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 25 Aug 2013 10:41:47 GMT Message-Id: <201308251041.r7PAfllB087101@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 , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 10:41:49 -0000 TB --- 2013-08-25 07:58:36 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-25 07:58:36 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-08-25 07:58:36 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-08-25 07:58:36 - cleaning the object tree TB --- 2013-08-25 07:59:40 - /usr/local/bin/svn stat /src TB --- 2013-08-25 07:59:54 - At svn revision 254824 TB --- 2013-08-25 07:59:55 - building world TB --- 2013-08-25 07:59:55 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 07:59:55 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 07:59:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 07:59:55 - SRCCONF=/dev/null TB --- 2013-08-25 07:59:55 - TARGET=powerpc TB --- 2013-08-25 07:59:55 - TARGET_ARCH=powerpc TB --- 2013-08-25 07:59:55 - TZ=UTC TB --- 2013-08-25 07:59:55 - __MAKE_CONF=/dev/null TB --- 2013-08-25 07:59:55 - cd /src TB --- 2013-08-25 07:59:55 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Aug 25 08:00:02 UTC 2013 >>> 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 Aug 25 10:35:34 UTC 2013 TB --- 2013-08-25 10:35:34 - generating LINT kernel config TB --- 2013-08-25 10:35:34 - cd /src/sys/powerpc/conf TB --- 2013-08-25 10:35:34 - /usr/bin/make -B LINT TB --- 2013-08-25 10:35:34 - cd /src/sys/powerpc/conf TB --- 2013-08-25 10:35:34 - /usr/sbin/config -m LINT TB --- 2013-08-25 10:35:34 - building LINT kernel TB --- 2013-08-25 10:35:34 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 10:35:34 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 10:35:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 10:35:34 - SRCCONF=/dev/null TB --- 2013-08-25 10:35:34 - TARGET=powerpc TB --- 2013-08-25 10:35:34 - TARGET_ARCH=powerpc TB --- 2013-08-25 10:35:34 - TZ=UTC TB --- 2013-08-25 10:35:34 - __MAKE_CONF=/dev/null TB --- 2013-08-25 10:35:34 - cd /src TB --- 2013-08-25 10:35:34 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Aug 25 10:35:34 UTC 2013 >>> 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 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/vxge/vxgehal/vxgehal-virtualpath.c cc -c -O -pipe -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 -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/vxge/vxgehal/vxgehal-channel.c cc -c -O -pipe -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 -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/vxge/vxgehal/vxgehal-fifo.c cc -c -O -pipe -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 -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/watchdog/watchdog.c cc -c -O -pipe -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 -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/wb/if_wb.c cc1: warnings being treated as errors /src/sys/dev/wb/if_wb.c: In function 'wb_newbuf': /src/sys/dev/wb/if_wb.c:850: warning: passing argument 4 of 'm_extadd' from incompatible pointer type *** Error code 1 Stop. bmake[1]: stopped in /obj/powerpc.powerpc/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-25 10:41:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-25 10:41:47 - ERROR: failed to build LINT kernel TB --- 2013-08-25 10:41:47 - 8378.56 user 1047.80 system 9790.84 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Aug 25 11:40:53 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7C3BED1; Sun, 25 Aug 2013 11:40:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 42D21292B; Sun, 25 Aug 2013 11:40:52 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r7PBepmH095755; Sun, 25 Aug 2013 07:40:51 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r7PBepLC095754; Sun, 25 Aug 2013 11:40:51 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 25 Aug 2013 11:40:51 GMT Message-Id: <201308251140.r7PBepLC095754@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 , , Subject: [head tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 11:40:53 -0000 TB --- 2013-08-25 08:15:57 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-25 08:15:57 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-08-25 08:15:57 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-08-25 08:15:57 - cleaning the object tree TB --- 2013-08-25 08:17:40 - /usr/local/bin/svn stat /src TB --- 2013-08-25 08:17:44 - At svn revision 254824 TB --- 2013-08-25 08:17:45 - building world TB --- 2013-08-25 08:17:45 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 08:17:45 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 08:17:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 08:17:45 - SRCCONF=/dev/null TB --- 2013-08-25 08:17:45 - TARGET=powerpc TB --- 2013-08-25 08:17:45 - TARGET_ARCH=powerpc64 TB --- 2013-08-25 08:17:45 - TZ=UTC TB --- 2013-08-25 08:17:45 - __MAKE_CONF=/dev/null TB --- 2013-08-25 08:17:45 - cd /src TB --- 2013-08-25 08:17:45 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Aug 25 08:17:52 UTC 2013 >>> 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 Aug 25 11:22:45 UTC 2013 TB --- 2013-08-25 11:22:45 - generating LINT kernel config TB --- 2013-08-25 11:22:45 - cd /src/sys/powerpc/conf TB --- 2013-08-25 11:22:45 - /usr/bin/make -B LINT TB --- 2013-08-25 11:22:45 - cd /src/sys/powerpc/conf TB --- 2013-08-25 11:22:45 - /usr/sbin/config -m LINT TB --- 2013-08-25 11:22:45 - skipping LINT kernel TB --- 2013-08-25 11:22:45 - cd /src/sys/powerpc/conf TB --- 2013-08-25 11:22:45 - /usr/sbin/config -m GENERIC TB --- 2013-08-25 11:22:45 - skipping GENERIC kernel TB --- 2013-08-25 11:22:45 - cd /src/sys/powerpc/conf TB --- 2013-08-25 11:22:45 - /usr/sbin/config -m GENERIC64 TB --- 2013-08-25 11:22:45 - building GENERIC64 kernel TB --- 2013-08-25 11:22:45 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 11:22:45 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 11:22:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 11:22:45 - SRCCONF=/dev/null TB --- 2013-08-25 11:22:45 - TARGET=powerpc TB --- 2013-08-25 11:22:45 - TARGET_ARCH=powerpc64 TB --- 2013-08-25 11:22:45 - TZ=UTC TB --- 2013-08-25 11:22:45 - __MAKE_CONF=/dev/null TB --- 2013-08-25 11:22:45 - cd /src TB --- 2013-08-25 11:22:45 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64 >>> Kernel build for GENERIC64 started on Sun Aug 25 11:22:45 UTC 2013 >>> 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 -Bshareable -d -warn-common -o if_vx.ko.debug if_vx.kld objcopy --only-keep-debug if_vx.ko.debug if_vx.ko.symbols objcopy --strip-debug --add-gnu-debuglink=if_vx.ko.symbols if_vx.ko.debug if_vx.ko ===> wb (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/wb/../../dev/wb/if_wb.c cc1: warnings being treated as errors /src/sys/modules/wb/../../dev/wb/if_wb.c: In function 'wb_newbuf': /src/sys/modules/wb/../../dev/wb/if_wb.c:850: warning: passing argument 4 of 'm_extadd' from incompatible pointer type *** Error code 1 Stop. bmake[3]: stopped in /src/sys/modules/wb *** Error code 1 Stop. bmake[2]: stopped in /src/sys/modules *** Error code 1 Stop. bmake[1]: stopped in /obj/powerpc.powerpc64/src/sys/GENERIC64 *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-25 11:40:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-25 11:40:51 - ERROR: failed to build GENERIC64 kernel TB --- 2013-08-25 11:40:51 - 10664.60 user 1343.78 system 12293.93 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Aug 25 14:19:46 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 870CD7FD; Sun, 25 Aug 2013 14:19:46 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.net (aran.keltia.net [88.191.250.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4BCA32FAC; Sun, 25 Aug 2013 14:19:45 +0000 (UTC) Received: from lonrach.local (unknown [IPv6:2a01:e34:ee87:4a00:fc3e:26b0:e8f8:2c6]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix) with ESMTPSA id 28B7E52AE; Sun, 25 Aug 2013 16:19:47 +0200 (CEST) Date: Sun, 25 Aug 2013 16:19:42 +0200 From: Ollivier Robert To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: patch to improve AES-NI performance Message-ID: <20130825141942.GB19969@lonrach.local> References: <20130822202027.GH94127@funkthat.com> <20130823151615.GD41379@roberto02-aw.erc.corp.eurocontrol.int> <20130823180413.GL94127@funkthat.com> <20130823182752.GA15392@lonrach.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130823182752.GA15392@lonrach.local> X-Operating-System: MacOS X / MBP 4,1 - FreeBSD 8.0 / T3500-E5520 Nehalem User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Aug 2013 14:19:46 -0000 According to Ollivier Robert: > You are right, I wanted to say r226837 which is the "code" one. FYI I've finally merged r226837,r226839 as r254856 in stable/9 as it is a prerequesite to apply jmg's patch. I've asked re@ whether they would consider this for 9.2. It is very late in the 9.2 release circle but that patch has been in 10 for more than a year now... -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From owner-freebsd-current@FreeBSD.ORG Sun Aug 25 14:21:15 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 67B75A0C; Sun, 25 Aug 2013 14:21:15 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 37AFC2FF1; Sun, 25 Aug 2013 14:21:15 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VDbBp-000OyN-U0; Sun, 25 Aug 2013 14:21:14 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r7PEL9v9050618; Sun, 25 Aug 2013 08:21:09 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/1Gz/VK1ocXq4RluFl/ePH Subject: Re: GCC withdraw From: Ian Lepore To: David Chisnall In-Reply-To: References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> <20130824115158.GA88999@zxy.spb.ru> <20130824154217.GE3796@zxy.spb.ru> <20130824224204.GH3796@zxy.spb.ru> Content-Type: text/plain; charset="us-ascii" Date: Sun, 25 Aug 2013 08:21:09 -0600 Message-ID: <1377440469.1111.124.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "Sam Fourman Jr." , toolchain@FreeBSD.org, Boris Samorodov , FreeBSD Current , Slawa Olhovchenkov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Aug 2013 14:21:15 -0000 On Sat, 2013-08-24 at 23:44 +0100, David Chisnall wrote: > On 24 Aug 2013, at 23:42, Slawa Olhovchenkov wrote: > > > And i found PR about clang and mplayer: ports/176272 > > This PR contains log with build error log. > > Please file clang bugs at http://llvm.org/bugs/ > > David > And THIS is a major reason why FreeBSD needs a compiler in base instead of all tools being ports. The last thing we need is to start responding to every problem with "this is not my problem, go file a report upstream." If we're already doing it for the compiler that's supposed to be the new supported tool, how much worse will peoples' experience be when we assert no ownership or responsibility for a toolchain at all? -- Ian From owner-freebsd-current@FreeBSD.ORG Sun Aug 25 15:30:36 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AF2D7C9F; Sun, 25 Aug 2013 15:30:36 +0000 (UTC) (envelope-from erik+lists@cederstrand.dk) Received: from csmtp2.one.com (csmtp2.one.com [91.198.169.22]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 681532363; Sun, 25 Aug 2013 15:30:36 +0000 (UTC) Received: from [192.168.1.69] (unknown [176.222.238.90]) by csmtp2.one.com (Postfix) with ESMTPA id A575310947; Sun, 25 Aug 2013 15:24:23 +0000 (UTC) Received: from [192.168.1.69] ([UNAVAILABLE]. [176.222.238.90]) (using TLSv1 with cipher AES128-SHA) by 0.0.0.0:587 (trex/4.8.87); Sun, 25 Aug 2013 15:16:42 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: GCC withdraw From: Erik Cederstrand In-Reply-To: <1377440469.1111.124.camel@revolution.hippie.lan> Date: Sun, 25 Aug 2013 17:24:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> <20130824115158.GA88999@zxy.spb.ru> <20130824154217.GE3796@zxy.spb.ru> <20130824224204.GH3796@zxy.spb.ru> <1377440469.1111.124.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1508) Cc: FreeBSD Current , David Chisnall , toolchain@FreeBSD.org, Slawa Olhovchenkov , "Sam Fourman Jr." , Boris Samorodov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Aug 2013 15:30:36 -0000 Den 25/08/2013 kl. 16.21 skrev Ian Lepore : >> Please file clang bugs at http://llvm.org/bugs/ >=20 > And THIS is a major reason why FreeBSD needs a compiler in base = instead > of all tools being ports. The last thing we need is to start = responding > to every problem with "this is not my problem, go file a report > upstream." If we're already doing it for the compiler that's supposed > to be the new supported tool, how much worse will peoples' experience = be > when we assert no ownership or responsibility for a toolchain at all? I think it's perfectly reasonable to direct compilation problems in a = program residing in ports to the developers of the compiler. It really = has nothing to do with the FreeBSD base compiler. The reason being that = mplayer relies on a non-docmented GCC-specific asm side-effect, and = there's a one-line patch in the PR which solves the problem, makes the = claim even more absurd. Expecting FreeBSD Clang maintainers to respond to compilation issues in = FreeBSD base seems perfectly reasonable. Expecting them to respond to = random issues in the ~24.000 ports is not. Erik= From owner-freebsd-current@FreeBSD.ORG Sun Aug 25 15:46:35 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BA07B2AE; Sun, 25 Aug 2013 15:46:35 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 70DB62429; Sun, 25 Aug 2013 15:46:35 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1VDcYR-0009YD-LY; Sun, 25 Aug 2013 19:48:39 +0400 Date: Sun, 25 Aug 2013 19:48:39 +0400 From: Slawa Olhovchenkov To: Erik Cederstrand Subject: Re: GCC withdraw Message-ID: <20130825154839.GL3796@zxy.spb.ru> References: <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> <20130824115158.GA88999@zxy.spb.ru> <20130824154217.GE3796@zxy.spb.ru> <20130824224204.GH3796@zxy.spb.ru> <1377440469.1111.124.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: FreeBSD Current , Ian Lepore , David Chisnall , toolchain@FreeBSD.org, "Sam Fourman Jr." , Boris Samorodov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Aug 2013 15:46:35 -0000 On Sun, Aug 25, 2013 at 05:24:23PM +0200, Erik Cederstrand wrote: > Expecting FreeBSD Clang maintainers to respond to compilation issues > in FreeBSD base seems perfectly reasonable. Expecting them to > respond to random issues in the ~24.000 ports is not. OK, how FreeBSD Clang maintainers can respond to issue with firewire? I don't imagine how to do this. From owner-freebsd-current@FreeBSD.ORG Sun Aug 25 15:57:31 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 54D4D4F3; Sun, 25 Aug 2013 15:57:31 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3504D24B2; Sun, 25 Aug 2013 15:57:31 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id r7PFvUdn060144; Sun, 25 Aug 2013 08:57:30 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id r7PFvUdZ060143; Sun, 25 Aug 2013 08:57:30 -0700 (PDT) (envelope-from sgk) Date: Sun, 25 Aug 2013 08:57:30 -0700 From: Steve Kargl To: David Chisnall Subject: Re: GCC withdraw Message-ID: <20130825155730.GA59962@troutmask.apl.washington.edu> References: <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> <20130824115158.GA88999@zxy.spb.ru> <20130824154217.GE3796@zxy.spb.ru> <20130824224204.GH3796@zxy.spb.ru> <20130824230615.GA55855@troutmask.apl.washington.edu> <1C36387A-B744-4E05-892E-AE2581D7E1ED@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1C36387A-B744-4E05-892E-AE2581D7E1ED@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Sam Fourman Jr." , toolchain@freebsd.org, Boris Samorodov , FreeBSD Current , Slawa Olhovchenkov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Aug 2013 15:57:31 -0000 On Sun, Aug 25, 2013 at 11:08:57AM +0100, David Chisnall wrote: > On 25 Aug 2013, at 00:06, Steve Kargl wrote: > > > On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote: > >> On 24 Aug 2013, at 23:42, Slawa Olhovchenkov wrote: > >> > >>> And i found PR about clang and mplayer: ports/176272 > >>> This PR contains log with build error log. > >> > >> Please file clang bugs at http://llvm.org/bugs/ > >> > > > > As if this is going to help. > > > > http://llvm.org/bugs/show_bug.cgi?id=8532 > > > > 2 years, 9 month and counting. > > This bug relates to a corner case in complex floating point support, > which GCC in base doesn't get right either, GCC addressed issue in 4.5.0. I don't necessarily agree with the fix, but gcc did not ignore it. I understand why FreeBSD has not updated to a newer gcc base. > and which affects a tiny proportion of users yep, anyone using complex arithmetic. > and which comes with a hypothetical test case Of course, it is a trivial testcase. It was meant to be trivial to demonstrate the bug and aid the compiler writer in fixing it. > but no evidence that any real-world code is affected by it. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/147599 > If you have some real-world code that is compiled correctly > by GCC but incorrectly by clang as a result of this, then > please update the bug. Go read FreeBSD libm's code where I (and now others) had/have to jump through hoops with cpack[f|l] functions to avoid the problem. > Oh, and it's worth noting that clang, as an extension, supports > using initialiser lists to create complex values and so this > particular case is trivial to avoid if you use this feature, > which you will if you create complex numbers using the macro that > the C specification introduced specifically to avoid this case. See msun/src/math_private.h. But, the above is irrelevant. You missed my point, so to be blunt. Reporting the bug to llvm does not mean that it will be fixed. More importantly the problem with mplayer and clang should be reported/recorded in FreeBSD's bug database where others can find the issue when clang fails to build mplayer. The mplayer maintainer can either fix the problem or escaluate the issue upstream. -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Aug 25 17:27:10 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F1C06CE6; Sun, 25 Aug 2013 17:27:09 +0000 (UTC) (envelope-from edschouten@gmail.com) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 84C4E286E; Sun, 25 Aug 2013 17:27:09 +0000 (UTC) Received: by mail-ve0-f180.google.com with SMTP id pb11so1534524veb.25 for ; Sun, 25 Aug 2013 10:27:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=1mLuRBnKI+livrDmzutiZm202MdV30v4ZDJsh+YqD/E=; b=MyG89CwpW/Gm7p0S7cQcItWBjohu8Tj8YRyS5UjrBIpnweFCFLZdgh7mkkp/vqDxsa fJIQTufg43BJlUBG8L/zrzgxosjdQuLD6vBupTczBb+Qn0OGfXA1b6M2aSd+ennCxXNt 5Zj6kdmjYGXdjRNmd9kDnNJSurpxVC36Oq1gMFzIwSS1lXpA3xhRW63GdhR24KSBudJo nGKI7nmoME0ogdUFZ/Ob0pXSbd9FZCa+WfzHyKQx6HQLcarbmrufH6rhzMPUKm/4XU9u 8208G9xrPzvcouRLU3Qpha7BW1Ch1ZuaTk6A9tTWTE7dZHf7pRspYjed/uJ9B0na1wjA epuA== MIME-Version: 1.0 X-Received: by 10.58.208.130 with SMTP id me2mr10646209vec.13.1377451628565; Sun, 25 Aug 2013 10:27:08 -0700 (PDT) Sender: edschouten@gmail.com Received: by 10.220.115.206 with HTTP; Sun, 25 Aug 2013 10:27:08 -0700 (PDT) In-Reply-To: <1C36387A-B744-4E05-892E-AE2581D7E1ED@freebsd.org> References: <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> <20130824115158.GA88999@zxy.spb.ru> <20130824154217.GE3796@zxy.spb.ru> <20130824224204.GH3796@zxy.spb.ru> <20130824230615.GA55855@troutmask.apl.washington.edu> <1C36387A-B744-4E05-892E-AE2581D7E1ED@freebsd.org> Date: Sun, 25 Aug 2013 19:27:08 +0200 X-Google-Sender-Auth: z6sdrhT1CyRHIfUZtEwA02tKEeM Message-ID: Subject: Re: GCC withdraw From: Ed Schouten To: David Chisnall Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current , toolchain@freebsd.org, Steve Kargl , Slawa Olhovchenkov , "Sam Fourman Jr." , Boris Samorodov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Aug 2013 17:27:10 -0000 2013/8/25 David Chisnall : > Oh, and it's worth noting that clang, as an extension, supports using ini= tialiser lists to create complex values and so this particular case is triv= ial to avoid if you use this feature, which you will if you create complex = numbers using the macro that the C specification introduced specifically to= avoid this case. Or even better, use the C11 CMPLX()/CMPLXF()/CMPLXL() macros, which are properly supported by FreeBSD -HEAD. --=20 Ed Schouten From owner-freebsd-current@FreeBSD.ORG Sun Aug 25 18:28:16 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C75BAB19; Sun, 25 Aug 2013 18:28:16 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 491802B27; Sun, 25 Aug 2013 18:28:15 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r7PIS9u0073352; Sun, 25 Aug 2013 14:28:09 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r7PIS9fK073340; Sun, 25 Aug 2013 18:28:09 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 25 Aug 2013 18:28:09 GMT Message-Id: <201308251828.r7PIS9fK073340@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 , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 18:28:17 -0000 TB --- 2013-08-25 11:50:19 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-25 11:50:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-08-25 11:50:19 - starting HEAD tinderbox run for i386/i386 TB --- 2013-08-25 11:50:19 - cleaning the object tree TB --- 2013-08-25 11:55:12 - /usr/local/bin/svn stat /src TB --- 2013-08-25 11:55:16 - At svn revision 254849 TB --- 2013-08-25 11:55:17 - building world TB --- 2013-08-25 11:55:17 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 11:55:17 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 11:55:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 11:55:17 - SRCCONF=/dev/null TB --- 2013-08-25 11:55:17 - TARGET=i386 TB --- 2013-08-25 11:55:17 - TARGET_ARCH=i386 TB --- 2013-08-25 11:55:17 - TZ=UTC TB --- 2013-08-25 11:55:17 - __MAKE_CONF=/dev/null TB --- 2013-08-25 11:55:17 - cd /src TB --- 2013-08-25 11:55:17 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Aug 25 11:55:24 UTC 2013 >>> 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 Aug 25 15:06:40 UTC 2013 TB --- 2013-08-25 15:06:40 - generating LINT kernel config TB --- 2013-08-25 15:06:40 - cd /src/sys/i386/conf TB --- 2013-08-25 15:06:40 - /usr/bin/make -B LINT TB --- 2013-08-25 15:06:40 - cd /src/sys/i386/conf TB --- 2013-08-25 15:06:40 - /usr/sbin/config -m LINT TB --- 2013-08-25 15:06:40 - building LINT kernel TB --- 2013-08-25 15:06:40 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 15:06:40 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 15:06:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 15:06:40 - SRCCONF=/dev/null TB --- 2013-08-25 15:06:40 - TARGET=i386 TB --- 2013-08-25 15:06:40 - TARGET_ARCH=i386 TB --- 2013-08-25 15:06:40 - TZ=UTC TB --- 2013-08-25 15:06:40 - __MAKE_CONF=/dev/null TB --- 2013-08-25 15:06:40 - cd /src TB --- 2013-08-25 15:06:40 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Aug 25 15:06:40 UTC 2013 >>> 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 Aug 25 15:41:11 UTC 2013 TB --- 2013-08-25 15:41:11 - cd /src/sys/i386/conf TB --- 2013-08-25 15:41:11 - /usr/sbin/config -m LINT-NOINET TB --- 2013-08-25 15:41:11 - building LINT-NOINET kernel TB --- 2013-08-25 15:41:11 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 15:41:11 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 15:41:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 15:41:11 - SRCCONF=/dev/null TB --- 2013-08-25 15:41:11 - TARGET=i386 TB --- 2013-08-25 15:41:11 - TARGET_ARCH=i386 TB --- 2013-08-25 15:41:11 - TZ=UTC TB --- 2013-08-25 15:41:11 - __MAKE_CONF=/dev/null TB --- 2013-08-25 15:41:11 - cd /src TB --- 2013-08-25 15:41:11 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Sun Aug 25 15:41:11 UTC 2013 >>> 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-NOINET completed on Sun Aug 25 16:11:41 UTC 2013 TB --- 2013-08-25 16:11:41 - cd /src/sys/i386/conf TB --- 2013-08-25 16:11:41 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-08-25 16:11:41 - building LINT-NOINET6 kernel TB --- 2013-08-25 16:11:41 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 16:11:41 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 16:11:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 16:11:41 - SRCCONF=/dev/null TB --- 2013-08-25 16:11:41 - TARGET=i386 TB --- 2013-08-25 16:11:41 - TARGET_ARCH=i386 TB --- 2013-08-25 16:11:41 - TZ=UTC TB --- 2013-08-25 16:11:41 - __MAKE_CONF=/dev/null TB --- 2013-08-25 16:11:41 - cd /src TB --- 2013-08-25 16:11:41 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Sun Aug 25 16:11:41 UTC 2013 >>> 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-NOINET6 completed on Sun Aug 25 16:42:31 UTC 2013 TB --- 2013-08-25 16:42:31 - cd /src/sys/i386/conf TB --- 2013-08-25 16:42:31 - /usr/sbin/config -m LINT-NOIP TB --- 2013-08-25 16:42:31 - building LINT-NOIP kernel TB --- 2013-08-25 16:42:31 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 16:42:31 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 16:42:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 16:42:31 - SRCCONF=/dev/null TB --- 2013-08-25 16:42:31 - TARGET=i386 TB --- 2013-08-25 16:42:31 - TARGET_ARCH=i386 TB --- 2013-08-25 16:42:31 - TZ=UTC TB --- 2013-08-25 16:42:31 - __MAKE_CONF=/dev/null TB --- 2013-08-25 16:42:31 - cd /src TB --- 2013-08-25 16:42:31 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Sun Aug 25 16:42:32 UTC 2013 >>> 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-NOIP completed on Sun Aug 25 17:10:46 UTC 2013 TB --- 2013-08-25 17:10:46 - cd /src/sys/i386/conf TB --- 2013-08-25 17:10:46 - /usr/sbin/config -m LINT-VIMAGE TB --- 2013-08-25 17:10:46 - building LINT-VIMAGE kernel TB --- 2013-08-25 17:10:46 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 17:10:46 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 17:10:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 17:10:46 - SRCCONF=/dev/null TB --- 2013-08-25 17:10:46 - TARGET=i386 TB --- 2013-08-25 17:10:46 - TARGET_ARCH=i386 TB --- 2013-08-25 17:10:46 - TZ=UTC TB --- 2013-08-25 17:10:46 - __MAKE_CONF=/dev/null TB --- 2013-08-25 17:10:46 - cd /src TB --- 2013-08-25 17:10:46 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Sun Aug 25 17:10:46 UTC 2013 >>> 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-VIMAGE completed on Sun Aug 25 17:42:18 UTC 2013 TB --- 2013-08-25 17:42:18 - cd /src/sys/i386/conf TB --- 2013-08-25 17:42:18 - /usr/sbin/config -m GENERIC TB --- 2013-08-25 17:42:18 - building GENERIC kernel TB --- 2013-08-25 17:42:18 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 17:42:18 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 17:42:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 17:42:18 - SRCCONF=/dev/null TB --- 2013-08-25 17:42:18 - TARGET=i386 TB --- 2013-08-25 17:42:18 - TARGET_ARCH=i386 TB --- 2013-08-25 17:42:18 - TZ=UTC TB --- 2013-08-25 17:42:18 - __MAKE_CONF=/dev/null TB --- 2013-08-25 17:42:18 - cd /src TB --- 2013-08-25 17:42:18 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Aug 25 17:42:18 UTC 2013 >>> 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 Aug 25 18:12:34 UTC 2013 TB --- 2013-08-25 18:12:34 - cd /src/sys/i386/conf TB --- 2013-08-25 18:12:34 - /usr/sbin/config -m PAE TB --- 2013-08-25 18:12:34 - building PAE kernel TB --- 2013-08-25 18:12:34 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 18:12:34 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 18:12:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 18:12:34 - SRCCONF=/dev/null TB --- 2013-08-25 18:12:34 - TARGET=i386 TB --- 2013-08-25 18:12:34 - TARGET_ARCH=i386 TB --- 2013-08-25 18:12:34 - TZ=UTC TB --- 2013-08-25 18:12:34 - __MAKE_CONF=/dev/null TB --- 2013-08-25 18:12:34 - cd /src TB --- 2013-08-25 18:12:34 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Sun Aug 25 18:12:34 UTC 2013 >>> 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 PAE completed on Sun Aug 25 18:21:44 UTC 2013 TB --- 2013-08-25 18:21:44 - cd /src/sys/i386/conf TB --- 2013-08-25 18:21:44 - /usr/sbin/config -m XBOX TB --- 2013-08-25 18:21:44 - building XBOX kernel TB --- 2013-08-25 18:21:44 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 18:21:44 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 18:21:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 18:21:44 - SRCCONF=/dev/null TB --- 2013-08-25 18:21:44 - TARGET=i386 TB --- 2013-08-25 18:21:44 - TARGET_ARCH=i386 TB --- 2013-08-25 18:21:44 - TZ=UTC TB --- 2013-08-25 18:21:44 - __MAKE_CONF=/dev/null TB --- 2013-08-25 18:21:44 - cd /src TB --- 2013-08-25 18:21:44 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Sun Aug 25 18:21:45 UTC 2013 >>> 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 XBOX completed on Sun Aug 25 18:25:05 UTC 2013 TB --- 2013-08-25 18:25:05 - cd /src/sys/i386/conf TB --- 2013-08-25 18:25:05 - /usr/sbin/config -m XEN TB --- 2013-08-25 18:25:05 - building XEN kernel TB --- 2013-08-25 18:25:05 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 18:25:05 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 18:25:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 18:25:05 - SRCCONF=/dev/null TB --- 2013-08-25 18:25:05 - TARGET=i386 TB --- 2013-08-25 18:25:05 - TARGET_ARCH=i386 TB --- 2013-08-25 18:25:05 - TZ=UTC TB --- 2013-08-25 18:25:05 - __MAKE_CONF=/dev/null TB --- 2013-08-25 18:25:05 - cd /src TB --- 2013-08-25 18:25:05 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Sun Aug 25 18:25:05 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ^~~~~~~~~~~~~~~~~~~~~~ /src/sys/dev/xen/netback/netback.c:593:41: error: no member named 'header' in 'struct pkthdr' m->m_pkthdr.rcvif, m->m_pkthdr.header, m->m_pkthdr.len); ~~~~~~~~~~~ ^ /src/sys/dev/xen/netback/netback.c:598:31: error: format specifies type 'short' but the argument has type 'uint32_t' (aka 'unsigned int') [-Werror,-Wformat] m->m_len, m->m_flags, m->m_type); ^~~~~~~~~ 3 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/i386.i386/src/sys/XEN *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-25 18:28:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-25 18:28:09 - ERROR: failed to build XEN kernel TB --- 2013-08-25 18:28:09 - 18742.88 user 3240.68 system 23869.64 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sun Aug 25 18:49:57 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AF184D7B; Sun, 25 Aug 2013 18:49:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 63B832C19; Sun, 25 Aug 2013 18:49:57 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r7PInuat003284; Sun, 25 Aug 2013 14:49:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r7PInuM2003279; Sun, 25 Aug 2013 18:49:56 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 25 Aug 2013 18:49:56 GMT Message-Id: <201308251849.r7PInuM2003279@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 , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 18:49:57 -0000 TB --- 2013-08-25 11:50:19 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-25 11:50:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-08-25 11:50:19 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-08-25 11:50:19 - cleaning the object tree TB --- 2013-08-25 11:55:41 - /usr/local/bin/svn stat /src TB --- 2013-08-25 11:55:44 - At svn revision 254849 TB --- 2013-08-25 11:55:45 - building world TB --- 2013-08-25 11:55:45 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 11:55:45 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 11:55:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 11:55:45 - SRCCONF=/dev/null TB --- 2013-08-25 11:55:45 - TARGET=amd64 TB --- 2013-08-25 11:55:45 - TARGET_ARCH=amd64 TB --- 2013-08-25 11:55:45 - TZ=UTC TB --- 2013-08-25 11:55:45 - __MAKE_CONF=/dev/null TB --- 2013-08-25 11:55:45 - cd /src TB --- 2013-08-25 11:55:45 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Aug 25 11:55:51 UTC 2013 >>> 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 Aug 25 15:44:02 UTC 2013 TB --- 2013-08-25 15:44:02 - generating LINT kernel config TB --- 2013-08-25 15:44:02 - cd /src/sys/amd64/conf TB --- 2013-08-25 15:44:02 - /usr/bin/make -B LINT TB --- 2013-08-25 15:44:02 - cd /src/sys/amd64/conf TB --- 2013-08-25 15:44:02 - /usr/sbin/config -m LINT TB --- 2013-08-25 15:44:02 - building LINT kernel TB --- 2013-08-25 15:44:02 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 15:44:02 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 15:44:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 15:44:02 - SRCCONF=/dev/null TB --- 2013-08-25 15:44:02 - TARGET=amd64 TB --- 2013-08-25 15:44:02 - TARGET_ARCH=amd64 TB --- 2013-08-25 15:44:02 - TZ=UTC TB --- 2013-08-25 15:44:02 - __MAKE_CONF=/dev/null TB --- 2013-08-25 15:44:02 - cd /src TB --- 2013-08-25 15:44:02 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Aug 25 15:44:03 UTC 2013 >>> 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 Aug 25 16:15:04 UTC 2013 TB --- 2013-08-25 16:15:04 - cd /src/sys/amd64/conf TB --- 2013-08-25 16:15:04 - /usr/sbin/config -m LINT-NOINET TB --- 2013-08-25 16:15:04 - building LINT-NOINET kernel TB --- 2013-08-25 16:15:04 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 16:15:04 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 16:15:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 16:15:04 - SRCCONF=/dev/null TB --- 2013-08-25 16:15:04 - TARGET=amd64 TB --- 2013-08-25 16:15:04 - TARGET_ARCH=amd64 TB --- 2013-08-25 16:15:04 - TZ=UTC TB --- 2013-08-25 16:15:04 - __MAKE_CONF=/dev/null TB --- 2013-08-25 16:15:04 - cd /src TB --- 2013-08-25 16:15:04 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Sun Aug 25 16:15:04 UTC 2013 >>> 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-NOINET completed on Sun Aug 25 16:43:52 UTC 2013 TB --- 2013-08-25 16:43:52 - cd /src/sys/amd64/conf TB --- 2013-08-25 16:43:52 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-08-25 16:43:52 - building LINT-NOINET6 kernel TB --- 2013-08-25 16:43:52 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 16:43:52 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 16:43:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 16:43:52 - SRCCONF=/dev/null TB --- 2013-08-25 16:43:52 - TARGET=amd64 TB --- 2013-08-25 16:43:52 - TARGET_ARCH=amd64 TB --- 2013-08-25 16:43:52 - TZ=UTC TB --- 2013-08-25 16:43:52 - __MAKE_CONF=/dev/null TB --- 2013-08-25 16:43:52 - cd /src TB --- 2013-08-25 16:43:52 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Sun Aug 25 16:43:52 UTC 2013 >>> 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-NOINET6 completed on Sun Aug 25 17:13:28 UTC 2013 TB --- 2013-08-25 17:13:28 - cd /src/sys/amd64/conf TB --- 2013-08-25 17:13:28 - /usr/sbin/config -m LINT-NOIP TB --- 2013-08-25 17:13:28 - building LINT-NOIP kernel TB --- 2013-08-25 17:13:28 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 17:13:28 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 17:13:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 17:13:28 - SRCCONF=/dev/null TB --- 2013-08-25 17:13:28 - TARGET=amd64 TB --- 2013-08-25 17:13:28 - TARGET_ARCH=amd64 TB --- 2013-08-25 17:13:28 - TZ=UTC TB --- 2013-08-25 17:13:28 - __MAKE_CONF=/dev/null TB --- 2013-08-25 17:13:28 - cd /src TB --- 2013-08-25 17:13:28 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Sun Aug 25 17:13:29 UTC 2013 >>> 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-NOIP completed on Sun Aug 25 17:41:19 UTC 2013 TB --- 2013-08-25 17:41:19 - cd /src/sys/amd64/conf TB --- 2013-08-25 17:41:19 - /usr/sbin/config -m LINT-VIMAGE TB --- 2013-08-25 17:41:19 - building LINT-VIMAGE kernel TB --- 2013-08-25 17:41:19 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 17:41:19 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 17:41:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 17:41:19 - SRCCONF=/dev/null TB --- 2013-08-25 17:41:19 - TARGET=amd64 TB --- 2013-08-25 17:41:19 - TARGET_ARCH=amd64 TB --- 2013-08-25 17:41:19 - TZ=UTC TB --- 2013-08-25 17:41:19 - __MAKE_CONF=/dev/null TB --- 2013-08-25 17:41:19 - cd /src TB --- 2013-08-25 17:41:19 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Sun Aug 25 17:41:20 UTC 2013 >>> 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-VIMAGE completed on Sun Aug 25 18:12:19 UTC 2013 TB --- 2013-08-25 18:12:19 - cd /src/sys/amd64/conf TB --- 2013-08-25 18:12:19 - /usr/sbin/config -m GENERIC TB --- 2013-08-25 18:12:19 - building GENERIC kernel TB --- 2013-08-25 18:12:19 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 18:12:19 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 18:12:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 18:12:19 - SRCCONF=/dev/null TB --- 2013-08-25 18:12:19 - TARGET=amd64 TB --- 2013-08-25 18:12:19 - TARGET_ARCH=amd64 TB --- 2013-08-25 18:12:19 - TZ=UTC TB --- 2013-08-25 18:12:19 - __MAKE_CONF=/dev/null TB --- 2013-08-25 18:12:19 - cd /src TB --- 2013-08-25 18:12:19 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Aug 25 18:12:19 UTC 2013 >>> 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 Aug 25 18:40:57 UTC 2013 TB --- 2013-08-25 18:40:57 - cd /src/sys/amd64/conf TB --- 2013-08-25 18:40:57 - /usr/sbin/config -m XENHVM TB --- 2013-08-25 18:40:57 - building XENHVM kernel TB --- 2013-08-25 18:40:57 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 18:40:57 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 18:40:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 18:40:57 - SRCCONF=/dev/null TB --- 2013-08-25 18:40:57 - TARGET=amd64 TB --- 2013-08-25 18:40:57 - TARGET_ARCH=amd64 TB --- 2013-08-25 18:40:57 - TZ=UTC TB --- 2013-08-25 18:40:57 - __MAKE_CONF=/dev/null TB --- 2013-08-25 18:40:57 - cd /src TB --- 2013-08-25 18:40:57 - /usr/bin/make -B buildkernel KERNCONF=XENHVM >>> Kernel build for XENHVM started on Sun Aug 25 18:40:57 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ^~~~~~~~~~~~~~~~~~~~~~ /src/sys/dev/xen/netback/netback.c:593:41: error: no member named 'header' in 'struct pkthdr' m->m_pkthdr.rcvif, m->m_pkthdr.header, m->m_pkthdr.len); ~~~~~~~~~~~ ^ /src/sys/dev/xen/netback/netback.c:598:31: error: format specifies type 'short' but the argument has type 'uint32_t' (aka 'unsigned int') [-Werror,-Wformat] m->m_len, m->m_flags, m->m_type); ^~~~~~~~~ 3 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/amd64.amd64/src/sys/XENHVM *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-25 18:49:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-25 18:49:56 - ERROR: failed to build XENHVM kernel TB --- 2013-08-25 18:49:56 - 19676.56 user 3457.40 system 25176.47 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sun Aug 25 23:21:02 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DAA4E7E5; Sun, 25 Aug 2013 23:21:02 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9033C28A6; Sun, 25 Aug 2013 23:21:02 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r7PNKr1A081753; Sun, 25 Aug 2013 19:20:58 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <521A9155.5010102@m5p.com> Date: Sun, 25 Aug 2013 19:20:53 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130716 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hans Petter Selasky Subject: Re: ulpt can't attach Lexmark E120 References: <5105527F.3010708@m5p.com> <201301271915.47712.hselasky@c2i.net> <510570C1.1060607@m5p.com> <201301272007.30682.hselasky@c2i.net> <5105AB16.2000607@m5p.com> <5215F4DF.6000305@m5p.com> <5215F743.8060403@bitfrost.no> <5216ACE5.7000500@m5p.com> <5216FE9F.2030608@bitfrost.no> <52174378.2020101@m5p.com> <521801E5.9000309@m5p.com> <52184F59.5080100@bitfrost.no> <5218F993.9050504@m5p.com> <5219C3FF.1070509@bitfrost.no> In-Reply-To: <5219C3FF.1070509@bitfrost.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Sun, 25 Aug 2013 19:20:59 -0400 (EDT) Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Aug 2013 23:21:02 -0000 On 08/25/13 04:44, Hans Petter Selasky wrote: > On 08/24/13 20:21, George Mitchell wrote: >> >> Setting hw.usb.dwc_otg.debug to any value greater than 0 generates an >> unending stream of debug output and effectively locks up the chip >> scrolling the output on the display. Perhaps there are some specific >> debug messages I could put in ... -- George > > Hi, > > Can you try this patch: > > http://svnweb.freebsd.org/changeset/base/254828 > > --HPS > _______________________________________________ > [...] I started trying to do too many things at once, and as a result it's going to take me a little while to try this patch out. My apologies! -- George From owner-freebsd-current@FreeBSD.ORG Mon Aug 26 01:21:22 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 75A21787 for ; Mon, 26 Aug 2013 01:21:22 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3D49A2E43 for ; Mon, 26 Aug 2013 01:21:21 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id c10so4093751ieb.31 for ; Sun, 25 Aug 2013 18:21:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=zFSCZTwm61Z1Vz3wlW9j/MomllmS/YWf0kmxM5KFMnw=; b=lPAJKZms98Sxyq3otjygrCniJ8E0JULGRAT2h1rJEQA435QdhKrGfsBJvaQeZ2GCu0 uOyDjb0Cmgd27FLdWJfjy9PvkEvYGoOzd6tGTlpWeVzJSozFgb/b1EDPN7arDnNsRWwF d4tVdd5NNTdf3oSflbb84SWge7W80+A5g8HzpspQvSXgdcmLjU0R/wPMp4oa5CeOKfps IKm36VtJ/pJnSneFj2u4N5MfVFv1xJAmpeYKq8ZfLkZic//vCkTALjmHo5BW1VvXWw0P yUBQ8QuseCnwlSOGhlKyi9+MrWZb90Czq1qH2KNbpWnvspkyS5NZ/aMuAT8bLqRr1IPu /2Rg== X-Gm-Message-State: ALoCoQmLKgmVLtibgnOQXZypgwxZiVXftFyFKbxikDjJB8Iju1HFBZp5k19HJGXFwYZKlK12WLtX X-Received: by 10.50.50.210 with SMTP id e18mr5107090igo.9.1377480081355; Sun, 25 Aug 2013 18:21:21 -0700 (PDT) Received: from 130.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id cl4sm15015055igc.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 25 Aug 2013 18:21:20 -0700 (PDT) Sender: Warner Losh Subject: Re: patch to add AES intrinsics to gcc Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 25 Aug 2013 19:21:18 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <066F5ACF-F2EA-42FF-8D27-BFE20E20B501@bsdimp.com> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> <5217DBAB.5030607@freebsd.org> <86032E72-A569-4946-B4F8-26F687067B31@bsdimp.com> <1380949A-254A-4222-BEDE-0C23E16E4F67@freebsd.org> <8C31A000-6806-4291-98A4-E8291E637BD2@bsdimp.com> To: Gerald Pfeifer X-Mailer: Apple Mail (2.1085) Cc: Adrian Chadd , re@freebsd.org, current@freebsd.org, John-Mark Gurney , Alfred Perlstein , toolchain@freebsd.org, "Sam Fourman Jr." X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Aug 2013 01:21:22 -0000 On Aug 25, 2013, at 7:12 PM, Gerald Pfeifer wrote: > On Sat, 24 Aug 2013, Warner Losh wrote: >>> "If you push gcc out to a port, and you have the 'external compiler'=20= >>> toolchain support working correctly enough to build with this, why=20= >>> don't we just push clang out to a port, and be done with it?" >> This is a stupid idea. It kills the tightly integrated nature of=20 >> FreeBSD. I'd say it is far too radical a departure and opens up a=20 >> huge can of "which version of what compiler" nightmare that we've=20 >> largely dodged to date because we had one (or maybe two) compilers=20 >> in the base system. >=20 > I am working towards establishing lang/gcc as _the_ version of GCC > to use for ports. >=20 > Today I looked at a couple of those GCC cross-compilers we have in=20 > ports, and I have to admit I am not thrilled. Each of those I saw > copies a lot from (older version of my ports), each has a different > maintainer, each has some additions, and there is little consistency. >=20 > Are these the base of 'external compiler' toolchain support? Are > there any plans to increase consistency and reduce redundancy? In > an ideal world, could those become slave ports of lang/gcc? In my experience, this has grown up rather hap-hazardly. Some more order = here would be good. In the past, for example, some ports had some of the = FreeBSD fixes, but not all so while I could build FreeBSD/mips gcc out = of /usr/src, I couldn't do that, even for the (then current) gcc42 port = since some of the fixes hadn't made it up stream. In an ideal world, we'd be able to build any version of gcc for any = FreeBSD platform (or have it fail up front) so we can use that as an = external toolchain. The initial work I did for external toolchains, that Brooks reworked (or = rewrote from scratch, I can't recall which he did), was with make xdev = in the tree... And that has its own set of pros and cons... All of = which are really a tangent, so I'll leave it at that. Warner From owner-freebsd-current@FreeBSD.ORG Mon Aug 26 01:03:36 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 75BE0609; Mon, 26 Aug 2013 01:03:36 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from ainaz.pair.com (ainaz.pair.com [209.68.2.66]) by mx1.freebsd.org (Postfix) with ESMTP id 4F6C02D6F; Mon, 26 Aug 2013 01:03:36 +0000 (UTC) Received: from trevally.dhcp.nue.suse.com (charybdis-ext.suse.de [195.135.221.2]) by ainaz.pair.com (Postfix) with ESMTPSA id DC42F3F418; Sun, 25 Aug 2013 21:03:32 -0400 (EDT) Date: Mon, 26 Aug 2013 03:03:31 +0200 (CEST) From: Gerald Pfeifer To: =?ISO-8859-15?Q?Bernhard_Fr=F6hlich?= Subject: Re: patch to add AES intrinsics to gcc In-Reply-To: Message-ID: References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-646792075-1377479013=:3920" X-Mailman-Approved-At: Mon, 26 Aug 2013 02:40:05 +0000 Cc: toolchain@freebsd.org, John-Mark Gurney , David Chisnall , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Aug 2013 01:03:36 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-646792075-1377479013=:3920 Content-Type: TEXT/PLAIN; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT On Fri, 23 Aug 2013, Bernhard Fröhlich wrote: > A possible hack could be to add a check for USE_GCC=any to behave like > a USE_GCC=yes on HEAD on the affected platforms. This pulls in lang/gcc > from ports for a lot of people on HEAD I suppose. I am planning to work on this a bit more once the two patches I submitted to portmgr this weekend (updating math/mpc, updating lang/gcc and the default ports version of GCC from 4.6 to 4.7) have made it into the tree. That said, already today when USE_GCC=any is specified and /usr/bin/gcc does not exist, USE_GCC=any basically becomes USE_GCC=yes and uses a current version of GCC, lang/gcc by default unless a different version is installed. Is this not working for you? Is there anything else that you'd like to see in Mk/bsd.gcc.mk? Gerald --0-646792075-1377479013=:3920-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 26 01:12:33 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 90FFA6A8; Mon, 26 Aug 2013 01:12:33 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from ainaz.pair.com (ainaz.pair.com [209.68.2.66]) by mx1.freebsd.org (Postfix) with ESMTP id 64FF82DCE; Mon, 26 Aug 2013 01:12:33 +0000 (UTC) Received: from trevally.dhcp.nue.suse.com (charybdis-ext.suse.de [195.135.221.2]) by ainaz.pair.com (Postfix) with ESMTPSA id DF6BB3F419; Sun, 25 Aug 2013 21:12:31 -0400 (EDT) Date: Mon, 26 Aug 2013 03:12:30 +0200 (CEST) From: Gerald Pfeifer To: Warner Losh Subject: Re: patch to add AES intrinsics to gcc In-Reply-To: Message-ID: References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> <5217DBAB.5030607@freebsd.org> <86032E72-A569-4946-B4F8-26F687067B31@bsdimp.com> <1380949A-254A-4222-BEDE-0C23E16E4F67@freebsd.org> <8C31A000-6806-4291-98A4-E8291E637BD2@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Mon, 26 Aug 2013 02:40:14 +0000 Cc: Adrian Chadd , re@freebsd.org, current@freebsd.org, John-Mark Gurney , Alfred Perlstein , toolchain@freebsd.org, "Sam Fourman Jr." X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Aug 2013 01:12:33 -0000 On Sat, 24 Aug 2013, Warner Losh wrote: >> "If you push gcc out to a port, and you have the 'external compiler' >> toolchain support working correctly enough to build with this, why >> don't we just push clang out to a port, and be done with it?" > This is a stupid idea. It kills the tightly integrated nature of > FreeBSD. I'd say it is far too radical a departure and opens up a > huge can of "which version of what compiler" nightmare that we've > largely dodged to date because we had one (or maybe two) compilers > in the base system. I am working towards establishing lang/gcc as _the_ version of GCC to use for ports. Today I looked at a couple of those GCC cross-compilers we have in ports, and I have to admit I am not thrilled. Each of those I saw copies a lot from (older version of my ports), each has a different maintainer, each has some additions, and there is little consistency. Are these the base of 'external compiler' toolchain support? Are there any plans to increase consistency and reduce redundancy? In an ideal world, could those become slave ports of lang/gcc? Gerald From owner-freebsd-current@FreeBSD.ORG Mon Aug 26 01:27:53 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C4288922; Mon, 26 Aug 2013 01:27:53 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from ainaz.pair.com (ainaz.pair.com [209.68.2.66]) by mx1.freebsd.org (Postfix) with ESMTP id 9E07C2E85; Mon, 26 Aug 2013 01:27:53 +0000 (UTC) Received: from trevally.dhcp.nue.suse.com (nat.nue.novell.com [195.135.221.2]) by ainaz.pair.com (Postfix) with ESMTPSA id 06C963F418; Sun, 25 Aug 2013 21:27:51 -0400 (EDT) Date: Mon, 26 Aug 2013 03:27:50 +0200 (CEST) From: Gerald Pfeifer To: =?ISO-8859-15?Q?Bernhard_Fr=F6hlich?= Subject: Re: patch to add AES intrinsics to gcc In-Reply-To: Message-ID: References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <521751AF.6040905@gmail.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1041702911-1377480255=:3920" X-Mailman-Approved-At: Mon, 26 Aug 2013 02:40:28 +0000 Cc: toolchain@freebsd.org, Volodymyr Kostyrko , John-Mark Gurney , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Aug 2013 01:27:53 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1041702911-1377480255=:3920 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15 Content-Transfer-Encoding: 8BIT On Fri, 23 Aug 2013, Bernhard Fröhlich wrote: > lang/gcc42 is on the list of ports that have USE_GCC=any. So you would > need to fix it first to be able to compile it with clang 3.3 from base. I don't think so. :-) You can install lang/gcc which builds just fine with clang, and then use lang/gcc to build lang/gcc42. In fact, if you have a system without GCC in the base, this should happen automatically when you build lang/gcc42. Does this not work? > We are not trying to build everything with lang/gcc but just the ports > that have USE_GCC=any in their Makefile. ...and those that have USE_GCC=yes in their Makefile. The difference between USE_GCC=yes and USE_GCC=any is that the later is there to support the transition period and uses /usr/bin/gcc if present. Personally, I would stop relying on /usr/bin/gcc (even if present) and use the lang/gcc port in all cases. That reduces the number of different scenarios to test, but will pull in lang/gcc in some more cases and may meet some resistance therefore. Gerald --0-1041702911-1377480255=:3920-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 26 01:41:35 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A54D8A93; Mon, 26 Aug 2013 01:41:35 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from ainaz.pair.com (ainaz.pair.com [209.68.2.66]) by mx1.freebsd.org (Postfix) with ESMTP id 817AD2F47; Mon, 26 Aug 2013 01:41:35 +0000 (UTC) Received: from trevally.dhcp.nue.suse.com (charybdis-ext.suse.de [195.135.221.2]) by ainaz.pair.com (Postfix) with ESMTPSA id 753373F418; Sun, 25 Aug 2013 21:41:33 -0400 (EDT) Date: Mon, 26 Aug 2013 03:41:32 +0200 (CEST) From: Gerald Pfeifer To: Volodymyr Kostyrko Subject: Re: patch to add AES intrinsics to gcc In-Reply-To: <521751AF.6040905@gmail.com> Message-ID: References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <521751AF.6040905@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Mon, 26 Aug 2013 02:40:36 +0000 Cc: toolchain@freebsd.org, John-Mark Gurney , =?ISO-8859-15?Q?Bernhard_Fr=F6hlich?= , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Aug 2013 01:41:35 -0000 On Fri, 23 Aug 2013, Volodymyr Kostyrko wrote: > I object. Many ports that compiles perfectly on gcc 4.2.1 can't be > compiled with lang/gcc. I checked this once and the number of ports > that require strictly gcc 4.2.1 was bigger for me then number of > ports that can't be compiled with clang but fill fine on lang/gcc. > > I'll gonna recheck whether lang/gcc42 is sufficient for them. But I > have that bad feeling... If there are ports that use USE_GCC=any and do not build with lang/gcc, these should have USE_GCC=4.2 -- without a '+'! -- not USE_GCC=any. It'll be great if you can fix any such port. Gerald From owner-freebsd-current@FreeBSD.ORG Mon Aug 26 03:44:08 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 97E9C944; Mon, 26 Aug 2013 03:44:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 59A5D2542; Mon, 26 Aug 2013 03:44:08 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r7Q3dcK8016204; Sun, 25 Aug 2013 23:39:39 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r7Q3dcZ9016196; Mon, 26 Aug 2013 03:39:38 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 26 Aug 2013 03:39:38 GMT Message-Id: <201308260339.r7Q3dcZ9016196@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 , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 03:44:08 -0000 TB --- 2013-08-25 23:50:27 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-25 23:50:27 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-08-25 23:50:27 - starting HEAD tinderbox run for i386/i386 TB --- 2013-08-25 23:50:27 - cleaning the object tree TB --- 2013-08-26 00:01:40 - /usr/local/bin/svn stat /src TB --- 2013-08-26 00:01:44 - At svn revision 254892 TB --- 2013-08-26 00:01:45 - building world TB --- 2013-08-26 00:01:45 - CROSS_BUILD_TESTING=YES TB --- 2013-08-26 00:01:45 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-26 00:01:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-26 00:01:45 - SRCCONF=/dev/null TB --- 2013-08-26 00:01:45 - TARGET=i386 TB --- 2013-08-26 00:01:45 - TARGET_ARCH=i386 TB --- 2013-08-26 00:01:45 - TZ=UTC TB --- 2013-08-26 00:01:45 - __MAKE_CONF=/dev/null TB --- 2013-08-26 00:01:45 - cd /src TB --- 2013-08-26 00:01:45 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Aug 26 00:01:52 UTC 2013 >>> 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 Aug 26 03:14:32 UTC 2013 TB --- 2013-08-26 03:14:32 - generating LINT kernel config TB --- 2013-08-26 03:14:32 - cd /src/sys/i386/conf TB --- 2013-08-26 03:14:32 - /usr/bin/make -B LINT TB --- 2013-08-26 03:14:32 - cd /src/sys/i386/conf TB --- 2013-08-26 03:14:32 - /usr/sbin/config -m LINT TB --- 2013-08-26 03:14:32 - building LINT kernel TB --- 2013-08-26 03:14:32 - CROSS_BUILD_TESTING=YES TB --- 2013-08-26 03:14:32 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-26 03:14:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-26 03:14:32 - SRCCONF=/dev/null TB --- 2013-08-26 03:14:32 - TARGET=i386 TB --- 2013-08-26 03:14:32 - TARGET_ARCH=i386 TB --- 2013-08-26 03:14:32 - TZ=UTC TB --- 2013-08-26 03:14:32 - __MAKE_CONF=/dev/null TB --- 2013-08-26 03:14:32 - cd /src TB --- 2013-08-26 03:14:32 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Aug 26 03:14:32 UTC 2013 >>> 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 -O2 -pipe -fms-extensions -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/drm2/radeonkms/../../../dev/drm2/radeon -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -I/obj/i386.i386/src/sys/LINT -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c /src/sys/modules/drm2/radeonkms/../../../dev/drm2/radeon/atom.c /src/sys/modules/drm2/radeonkms/../../../dev/drm2/radeon/atom.c:92:9: error: 'DEBUG' macro redefined [-Werror] #define DEBUG(...) do if (atom_debug) { printf(__FILE__ __VA_ARGS__); } while (0) ^ /obj/i386.i386/src/sys/LINT/opt_global.h:41:9: note: previous definition is here #define DEBUG 1 ^ 1 error generated. *** Error code 1 Stop. bmake[4]: stopped in /src/sys/modules/drm2/radeonkms *** Error code 1 Stop. bmake[3]: stopped in /src/sys/modules/drm2 *** Error code 1 Stop. bmake[2]: stopped in /src/sys/modules *** Error code 1 Stop. bmake[1]: stopped in /obj/i386.i386/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-26 03:39:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-26 03:39:38 - ERROR: failed to build LINT kernel TB --- 2013-08-26 03:39:38 - 10522.13 user 1887.81 system 13750.82 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Mon Aug 26 04:13:15 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AC6A0EFD; Mon, 26 Aug 2013 04:13:15 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7322E2695; Mon, 26 Aug 2013 04:13:15 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r7Q4DEv5089780; Mon, 26 Aug 2013 00:13:14 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r7Q4DEOI089779; Mon, 26 Aug 2013 04:13:14 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 26 Aug 2013 04:13:14 GMT Message-Id: <201308260413.r7Q4DEOI089779@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 , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 04:13:15 -0000 TB --- 2013-08-25 23:50:27 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-25 23:50:27 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-08-25 23:50:27 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-08-25 23:50:27 - cleaning the object tree TB --- 2013-08-26 00:01:54 - /usr/local/bin/svn stat /src TB --- 2013-08-26 00:01:57 - At svn revision 254892 TB --- 2013-08-26 00:01:58 - building world TB --- 2013-08-26 00:01:58 - CROSS_BUILD_TESTING=YES TB --- 2013-08-26 00:01:58 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-26 00:01:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-26 00:01:58 - SRCCONF=/dev/null TB --- 2013-08-26 00:01:58 - TARGET=amd64 TB --- 2013-08-26 00:01:58 - TARGET_ARCH=amd64 TB --- 2013-08-26 00:01:58 - TZ=UTC TB --- 2013-08-26 00:01:58 - __MAKE_CONF=/dev/null TB --- 2013-08-26 00:01:58 - cd /src TB --- 2013-08-26 00:01:58 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Aug 26 00:02:04 UTC 2013 >>> 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 Mon Aug 26 03:50:57 UTC 2013 TB --- 2013-08-26 03:50:57 - generating LINT kernel config TB --- 2013-08-26 03:50:57 - cd /src/sys/amd64/conf TB --- 2013-08-26 03:50:57 - /usr/bin/make -B LINT TB --- 2013-08-26 03:50:57 - cd /src/sys/amd64/conf TB --- 2013-08-26 03:50:57 - /usr/sbin/config -m LINT TB --- 2013-08-26 03:50:57 - building LINT kernel TB --- 2013-08-26 03:50:57 - CROSS_BUILD_TESTING=YES TB --- 2013-08-26 03:50:57 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-26 03:50:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-26 03:50:57 - SRCCONF=/dev/null TB --- 2013-08-26 03:50:57 - TARGET=amd64 TB --- 2013-08-26 03:50:57 - TARGET_ARCH=amd64 TB --- 2013-08-26 03:50:57 - TZ=UTC TB --- 2013-08-26 03:50:57 - __MAKE_CONF=/dev/null TB --- 2013-08-26 03:50:57 - cd /src TB --- 2013-08-26 03:50:57 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Aug 26 03:50:57 UTC 2013 >>> 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 -O2 -pipe -fms-extensions -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/drm2/radeonkms/../../../dev/drm2/radeon -DHAVE_KERNEL_OPTION_HEADERS -include /obj/amd64.amd64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/obj/amd64.amd64/src/sys/LINT -fno-builtin -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c /src/sys/modules/drm2/radeonkms/../../../dev/drm2/radeon/atom.c /src/sys/modules/drm2/radeonkms/../../../dev/drm2/radeon/atom.c:92:9: error: 'DEBUG' macro redefined [-Werror] #define DEBUG(...) do if (atom_debug) { printf(__FILE__ __VA_ARGS__); } while (0) ^ /obj/amd64.amd64/src/sys/LINT/opt_global.h:35:9: note: previous definition is here #define DEBUG 1 ^ 1 error generated. *** Error code 1 Stop. bmake[4]: stopped in /src/sys/modules/drm2/radeonkms *** Error code 1 Stop. bmake[3]: stopped in /src/sys/modules/drm2 *** Error code 1 Stop. bmake[2]: stopped in /src/sys/modules *** Error code 1 Stop. bmake[1]: stopped in /obj/amd64.amd64/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-26 04:13:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-26 04:13:14 - ERROR: failed to build LINT kernel TB --- 2013-08-26 04:13:14 - 11943.19 user 2235.62 system 15766.72 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Mon Aug 26 05:57:04 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 80CDF7E3 for ; Mon, 26 Aug 2013 05:57:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E88EE2A2B for ; Mon, 26 Aug 2013 05:57:03 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r7Q5ux2N062274; Mon, 26 Aug 2013 08:56:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r7Q5ux2N062274 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r7Q5uwjm062273; Mon, 26 Aug 2013 08:56:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 26 Aug 2013 08:56:58 +0300 From: Konstantin Belousov To: Larry Rosenman Subject: Re: 2 crashes.... (today's -CURRENT) Message-ID: <20130826055658.GF4972@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uKKzWs+ZAQbsF2l3" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Aug 2013 05:57:04 -0000 --uKKzWs+ZAQbsF2l3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 25, 2013 at 01:56:55AM -0500, Larry Rosenman wrote: > And a 4th: >=20 > borg.lerctr.org dumped core - see /var/crash/vmcore.3 =2E... All the traces have little in common except a feel of the random memory corruption. Note that you are the only reporter of such mass panics, so the problem is very specific to your configuration. You still have nvidia.ko loaded, does it change anything if the driver is unloaded ? The same question WRT dtrace modules. --uKKzWs+ZAQbsF2l3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQIcBAEBAgAGBQJSGu4pAAoJEJDCuSvBvK1BRNsP+weJ95uUg6IPzUhKOhDzIWA3 YF2ITmVlf2Ijf9z/W4Ohu3l/enh47dVRweT4wK3tGweH14JGvIUa5WDogRTCqJRb +90jnxLGphWtzY9s0BTJ1IUIVEQL0IcrrfgtfvSxDv+1RB5DC4GErdR96FcwnMEc UI1zvdKPqkC8B8HckiGYEHeYNymz4Tt4COIjpwKV/wP86ZIT2duVfCLbZNC4SlQT KdZuAYGygbbBogKSsISazI9KTbI8wFhPd7M1Kl/+syjC+dNFTxBGYsp87OhIty/1 KRcT1QbYByXCPnTeqxfDX14Kll3k7EbTl+rdEKesBAsc8caY7/ddfEHUBBzdg58v Bvf0qYhFG9qPaBlms8psq2e0yr+UKUzmt3/KChVP8om/75at1I0Ee+CKSSJRQ//+ eS/iqymmhnbT2wOufqjS8D+o1SDiXGxtRLv/EOEyOvyBGxOXliByfktHQsdXuVpI miOauHKi8gu5fKjLUkKHHxZzHl5qFK074b7JGWTmrGkrxHwXBS2bFSL6EEyW9QlA tQrjRiAH51VMWTLhvmu5tGdkvZMl1UKPxUGJU1rJ349MXaAE3ZwUVjXjUX0QTxsk JtOdVAznLN5TTwtb2x7nklocL2GQQipcu9wVYmdvk31chxCjn4x0ZHBBKRcSKSh9 sVeB53Y7Pv1IJj5OMsv1 =y0m0 -----END PGP SIGNATURE----- --uKKzWs+ZAQbsF2l3-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 26 06:58:05 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B523767A; Mon, 26 Aug 2013 06:58:05 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8119D2CAC; Mon, 26 Aug 2013 06:58:05 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r7Q6w4eF018699; Mon, 26 Aug 2013 02:58:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r7Q6w4ZN018648; Mon, 26 Aug 2013 06:58:04 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 26 Aug 2013 06:58:04 GMT Message-Id: <201308260658.r7Q6w4ZN018648@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 , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 06:58:05 -0000 TB --- 2013-08-26 03:39:39 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-26 03:39:39 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-08-26 03:39:39 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-08-26 03:39:39 - cleaning the object tree TB --- 2013-08-26 03:39:39 - /usr/local/bin/svn stat /src TB --- 2013-08-26 03:39:57 - At svn revision 254892 TB --- 2013-08-26 03:39:58 - building world TB --- 2013-08-26 03:39:58 - CROSS_BUILD_TESTING=YES TB --- 2013-08-26 03:39:58 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-26 03:39:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-26 03:39:58 - SRCCONF=/dev/null TB --- 2013-08-26 03:39:58 - TARGET=pc98 TB --- 2013-08-26 03:39:58 - TARGET_ARCH=i386 TB --- 2013-08-26 03:39:58 - TZ=UTC TB --- 2013-08-26 03:39:58 - __MAKE_CONF=/dev/null TB --- 2013-08-26 03:39:58 - cd /src TB --- 2013-08-26 03:39:58 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Aug 26 03:40:06 UTC 2013 >>> 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 Aug 26 06:55:02 UTC 2013 TB --- 2013-08-26 06:55:02 - generating LINT kernel config TB --- 2013-08-26 06:55:02 - cd /src/sys/pc98/conf TB --- 2013-08-26 06:55:02 - /usr/bin/make -B LINT TB --- 2013-08-26 06:55:02 - cd /src/sys/pc98/conf TB --- 2013-08-26 06:55:02 - /usr/sbin/config -m LINT TB --- 2013-08-26 06:55:02 - building LINT kernel TB --- 2013-08-26 06:55:02 - CROSS_BUILD_TESTING=YES TB --- 2013-08-26 06:55:02 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-26 06:55:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-26 06:55:02 - SRCCONF=/dev/null TB --- 2013-08-26 06:55:02 - TARGET=pc98 TB --- 2013-08-26 06:55:02 - TARGET_ARCH=i386 TB --- 2013-08-26 06:55:02 - TZ=UTC TB --- 2013-08-26 06:55:02 - __MAKE_CONF=/dev/null TB --- 2013-08-26 06:55:02 - cd /src TB --- 2013-08-26 06:55:02 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Aug 26 06:55:02 UTC 2013 >>> 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 [...] In file included from /src/sys/modules/drm2/radeonkms/../../../dev/drm2/radeon/radeon.h:75: In file included from @/contrib/dev/acpica/include/acpi.h:56: In file included from @/contrib/dev/acpica/include/platform/acenv.h:155: @/contrib/dev/acpica/include/platform/acfreebsd.h:75:10: fatal error: 'machine/acpica_machdep.h' file not found #include ^ 1 error generated. mkdep: compile failed *** Error code 1 Stop. bmake[4]: stopped in /src/sys/modules/drm2/radeonkms *** Error code 1 Stop. bmake[3]: stopped in /src/sys/modules/drm2 *** Error code 1 Stop. bmake[2]: stopped in /src/sys/modules *** Error code 1 Stop. bmake[1]: stopped in /obj/pc98.i386/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-26 06:58:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-26 06:58:04 - ERROR: failed to build LINT kernel TB --- 2013-08-26 06:58:04 - 9796.95 user 1273.42 system 11904.91 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Mon Aug 26 10:52:48 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 66E8B38F for ; Mon, 26 Aug 2013 10:52:48 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 25BBD2429 for ; Mon, 26 Aug 2013 10:52:48 +0000 (UTC) Received: by mail-ve0-f178.google.com with SMTP id ox1so1931554veb.23 for ; Mon, 26 Aug 2013 03:52:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VHQdkB1zTvN92Wyph6j7nY75MXTtofefOG3RFXTRXaE=; b=VWPyJdRY6k+iwB3nok/YEyjUHtUhF7gBsdh56ylZAHD/AMtInfunCEkaK1IoCNJFUl uPJZamv4pZlCFLsSYVPXYSr8r16i42P2EMwubsm/jOMwvRMfXmPcfYVu3rQoGyElBQLk OLFsZ2IRnLdlXLhkPTTvDCh1YuRbeed5+jBF2HzGJhVCqG/ilK9iX1oLVcditCWzrdUU POJfSkkY7OQ7HUSieXy2o5GAZs9Iww1e6c1Rj8bEJEP1UNyfEopd5RbJTG6Tn9mkMJTo 4rOGf3SA/ZHsz5o8EOwLgOw7zmVt/2N7Nj+71iq0mUFwNVLBy1V14ifGAyvRtEMOFcVW gbUg== MIME-Version: 1.0 X-Received: by 10.58.198.13 with SMTP id iy13mr14490921vec.11.1377514367268; Mon, 26 Aug 2013 03:52:47 -0700 (PDT) Received: by 10.220.96.78 with HTTP; Mon, 26 Aug 2013 03:52:47 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Aug 2013 06:52:47 -0400 Message-ID: Subject: Re: 2 crashes.... (today's -CURRENT) From: "Sam Fourman Jr." To: Larry Rosenman Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Aug 2013 10:52:48 -0000 On Sat, Aug 24, 2013 at 6:47 PM, Larry Rosenman wrote: > Both full core.txt's are available at: > > http://www.lerctr.org/~ler/**FreeBSD/ > > Larry, I am not certain I can be of much help but i am curious what hardware you have. do you have a full dmesg? i went back in your previous post and i didn't see one. Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Mon Aug 26 03:39:11 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 57CC689C for ; Mon, 26 Aug 2013 03:39:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2BE5524DB for ; Mon, 26 Aug 2013 03:39:10 +0000 (UTC) Received: by mail-pd0-f172.google.com with SMTP id z10so2926783pdj.3 for ; Sun, 25 Aug 2013 20:39:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:from:subject :date:to; bh=puXfa+b8hzyct6lO3fJxsl6NTtuzp1I5OxTmgHtZFXs=; b=pE6g9hCzkuzRvvSGgb3ZRF2IXyzJAz5XwJ8/7dYIqveTr3TxYm6jl+349N3qJ7LAVk NRXWqyJpM4m5TswvCc3zpKdWB8bFcSdcUjZDQ3bynOgUaSm1ldioT9e9E1CzDJWLLP0u OGQH9lFC7lFmjFee4KFtSO5bIxQnlhQkGa130q7332Ma29hWUnNkmAIqmTR0HCjqUPAI h4I/IJ9GpEngBa9w3E+cDeeOM8TyFpFMyWuPMUpwtwzALG/N4Bgc3+fxFMj8N5a9n2CF CphkGSou/lwh1FA2a5TIg0NIUnygcfHrDRUpuGKIYeZEmBTTvrdL2hjPpPQ49uJRWk6V t5MA== X-Gm-Message-State: ALoCoQnvt8hQhUf9Ifg0vQCceJNi/HCuRtCqNkLTtE+LEFebvnQpKlC+9rqAQu+ijgwGxlaH/Cow X-Received: by 10.66.161.229 with SMTP id xv5mr12392650pab.87.1377488343870; Sun, 25 Aug 2013 20:39:03 -0700 (PDT) Received: from [10.0.0.122] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id qp10sm16967023pab.13.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 25 Aug 2013 20:39:02 -0700 (PDT) References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <521751AF.6040905@gmail.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9B206) From: Warner Losh Subject: Re: patch to add AES intrinsics to gcc Date: Sun, 25 Aug 2013 21:38:55 -0600 To: Gerald Pfeifer X-Mailman-Approved-At: Mon, 26 Aug 2013 11:01:56 +0000 Cc: "toolchain@freebsd.org" , Volodymyr Kostyrko , John-Mark Gurney , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Aug 2013 03:39:11 -0000 Can all such ports be identified with a ports build run in a special chroot w= ithout FreeBSD's FCC installed? Sent from my iPad On Aug 25, 2013, at 7:41 PM, Gerald Pfeifer wrote: > On Fri, 23 Aug 2013, Volodymyr Kostyrko wrote: >> I object. Many ports that compiles perfectly on gcc 4.2.1 can't be=20 >> compiled with lang/gcc. I checked this once and the number of ports=20 >> that require strictly gcc 4.2.1 was bigger for me then number of=20 >> ports that can't be compiled with clang but fill fine on lang/gcc. >>=20 >> I'll gonna recheck whether lang/gcc42 is sufficient for them. But I=20 >> have that bad feeling... >=20 > If there are ports that use USE_GCC=3Dany and do not build with > lang/gcc, these should have USE_GCC=3D4.2 -- without a '+'! -- > not USE_GCC=3Dany. >=20 > It'll be great if you can fix any such port. >=20 > Gerald > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd.or= g" From owner-freebsd-current@FreeBSD.ORG Mon Aug 26 11:04:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C10BDB9B; Mon, 26 Aug 2013 11:04:22 +0000 (UTC) (envelope-from roger.pau@citrix.com) Received: from SMTP.EU.CITRIX.COM (smtp.eu.citrix.com [46.33.159.39]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1D5692658; Mon, 26 Aug 2013 11:04:21 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.89,957,1367971200"; d="scan'208";a="8097589" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 26 Aug 2013 11:04:14 +0000 Received: from localhost.localdomain (10.68.19.166) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Mon, 26 Aug 2013 12:04:14 +0100 From: Roger Pau Monne To: Subject: [PATCH] xen-netback: fix compile errors introduced by r254804 and r254807 Date: Mon, 26 Aug 2013 13:02:01 +0200 Message-ID: <1377514921-2132-1-git-send-email-roger.pau@citrix.com> X-Mailer: git-send-email 1.7.7.5 (Apple Git-26) MIME-Version: 1.0 Content-Type: text/plain Cc: andre@freebsd.org, Roger Pau Monne X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Aug 2013 11:04:22 -0000 r254804 and r254807 changed the types of some of the members of the mbuf struct, and introduced some compile time errors in netback debug messages that prevented compiling a XENHVM kernel. Cc: andre@freebsd.org --- sys/dev/xen/netback/netback.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/sys/dev/xen/netback/netback.c b/sys/dev/xen/netback/netback.c index f18b791..16a54d9 100644 --- a/sys/dev/xen/netback/netback.c +++ b/sys/dev/xen/netback/netback.c @@ -585,16 +585,16 @@ xnb_dump_mbuf(const struct mbuf *m) printf("xnb_dump_mbuf:\n"); if (m->m_flags & M_PKTHDR) { - printf(" flowid=%10d, csum_flags=%#8x, csum_data=%#8x, " + printf(" flowid=%10d, csum_flags=%b, csum_data=%#8x, " "tso_segsz=%5hd\n", - m->m_pkthdr.flowid, m->m_pkthdr.csum_flags, + m->m_pkthdr.flowid, (int)m->m_pkthdr.csum_flags, CSUM_BITS, m->m_pkthdr.csum_data, m->m_pkthdr.tso_segsz); printf(" rcvif=%16p, header=%18p, len=%19d\n", - m->m_pkthdr.rcvif, m->m_pkthdr.header, m->m_pkthdr.len); + m->m_pkthdr.rcvif, m->m_pkthdr.PH_loc.ptr, m->m_pkthdr.len); } printf(" m_next=%16p, m_nextpk=%16p, m_data=%16p\n", m->m_next, m->m_nextpkt, m->m_data); - printf(" m_len=%17d, m_flags=%#15x, m_type=%18hd\n", + printf(" m_len=%17d, m_flags=%#15x, m_type=%u\n", m->m_len, m->m_flags, m->m_type); len = m->m_len; -- 1.7.7.5 (Apple Git-26) From owner-freebsd-current@FreeBSD.ORG Mon Aug 26 12:22:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 82460A15 for ; Mon, 26 Aug 2013 12:22:53 +0000 (UTC) (envelope-from kolyasir@gmail.com) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5FD7D2F4D for ; Mon, 26 Aug 2013 12:22:53 +0000 (UTC) Received: by mail-pb0-f45.google.com with SMTP id mc17so3379198pbc.32 for ; Mon, 26 Aug 2013 05:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=clLPzewPfOoKvaFozAWuBDrP4YUHVOYRxTUod8TvxlM=; b=duM9pLCdPFmx0TO2Gd1QeljIvNjiCa4SSIUSAjWolAAnN3LMBymAi1YKDB7cH57HV8 xSmFbXLH+xvrROzg9Ze0b2AfF1pCd8TQrOK+CJfxPOpLQ50RYuQkwCe6xc1yUq11e6CJ zxKtsQ/0LN6sOiCeFsH9lsYZILqIkC3cB1vRWU45aTnn0erZcIvOhfLqn17PTGKn7Lku 6l2r51V8vRp2q3e+PiHLiEKJ57n3xLbNaKkHmgiG7oEaosPb3Gpw2875gpHFxOKDZqET JhATyVlh/EUl+5g21YDjrnHsrSxexlbSu2t7EAf9XGN3ErfGISqijmm7ING3S62M1aN0 G15A== MIME-Version: 1.0 X-Received: by 10.67.23.164 with SMTP id ib4mr14421540pad.42.1377519771195; Mon, 26 Aug 2013 05:22:51 -0700 (PDT) Received: by 10.70.58.161 with HTTP; Mon, 26 Aug 2013 05:22:51 -0700 (PDT) Date: Mon, 26 Aug 2013 17:22:51 +0500 Message-ID: Subject: how to make a option in menuconfig as new feature From: Yasir hussan To: Current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Aug 2013 12:22:53 -0000 Hi, I want to add up a kernel module to my linux kernel,currently i am mannuly changing .config file to include my new module but i want to add it as option in menuconfig from where i choose it where it should be included or not... Thanks From owner-freebsd-current@FreeBSD.ORG Mon Aug 26 12:24:57 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2FF8DB51 for ; Mon, 26 Aug 2013 12:24:57 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E15362F6E for ; Mon, 26 Aug 2013 12:24:56 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 373CB6A6006; Mon, 26 Aug 2013 14:24:54 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id r7QCOrqq011596; Mon, 26 Aug 2013 14:24:53 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id r7QCOrCm011186; Mon, 26 Aug 2013 14:24:53 +0200 (CEST) (envelope-from lars) Date: Mon, 26 Aug 2013 14:24:53 +0200 From: Lars Engels To: Yasir hussan Subject: Re: how to make a option in menuconfig as new feature Message-ID: <20130826122453.GK96164@e-new.0x20.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n83H03bbH672hrlY" Content-Disposition: inline In-Reply-To: X-Editor: VIM - Vi IMproved 7.3 X-Operation-System: FreeBSD 8.4-RELEASE-p3 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Aug 2013 12:24:57 -0000 --n83H03bbH672hrlY Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 26, 2013 at 05:22:51PM +0500, Yasir hussan wrote: > Hi, >=20 > I want to add up a kernel module to my linux kernel,currently i am mannuly > changing .config file to include my new module but i want to add it as > option in menuconfig from where i choose it where it should be included or > not... >=20 > Thanks Hi, wrong mailing list, wrong operating system. FreeBSD is not Linux. :) --n83H03bbH672hrlY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iEYEARECAAYFAlIbSRUACgkQKc512sD3afgSmQCfTV8bRZGqY1yrpxkqMKmW2yfO QLQAn1KaNMKxkbK2mZ+FSG+ptNz1qL8x =HcgM -----END PGP SIGNATURE----- --n83H03bbH672hrlY-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 26 13:15:06 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 633A6BFF for ; Mon, 26 Aug 2013 13:15:06 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr [80.12.242.127]) by mx1.freebsd.org (Postfix) with ESMTP id F21622360 for ; Mon, 26 Aug 2013 13:15:05 +0000 (UTC) Received: from localhost ([90.55.173.166]) by mwinf5d10 with ME id HREv1m00K3bm9Na03REwKa; Mon, 26 Aug 2013 15:14:57 +0200 Message-ID: <521B54CF.3020905@orange.fr> Date: Mon, 26 Aug 2013 15:14:55 +0200 From: Claude Buisson User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130810 Thunderbird/17.0.8 MIME-Version: 1.0 To: Gerald Pfeifer Subject: Re: patch to add AES intrinsics to gcc References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> <5217DBAB.5030607@freebsd.org> <86032E72-A569-4946-B4F8-26F687067B31@bsdimp.com> <1380949A-254A-4222-BEDE-0C23E16E4F67@freebsd.org> <8C31A000-6806-4291-98A4-E8291E637BD2@bsdimp.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: re@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Aug 2013 13:15:06 -0000 On 08/26/2013 03:12, Gerald Pfeifer wrote: > On Sat, 24 Aug 2013, Warner Losh wrote: >>> "If you push gcc out to a port, and you have the 'external compiler' >>> toolchain support working correctly enough to build with this, why >>> don't we just push clang out to a port, and be done with it?" >> This is a stupid idea. It kills the tightly integrated nature of >> FreeBSD. I'd say it is far too radical a departure and opens up a >> huge can of "which version of what compiler" nightmare that we've >> largely dodged to date because we had one (or maybe two) compilers >> in the base system. > > I am working towards establishing lang/gcc as _the_ version of GCC > to use for ports. > > Today I looked at a couple of those GCC cross-compilers we have in > ports, and I have to admit I am not thrilled. Each of those I saw > copies a lot from (older version of my ports), each has a different > maintainer, each has some additions, and there is little consistency. > Perhaps you could have a look at the fact that lang/gcc is at 4.6.3, and lang/gcc46 is no more a snapshot but a true release 4.6.4. IMHO, lang/gcc must be discontinued, or updated to 4.6.4 and lang/gcc46 discontinued ? > Are these the base of 'external compiler' toolchain support? Are > there any plans to increase consistency and reduce redundancy? In > an ideal world, could those become slave ports of lang/gcc? > > Gerald Claude Buisson From owner-freebsd-current@FreeBSD.ORG Mon Aug 26 13:22:46 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6C2CB13A for ; Mon, 26 Aug 2013 13:22:46 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D283623F6 for ; Mon, 26 Aug 2013 13:22:45 +0000 (UTC) Received: (qmail 6511 invoked from network); 26 Aug 2013 14:04:51 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 26 Aug 2013 14:04:51 -0000 Message-ID: <521B569C.4080906@freebsd.org> Date: Mon, 26 Aug 2013 15:22:36 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Roger Pau Monne Subject: Re: [PATCH] xen-netback: fix compile errors introduced by r254804 and r254807 References: <1377514921-2132-1-git-send-email-roger.pau@citrix.com> In-Reply-To: <1377514921-2132-1-git-send-email-roger.pau@citrix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Aug 2013 13:22:46 -0000 On 26.08.2013 13:02, Roger Pau Monne wrote: > r254804 and r254807 changed the types of some of the members of the > mbuf struct, and introduced some compile time errors in netback > debug messages that prevented compiling a XENHVM kernel. Thanks, I fixed the printf's with r254910 in a slightly different way just before I saw your email. There's a dedicated m_print() function upcoming that can/should replace all those hand-grown variants. -- Andre > Cc: andre@freebsd.org > --- > sys/dev/xen/netback/netback.c | 8 ++++---- > 1 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/sys/dev/xen/netback/netback.c b/sys/dev/xen/netback/netback.c > index f18b791..16a54d9 100644 > --- a/sys/dev/xen/netback/netback.c > +++ b/sys/dev/xen/netback/netback.c > @@ -585,16 +585,16 @@ xnb_dump_mbuf(const struct mbuf *m) > > printf("xnb_dump_mbuf:\n"); > if (m->m_flags & M_PKTHDR) { > - printf(" flowid=%10d, csum_flags=%#8x, csum_data=%#8x, " > + printf(" flowid=%10d, csum_flags=%b, csum_data=%#8x, " > "tso_segsz=%5hd\n", > - m->m_pkthdr.flowid, m->m_pkthdr.csum_flags, > + m->m_pkthdr.flowid, (int)m->m_pkthdr.csum_flags, CSUM_BITS, > m->m_pkthdr.csum_data, m->m_pkthdr.tso_segsz); > printf(" rcvif=%16p, header=%18p, len=%19d\n", > - m->m_pkthdr.rcvif, m->m_pkthdr.header, m->m_pkthdr.len); > + m->m_pkthdr.rcvif, m->m_pkthdr.PH_loc.ptr, m->m_pkthdr.len); > } > printf(" m_next=%16p, m_nextpk=%16p, m_data=%16p\n", > m->m_next, m->m_nextpkt, m->m_data); > - printf(" m_len=%17d, m_flags=%#15x, m_type=%18hd\n", > + printf(" m_len=%17d, m_flags=%#15x, m_type=%u\n", > m->m_len, m->m_flags, m->m_type); > > len = m->m_len; > From owner-freebsd-current@FreeBSD.ORG Mon Aug 26 13:43:47 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1521B6A0; Mon, 26 Aug 2013 13:43:47 +0000 (UTC) (envelope-from roger.pau@citrix.com) Received: from SMTP.EU.CITRIX.COM (smtp.eu.citrix.com [46.33.159.39]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5F1192536; Mon, 26 Aug 2013 13:43:45 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.89,958,1367971200"; d="scan'208";a="8101743" Received: from lonpex01cl01.citrite.net ([10.30.203.101]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/AES128-SHA; 26 Aug 2013 13:43:44 +0000 Received: from [192.168.1.30] (10.30.203.1) by LONPEX01CL01.citrite.net (10.30.203.101) with Microsoft SMTP Server id 14.2.342.4; Mon, 26 Aug 2013 14:43:43 +0100 Message-ID: <521B5B8E.6060806@citrix.com> Date: Mon, 26 Aug 2013 15:43:42 +0200 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: [PATCH] xen-netback: fix compile errors introduced by r254804 and r254807 References: <1377514921-2132-1-git-send-email-roger.pau@citrix.com> <521B569C.4080906@freebsd.org> In-Reply-To: <521B569C.4080906@freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.30.203.1] Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Aug 2013 13:43:47 -0000 On 26/08/13 15:22, Andre Oppermann wrote: > On 26.08.2013 13:02, Roger Pau Monne wrote: >> r254804 and r254807 changed the types of some of the members of the >> mbuf struct, and introduced some compile time errors in netback >> debug messages that prevented compiling a XENHVM kernel. > > Thanks, I fixed the printf's with r254910 in a slightly different way just > before I saw your email. Thanks, just saw your fix on the repos. > There's a dedicated m_print() function upcoming that can/should replace all > those hand-grown variants. That should be helpful. I was wondering if there's a way to add the XENHVM kernel configs to the tinderbox tester, so we can at least have a compile test for XEN PVHVM kernels. From owner-freebsd-current@FreeBSD.ORG Mon Aug 26 13:54:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0FA68A7A; Mon, 26 Aug 2013 13:54:20 +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]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C297325C4; Mon, 26 Aug 2013 13:54:19 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1VDxFK-003ox8-2o>; Mon, 26 Aug 2013 15:54:18 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198] helo=telesto) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1VDxFJ-003Ysd-Vd>; Mon, 26 Aug 2013 15:54:18 +0200 Date: Mon, 26 Aug 2013 15:54:12 +0200 From: "O. Hartmann" To: FreeBSD CURRENT , FreeBSD Ports Subject: print/cups: 10.0-CURRENT renders cups unusable / recompilation fails due to missing libiconv Message-ID: <20130826155412.3f92b44a@telesto> Organization: FU Berlin X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/ct6vh.DGyS8c+dbB6KkJykp"; protocol="application/pgp-signature" X-Originating-IP: 130.133.86.198 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Aug 2013 13:54:20 -0000 --Sig_/ct6vh.DGyS8c+dbB6KkJykp Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Today I update a box to 10.0-CURRENT #0 r254896: Mon Aug 26 09:42:48 CEST 2013 amd64. Bevor the update this morning, I ran a box with the sources from around last Friday and port print/cups was working fine so far. After building/installation of world/kernel today as of r254896 the cups daemon didn't respond when accessd locally via port 631, printing is rejected with messages like "reset by peer" and furthermore, when I thought the cups binary might be out of sync with the environment, I tried to recompile the whole preint/cups installation, but this fails now in a close to EPICAL way not finding "libiconv"=20 [...] cc -L../cgi-bin -L../cups -L../filter -L../ppdc -L../scheduler -L/usr/local/lib -Wl,-rpath=3D/usr/lib:/usr/local/lib -Wl,-R/usr/local/lib -Wall -Wno-format-y2k -Wunused -fPIC -Os -g -fstack-protector -Wno-tautological-compare -o bannertops bannertops.o pstext.o common.o -lcupsimage \ -lcups -lssl -lcrypto -lz -pthread -lcrypt -lm -lssp_nonshared ../cups/libcups.so: undefined reference to `libiconv' ../cups/libcups.so: undefined reference to `libiconv_close' ../cups/libcups.so: undefined reference to `libiconv_open' Well, freeBSD 10.0-CUR seems now "out of cups" as far as I can see. The old installation is not working since it now rejects connections, a recompilation isn't possible due to the libiconv issue. What happens here, how can this problem be solved? Regards, Oliver P.S. Sorry for cross posting, but I think this is for both CURRENT and PORT list of interest. --Sig_/ct6vh.DGyS8c+dbB6KkJykp Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSG14JAAoJEOgBcD7A/5N8PGgH/0D0nSpeTWYfy2VsjtJ2a0Df Vd1k5yk1bwKy38lX1LNbzWW55B9oxQiP7RY0wemqTbZklvfYUYK0u01KCqqdNPnO wqiXft0B5Sjl6IpNJXj9W78B6MaHwpjEAWL/QkXJi/J/38ikR0HOtgMFRv+gDBIj h3C/rp9y1jQ+fXAGKGgEM6uohfB+LXfS6dOk8GKV9QNIDxeq6LeYv9XT2tnIJ5Os ZZEQzjBzZM2/FZRsexIwqd7tKXRKgEEA7wmJuQD6mf3E2ta8qF8RIp6tRE4CP3i7 /cwLLr5DeddUFELbkET0eQkVj0w4V2PruoSP+KF+5G8v/IFa1EGDdh0oFQWKND4= =FX5Y -----END PGP SIGNATURE----- --Sig_/ct6vh.DGyS8c+dbB6KkJykp-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 26 14:01:57 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6E1CCF48 for ; Mon, 26 Aug 2013 14:01:57 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D3207264B for ; Mon, 26 Aug 2013 14:01:56 +0000 (UTC) Received: (qmail 6678 invoked from network); 26 Aug 2013 14:44:07 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 26 Aug 2013 14:44:07 -0000 Message-ID: <521B5FD0.3020405@freebsd.org> Date: Mon, 26 Aug 2013 16:01:52 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= Subject: Re: [PATCH] xen-netback: fix compile errors introduced by r254804 and r254807 References: <1377514921-2132-1-git-send-email-roger.pau@citrix.com> <521B569C.4080906@freebsd.org> <521B5B8E.6060806@citrix.com> In-Reply-To: <521B5B8E.6060806@citrix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Aug 2013 14:01:57 -0000 On 26.08.2013 15:43, Roger Pau Monné wrote: > On 26/08/13 15:22, Andre Oppermann wrote: >> On 26.08.2013 13:02, Roger Pau Monne wrote: >>> r254804 and r254807 changed the types of some of the members of the >>> mbuf struct, and introduced some compile time errors in netback >>> debug messages that prevented compiling a XENHVM kernel. >> >> Thanks, I fixed the printf's with r254910 in a slightly different way just >> before I saw your email. > > Thanks, just saw your fix on the repos. > >> There's a dedicated m_print() function upcoming that can/should replace all >> those hand-grown variants. > > That should be helpful. I was wondering if there's a way to add the > XENHVM kernel configs to the tinderbox tester, so we can at least have a > compile test for XEN PVHVM kernels. It is and that's where I saw it. There's so many kernels to compile these days to get complete code coverage. -- Andre From owner-freebsd-current@FreeBSD.ORG Mon Aug 26 14:24:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4AADF94A; Mon, 26 Aug 2013 14:24:40 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0C84627A3; Mon, 26 Aug 2013 14:24:39 +0000 (UTC) Received: from coleburn.avinity.tv (host-229-161-243.77.avinity.tv [77.243.161.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 3A0055C43; Mon, 26 Aug 2013 16:24:29 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: print/cups: 10.0-CURRENT renders cups unusable / recompilation fails due to missing libiconv From: Dimitry Andric In-Reply-To: <20130826155412.3f92b44a@telesto> Date: Mon, 26 Aug 2013 16:24:26 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <20130826155412.3f92b44a@telesto> To: O. Hartmann X-Mailer: Apple Mail (2.1508) Cc: FreeBSD CURRENT , FreeBSD Ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Aug 2013 14:24:40 -0000 On Aug 26, 2013, at 15:54, O. Hartmann wrote: > Today I update a box to 10.0-CURRENT #0 r254896: Mon Aug 26 09:42:48 > CEST 2013 amd64. Bevor the update this morning, I ran a box with the > sources from around last Friday and port print/cups was working fine > so far. > > After building/installation of world/kernel today as of r254896 the > cups daemon didn't respond when accessd locally via port 631, printing > is rejected with messages like "reset by peer" I can't help you with this... > and furthermore, when I > thought the cups binary might be out of sync with the environment, I > tried to recompile the whole preint/cups installation, but this fails > now in a close to EPICAL way not finding "libiconv" > > [...] > cc -L../cgi-bin -L../cups -L../filter -L../ppdc -L../scheduler > -L/usr/local/lib -Wl,-rpath=/usr/lib:/usr/local/lib > -Wl,-R/usr/local/lib -Wall -Wno-format-y2k -Wunused -fPIC -Os -g > -fstack-protector -Wno-tautological-compare -o bannertops bannertops.o > pstext.o common.o -lcupsimage \ -lcups -lssl -lcrypto -lz -pthread > -lcrypt -lm -lssp_nonshared ../cups/libcups.so: undefined reference to > `libiconv' ../cups/libcups.so: undefined reference to > `libiconv_close' ../cups/libcups.so: undefined reference to > `libiconv_open' ... but maybe I can help here. This is due to iconv being enabled in the base system, as I pointed out here: http://lists.freebsd.org/pipermail/freebsd-ports/2013-August/085459.html The easiest workaround for now is to force LDFLAGS to contain -liconv in the port's Makefile, e.g.: Index: print/cups-base/Makefile =================================================================== --- print/cups-base/Makefile (revision 324846) +++ print/cups-base/Makefile (working copy) @@ -23,7 +23,7 @@ GNU_CONFIGURE= yes CFLAGS+= ${PTHREAD_CFLAGS} CPPFLAGS+= -I${LOCALBASE}/include -LDFLAGS+= -L${LOCALBASE}/lib +LDFLAGS+= -L${LOCALBASE}/lib -liconv DSOFLAGS= -Wl,-rpath,${PREFIX}/lib -L${PREFIX}/lib ${LDFLAGS} CONFIGURE_ENV= DSOFLAGS="${DSOFLAGS}" CONFIGURE_ARGS+= --localstatedir=/var \ -Dimitry From owner-freebsd-current@FreeBSD.ORG Mon Aug 26 15:29:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C7C157DB for ; Mon, 26 Aug 2013 15:29:40 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6243F2B86 for ; Mon, 26 Aug 2013 15:29:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:References:Message-ID:In-Reply-To:Subject:cc:To:Sender:From:Date; bh=QTMXqIzMcEqrephOf+tFFQXtNqzxTVuLIjfyzYlZQe0=; b=bDS9Bd5kTt5A0k3LQvTownQRcbvudWR0Lziv34OChY+FkMLEs1HUUFtpCL9Mbf/AKv0PyF3Xs5b4j6UGYOuIMzzEA3k3F8IIjn72ZhPoPG3iqKGE9PyxiPTkC9+2+7H+QlowCdZ/DGc4K6bcZplXmWiGBStunobqkZOdp+ZF+B0=; Received: from cpe-72-182-93-216.austin.res.rr.com ([72.182.93.216]:36022 helo=borg) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VDyjW-000FIB-36; Mon, 26 Aug 2013 10:29:37 -0500 Date: Mon, 26 Aug 2013 10:29:31 -0500 (CDT) From: Larry Rosenman Sender: ler@borg To: "Sam Fourman Jr." Subject: Re: 2 crashes.... (today's -CURRENT) In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Aug 2013 15:29:40 -0000 On Mon, 26 Aug 2013, Sam Fourman Jr. wrote: > On Sat, Aug 24, 2013 at 6:47 PM, Larry Rosenman wrote: > >> Both full core.txt's are available at: >> >> http://www.lerctr.org/~ler/**FreeBSD/ >> >> > Larry, > I am not certain I can be of much help but i am curious what hardware you > have. > do you have a full dmesg? i went back in your previous post and i didn't > see one. > > Sam Fourman Jr. > Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #32 r254807: Sat Aug 24 16:52:42 CDT 2013 root@borg.lerctr.org:/usr/obj/usr/src/sys/BORG-DTRACE amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz (2327.55-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Family = 0x6 Model = 0x17 Stepping = 6 Features=0xbfebfbff Features2=0xce3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 68719476736 (65536 MB) avail memory = 65661091840 (62619 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 netmap: loaded module random: initialized cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) unknown: I/O range not supported cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 350 Event timer "HPET1" frequency 14318180 Hz quality 340 Event timer "HPET2" frequency 14318180 Hz quality 340 atrtc0: port 0x70-0x71 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 0.0 on pci1 pci2: on pcib2 pcib3: irq 16 at device 0.0 on pci2 pci3: on pcib3 pcib4: at device 0.0 on pci3 pci4: on pcib4 pcib5: at device 0.2 on pci3 pci5: on pcib5 pcib6: irq 18 at device 2.0 on pci2 pci6: on pcib6 em0: port 0x2000-0x201f mem 0xd9220000-0xd923ffff,0xd9200000-0xd921ffff irq 18 at device 0.0 on pci6 em0: Using an MSI interrupt em0: Ethernet address: 00:30:48:f2:29:9c 001.000009 netmap_attach [2244] success for em0 em1: port 0x2020-0x203f mem 0xd9260000-0xd927ffff,0xd9240000-0xd925ffff irq 19 at device 0.1 on pci6 em1: Using an MSI interrupt em1: Ethernet address: 00:30:48:f2:29:9d 001.000010 netmap_attach [2244] success for em1 pcib7: at device 0.3 on pci1 pci7: on pcib7 pcib8: at device 4.0 on pci0 pci8: on pcib8 vgapci0: port 0x3000-0x307f mem 0xd8000000-0xd8ffffff,0xc0000000-0xc7ffffff,0xc8000000-0xc9ffffff irq 16 at device 0.0 on pci8 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io hdac0: mem 0xd9000000-0xd9003fff irq 17 at device 0.1 on pci8 pcib9: at device 6.0 on pci0 pci9: on pcib9 pci0: at device 8.0 (no driver attached) pcib10: irq 17 at device 28.0 on pci0 pci10: on pcib10 pcib11: irq 16 at device 0.0 on pci10 pci11: on pcib11 pcm0: port 0x4080-0x409f,0x4000-0x407f irq 16 at device 0.0 on pci11 pcm0: system configuration SubVendorID: 0x1412, SubDeviceID: 0x2403 XIN2 Clock Source: 24.576MHz(96kHz*256) MPU-401 UART(s) #: not implemented ADC #: 1 and SPDIF receiver connected DAC #: 4 Multi-track converter type: AC'97(SDATA_OUT:packed) S/PDIF(IN/OUT): 1/1 ID# 0x00 GPIO(mask/dir/state): 0xff/0xff/0xff uhci0: port 0x1800-0x181f irq 17 at device 29.0 on pci0 usbus0 on uhci0 uhci1: port 0x1820-0x183f irq 19 at device 29.1 on pci0 usbus1 on uhci1 uhci2: port 0x1840-0x185f irq 18 at device 29.2 on pci0 usbus2 on uhci2 ehci0: mem 0xd9600400-0xd96007ff irq 17 at device 29.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 pcib12: at device 30.0 on pci0 pci12: on pcib12 vgapci1: port 0x5000-0x50ff mem 0xd0000000-0xd7ffffff,0xd9300000-0xd930ffff irq 18 at device 1.0 on pci12 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 ata0: at channel 0 on atapci0 ahci0: port 0x18a0-0x18a7,0x1874-0x1877,0x1878-0x187f,0x1870-0x1873,0x1880-0x189f mem 0xd9600800-0xd9600bff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.10 with 6 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 ichsmb0: port 0x1100-0x111f irq 19 at device 31.3 on pci0 smbus0: on ichsmb0 acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ichwd0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 coretemp2: on cpu2 est2: on cpu2 p4tcc2: on cpu2 coretemp3: on cpu3 est3: on cpu3 p4tcc3: on cpu3 coretemp4: on cpu4 est4: on cpu4 p4tcc4: on cpu4 coretemp5: on cpu5 est5: on cpu5 p4tcc5: on cpu5 coretemp6: on cpu6 est6: on cpu6 p4tcc6: on cpu6 coretemp7: on cpu7 est7: on cpu7 p4tcc7: on cpu7 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm1: at nid 4 on hdaa0 pcm2: at nid 5 on hdaa0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen2.1: at usbus2 uhub1: on usbus2 ugen1.1: at usbus1 uhub2: on usbus1 ugen3.1: at usbus3 uhub3: on usbus3 ata0: DMA limited to UDMA33, controller found non-ATA66 cable ada0 at ahcich0 bus 0 scbus1 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada0: quirks=0x1<4K> ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus2 target 0 lun 0 ada1: ATA-8 SATA 3.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada1: quirks=0x1<4K> ada1: Previously was known as ad6 ada2 at ahcich2 bus 0 scbus3 target 0 lun 0 ada2: ATA-8 SATA 3.x device ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada2: quirks=0x1<4K> ada2: Previously was known as ad8 ada3 at ahcich3 bus 0 scbus4 target 0 lun 0 ada3: ATA-8 SATA 3.x device ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada3: quirks=0x1<4K> ada3: Previously was known as ad10 ada4 at ahcich4 bus 0 scbus5 target 0 lun 0 ada4: ATA-8 SATA 3.x device ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada4: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada4: quirks=0x1<4K> ada4: Previously was known as ad12 ada5 at ahcich5 bus 0 scbus6 target 0 lun 0 ada5: ATA-8 SATA 3.x device ada5: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada5: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada5: quirks=0x1<4K> ada5: Previously was known as ad14 cd0 at ata0 bus 0 scbus0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present SMP: AP CPU #4 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #7 Launched! uhub2: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub0: 2 ports with 2 removable, self powered Root mount waiting for: usbus3 uhub3: 6 ports with 6 removable, self powered Root mount waiting for: usbus3 Root mount waiting for: usbus3 ugen3.2: at usbus3 ukbd0: on usbus3 kbd2 at ukbd0 Trying to mount root from zfs:zroot/ROOT/default []... ugen0.2: at usbus0 ugen0.3: at usbus0 ffclock reset: HPET (14318180 Hz), time = 1377417883.500000000 uhid0: on usbus3 ums0: on usbus0 ums0: 5 buttons and [XYZ] coordinates ID=0 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Mon Aug 26 15:43:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6F1A9D87 for ; Mon, 26 Aug 2013 15:43:03 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 41EDD2C58 for ; Mon, 26 Aug 2013 15:43:03 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id a14so4890801iee.26 for ; Mon, 26 Aug 2013 08:43:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=/z1m8uRtdqEWAdT8ap1mOwB2gokZRI4kYiZgqCrHX4w=; b=g9FxIOY+n8pi4rClSzlqkIZ/gUSdGEqMADxnf429zytei7AKGYKdO6L/Wg6oSUEoGr IZEPYrZybtyxLnFe49p7GZbG2i1gnp0kKUwY2/7y22IQsv4HB13i356cKiJc6gXfFcB7 kvk9sOj0g+180FJeQUP1qGIMDE6DmXNRtTigvJU9YPjOijYS1DVMtnkwq99Js9W9J9QZ dxEFFdsqxTzSuT+KVD7CfgWQDGVtYMky5fHnxIKRHf5pYQv8MXl/ZnRhCKnvk9/Ltuvf zfbCdud2AijacoLuDlWzDSpvycm7MuO3iimYr6KKpjNQdQ/Vedx4mI8r/a2AmeJ6KxPI Xy9A== X-Gm-Message-State: ALoCoQkZJJIzcpCggQs5B7AtJvGR6pLeVp+B4QY6+UZiZpVzgGJHPYhRe6rhIJlTtwxTAiXQdCWj X-Received: by 10.42.79.4 with SMTP id p4mr2123931ick.21.1377531782396; Mon, 26 Aug 2013 08:43:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.158.74 with HTTP; Mon, 26 Aug 2013 08:42:47 -0700 (PDT) From: "Lundberg, Johannes" Date: Mon, 26 Aug 2013 16:42:47 +0100 Message-ID: Subject: xhci broken on 10-CURRENT and 2013 MacBook Air? To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-usb@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Aug 2013 15:43:03 -0000 Hi I'm trying to install 10-CURRENT on a 2013 MacBook Air and there seem to be some problem with the xhci driver. During boot of the memstick image of current from 20130818 I get either of the following errors: - Boot freezes during probe of xhci devices. - Probing times out (immediately) and I get the mountroot> prompt but no functional keyboard. I tried an image of 10-current from May but the problem is the same so what ever change that made this stop working was committed before May. I also tried disabling xhci with the following steps but without success - Enter boot prompt - set hint.xhci.0.disabled=1 - load ehci / uhci - boot The 9.1 release successfully detects all usb devices during install but stop working at the partitioning tool because the PCIe SSD drive isn't detected. Using 9.1 as LiveCD I managed to pull out the following information. ----- MacBook Air 2013, FreeBSD 9.1 LiveCD dmesg output xhci0: mem 0xb0a00000-0xb0a0ffff at device 20.0 on pci0 pciconf -l output xhci0@pci0:0:20:0: class=0x0c0330 card=0x72708086 chip=0x9c318086 rev=0x04 hdr=0x00 usbconfig output ugen0.1: at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE ugen0.2: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen0.3: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen0.4: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen0.5: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen0.6: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen0.7: at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON ----- Anyone has any clue what's going on? Best regards Johannes Lundberg BRILLIANTSERVICE CO., LTD. From owner-freebsd-current@FreeBSD.ORG Mon Aug 26 15:56:09 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 969A6C3 for ; Mon, 26 Aug 2013 15:56:09 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 66D5B2D08 for ; Mon, 26 Aug 2013 15:56:08 +0000 (UTC) Received: by mail-ie0-f176.google.com with SMTP id s9so4993359iec.7 for ; Mon, 26 Aug 2013 08:56:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=34ZaMyG3bhq30SCWctJCtXaMWgaCcV2Vs4HHcNqY6tM=; b=Jx1URvaanCuj0ZV4xZ/T6Q0qsjMxHA1LumfdCmEqnqKFg1FzX2magifxcGtDxpi7v9 lFQibGLYXn8juxcyfveFMXLV6NBfhGRiipJ5IllPs0lV1ojK7q+Np8xc9ugFkKLfmnYo orrnSV47aPICkNCvu+SZ+7RT1ECmcKoFMddNDl/3+wVykCM7bjXZ9i37VNZL4TrzyyZg Fj1ixC20LhpIH3uHt5EzL2QeyF96VESy5QdbgiJK0IKokNrHRpuNkCTutJdbvmGBYj76 DWCaUY0qiuAXojP/+wEBOIx0p6LN535pfX81zGa304Tv86SeIYUDUlQa9IX8cJ26faDD 97yg== X-Gm-Message-State: ALoCoQlhMZYStf8udMjRGk7W2LNOmnb21EbNGokrZ3EJ0MIFEDuH07XJm6GcLZGtsYMCehfvu1eN X-Received: by 10.50.20.232 with SMTP id q8mr7157772ige.0.1377532568538; Mon, 26 Aug 2013 08:56:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.158.74 with HTTP; Mon, 26 Aug 2013 08:55:53 -0700 (PDT) In-Reply-To: References: From: "Lundberg, Johannes" Date: Mon, 26 Aug 2013 16:55:53 +0100 Message-ID: Subject: Re: xhci broken on 10-CURRENT and 2013 MacBook Air? To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-usb@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Aug 2013 15:56:09 -0000 Just looked through the PR mail that came today and found possible duplicates. o usb/180726 usb XHCI umass support breaks between r248085 and r252560 o usb/179342 usb Freebsd 10.0-current USB 3.0 not working (xhci_do_coma Johannes Lundberg BRILLIANTSERVICE CO., LTD. On Mon, Aug 26, 2013 at 4:42 PM, Lundberg, Johannes < johannes@brilliantservice.co.jp> wrote: > Hi > > I'm trying to install 10-CURRENT on a 2013 MacBook Air and there seem to > be some problem with the xhci driver. > > During boot of the memstick image of current from 20130818 I get either of > the following errors: > > - Boot freezes during probe of xhci devices. > - Probing times out (immediately) and I get the mountroot> prompt but no > functional keyboard. > > I tried an image of 10-current from May but the problem is the same so > what ever change that made this stop working was committed before May. > > I also tried disabling xhci with the following steps but without success > > - Enter boot prompt > - set hint.xhci.0.disabled=1 > - load ehci / uhci > - boot > > The 9.1 release successfully detects all usb devices during install but > stop working at the partitioning tool because the PCIe SSD drive isn't > detected. Using 9.1 as LiveCD I managed to pull out the following > information. > > ----- > > MacBook Air 2013, FreeBSD 9.1 LiveCD > > dmesg output > > xhci0: mem 0xb0a00000-0xb0a0ffff at > device 20.0 on pci0 > > pciconf -l output > > xhci0@pci0:0:20:0: class=0x0c0330 card=0x72708086 chip=0x9c318086 > rev=0x04 hdr=0x00 > > usbconfig output > > ugen0.1: at usbus0, cfg=0 md=HOST spd=SUPER > (5.0Gbps) pwr=SAVE > ugen0.2: at usbus0, cfg=0 md=HOST spd=FULL > (12Mbps) pwr=SAVE > ugen0.3: at usbus0, cfg=0 md=HOST spd=FULL > (12Mbps) pwr=ON > ugen0.4: at usbus0, cfg=0 md=HOST spd=FULL > (12Mbps) pwr=ON > ugen0.5: at usbus0, cfg=0 > md=HOST spd=FULL (12Mbps) pwr=ON > ugen0.6: at usbus0, cfg=0 > md=HOST spd=FULL (12Mbps) pwr=ON > ugen0.7: at usbus0, cfg=0 md=HOST spd=SUPER > (5.0Gbps) pwr=ON > > ----- > > Anyone has any clue what's going on? > > Best regards > > Johannes Lundberg > BRILLIANTSERVICE CO., LTD. > From owner-freebsd-current@FreeBSD.ORG Mon Aug 26 16:02:46 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 038D4399; Mon, 26 Aug 2013 16:02:46 +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]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 881852D7A; Mon, 26 Aug 2013 16:02:45 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1VDzFb-000Ylb-Rw>; Mon, 26 Aug 2013 18:02:43 +0200 Received: from f052085051.adsl.alicedsl.de ([78.52.85.51] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1VDzFb-003jks-N3>; Mon, 26 Aug 2013 18:02:43 +0200 Date: Mon, 26 Aug 2013 18:02:43 +0200 From: "O. Hartmann" To: Dimitry Andric Subject: Re: print/cups: 10.0-CURRENT renders cups unusable / recompilation fails due to missing libiconv Message-ID: <20130826180243.67d1a9ca@thor.walstatt.dyndns.org> In-Reply-To: References: <20130826155412.3f92b44a@telesto> Organization: FU Berlin X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/ZLgPI4ARdkNHoch957b7gSY"; protocol="application/pgp-signature" X-Originating-IP: 78.52.85.51 Cc: FreeBSD CURRENT , FreeBSD Ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Aug 2013 16:02:46 -0000 --Sig_/ZLgPI4ARdkNHoch957b7gSY Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 26 Aug 2013 16:24:26 +0200 Dimitry Andric wrote: [...] > > and furthermore, when I > > thought the cups binary might be out of sync with the environment, I > > tried to recompile the whole preint/cups installation, but this > > fails now in a close to EPICAL way not finding "libiconv"=20 > >=20 > > [...] > > cc -L../cgi-bin -L../cups -L../filter -L../ppdc -L../scheduler > > -L/usr/local/lib -Wl,-rpath=3D/usr/lib:/usr/local/lib > > -Wl,-R/usr/local/lib -Wall -Wno-format-y2k -Wunused -fPIC -Os -g > > -fstack-protector -Wno-tautological-compare -o bannertops > > bannertops.o pstext.o common.o -lcupsimage \ -lcups -lssl > > -lcrypto -lz -pthread -lcrypt -lm > > -lssp_nonshared ../cups/libcups.so: undefined reference to > > `libiconv' ../cups/libcups.so: undefined reference to > > `libiconv_close' ../cups/libcups.so: undefined reference to > > `libiconv_open' >=20 > ... but maybe I can help here. This is due to iconv being enabled in > the base system, as I pointed out here: >=20 > http://lists.freebsd.org/pipermail/freebsd-ports/2013-August/085459.html >=20 > The easiest workaround for now is to force LDFLAGS to contain -liconv > in the port's Makefile, e.g.: >=20 > Index: print/cups-base/Makefile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- print/cups-base/Makefile (revision 324846) > +++ print/cups-base/Makefile (working copy) > @@ -23,7 +23,7 @@ > GNU_CONFIGURE=3D yes > CFLAGS+=3D ${PTHREAD_CFLAGS} > CPPFLAGS+=3D -I${LOCALBASE}/include > -LDFLAGS+=3D -L${LOCALBASE}/lib > +LDFLAGS+=3D -L${LOCALBASE}/lib -liconv > DSOFLAGS=3D -Wl,-rpath,${PREFIX}/lib -L${PREFIX}/lib ${LDFLAGS} > CONFIGURE_ENV=3D DSOFLAGS=3D"${DSOFLAGS}" > CONFIGURE_ARGS+=3D --localstatedir=3D/var \ >=20 > -Dimitry >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" Sorry, I missed the detailed explanation and how-to. Applying the add on th LDCONFIG solves the problem. Thank you very much Oliver --Sig_/ZLgPI4ARdkNHoch957b7gSY Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSG3wjAAoJEOgBcD7A/5N8+BYH/iToGqRU9yIkCPiftO1KNLfJ 1dgs8cGu85QujxtN4pfKNDCtQQb0zV3OcR903iVqD5Y8HyNXbKFVvIzCDM39UZpz kT+BJRr2wLQPunGR5TTRc7x38PB+xRl4YamGDJPlPRqyQTzw3LJWuyl8uZ2e6Z68 sViSk30THz5mYJ3iml5sNWf1hS/5IjAhwaXu3btFkWh1ag00YQJHU5kwGrHikxYD 8SfUMz6Jee3FxEFACOGt1GnsTcAbI1IuwbNrpxo6JYeqr99k5C4NLmboF1/GOjPE /RJxKAbNI3qFqabeAVt+cjrUEa8cAcuABow5pOclS5F7bQM15B/SvT4z2OWQrC8= =npls -----END PGP SIGNATURE----- --Sig_/ZLgPI4ARdkNHoch957b7gSY-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 26 16:53:39 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E51A3736; Mon, 26 Aug 2013 16:53:38 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7E6A120F4; Mon, 26 Aug 2013 16:53:37 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r7QGraMG024765; Mon, 26 Aug 2013 12:53:36 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r7QGraIP024674; Mon, 26 Aug 2013 16:53:36 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 26 Aug 2013 16:53:36 GMT Message-Id: <201308261653.r7QGraIP024674@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 , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 16:53:39 -0000 TB --- 2013-08-26 10:10:21 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-26 10:10:21 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-08-26 10:10:21 - starting HEAD tinderbox run for i386/i386 TB --- 2013-08-26 10:10:21 - cleaning the object tree TB --- 2013-08-26 10:13:15 - /usr/local/bin/svn stat /src TB --- 2013-08-26 10:13:18 - At svn revision 254900 TB --- 2013-08-26 10:13:19 - building world TB --- 2013-08-26 10:13:19 - CROSS_BUILD_TESTING=YES TB --- 2013-08-26 10:13:19 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-26 10:13:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-26 10:13:19 - SRCCONF=/dev/null TB --- 2013-08-26 10:13:19 - TARGET=i386 TB --- 2013-08-26 10:13:19 - TARGET_ARCH=i386 TB --- 2013-08-26 10:13:19 - TZ=UTC TB --- 2013-08-26 10:13:19 - __MAKE_CONF=/dev/null TB --- 2013-08-26 10:13:19 - cd /src TB --- 2013-08-26 10:13:19 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Aug 26 10:13:26 UTC 2013 >>> 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 Aug 26 13:25:42 UTC 2013 TB --- 2013-08-26 13:25:42 - generating LINT kernel config TB --- 2013-08-26 13:25:42 - cd /src/sys/i386/conf TB --- 2013-08-26 13:25:42 - /usr/bin/make -B LINT TB --- 2013-08-26 13:25:42 - cd /src/sys/i386/conf TB --- 2013-08-26 13:25:42 - /usr/sbin/config -m LINT TB --- 2013-08-26 13:25:42 - building LINT kernel TB --- 2013-08-26 13:25:42 - CROSS_BUILD_TESTING=YES TB --- 2013-08-26 13:25:42 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-26 13:25:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-26 13:25:42 - SRCCONF=/dev/null TB --- 2013-08-26 13:25:42 - TARGET=i386 TB --- 2013-08-26 13:25:42 - TARGET_ARCH=i386 TB --- 2013-08-26 13:25:42 - TZ=UTC TB --- 2013-08-26 13:25:42 - __MAKE_CONF=/dev/null TB --- 2013-08-26 13:25:42 - cd /src TB --- 2013-08-26 13:25:42 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Aug 26 13:25:42 UTC 2013 >>> 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 Aug 26 14:01:31 UTC 2013 TB --- 2013-08-26 14:01:31 - cd /src/sys/i386/conf TB --- 2013-08-26 14:01:31 - /usr/sbin/config -m LINT-NOINET TB --- 2013-08-26 14:01:31 - building LINT-NOINET kernel TB --- 2013-08-26 14:01:31 - CROSS_BUILD_TESTING=YES TB --- 2013-08-26 14:01:31 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-26 14:01:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-26 14:01:31 - SRCCONF=/dev/null TB --- 2013-08-26 14:01:31 - TARGET=i386 TB --- 2013-08-26 14:01:31 - TARGET_ARCH=i386 TB --- 2013-08-26 14:01:31 - TZ=UTC TB --- 2013-08-26 14:01:31 - __MAKE_CONF=/dev/null TB --- 2013-08-26 14:01:31 - cd /src TB --- 2013-08-26 14:01:31 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Mon Aug 26 14:01:31 UTC 2013 >>> 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-NOINET completed on Mon Aug 26 14:33:11 UTC 2013 TB --- 2013-08-26 14:33:11 - cd /src/sys/i386/conf TB --- 2013-08-26 14:33:11 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-08-26 14:33:11 - building LINT-NOINET6 kernel TB --- 2013-08-26 14:33:11 - CROSS_BUILD_TESTING=YES TB --- 2013-08-26 14:33:11 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-26 14:33:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-26 14:33:11 - SRCCONF=/dev/null TB --- 2013-08-26 14:33:11 - TARGET=i386 TB --- 2013-08-26 14:33:11 - TARGET_ARCH=i386 TB --- 2013-08-26 14:33:11 - TZ=UTC TB --- 2013-08-26 14:33:11 - __MAKE_CONF=/dev/null TB --- 2013-08-26 14:33:11 - cd /src TB --- 2013-08-26 14:33:11 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Mon Aug 26 14:33:11 UTC 2013 >>> 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-NOINET6 completed on Mon Aug 26 15:05:13 UTC 2013 TB --- 2013-08-26 15:05:13 - cd /src/sys/i386/conf TB --- 2013-08-26 15:05:13 - /usr/sbin/config -m LINT-NOIP TB --- 2013-08-26 15:05:14 - building LINT-NOIP kernel TB --- 2013-08-26 15:05:14 - CROSS_BUILD_TESTING=YES TB --- 2013-08-26 15:05:14 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-26 15:05:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-26 15:05:14 - SRCCONF=/dev/null TB --- 2013-08-26 15:05:14 - TARGET=i386 TB --- 2013-08-26 15:05:14 - TARGET_ARCH=i386 TB --- 2013-08-26 15:05:14 - TZ=UTC TB --- 2013-08-26 15:05:14 - __MAKE_CONF=/dev/null TB --- 2013-08-26 15:05:14 - cd /src TB --- 2013-08-26 15:05:14 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Mon Aug 26 15:05:14 UTC 2013 >>> 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-NOIP completed on Mon Aug 26 15:34:19 UTC 2013 TB --- 2013-08-26 15:34:19 - cd /src/sys/i386/conf TB --- 2013-08-26 15:34:19 - /usr/sbin/config -m LINT-VIMAGE TB --- 2013-08-26 15:34:19 - building LINT-VIMAGE kernel TB --- 2013-08-26 15:34:19 - CROSS_BUILD_TESTING=YES TB --- 2013-08-26 15:34:19 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-26 15:34:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-26 15:34:19 - SRCCONF=/dev/null TB --- 2013-08-26 15:34:19 - TARGET=i386 TB --- 2013-08-26 15:34:19 - TARGET_ARCH=i386 TB --- 2013-08-26 15:34:19 - TZ=UTC TB --- 2013-08-26 15:34:19 - __MAKE_CONF=/dev/null TB --- 2013-08-26 15:34:19 - cd /src TB --- 2013-08-26 15:34:19 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Mon Aug 26 15:34:19 UTC 2013 >>> 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-VIMAGE completed on Mon Aug 26 16:07:12 UTC 2013 TB --- 2013-08-26 16:07:12 - cd /src/sys/i386/conf TB --- 2013-08-26 16:07:12 - /usr/sbin/config -m GENERIC TB --- 2013-08-26 16:07:12 - building GENERIC kernel TB --- 2013-08-26 16:07:12 - CROSS_BUILD_TESTING=YES TB --- 2013-08-26 16:07:12 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-26 16:07:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-26 16:07:12 - SRCCONF=/dev/null TB --- 2013-08-26 16:07:12 - TARGET=i386 TB --- 2013-08-26 16:07:12 - TARGET_ARCH=i386 TB --- 2013-08-26 16:07:12 - TZ=UTC TB --- 2013-08-26 16:07:12 - __MAKE_CONF=/dev/null TB --- 2013-08-26 16:07:12 - cd /src TB --- 2013-08-26 16:07:12 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Aug 26 16:07:12 UTC 2013 >>> 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 Aug 26 16:38:07 UTC 2013 TB --- 2013-08-26 16:38:07 - cd /src/sys/i386/conf TB --- 2013-08-26 16:38:07 - /usr/sbin/config -m PAE TB --- 2013-08-26 16:38:07 - building PAE kernel TB --- 2013-08-26 16:38:07 - CROSS_BUILD_TESTING=YES TB --- 2013-08-26 16:38:07 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-26 16:38:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-26 16:38:07 - SRCCONF=/dev/null TB --- 2013-08-26 16:38:07 - TARGET=i386 TB --- 2013-08-26 16:38:07 - TARGET_ARCH=i386 TB --- 2013-08-26 16:38:07 - TZ=UTC TB --- 2013-08-26 16:38:07 - __MAKE_CONF=/dev/null TB --- 2013-08-26 16:38:07 - cd /src TB --- 2013-08-26 16:38:07 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Mon Aug 26 16:38:07 UTC 2013 >>> 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 PAE completed on Mon Aug 26 16:47:17 UTC 2013 TB --- 2013-08-26 16:47:17 - cd /src/sys/i386/conf TB --- 2013-08-26 16:47:17 - /usr/sbin/config -m XBOX TB --- 2013-08-26 16:47:17 - building XBOX kernel TB --- 2013-08-26 16:47:17 - CROSS_BUILD_TESTING=YES TB --- 2013-08-26 16:47:17 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-26 16:47:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-26 16:47:17 - SRCCONF=/dev/null TB --- 2013-08-26 16:47:17 - TARGET=i386 TB --- 2013-08-26 16:47:17 - TARGET_ARCH=i386 TB --- 2013-08-26 16:47:17 - TZ=UTC TB --- 2013-08-26 16:47:17 - __MAKE_CONF=/dev/null TB --- 2013-08-26 16:47:17 - cd /src TB --- 2013-08-26 16:47:17 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Mon Aug 26 16:47:17 UTC 2013 >>> 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 XBOX completed on Mon Aug 26 16:50:38 UTC 2013 TB --- 2013-08-26 16:50:38 - cd /src/sys/i386/conf TB --- 2013-08-26 16:50:38 - /usr/sbin/config -m XEN TB --- 2013-08-26 16:50:38 - building XEN kernel TB --- 2013-08-26 16:50:38 - CROSS_BUILD_TESTING=YES TB --- 2013-08-26 16:50:38 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-26 16:50:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-26 16:50:38 - SRCCONF=/dev/null TB --- 2013-08-26 16:50:38 - TARGET=i386 TB --- 2013-08-26 16:50:38 - TARGET_ARCH=i386 TB --- 2013-08-26 16:50:38 - TZ=UTC TB --- 2013-08-26 16:50:38 - __MAKE_CONF=/dev/null TB --- 2013-08-26 16:50:38 - cd /src TB --- 2013-08-26 16:50:38 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Mon Aug 26 16:50:38 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ^~~~~~~~~~~~~~~~~~~~~~ /src/sys/dev/xen/netback/netback.c:593:41: error: no member named 'header' in 'struct pkthdr' m->m_pkthdr.rcvif, m->m_pkthdr.header, m->m_pkthdr.len); ~~~~~~~~~~~ ^ /src/sys/dev/xen/netback/netback.c:598:31: error: format specifies type 'short' but the argument has type 'uint32_t' (aka 'unsigned int') [-Werror,-Wformat] m->m_len, m->m_flags, m->m_type); ^~~~~~~~~ 3 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/i386.i386/src/sys/XEN *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-26 16:53:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-26 16:53:35 - ERROR: failed to build XEN kernel TB --- 2013-08-26 16:53:35 - 18997.41 user 3324.55 system 24194.10 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Mon Aug 26 17:16:27 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 603A6DD5; Mon, 26 Aug 2013 17:16:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F29A6220D; Mon, 26 Aug 2013 17:16:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r7QHGP1m068441; Mon, 26 Aug 2013 13:16:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r7QHGPAl068436; Mon, 26 Aug 2013 17:16:25 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 26 Aug 2013 17:16:25 GMT Message-Id: <201308261716.r7QHGPAl068436@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 , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 17:16:27 -0000 TB --- 2013-08-26 10:10:21 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-26 10:10:21 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-08-26 10:10:21 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-08-26 10:10:21 - cleaning the object tree TB --- 2013-08-26 10:13:34 - /usr/local/bin/svn stat /src TB --- 2013-08-26 10:13:37 - At svn revision 254900 TB --- 2013-08-26 10:13:38 - building world TB --- 2013-08-26 10:13:38 - CROSS_BUILD_TESTING=YES TB --- 2013-08-26 10:13:38 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-26 10:13:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-26 10:13:38 - SRCCONF=/dev/null TB --- 2013-08-26 10:13:38 - TARGET=amd64 TB --- 2013-08-26 10:13:38 - TARGET_ARCH=amd64 TB --- 2013-08-26 10:13:38 - TZ=UTC TB --- 2013-08-26 10:13:38 - __MAKE_CONF=/dev/null TB --- 2013-08-26 10:13:38 - cd /src TB --- 2013-08-26 10:13:38 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Aug 26 10:13:45 UTC 2013 >>> 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 Mon Aug 26 14:02:25 UTC 2013 TB --- 2013-08-26 14:02:25 - generating LINT kernel config TB --- 2013-08-26 14:02:25 - cd /src/sys/amd64/conf TB --- 2013-08-26 14:02:25 - /usr/bin/make -B LINT TB --- 2013-08-26 14:02:25 - cd /src/sys/amd64/conf TB --- 2013-08-26 14:02:25 - /usr/sbin/config -m LINT TB --- 2013-08-26 14:02:25 - building LINT kernel TB --- 2013-08-26 14:02:25 - CROSS_BUILD_TESTING=YES TB --- 2013-08-26 14:02:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-26 14:02:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-26 14:02:25 - SRCCONF=/dev/null TB --- 2013-08-26 14:02:25 - TARGET=amd64 TB --- 2013-08-26 14:02:25 - TARGET_ARCH=amd64 TB --- 2013-08-26 14:02:25 - TZ=UTC TB --- 2013-08-26 14:02:25 - __MAKE_CONF=/dev/null TB --- 2013-08-26 14:02:25 - cd /src TB --- 2013-08-26 14:02:25 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Aug 26 14:02:25 UTC 2013 >>> 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 Aug 26 14:34:32 UTC 2013 TB --- 2013-08-26 14:34:32 - cd /src/sys/amd64/conf TB --- 2013-08-26 14:34:32 - /usr/sbin/config -m LINT-NOINET TB --- 2013-08-26 14:34:32 - building LINT-NOINET kernel TB --- 2013-08-26 14:34:32 - CROSS_BUILD_TESTING=YES TB --- 2013-08-26 14:34:32 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-26 14:34:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-26 14:34:32 - SRCCONF=/dev/null TB --- 2013-08-26 14:34:32 - TARGET=amd64 TB --- 2013-08-26 14:34:32 - TARGET_ARCH=amd64 TB --- 2013-08-26 14:34:32 - TZ=UTC TB --- 2013-08-26 14:34:32 - __MAKE_CONF=/dev/null TB --- 2013-08-26 14:34:32 - cd /src TB --- 2013-08-26 14:34:32 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Mon Aug 26 14:34:32 UTC 2013 >>> 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-NOINET completed on Mon Aug 26 15:05:13 UTC 2013 TB --- 2013-08-26 15:05:13 - cd /src/sys/amd64/conf TB --- 2013-08-26 15:05:13 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-08-26 15:05:13 - building LINT-NOINET6 kernel TB --- 2013-08-26 15:05:13 - CROSS_BUILD_TESTING=YES TB --- 2013-08-26 15:05:13 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-26 15:05:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-26 15:05:13 - SRCCONF=/dev/null TB --- 2013-08-26 15:05:13 - TARGET=amd64 TB --- 2013-08-26 15:05:13 - TARGET_ARCH=amd64 TB --- 2013-08-26 15:05:13 - TZ=UTC TB --- 2013-08-26 15:05:13 - __MAKE_CONF=/dev/null TB --- 2013-08-26 15:05:13 - cd /src TB --- 2013-08-26 15:05:13 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Mon Aug 26 15:05:13 UTC 2013 >>> 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-NOINET6 completed on Mon Aug 26 15:35:45 UTC 2013 TB --- 2013-08-26 15:35:45 - cd /src/sys/amd64/conf TB --- 2013-08-26 15:35:45 - /usr/sbin/config -m LINT-NOIP TB --- 2013-08-26 15:35:45 - building LINT-NOIP kernel TB --- 2013-08-26 15:35:45 - CROSS_BUILD_TESTING=YES TB --- 2013-08-26 15:35:45 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-26 15:35:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-26 15:35:45 - SRCCONF=/dev/null TB --- 2013-08-26 15:35:45 - TARGET=amd64 TB --- 2013-08-26 15:35:45 - TARGET_ARCH=amd64 TB --- 2013-08-26 15:35:45 - TZ=UTC TB --- 2013-08-26 15:35:45 - __MAKE_CONF=/dev/null TB --- 2013-08-26 15:35:45 - cd /src TB --- 2013-08-26 15:35:45 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Mon Aug 26 15:35:45 UTC 2013 >>> 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-NOIP completed on Mon Aug 26 16:04:46 UTC 2013 TB --- 2013-08-26 16:04:46 - cd /src/sys/amd64/conf TB --- 2013-08-26 16:04:46 - /usr/sbin/config -m LINT-VIMAGE TB --- 2013-08-26 16:04:46 - building LINT-VIMAGE kernel TB --- 2013-08-26 16:04:46 - CROSS_BUILD_TESTING=YES TB --- 2013-08-26 16:04:46 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-26 16:04:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-26 16:04:46 - SRCCONF=/dev/null TB --- 2013-08-26 16:04:46 - TARGET=amd64 TB --- 2013-08-26 16:04:46 - TARGET_ARCH=amd64 TB --- 2013-08-26 16:04:46 - TZ=UTC TB --- 2013-08-26 16:04:46 - __MAKE_CONF=/dev/null TB --- 2013-08-26 16:04:46 - cd /src TB --- 2013-08-26 16:04:46 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Mon Aug 26 16:04:46 UTC 2013 >>> 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-VIMAGE completed on Mon Aug 26 16:36:37 UTC 2013 TB --- 2013-08-26 16:36:37 - cd /src/sys/amd64/conf TB --- 2013-08-26 16:36:37 - /usr/sbin/config -m GENERIC TB --- 2013-08-26 16:36:37 - building GENERIC kernel TB --- 2013-08-26 16:36:37 - CROSS_BUILD_TESTING=YES TB --- 2013-08-26 16:36:37 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-26 16:36:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-26 16:36:37 - SRCCONF=/dev/null TB --- 2013-08-26 16:36:37 - TARGET=amd64 TB --- 2013-08-26 16:36:37 - TARGET_ARCH=amd64 TB --- 2013-08-26 16:36:37 - TZ=UTC TB --- 2013-08-26 16:36:37 - __MAKE_CONF=/dev/null TB --- 2013-08-26 16:36:37 - cd /src TB --- 2013-08-26 16:36:37 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Aug 26 16:36:37 UTC 2013 >>> 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 Aug 26 17:06:37 UTC 2013 TB --- 2013-08-26 17:06:37 - cd /src/sys/amd64/conf TB --- 2013-08-26 17:06:37 - /usr/sbin/config -m XENHVM TB --- 2013-08-26 17:06:37 - building XENHVM kernel TB --- 2013-08-26 17:06:37 - CROSS_BUILD_TESTING=YES TB --- 2013-08-26 17:06:37 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-26 17:06:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-26 17:06:37 - SRCCONF=/dev/null TB --- 2013-08-26 17:06:37 - TARGET=amd64 TB --- 2013-08-26 17:06:37 - TARGET_ARCH=amd64 TB --- 2013-08-26 17:06:37 - TZ=UTC TB --- 2013-08-26 17:06:37 - __MAKE_CONF=/dev/null TB --- 2013-08-26 17:06:37 - cd /src TB --- 2013-08-26 17:06:37 - /usr/bin/make -B buildkernel KERNCONF=XENHVM >>> Kernel build for XENHVM started on Mon Aug 26 17:06:37 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ^~~~~~~~~~~~~~~~~~~~~~ /src/sys/dev/xen/netback/netback.c:593:41: error: no member named 'header' in 'struct pkthdr' m->m_pkthdr.rcvif, m->m_pkthdr.header, m->m_pkthdr.len); ~~~~~~~~~~~ ^ /src/sys/dev/xen/netback/netback.c:598:31: error: format specifies type 'short' but the argument has type 'uint32_t' (aka 'unsigned int') [-Werror,-Wformat] m->m_len, m->m_flags, m->m_type); ^~~~~~~~~ 3 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/amd64.amd64/src/sys/XENHVM *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-26 17:16:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-26 17:16:25 - ERROR: failed to build XENHVM kernel TB --- 2013-08-26 17:16:25 - 19926.56 user 3556.06 system 25564.04 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Mon Aug 26 18:21:02 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 420447F1; Mon, 26 Aug 2013 18:21:02 +0000 (UTC) (envelope-from hps@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id F132025D3; Mon, 26 Aug 2013 18:21:01 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta.bitpro.no (Postfix) with ESMTP id E5F737A1B3; Mon, 26 Aug 2013 20:21:00 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 329E88F44C7; Mon, 26 Aug 2013 20:21:13 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixVgt7GVHldG; Mon, 26 Aug 2013 20:21:12 +0200 (CEST) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) by mail.lockless.no (Postfix) with ESMTPSA id 6A7E78F44B4; Mon, 26 Aug 2013 20:21:12 +0200 (CEST) Message-ID: <521B9CD7.8010902@bitfrost.no> Date: Mon, 26 Aug 2013 20:22:15 +0200 From: Hans Petter Selasky Organization: Bitfrost A/S User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130522 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Lundberg, Johannes" Subject: Re: xhci broken on 10-CURRENT and 2013 MacBook Air? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , freebsd-usb@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Aug 2013 18:21:02 -0000 On 08/26/13 17:55, Lundberg, Johannes wrote: > Just looked through the PR mail that came today and found possible > duplicates. > > o usb/180726 usb XHCI umass support breaks between r248085 and > r252560 > o usb/179342 usb Freebsd 10.0-current USB 3.0 not working > (xhci_do_coma > Hi, What happens if you load xhci after reaching the boot prompt? Might also be worth trying: hw.usb.xhci.msi=0 Are you able to bisect the 10-current code until you find the diff that broke it? --HPS From owner-freebsd-current@FreeBSD.ORG Mon Aug 26 18:23:46 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 72F52A3D; Mon, 26 Aug 2013 18:23:46 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vb0-x22e.google.com (mail-vb0-x22e.google.com [IPv6:2607:f8b0:400c:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1D4382603; Mon, 26 Aug 2013 18:23:46 +0000 (UTC) Received: by mail-vb0-f46.google.com with SMTP id p13so2228996vbe.19 for ; Mon, 26 Aug 2013 11:23:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=RQuLwqwcl2A9LfJeqWRrOZOOh+By4O3BdAkMRT+5Lgo=; b=Pn5MUEXwmGrhXNLhhrbPFCh0jaI7heNUsslPpOG6IqZxFn1NGlaNFQNjQ0h7Ko0DRa QjXPP+NIpZESROZzMn8njs+T0FYCK7fhq5hO9qfdTU8ZvnmwhCK1CRNGMx5h1hk7ZPrW l1/R8Epy/FZ1hOngRJWJXJ4zPKfmKNjVL/ssgnd3ORGCffCB6EAP4RTjh9l+uoRn9r7r 1tkh1gczLruzbsccntTDyZtXvu7COAyLtz8oix4F17mKV9wYhrk3l5GxaJAc2Zn01eK4 FIHV3qudqVGacH6wv1iPDWAA8B5cAv9eRlFw4aqNyrVh1LpLguc7M4cwPzjdmX9SZpsv iyKg== MIME-Version: 1.0 X-Received: by 10.221.55.4 with SMTP id vw4mr28247vcb.37.1377541424857; Mon, 26 Aug 2013 11:23:44 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.220.65.132 with HTTP; Mon, 26 Aug 2013 11:23:44 -0700 (PDT) In-Reply-To: <201308231129.03990.jhb@freebsd.org> References: <201308230945.28701.jhb@freebsd.org> <201308231129.03990.jhb@freebsd.org> Date: Mon, 26 Aug 2013 11:23:44 -0700 X-Google-Sender-Auth: vKoK2_ItfOXCxNyJwB-OrVbQpSY Message-ID: Subject: Re: Question about socket timeouts From: Davide Italiano To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: Vitja Makarov , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Aug 2013 18:23:46 -0000 On Fri, Aug 23, 2013 at 5:29 PM, John Baldwin wrote: > On Friday, August 23, 2013 9:53:12 am Davide Italiano wrote: >> On Fri, Aug 23, 2013 at 3:45 PM, John Baldwin wrote: >> > On Friday, August 23, 2013 2:27:58 am Vitja Makarov wrote: >> >> 2013/8/22 John Baldwin : >> >> > On Thursday, August 22, 2013 12:18:48 am Vitja Makarov wrote: >> >> >> 2013/8/21 John Baldwin : >> >> >> > On Monday, August 19, 2013 11:13:02 pm Daniel Eischen wrote: >> >> >> >> On Mon, 19 Aug 2013, Adrian Chadd wrote: >> >> >> >> >> >> >> >> > Yes! Please file a PR! >> >> >> >> >> >> >> >> This sorta implies that both are acceptable (although, >> >> >> >> the Linux behavior seems more desirable). >> >> >> >> >> >> >> >> http://austingroupbugs.net/view.php?id=369 >> >> >> > >> >> >> > No, that says "round up", so it does mean that the requested timeout >> >> >> > should be the minimum amount slept. tvtohz() does this. Really odd >> >> >> > that the socket code is using its own version of this rather than >> >> >> > tvtohz(). >> >> >> > >> >> >> > Oh, I bet this just predates tvtohz(). Interesting that it keeps > getting >> >> >> > bug fixes in its history that simply using tvtohz() would have > solved. >> >> >> > >> >> >> > Try this: >> >> >> > >> >> >> > Index: uipc_socket.c >> >> >> > =================================================================== >> >> >> > --- uipc_socket.c (revision 254570) >> >> >> > +++ uipc_socket.c (working copy) >> >> >> > @@ -2699,21 +2699,16 @@ sosetopt(struct socket *so, struct sockopt > *sopt) >> >> >> > if (error) >> >> >> > goto bad; >> >> >> > >> >> >> > - /* assert(hz > 0); */ >> >> >> > if (tv.tv_sec < 0 || tv.tv_sec > INT_MAX / > hz || >> >> >> > tv.tv_usec < 0 || tv.tv_usec >= 1000000) > { >> >> >> > error = EDOM; >> >> >> > goto bad; >> >> >> > } >> >> >> > - /* assert(tick > 0); */ >> >> >> > - /* assert(ULONG_MAX - INT_MAX >= 1000000); > */ >> >> >> > - val = (u_long)(tv.tv_sec * hz) + tv.tv_usec > / tick; >> >> >> > - if (val > INT_MAX) { >> >> >> > + val = tvtohz(&tv); >> >> >> > + if (val == INT_MAX) { >> >> >> > error = EDOM; >> >> >> > goto bad; >> >> >> > } >> >> >> > - if (val == 0 && tv.tv_usec != 0) >> >> >> > - val = 1; >> >> >> > >> >> >> > switch (sopt->sopt_name) { >> >> >> > case SO_SNDTIMEO: >> >> >> > >> >> >> >> >> >> That must help. But I want to see the issue solved in the next >> >> >> release. I can't apply patch to the production system. Btw in >> >> >> production environment we have kern.hz set to 1000 so it's not a >> >> >> problem there. >> >> > >> >> > Can you test this in some way in a test environment? >> >> > >> >> >> >> Ok, sorry for posting out of the list. >> >> >> >> Simple test program is attached. Without your patch timeout expires in >> >> about 20ms. With it it's ~40ms. >> >> >> >> 40 instead of 30 is beacuse of odd tick added by tvtohz(). >> > >> > Ok, thanks. tvtohz() will be good to MFC (and I will do that), but for >> > HEAD I think we can fix this to use a precise timeout. I've cc'd davide@ >> > so he can take a look at that. >> > >> > -- >> > John Baldwin >> >> Hi, >> I think I can switch this code to new timeout KPI, but this will >> require the timeout field of 'struct sockbuf' to be changed from 'int' >> to 'sbintime_t' which breaks binary compatibility. Do you have any >> strong objections about this? If any, I would like this to happen ABI >> freeze, so it looks like this is the right moment. > > This should be fine to change now, it just can't be MFC'd (which we can't > do anyway). > > -- > John Baldwin Please consider the following patch: http://people.freebsd.org/~davide/review/socket_timeout.diff I've tested it and it works OK. I got a timeout which is ~= 25ms using the testcase provided by the user. The only doubt I have is about the range check, I've changed a bit because the 'integer' part of sbintime_t fits in 32-bits, but I'm not sure it's the best way of doing this. Thanks, -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare From owner-freebsd-current@FreeBSD.ORG Mon Aug 26 18:25:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A4C8BB86; Mon, 26 Aug 2013 18:25:21 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 51474261E; Mon, 26 Aug 2013 18:25:21 +0000 (UTC) Received: by mail-ve0-f170.google.com with SMTP id 15so2411178vea.15 for ; Mon, 26 Aug 2013 11:25:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=kw0fAQDHeGcBHzo+slZpDRRJqDWAF+ZawVITMTzkBHc=; b=DXMsOZYB/hMJo4CkLmCqCklGM4T9ujBy+h/o0SbR0N564dvZ/4FVtPg1Jj2tsjdj6v G7v2Sn+LPTYOr3//GvbcwqBx7qu8+xKXlJSD+pjiOD54ZX1AHAbKaezhF/5JCAA4Bwxb UkI9UmThosDpyuhCooSGkVJzxyAAq7COJQmT/z2uZJ/Zvv+G5T3OuDqTiUz0ZvVG6hrW YYz/WiAIjGZmNKX56kOBKuRtIMzdFBPILobqBbfnsIipMYoQksNJZBIBFmOEcIoZw5x/ w2DomppymrwavIe1abimtAx2pfjZzvEN9zsKlo9yXU+uPcFhJxOEgGnWjBusxjvuIBqX U7OQ== MIME-Version: 1.0 X-Received: by 10.58.196.132 with SMTP id im4mr1493489vec.28.1377541520516; Mon, 26 Aug 2013 11:25:20 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.220.65.132 with HTTP; Mon, 26 Aug 2013 11:25:20 -0700 (PDT) In-Reply-To: References: <201308221408.08203.jhb@freebsd.org> <201308230945.28701.jhb@freebsd.org> Date: Mon, 26 Aug 2013 11:25:20 -0700 X-Google-Sender-Auth: GnwaRmfj3bRpfhZYJO532p2zh2I Message-ID: Subject: Re: Question about socket timeouts From: Davide Italiano To: Vitja Makarov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Aug 2013 18:25:21 -0000 On Fri, Aug 23, 2013 at 7:04 AM, Vitja Makarov wrote: > 2013/8/23 Davide Italiano : > > I think that for socket's timeouts it's ok to have a HZ-precision. It > would be much more important to implement high-precision timeouts for > select() and friends, if it's not done yet (sorry I'm running 9.1). > JFYI, select()/usleep()/etc... are all fine grained right now in HEAD. > > -- > vitja. -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare From owner-freebsd-current@FreeBSD.ORG Mon Aug 26 18:27:50 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0C7AECBC; Mon, 26 Aug 2013 18:27:50 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CC2B6263D; Mon, 26 Aug 2013 18:27:49 +0000 (UTC) Received: from jhbbsd.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 87952B945; Mon, 26 Aug 2013 14:27:48 -0400 (EDT) From: John Baldwin To: Ian Lepore Subject: Re: How to best overload the fileops ? Date: Mon, 26 Aug 2013 10:30:05 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <521508F4.6030502@rawbw.com> <5217C0DC.8050107@rawbw.com> <1377290165.1111.85.camel@revolution.hippie.lan> In-Reply-To: <1377290165.1111.85.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201308261030.05683.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 26 Aug 2013 14:27:48 -0400 (EDT) Cc: Yuri , John-Mark Gurney , Mateusz Guzik , Roman Divacky , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Aug 2013 18:27:50 -0000 On Friday, August 23, 2013 4:36:05 pm Ian Lepore wrote: > On Fri, 2013-08-23 at 13:06 -0700, Yuri wrote: > > On 08/23/2013 10:02, John Baldwin wrote: > > > There is something similar: see devfs_ops_f in sys/fs/devfs/devfs_vnops.c. > > > > devfs_ops_f is a local static fileops object for devfs. I don't see how > > is this similar to our situation. devfs doesn't overload any other file > > system, they are a file system on their own. > > > > I think the point is that devfs_ops_f provides several devfs-specific > methods and then "inherits" the rest by referencing the standard > vn_whatever functions. Since John recommended that you expose the > fo_whatever methods, I think he's suggesting you build your ops table by > providing your own close method and fill in the rest of the table with > the now-exposed kqueue ops methods. > > It's not as neat and clean as "class epollops : public kqueueops {...}" > but it's probably not as bad as using clever macros to try to turn C > into a sort of C++Lite. Correct. Just use something like: static struct fileops epollops = { .fo_read = kqueue_read, ... .fo_close = epoll_close, ... } -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Aug 26 18:45:30 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2B15D7D4; Mon, 26 Aug 2013 18:45:30 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A6C80273A; Mon, 26 Aug 2013 18:45:29 +0000 (UTC) Received: by mail-vc0-f169.google.com with SMTP id ib11so2362043vcb.14 for ; Mon, 26 Aug 2013 11:45:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=1eN6suHFYVPG/ZPNbyyUSstgvMT2vDNQnDD+m7G3FIU=; b=PS0HPAq5tNsxGTR6LSYTpce17cMfwJSWvYLZcpilsAmDAywC/1X4ZBUbsA1Z4xr3pc FHfFJ8w+sOwdFxh/L8K/QzYJFIUCr1/3itLxNVMBW5C6I0wsJuUVy887DTrGOfHIfqk/ ilqtOskFYN0z2uzxuCZCIttpRsU/UWp81/p0DdUSPzU0FIPy1fsshTUBCiyeAyLz7CqS l+jI/3wMGG8kdORenv35b84pvs+DyEiK9UWsG7OnnDGw3PNqIEVENYcxCKgUJAPziXGi Ov5L+MNijeuIx7EwOlzrU26BLjrzDti/ndSbLVv9CAIEk5M02L2YDCT1f6o5DemBTSPp tS1A== MIME-Version: 1.0 X-Received: by 10.220.174.200 with SMTP id u8mr16166622vcz.6.1377542728764; Mon, 26 Aug 2013 11:45:28 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.220.65.132 with HTTP; Mon, 26 Aug 2013 11:45:28 -0700 (PDT) In-Reply-To: References: <5218AA36.1080807@ipfw.ru> Date: Mon, 26 Aug 2013 11:45:28 -0700 X-Google-Sender-Auth: uAH71tZSdvuPxJdT5_x8nHM2C0g Message-ID: Subject: Re: [rfc] migrate lagg to an rmlock From: Davide Italiano To: Robert Watson Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net , Adrian Chadd , freebsd-current , "Alexander V. Chernikov" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Aug 2013 18:45:30 -0000 On Sat, Aug 24, 2013 at 7:16 AM, Robert Watson wrote: > On Sat, 24 Aug 2013, Alexander V. Chernikov wrote: > >> On 24.08.2013 00:54, Adrian Chadd wrote: >>> >>> >>> I'd like to commit this to -10. It migrates the if_lagg locking >>> from a rw lock to a rm lock. We see a bit of contention between the >>> transmit and >> >> >> We're running lagg with rmlock on several hundred heavily loaded machines, >> it really works better. However, there should not be any contention between >> receive and transmit side since there is actually no _real_ need to lock RX >> (and even use lagg receive code at all): >> >> http://lists.freebsd.org/pipermail/svn-src-all/2013-April/067570.html > > > We should distinguish "lock contention" from "line contention". When > acquiring a rwlock on multiple CPUs concurrently, the cache lines used to > implement the lock are contended, as they must bounce between caches via the > cache coherence protocol, also referred to as "contention". In the if_lagg > code, I assume that the read-only acquire of the rwlock (and perhaps now > rmlock) is for data stability rather than mutual exclusion -- e.g., to allow > processing to completion against a stable version of the lagg configuration. > As such, indeed, there should be no lock contention unless a configuration > update takes place, and any line contention is a property of the locking > primitive rather than data model. > > There are a number of other places in the kernel where migration to an > rmlock makes sense -- however, some care must be taken for four reasons: (1) > while read locks don't experience line contention, write locking becomes > observably e.g., rmlocks might not be suitable for tcbinfo; (2) rmlocks, > unlike rwlocks, more expensive so is not suitable for all rwlock line > contention spots -- implement reader priority propagation, so you must > reason about; and (3) historically, rmlocks have not fully implemented > WITNESS so you may get less good debugging output. if_lagg is a nice place I'm not sure what you mean here with (3), because from my understanding of the code WITNESS is implemented both in the sleepable and non-sleepable case, but there could be something I'm missing. Something I think we lack in rmlock code is fully supported LOCK_PROFILING as we have in all the other primitives, but again, if I'm wrong feel free to correct me. > to use rmlocks, as reconfigurations are very rare, and it's really all about > long-term data stability. > > Robert > > _______________________________________________ > 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" Thanks, -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare From owner-freebsd-current@FreeBSD.ORG Mon Aug 26 19:02:46 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 14C631EC for ; Mon, 26 Aug 2013 19:02:46 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D6B042884 for ; Mon, 26 Aug 2013 19:02:45 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id 9so5578104iec.2 for ; Mon, 26 Aug 2013 12:02:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=GeM71uf9yKXfmOVgZ//yTC6OA3Vs2a+bHMrBxGrIyJM=; b=WTiiQkQvc38npYqjeW255xwp1rPuZEvtnnoGD4uxxyE/U+7MkiBW2bIuCzK6utoXEP izhdb2W/HD9b6tnIman3k9l9A2MeEKudpI5G7jEGzqLBEe6wWj364/ACum4WRfcjzqz5 xnJsuk76u2Y7XTPN+gcdm3M/RsI4tXuYSI9+ZcniZbr0tIfbiUU5//H9dj0XDwZo5S8D YKm4XKkYf5m1e+gzGc0cPKCd/GnOfgxq/KM5U06JKz4uOIdljrzv+F0aEE9cg+Rs3jT3 N2ZAo4l7Vo4TtAtGnqtfZVgD5wsFNz7DfUvLAY5saa2mDeJpB1uMDyE4ac7qx5G4XdT/ wscA== X-Gm-Message-State: ALoCoQmX3g2ytNX0o4RONh0KnZ02J5NlrnoakcfW+UKub/70mnkqtSNaWEdkZXeIMkJ60sdfNvgi X-Received: by 10.50.124.65 with SMTP id mg1mr7519841igb.43.1377543764995; Mon, 26 Aug 2013 12:02:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.158.74 with HTTP; Mon, 26 Aug 2013 12:02:29 -0700 (PDT) In-Reply-To: <521B9CD7.8010902@bitfrost.no> References: <521B9CD7.8010902@bitfrost.no> From: "Lundberg, Johannes" Date: Mon, 26 Aug 2013 20:02:29 +0100 Message-ID: Subject: Re: xhci broken on 10-CURRENT and 2013 MacBook Air? To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current , freebsd-usb@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Aug 2013 19:02:46 -0000 Hi Hans Thanks but nothing of that makes any difference. Well, it's gonna be difficult to find the diff I think... The oldest image I could find was from May. What I'm doing now is compiling a bootonly.iso of current with a xhci.h/c that's reverted to 9.1 release version to see if that will boot. Johannes Lundberg BRILLIANTSERVICE CO., LTD. On Mon, Aug 26, 2013 at 7:22 PM, Hans Petter Selasky wrote: > On 08/26/13 17:55, Lundberg, Johannes wrote: > >> Just looked through the PR mail that came today and found possible >> duplicates. >> >> o usb/180726 usb XHCI umass support breaks between r248085 and >> r252560 >> o usb/179342 usb Freebsd 10.0-current USB 3.0 not working >> (xhci_do_coma >> >> > Hi, > > What happens if you load xhci after reaching the boot prompt? > > Might also be worth trying: > > hw.usb.xhci.msi=0 > > Are you able to bisect the 10-current code until you find the diff that > broke it? > > --HPS > From owner-freebsd-current@FreeBSD.ORG Mon Aug 26 19:08:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6B9397A2; Mon, 26 Aug 2013 19:08:18 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0DF4A28D4; Mon, 26 Aug 2013 19:08:18 +0000 (UTC) Received: from jhbbsd.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AB4C5B97F; Mon, 26 Aug 2013 15:08:16 -0400 (EDT) From: John Baldwin To: Davide Italiano Subject: Re: Question about socket timeouts Date: Mon, 26 Aug 2013 15:05:06 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <201308231129.03990.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Message-Id: <201308261505.06342.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 26 Aug 2013 15:08:16 -0400 (EDT) Cc: Vitja Makarov , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Aug 2013 19:08:18 -0000 On Monday, August 26, 2013 2:23:44 pm Davide Italiano wrote: > On Fri, Aug 23, 2013 at 5:29 PM, John Baldwin wrote: > > On Friday, August 23, 2013 9:53:12 am Davide Italiano wrote: > >> On Fri, Aug 23, 2013 at 3:45 PM, John Baldwin wrote: > >> > On Friday, August 23, 2013 2:27:58 am Vitja Makarov wrote: > >> >> 2013/8/22 John Baldwin : > >> >> > On Thursday, August 22, 2013 12:18:48 am Vitja Makarov wrote: > >> >> >> 2013/8/21 John Baldwin : > >> >> >> > On Monday, August 19, 2013 11:13:02 pm Daniel Eischen wrote: > >> >> >> >> On Mon, 19 Aug 2013, Adrian Chadd wrote: > >> >> >> >> > >> >> >> >> > Yes! Please file a PR! > >> >> >> >> > >> >> >> >> This sorta implies that both are acceptable (although, > >> >> >> >> the Linux behavior seems more desirable). > >> >> >> >> > >> >> >> >> http://austingroupbugs.net/view.php?id=369 > >> >> >> > > >> >> >> > No, that says "round up", so it does mean that the requested timeout > >> >> >> > should be the minimum amount slept. tvtohz() does this. Really odd > >> >> >> > that the socket code is using its own version of this rather than > >> >> >> > tvtohz(). > >> >> >> > > >> >> >> > Oh, I bet this just predates tvtohz(). Interesting that it keeps > > getting > >> >> >> > bug fixes in its history that simply using tvtohz() would have > > solved. > >> >> >> > > >> >> >> > Try this: > >> >> >> > > >> >> >> > Index: uipc_socket.c > >> >> >> > =================================================================== > >> >> >> > --- uipc_socket.c (revision 254570) > >> >> >> > +++ uipc_socket.c (working copy) > >> >> >> > @@ -2699,21 +2699,16 @@ sosetopt(struct socket *so, struct sockopt > > *sopt) > >> >> >> > if (error) > >> >> >> > goto bad; > >> >> >> > > >> >> >> > - /* assert(hz > 0); */ > >> >> >> > if (tv.tv_sec < 0 || tv.tv_sec > INT_MAX / > > hz || > >> >> >> > tv.tv_usec < 0 || tv.tv_usec >= 1000000) > > { > >> >> >> > error = EDOM; > >> >> >> > goto bad; > >> >> >> > } > >> >> >> > - /* assert(tick > 0); */ > >> >> >> > - /* assert(ULONG_MAX - INT_MAX >= 1000000); > > */ > >> >> >> > - val = (u_long)(tv.tv_sec * hz) + tv.tv_usec > > / tick; > >> >> >> > - if (val > INT_MAX) { > >> >> >> > + val = tvtohz(&tv); > >> >> >> > + if (val == INT_MAX) { > >> >> >> > error = EDOM; > >> >> >> > goto bad; > >> >> >> > } > >> >> >> > - if (val == 0 && tv.tv_usec != 0) > >> >> >> > - val = 1; > >> >> >> > > >> >> >> > switch (sopt->sopt_name) { > >> >> >> > case SO_SNDTIMEO: > >> >> >> > > >> >> >> > >> >> >> That must help. But I want to see the issue solved in the next > >> >> >> release. I can't apply patch to the production system. Btw in > >> >> >> production environment we have kern.hz set to 1000 so it's not a > >> >> >> problem there. > >> >> > > >> >> > Can you test this in some way in a test environment? > >> >> > > >> >> > >> >> Ok, sorry for posting out of the list. > >> >> > >> >> Simple test program is attached. Without your patch timeout expires in > >> >> about 20ms. With it it's ~40ms. > >> >> > >> >> 40 instead of 30 is beacuse of odd tick added by tvtohz(). > >> > > >> > Ok, thanks. tvtohz() will be good to MFC (and I will do that), but for > >> > HEAD I think we can fix this to use a precise timeout. I've cc'd davide@ > >> > so he can take a look at that. > >> > > >> > -- > >> > John Baldwin > >> > >> Hi, > >> I think I can switch this code to new timeout KPI, but this will > >> require the timeout field of 'struct sockbuf' to be changed from 'int' > >> to 'sbintime_t' which breaks binary compatibility. Do you have any > >> strong objections about this? If any, I would like this to happen ABI > >> freeze, so it looks like this is the right moment. > > > > This should be fine to change now, it just can't be MFC'd (which we can't > > do anyway). > > > > -- > > John Baldwin > > Please consider the following patch: > http://people.freebsd.org/~davide/review/socket_timeout.diff > I've tested it and it works OK. I got a timeout which is ~= 25ms using > the testcase provided by the user. > The only doubt I have is about the range check, I've changed a bit > because the 'integer' part of sbintime_t fits in 32-bits, but I'm not > sure it's the best way of doing this. Nice! Bruce actually wants me to adjust the range check a bit (which will fit in well with your changes I think). Please let me get that fix in (so it can be part of the future MFC) and then you can commit this. Thanks! Actually, I think you still need to patch the sogetopt() case to work correctly (it is still doing a manual conversion from 'val' to a timeval assuming it is in 'hz' units). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Aug 27 04:26:11 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 082D7B5F; Tue, 27 Aug 2013 04:26:11 +0000 (UTC) (envelope-from bryanv@daemoninthecloset.org) Received: from torment.daemoninthecloset.org (torment.daemoninthecloset.org [94.242.209.234]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8E07F28B4; Tue, 27 Aug 2013 04:26:10 +0000 (UTC) Received: from sage.daemoninthecloset.org (unknown [70.114.209.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sage.daemoninthecloset.org", Issuer "daemoninthecloset.org" (verified OK)) by torment.daemoninthecloset.org (Postfix) with ESMTPS id 9865C42C2632; Tue, 27 Aug 2013 06:24:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at daemoninthecloset.org X-Virus-Scanned: amavisd-new at daemoninthecloset.org Date: Mon, 26 Aug 2013 23:18:37 -0500 (CDT) From: Bryan Venteicher To: Harald Schmalzbauer Message-ID: <1117188271.19176.1377577117350.JavaMail.root@daemoninthecloset.org> In-Reply-To: <5214D37F.5000307@omnilan.de> References: <601099152.721.1375661537866.JavaMail.root@daemoninthecloset.org> <5214D37F.5000307@omnilan.de> Subject: Re: [CFT] VMware vmxnet3 ethernet driver MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [192.168.10.20] X-Mailer: Zimbra 8.0.2_GA_5569 (ZimbraWebClient - GC20 ([unknown])/8.0.2_GA_5569) Thread-Topic: VMware vmxnet3 ethernet driver Thread-Index: wVc2YFjrnum8ylaZxy8pLzcODD7JCg== Cc: FreeBSD Stable , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 27 Aug 2013 04:26:11 -0000 ----- Original Message ----- > Bez=C3=BCglich Bryan Venteicher's Nachricht vom 05.08.2013 02:12 (localti= me): > > Hi, > > > > I've ported the OpenBSD vmxnet3 ethernet driver to FreeBSD. I did a > > lot of cleanup, bug fixes, new features, etc (+2000 new lines) along > > the way so there is not much of a resemblance left. > > > > The driver is in good enough shape I'd like additional testers. A patch > > against -CURRENT is at [1]. Alternatively, the driver and a Makefile is > > at [2]; this should compile at least as far back as 9.1. I can look at > > 8-STABLE if there is interest. > > > > Obviously, besides reports of 'it works', I'm interested performance vs > > the emulated e1000, and (for those using it) the VMware tools vmxnet3 > > driver. Hopefully it is no worse :) >=20 > Hello Bryan, >=20 > thanks a lot for your hard work! >=20 > It seems if_vmx doesn't support jumbo frames. If I set mtu 9000, I get > =C2=BBvmx0: cannot populate Rx queue 0=C2=AB, I have no problems using ju= mbo > frames with vmxnet3. >=20 This could fail for two reasons - could not allocate an mbuf cluster, or the call to bus_dmamap_load_mbuf_sg() failed. For the former, you should check vmstat -z. For the later, the behavior of bus_dmamap_load_mbuf= _sg() changed between 9.1 and 9.2, and I know it was broken for awhile. I don't recall exactly when I fixed it (I think shortly after I made the original announcement). Could you retry with the files from HEAD @ [1]? Also, there are new sysctl oids (dev.vmx.X.mbuf_load_failed & dev.vmx.X.mgetcl_failed) for these errors. I just compiled the driver on 9.2-RC2 with the sources from HEAD and was able to change the MTU to 9000. [1]- http://svnweb.freebsd.org/base/head/sys/dev/vmware/vmxnet3/ > I took a oldish host (4x2,8GHz Core2[LGA775]) with recent software: ESXi > 5.1U1 and FreeBSD-9.2-RC2 > Two guests are connected to one MTU9000 "VMware Software Switch". >=20 I've got a few performance things to still look at. What's the sysctl=20 dev.vmx.X output for the if_vmx<->if_vmx tests? > Simple iperf (standard TCP) results: >=20 > vmxnet3jumbo <-> vmxnet3jumbo > 5.3Gbits/sec, load: 40-60%Sys 0.5-2%Intr >=20 > vmxnet3 <-> vmxnet3 > 1.85 GBits/sec, load: 60-80%Sys 0-0.8%Intr >=20 >=20 > if_vmx <-> if_vmx > 1.51 GBits/sec, load: 10-45%Sys 40-48%Intr > !!! > if_vmxjumbo <-> if_vmxjumbo not possible >=20 >=20 > if_em(e1000) <-> if_em(e1000) > 1.23 GBits/sec, load: 80-60%Sys 0.5-8%Intr >=20 > if_em(e1000)jumbo <-> if_em(e1000)jumbo > 2.27Gbits/sec, load: 40-30%Sys 0.5-5%Intr >=20 >=20 > if_igb(e1000e)junmbo <-> if_igb(e1000e)jumbo > 5.03 Gbits/s, load: 70-60%Sys 0.5%Intr >=20 > if_igb(e1000e) <-> if_igb(e1000e) > 1.39 Gbits/s, load: 60-80%Sys 0.5%Intr >=20 >=20 > f_igb(e1000e) <-> if_igb(e1000e), both hw.em.[rt]xd=3D4096 > 1.66 Gbits/s, load: 65-90%Sys 0.5%Intr >=20 > if_igb(e1000e)junmbo <-> if_igb(e1000e)jumbo, both hw.em.[rt]xd=3D4096 > 4.81 Gbits/s, load: 65%Sys 0.5%Intr >=20 > Conclusion: > if_vmx performs well compared to the regular emulated nics and standard > MTU, but it's behind tuned e1000e nic emulation and can't reach vmxnet3 > performance with regular mtu. If one needs throughput, the missing jumbo > frame support in if_vmx is a show stopper. >=20 > e1000e is preferable over e1000, even if not officially choosable with > "FreeBSD"-selection as guest (edit .vmx and alter ethernet0.virtualDev = =3D > "e1000e", and dont forget to set hw.em.enable_msix=3D0 in loader.conf, > although the driver e1000e attaches is if_igb!) >=20 > Thanks, >=20 > -Harry >=20 > From owner-freebsd-current@FreeBSD.ORG Tue Aug 27 09:05:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 39AC9FC6; Tue, 27 Aug 2013 09:05:40 +0000 (UTC) (envelope-from hps@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id E97942864; Tue, 27 Aug 2013 09:05:39 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta.bitpro.no (Postfix) with ESMTP id C801E7A26D; Tue, 27 Aug 2013 11:05:31 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 3C37D8F46F7; Tue, 27 Aug 2013 11:05:44 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQSU4shRy5XN; Tue, 27 Aug 2013 11:05:43 +0200 (CEST) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) by mail.lockless.no (Postfix) with ESMTPSA id 047CE8F46F4; Tue, 27 Aug 2013 11:05:42 +0200 (CEST) Message-ID: <521C6C26.7050207@bitfrost.no> Date: Tue, 27 Aug 2013 11:06:46 +0200 From: Hans Petter Selasky Organization: Bitfrost A/S User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130522 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Lundberg, Johannes" Subject: Re: xhci broken on 10-CURRENT and 2013 MacBook Air? References: <521B9CD7.8010902@bitfrost.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , freebsd-usb@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 27 Aug 2013 09:05:40 -0000 On 08/26/13 21:02, Lundberg, Johannes wrote: > Hi Hans > > Thanks but nothing of that makes any difference. Well, it's gonna be > difficult to find the diff I think... The oldest image I could find was > from May. > > What I'm doing now is compiling a bootonly.iso of current with a xhci.h/c > that's reverted to 9.1 release version to see if that will boot. > Hi, If it just hangs, can be an IRQ looping issue. You can also try to boot using bootverbose and configure the xhci driver with debugging on in the sys/dev/usb/controller/xhci.c by default to see just what is exactly going on. If you can suggest a patch, that would be great. --HPS From owner-freebsd-current@FreeBSD.ORG Tue Aug 27 09:12:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8C13233A for ; Tue, 27 Aug 2013 09:12:25 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5B7BA28E3 for ; Tue, 27 Aug 2013 09:12:25 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id 9so6801539iec.2 for ; Tue, 27 Aug 2013 02:12:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=W+6bHFM+rDPIL1SFe6zhducnTD7Rzrzb3OSg7gVXjsY=; b=DsoVYbVKrNFfszp1JYwuN8lISfLCFnHqd04AfVPzx6UXcMOYfVq7YBYrEOrMCOcgg4 ce2HW2cCojtOIJz8cn60E6LkPvi6w8mgXATSLcKbz5S2oL2YNg74M7IOf7YngBBcV7HS n8mdCiXm4vQSm9btVpg7TCnZUsZ1gcyANfHdzAopvXQj4I5nuyer7KbnaNj4FB8vR7R+ sJ0j/i5R9U/sLZ2F2P+exrdff7VBaO4Qsux+rHGQzkvRQoAPH6e73hfoRP51dFH/btsw B1joCYZzpWPQ2uFLDsWwVT6gYMRE+gXV9Eo2YnIJdis2UAzEFLsCo7W/rPeM2Wrw6C5G ZHuA== X-Gm-Message-State: ALoCoQmTIPKO2UkCzsZjn//dRFtdbOw7y9lBdiMY+mxmCprhd8BkreslJvMP77oj6DHk00LCViYN X-Received: by 10.50.49.65 with SMTP id s1mr9331415ign.43.1377594744443; Tue, 27 Aug 2013 02:12:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.158.74 with HTTP; Tue, 27 Aug 2013 02:12:09 -0700 (PDT) In-Reply-To: <521C6C26.7050207@bitfrost.no> References: <521B9CD7.8010902@bitfrost.no> <521C6C26.7050207@bitfrost.no> From: "Lundberg, Johannes" Date: Tue, 27 Aug 2013 10:12:09 +0100 Message-ID: Subject: Re: xhci broken on 10-CURRENT and 2013 MacBook Air? To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current , freebsd-usb@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 27 Aug 2013 09:12:25 -0000 Hi Hans Sure, I will try it out later and mail the results. Now I'm running current with usb part reverted to 9.1. It gets me pass the usb probing to the part that I really wanted to confirm. If FreeBSD supports the SSD drive on the new MacBook Air. It seems that it doesn't so that one more thing that we need to look into. Johannes Lundberg BRILLIANTSERVICE CO., LTD. On Tue, Aug 27, 2013 at 10:06 AM, Hans Petter Selasky wrote: > On 08/26/13 21:02, Lundberg, Johannes wrote: > >> Hi Hans >> >> Thanks but nothing of that makes any difference. Well, it's gonna be >> difficult to find the diff I think... The oldest image I could find was >> from May. >> >> What I'm doing now is compiling a bootonly.iso of current with a xhci.h/c >> that's reverted to 9.1 release version to see if that will boot. >> >> > Hi, > > If it just hangs, can be an IRQ looping issue. > > You can also try to boot using bootverbose and configure the xhci driver > with debugging on in the sys/dev/usb/controller/xhci.c by default to see > just what is exactly going on. > > If you can suggest a patch, that would be great. > > --HPS > > From owner-freebsd-current@FreeBSD.ORG Tue Aug 27 09:14:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 461A74AC; Tue, 27 Aug 2013 09:14:37 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E7F85290E; Tue, 27 Aug 2013 09:14:36 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id n20so1248515qaj.7 for ; Tue, 27 Aug 2013 02:14:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=zDhqW3lgKjDNPcHG+X9Wnzvfel2vzqqq40kiRZNyQzk=; b=vAJCx2vD1YsGqtKdmOeTz5mBoCXPET66NnH0+JRCVpna/bvqZaEMxb7Y/6jSJJJgyC zTbgxYaXcatmcloRofoXKX2o2Pu1oFLBu5a57y/ediY0PQPprLpMB0etCMj4zzxwDEGV Ug43CSNsmUIeU195I0ziL2Yw1fSYQp0fInkwr33DK9HsfPV75D2ZUDUK8N4LVaynkx2Y 7IIv2SHOalvYuvOKTkjCTfZHRUcyunmbwlar6urTyWc8PVcp5kU7F8UPt6ZqTEBl1tfV y47RODEbAhQcYOoJIXizEp77RV0QuyurQBjqlJH5eI5VAyOeAJvB0JFIjP8J0S2VQO8N OP2A== MIME-Version: 1.0 X-Received: by 10.49.107.105 with SMTP id hb9mr8278776qeb.74.1377594876103; Tue, 27 Aug 2013 02:14:36 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.128.70 with HTTP; Tue, 27 Aug 2013 02:14:36 -0700 (PDT) In-Reply-To: References: <521B9CD7.8010902@bitfrost.no> <521C6C26.7050207@bitfrost.no> Date: Tue, 27 Aug 2013 02:14:36 -0700 X-Google-Sender-Auth: HNcMyisgWaXF9yVpyws75YZPjA8 Message-ID: Subject: Re: xhci broken on 10-CURRENT and 2013 MacBook Air? From: Adrian Chadd To: "Lundberg, Johannes" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Hans Petter Selasky , FreeBSD Current , "freebsd-usb@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 27 Aug 2013 09:14:37 -0000 Hm! Is there a Linux driver for this SSD? Does Linux approximately boot on this thing? -adrian From owner-freebsd-current@FreeBSD.ORG Tue Aug 27 11:11:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7646B7B8; Tue, 27 Aug 2013 11:11:56 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 27A8B2F60; Tue, 27 Aug 2013 11:11:56 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r7RBBlp8097269; Tue, 27 Aug 2013 07:11:52 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <521C8973.4080504@m5p.com> Date: Tue, 27 Aug 2013 07:11:47 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130716 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hans Petter Selasky Subject: Re: ulpt can't attach Lexmark E120 References: <5105527F.3010708@m5p.com> <201301271915.47712.hselasky@c2i.net> <510570C1.1060607@m5p.com> <201301272007.30682.hselasky@c2i.net> <5105AB16.2000607@m5p.com> <5215F4DF.6000305@m5p.com> <5215F743.8060403@bitfrost.no> <5216ACE5.7000500@m5p.com> <5216FE9F.2030608@bitfrost.no> <52174378.2020101@m5p.com> <521801E5.9000309@m5p.com> <52184F59.5080100@bitfrost.no> <5218F993.9050504@m5p.com> <5219C3FF.1070509@bitfrost.no> <521A9155.5010102@m5p.com> In-Reply-To: <521A9155.5010102@m5p.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Tue, 27 Aug 2013 07:11:52 -0400 (EDT) Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 27 Aug 2013 11:11:56 -0000 On 08/25/13 19:20, George Mitchell wrote: > On 08/25/13 04:44, Hans Petter Selasky wrote: >> On 08/24/13 20:21, George Mitchell wrote: >>> >>> Setting hw.usb.dwc_otg.debug to any value greater than 0 generates an >>> unending stream of debug output and effectively locks up the chip >>> scrolling the output on the display. Perhaps there are some specific >>> debug messages I could put in ... -- George >> >> Hi, >> >> Can you try this patch: >> >> http://svnweb.freebsd.org/changeset/base/254828 >> >> --HPS >> _______________________________________________ >> [...] > > I started trying to do too many things at once, and as a result it's > going to take me a little while to try this patch out. My apologies! > -- George > Now that I have put my RPi build environment back together, I hope to try your patch tonight. Sorry for the delay! -- George From owner-freebsd-current@FreeBSD.ORG Tue Aug 27 05:10:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 41158371; Tue, 27 Aug 2013 05:10:18 +0000 (UTC) (envelope-from vitja.makarov@gmail.com) Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CF34D2AFD; Tue, 27 Aug 2013 05:10:17 +0000 (UTC) Received: by mail-vb0-f47.google.com with SMTP id h10so2712870vbh.34 for ; Mon, 26 Aug 2013 22:10:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TkmbD9KWNuKjO6DVtlPMl7QPVGf5N3MWVpLZk0vV4Vc=; b=NFTtskuLmn/bHpNmg6XKzSRJiGGQXAC2CFXQyxEuIIINR5oYweI4lGawyuq18ED9dd MTcZYOCd7nUiKyw5HgY+Me7UNFbXPhazKcT2XdT+0w+jtCrUmqwp3FgHXs9LnJyjL+oj 0YRgS+Wf86FAAnIQ72ZXG3LTHA6LkGn9x68UhbEdTiR0EcThnLmEr6rEIahj+HCSeZIs 7mN4nLc53vm1ii1/B/UmHkUk9YKNMGNdVdL0vltilBqevS5kA7Znahv22qs1BNHFczED grV5nB6SJGX63LsIqKUvACQTmVsJgfl2IkWZKNFTtg66VC3pyKSIAa82N+V+3OoH2O2m HBuA== MIME-Version: 1.0 X-Received: by 10.220.186.202 with SMTP id ct10mr18648408vcb.14.1377580216889; Mon, 26 Aug 2013 22:10:16 -0700 (PDT) Received: by 10.52.27.51 with HTTP; Mon, 26 Aug 2013 22:10:16 -0700 (PDT) In-Reply-To: References: <201308221408.08203.jhb@freebsd.org> <201308230945.28701.jhb@freebsd.org> Date: Tue, 27 Aug 2013 09:10:16 +0400 Message-ID: Subject: Re: Question about socket timeouts From: Vitja Makarov To: Davide Italiano Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Tue, 27 Aug 2013 11:24:48 +0000 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 27 Aug 2013 05:10:18 -0000 2013/8/26 Davide Italiano : > Please consider the following patch: > http://people.freebsd.org/~davide/review/socket_timeout.diff > I've tested it and it works OK. I got a timeout which is ~= 25ms using > the testcase provided by the user. > The only doubt I have is about the range check, I've changed a bit > because the 'integer' part of sbintime_t fits in 32-bits, but I'm not > sure it's the best way of doing this. Nice, that worked for me! I got ~26ms timeouts in average on my VM. > On Fri, Aug 23, 2013 at 7:04 AM, Vitja Makarov wrote: >> 2013/8/23 Davide Italiano : >> >> I think that for socket's timeouts it's ok to have a HZ-precision. It >> would be much more important to implement high-precision timeouts for >> select() and friends, if it's not done yet (sorry I'm running 9.1). >> > > JFYI, select()/usleep()/etc... are all fine grained right now in HEAD. > That's cool! Does that mean that FreeBSD 10 would be a tickless system? -- vitja. From owner-freebsd-current@FreeBSD.ORG Tue Aug 27 13:17:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 65EE969D for ; Tue, 27 Aug 2013 13:17:19 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from hosted.mx.as41113.net (abby.lhr1.as41113.net [91.208.177.20]) by mx1.freebsd.org (Postfix) with ESMTP id 2EE5226B4 for ; Tue, 27 Aug 2013 13:17:15 +0000 (UTC) Received: from [192.168.1.218] (staff-ns50-3.as25178.net [212.9.98.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by hosted.mx.as41113.net (Postfix) with ESMTPSA id 3cPVx61MTkzB8 for ; Tue, 27 Aug 2013 14:17:14 +0100 (BST) Message-ID: <521CA6D6.2060509@rewt.org.uk> Date: Tue, 27 Aug 2013 14:17:10 +0100 From: Joe Holden User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: route get fails References: <20130824134223.6bf7634c@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 27 Aug 2013 13:17:19 -0000 On 24/08/2013 13:30, Kimmo Paasiala wrote: > On Sat, Aug 24, 2013 at 2:42 PM, Pawel Pekala wrote: >> Hi, >> >> For some time now I get this: >> >> [corn:~]> route get >> route: writing to routing socket: Invalid argument >> >> Is this just my build or anyone can confirm this? >> >> -- >> pozdrawiam / with regards >> PaweÅ‚ PÄ™kala > > Nothing wrong there, you're not providing a required argument that is > the destination IP address. In my opinion route(8) should return a > proper error message in this case. OS X route(8) behaves exactly the > same BTW. > > -Kimmo You probably want netstat -rnfinet[6] here, judging from your surprise that 'route get' returns the above. From owner-freebsd-current@FreeBSD.ORG Tue Aug 27 13:21:48 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 98A268E7; Tue, 27 Aug 2013 13:21:48 +0000 (UTC) (envelope-from lists@c0mplx.org) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5A2FD2719; Tue, 27 Aug 2013 13:21:48 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VEJDN-0002XR-Cy; Tue, 27 Aug 2013 15:21:45 +0200 Date: Tue, 27 Aug 2013 15:21:45 +0200 From: Kurt Jaeger To: Pawel Pekala Subject: Re: route get fails Message-ID: <20130827132145.GX2951@home.opsec.eu> References: <20130824134223.6bf7634c@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130824134223.6bf7634c@FreeBSD.org> Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 27 Aug 2013 13:21:48 -0000 Hi! > For some time now I get this: > > [corn:~]> route get > route: writing to routing socket: Invalid argument > > Is this just my build or anyone can confirm this? A patch for route to display a more useful error message: http://www.freebsd.org/cgi/query-pr.cgi?pr=181532 -- pi@opsec.eu +49 171 3101372 7 years to go ! From owner-freebsd-current@FreeBSD.ORG Tue Aug 27 14:29:19 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1272C353; Tue, 27 Aug 2013 14:29:19 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from s1.omnilan.de (s1.omnilan.de [217.91.127.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6E7742B74; Tue, 27 Aug 2013 14:29:18 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by s1.omnilan.de (8.13.8/8.13.8) with ESMTP id r7RET5Hv049993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Aug 2013 16:29:06 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <521CB7AC.90605@omnilan.de> Date: Tue, 27 Aug 2013 16:29:00 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Bryan Venteicher Subject: Re: [CFT] VMware vmxnet3 ethernet driver References: <601099152.721.1375661537866.JavaMail.root@daemoninthecloset.org> <5214D37F.5000307@omnilan.de> <1117188271.19176.1377577117350.JavaMail.root@daemoninthecloset.org> In-Reply-To: <1117188271.19176.1377577117350.JavaMail.root@daemoninthecloset.org> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA68C03B9D347177ACD70FBCB" Cc: FreeBSD Stable , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 27 Aug 2013 14:29:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA68C03B9D347177ACD70FBCB Content-Type: multipart/mixed; boundary="------------030705050708030202060003" This is a multi-part message in MIME format. --------------030705050708030202060003 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bez=C3=BCglich Bryan Venteicher's Nachricht vom 27.08.2013 06:18 (localt= ime): =2E.. >> It seems if_vmx doesn't support jumbo frames. If I set mtu 9000, I get= >> =C2=BBvmx0: cannot populate Rx queue 0=C2=AB, I have no problems using= jumbo >> frames with vmxnet3. >> > This could fail for two reasons - could not allocate an mbuf cluster, > or the call to bus_dmamap_load_mbuf_sg() failed. For the former, you > should check vmstat -z. For the later, the behavior of bus_dmamap_load_= mbuf_sg() > changed between 9.1 and 9.2, and I know it was broken for awhile. I don= 't > recall exactly when I fixed it (I think shortly after I made the origin= al > announcement). Could you retry with the files from HEAD @ [1]? Also, th= ere > are new sysctl oids (dev.vmx.X.mbuf_load_failed & dev.vmx.X.mgetcl_fail= ed) > for these errors. > > I just compiled the driver on 9.2-RC2 with the sources from HEAD and wa= s > able to change the MTU to 9000. > > [1]- http://svnweb.freebsd.org/base/head/sys/dev/vmware/vmxnet3/ Thanks a lot for your ongoing work! I can confirm that with recent if_vmx.c from head and compiled for 9.2-RC3, setting mtu to 9000 works as expected :-) >> I took a oldish host (4x2,8GHz Core2[LGA775]) with recent software: ES= Xi >> 5.1U1 and FreeBSD-9.2-RC2 >> Two guests are connected to one MTU9000 "VMware Software Switch". >> > I've got a few performance things to still look at. What's the sysctl=20 > dev.vmx.X output for the if_vmx<->if_vmx tests? Just repeated if_vmx simple iperf bench, results vary slightly from standard 10sec run to run, but still noticable high Intr usage: if_vmx <-> if_vmx 1.32 GBits/sec, load: 10-45%Sys 40-48%Intr if_vmxJumbo <-> if_vmxJumbo 5.01 GBits/sec, load: 10-45%Sys 40-48%Intr Please find attached the different outputs of dev.vmx.X (the mtu9000 run = was only 3.47GBits/sec in that case, took the numbers anyway) wbr, -Harry --------------030705050708030202060003 Content-Type: text/plain; name="dev_vmx_iperfclient-i386_mtu1500.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dev_vmx_iperfclient-i386_mtu1500.txt" ZGV2LnZteC4wLiVkZXNjOiBWTXdhcmUgVk1YTkVUMyBFdGhlcm5ldCBBZGFwdGVyCmRldi52 bXguMC4lZHJpdmVyOiB2bXgKZGV2LnZteC4wLiVsb2NhdGlvbjogc2xvdD0wIGZ1bmN0aW9u PTAgaGFuZGxlPVxfU0JfLlBDSTAuUEU0MC5TMUYwCmRldi52bXguMC4lcG5waW5mbzogdmVu ZG9yPTB4MTVhZCBkZXZpY2U9MHgwN2IwIHN1YnZlbmRvcj0weDE1YWQgc3ViZGV2aWNlPTB4 MDdiMCBjbGFzcz0weDAyMDAwMApkZXYudm14LjAuJXBhcmVudDogcGNpMwpkZXYudm14LjAu bnR4cXVldWVzOiAxCmRldi52bXguMC5ucnhxdWV1ZXM6IDEKZGV2LnZteC4wLmNvbGxhcHNl ZDogMApkZXYudm14LjAubWdldGNsX2ZhaWxlZDogMApkZXYudm14LjAubWJ1Zl9sb2FkX2Zh aWxlZDogMApkZXYudm14LjAudHhxMC5yaW5nZnVsbDogMTMzNDc5CmRldi52bXguMC50eHEw Lm9mZmxvYWRfZmFpbGVkOiAwCmRldi52bXguMC50eHEwLmhzdGF0cy50c29fcGFja2V0czog NTY0OTg2CmRldi52bXguMC50eHEwLmhzdGF0cy50c29fYnl0ZXM6IDE2ODYxODQ1ODAKZGV2 LnZteC4wLnR4cTAuaHN0YXRzLnVjYXN0X3BhY2tldHM6IDU3MDYwNApkZXYudm14LjAudHhx MC5oc3RhdHMudW5pY2FzdF9ieXRlczogMTY5NDY3OTYwOApkZXYudm14LjAudHhxMC5oc3Rh dHMubWNhc3RfcGFja2V0czogMApkZXYudm14LjAudHhxMC5oc3RhdHMubWNhc3RfYnl0ZXM6 IDAKZGV2LnZteC4wLnR4cTAuaHN0YXRzLmVycm9yOiAwCmRldi52bXguMC50eHEwLmhzdGF0 cy5kaXNjYXJkOiAwCmRldi52bXguMC50eHEwLmRlYnVnLmNtZF9oZWFkOiAxMDYKZGV2LnZt eC4wLnR4cTAuZGVidWcuY21kX25leHQ6IDEwNgpkZXYudm14LjAudHhxMC5kZWJ1Zy5jbWRf bmRlc2M6IDUxMgpkZXYudm14LjAudHhxMC5kZWJ1Zy5jbWRfZ2VuOiAwCmRldi52bXguMC50 eHEwLmRlYnVnLmNvbXBfbmV4dDogMjM4CmRldi52bXguMC50eHEwLmRlYnVnLmNvbXBfbmRl c2M6IDUxMgpkZXYudm14LjAudHhxMC5kZWJ1Zy5jb21wX2dlbjogMQpkZXYudm14LjAucnhx MC5oc3RhdHMubHJvX3BhY2tldHM6IDAKZGV2LnZteC4wLnJ4cTAuaHN0YXRzLmxyb19ieXRl czogMApkZXYudm14LjAucnhxMC5oc3RhdHMudWNhc3RfcGFja2V0czogNTc5MTM3CmRldi52 bXguMC5yeHEwLmhzdGF0cy51bmljYXN0X2J5dGVzOiAzODQwOTMxMgpkZXYudm14LjAucnhx MC5oc3RhdHMubWNhc3RfcGFja2V0czogMApkZXYudm14LjAucnhxMC5oc3RhdHMubWNhc3Rf Ynl0ZXM6IDAKZGV2LnZteC4wLnJ4cTAuaHN0YXRzLmJjYXN0X3BhY2tldHM6IDI5CmRldi52 bXguMC5yeHEwLmhzdGF0cy5iY2FzdF9ieXRlczogMTc0MApkZXYudm14LjAucnhxMC5oc3Rh dHMubm9idWZmZXI6IDAKZGV2LnZteC4wLnJ4cTAuaHN0YXRzLmVycm9yOiAwCmRldi52bXgu MC5yeHEwLmRlYnVnLmNtZDBfZmlsbDogOTQKZGV2LnZteC4wLnJ4cTAuZGVidWcuY21kMF9u ZGVzYzogMjU2CmRldi52bXguMC5yeHEwLmRlYnVnLmNtZDBfZ2VuOiAwCmRldi52bXguMC5y eHEwLmRlYnVnLmNtZDFfZmlsbDogMApkZXYudm14LjAucnhxMC5kZWJ1Zy5jbWQxX25kZXNj OiAyNTYKZGV2LnZteC4wLnJ4cTAuZGVidWcuY21kMV9nZW46IDAKZGV2LnZteC4wLnJ4cTAu ZGVidWcuY29tcF9uZXh0OiA5NApkZXYudm14LjAucnhxMC5kZWJ1Zy5jb21wX25kZXNjOiA1 MTIKZGV2LnZteC4wLnJ4cTAuZGVidWcuY29tcF9nZW46IDAK --------------030705050708030202060003 Content-Type: text/plain; name="dev_vmx_iperfclient-i386_mtu9000.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dev_vmx_iperfclient-i386_mtu9000.txt" ZGV2LnZteC4wLiVkZXNjOiBWTXdhcmUgVk1YTkVUMyBFdGhlcm5ldCBBZGFwdGVyCmRldi52 bXguMC4lZHJpdmVyOiB2bXgKZGV2LnZteC4wLiVsb2NhdGlvbjogc2xvdD0wIGZ1bmN0aW9u PTAgaGFuZGxlPVxfU0JfLlBDSTAuUEU0MC5TMUYwCmRldi52bXguMC4lcG5waW5mbzogdmVu ZG9yPTB4MTVhZCBkZXZpY2U9MHgwN2IwIHN1YnZlbmRvcj0weDE1YWQgc3ViZGV2aWNlPTB4 MDdiMCBjbGFzcz0weDAyMDAwMApkZXYudm14LjAuJXBhcmVudDogcGNpMwpkZXYudm14LjAu bnR4cXVldWVzOiAxCmRldi52bXguMC5ucnhxdWV1ZXM6IDEKZGV2LnZteC4wLmNvbGxhcHNl ZDogMApkZXYudm14LjAubWdldGNsX2ZhaWxlZDogMApkZXYudm14LjAubWJ1Zl9sb2FkX2Zh aWxlZDogMApkZXYudm14LjAudHhxMC5yaW5nZnVsbDogNTg5NTAKZGV2LnZteC4wLnR4cTAu b2ZmbG9hZF9mYWlsZWQ6IDAKZGV2LnZteC4wLnR4cTAuaHN0YXRzLnRzb19wYWNrZXRzOiAy MzA1MDgKZGV2LnZteC4wLnR4cTAuaHN0YXRzLnRzb19ieXRlczogNDMxNDAyMDExMgpkZXYu dm14LjAudHhxMC5oc3RhdHMudWNhc3RfcGFja2V0czogMjM1MzgyCmRldi52bXguMC50eHEw LmhzdGF0cy51bmljYXN0X2J5dGVzOiA0MzU2OTQzNTUyCmRldi52bXguMC50eHEwLmhzdGF0 cy5tY2FzdF9wYWNrZXRzOiAwCmRldi52bXguMC50eHEwLmhzdGF0cy5tY2FzdF9ieXRlczog MApkZXYudm14LjAudHhxMC5oc3RhdHMuZXJyb3I6IDAKZGV2LnZteC4wLnR4cTAuaHN0YXRz LmRpc2NhcmQ6IDAKZGV2LnZteC4wLnR4cTAuZGVidWcuY21kX2hlYWQ6IDMzMwpkZXYudm14 LjAudHhxMC5kZWJ1Zy5jbWRfbmV4dDogMzMzCmRldi52bXguMC50eHEwLmRlYnVnLmNtZF9u ZGVzYzogNTEyCmRldi52bXguMC50eHEwLmRlYnVnLmNtZF9nZW46IDAKZGV2LnZteC4wLnR4 cTAuZGVidWcuY29tcF9uZXh0OiAzNzYKZGV2LnZteC4wLnR4cTAuZGVidWcuY29tcF9uZGVz YzogNTEyCmRldi52bXguMC50eHEwLmRlYnVnLmNvbXBfZ2VuOiAwCmRldi52bXguMC5yeHEw LmhzdGF0cy5scm9fcGFja2V0czogMApkZXYudm14LjAucnhxMC5oc3RhdHMubHJvX2J5dGVz OiAwCmRldi52bXguMC5yeHEwLmhzdGF0cy51Y2FzdF9wYWNrZXRzOiAyNTU5MTgKZGV2LnZt eC4wLnJ4cTAuaHN0YXRzLnVuaWNhc3RfYnl0ZXM6IDE3MDQzOTE4CmRldi52bXguMC5yeHEw LmhzdGF0cy5tY2FzdF9wYWNrZXRzOiAwCmRldi52bXguMC5yeHEwLmhzdGF0cy5tY2FzdF9i eXRlczogMApkZXYudm14LjAucnhxMC5oc3RhdHMuYmNhc3RfcGFja2V0czogMTUKZGV2LnZt eC4wLnJ4cTAuaHN0YXRzLmJjYXN0X2J5dGVzOiA5MDAKZGV2LnZteC4wLnJ4cTAuaHN0YXRz Lm5vYnVmZmVyOiAwCmRldi52bXguMC5yeHEwLmhzdGF0cy5lcnJvcjogMApkZXYudm14LjAu cnhxMC5kZWJ1Zy5jbWQwX2ZpbGw6IDEyMQpkZXYudm14LjAucnhxMC5kZWJ1Zy5jbWQwX25k ZXNjOiAyNTYKZGV2LnZteC4wLnJ4cTAuZGVidWcuY21kMF9nZW46IDEKZGV2LnZteC4wLnJ4 cTAuZGVidWcuY21kMV9maWxsOiAwCmRldi52bXguMC5yeHEwLmRlYnVnLmNtZDFfbmRlc2M6 IDI1NgpkZXYudm14LjAucnhxMC5kZWJ1Zy5jbWQxX2dlbjogMApkZXYudm14LjAucnhxMC5k ZWJ1Zy5jb21wX25leHQ6IDQ0NQpkZXYudm14LjAucnhxMC5kZWJ1Zy5jb21wX25kZXNjOiA1 MTIKZGV2LnZteC4wLnJ4cTAuZGVidWcuY29tcF9nZW46IDAK --------------030705050708030202060003 Content-Type: text/plain; name="dev_vmx_iperfserver-amd64_mtu1500.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dev_vmx_iperfserver-amd64_mtu1500.txt" ZGV2LnZteC4wLiVkZXNjOiBWTXdhcmUgVk1YTkVUMyBFdGhlcm5ldCBBZGFwdGVyCmRldi52 bXguMC4lZHJpdmVyOiB2bXgKZGV2LnZteC4wLiVsb2NhdGlvbjogc2xvdD0wIGZ1bmN0aW9u PTAgaGFuZGxlPVxfU0JfLlBDSTAuUEU0MS5TMUYwCmRldi52bXguMC4lcG5waW5mbzogdmVu ZG9yPTB4MTVhZCBkZXZpY2U9MHgwN2IwIHN1YnZlbmRvcj0weDE1YWQgc3ViZGV2aWNlPTB4 MDdiMCBjbGFzcz0weDAyMDAwMApkZXYudm14LjAuJXBhcmVudDogcGNpNApkZXYudm14LjAu bnR4cXVldWVzOiAxCmRldi52bXguMC5ucnhxdWV1ZXM6IDEKZGV2LnZteC4wLmNvbGxhcHNl ZDogMApkZXYudm14LjAubWdldGNsX2ZhaWxlZDogMApkZXYudm14LjAubWJ1Zl9sb2FkX2Zh aWxlZDogMApkZXYudm14LjAudHhxMC5yaW5nZnVsbDogMApkZXYudm14LjAudHhxMC5vZmZs b2FkX2ZhaWxlZDogMApkZXYudm14LjAudHhxMC5oc3RhdHMudHNvX3BhY2tldHM6IDAKZGV2 LnZteC4wLnR4cTAuaHN0YXRzLnRzb19ieXRlczogMApkZXYudm14LjAudHhxMC5oc3RhdHMu dWNhc3RfcGFja2V0czogNTc5MTM1CmRldi52bXguMC50eHEwLmhzdGF0cy51bmljYXN0X2J5 dGVzOiAzODQwOTE3NApkZXYudm14LjAudHhxMC5oc3RhdHMubWNhc3RfcGFja2V0czogMApk ZXYudm14LjAudHhxMC5oc3RhdHMubWNhc3RfYnl0ZXM6IDAKZGV2LnZteC4wLnR4cTAuaHN0 YXRzLmVycm9yOiAwCmRldi52bXguMC50eHEwLmhzdGF0cy5kaXNjYXJkOiAwCmRldi52bXgu MC50eHEwLmRlYnVnLmNtZF9oZWFkOiA2NApkZXYudm14LjAudHhxMC5kZWJ1Zy5jbWRfbmV4 dDogNjQKZGV2LnZteC4wLnR4cTAuZGVidWcuY21kX25kZXNjOiA1MTIKZGV2LnZteC4wLnR4 cTAuZGVidWcuY21kX2dlbjogMApkZXYudm14LjAudHhxMC5kZWJ1Zy5jb21wX25leHQ6IDY0 CmRldi52bXguMC50eHEwLmRlYnVnLmNvbXBfbmRlc2M6IDUxMgpkZXYudm14LjAudHhxMC5k ZWJ1Zy5jb21wX2dlbjogMApkZXYudm14LjAucnhxMC5oc3RhdHMubHJvX3BhY2tldHM6IDAK ZGV2LnZteC4wLnJ4cTAuaHN0YXRzLmxyb19ieXRlczogMApkZXYudm14LjAucnhxMC5oc3Rh dHMudWNhc3RfcGFja2V0czogMTE0NzE4NgpkZXYudm14LjAucnhxMC5oc3RhdHMudW5pY2Fz dF9ieXRlczogMTczMjA3MTE2MApkZXYudm14LjAucnhxMC5oc3RhdHMubWNhc3RfcGFja2V0 czogMApkZXYudm14LjAucnhxMC5oc3RhdHMubWNhc3RfYnl0ZXM6IDAKZGV2LnZteC4wLnJ4 cTAuaHN0YXRzLmJjYXN0X3BhY2tldHM6IDQ0CmRldi52bXguMC5yeHEwLmhzdGF0cy5iY2Fz dF9ieXRlczogMjY0MApkZXYudm14LjAucnhxMC5oc3RhdHMubm9idWZmZXI6IDMxMwpkZXYu dm14LjAucnhxMC5oc3RhdHMuZXJyb3I6IDAKZGV2LnZteC4wLnJ4cTAuZGVidWcuY21kMF9m aWxsOiA5NApkZXYudm14LjAucnhxMC5kZWJ1Zy5jbWQwX25kZXNjOiAyNTYKZGV2LnZteC4w LnJ4cTAuZGVidWcuY21kMF9nZW46IDEKZGV2LnZteC4wLnJ4cTAuZGVidWcuY21kMV9maWxs OiAwCmRldi52bXguMC5yeHEwLmRlYnVnLmNtZDFfbmRlc2M6IDI1NgpkZXYudm14LjAucnhx MC5kZWJ1Zy5jbWQxX2dlbjogMApkZXYudm14LjAucnhxMC5kZWJ1Zy5jb21wX25leHQ6IDM1 MApkZXYudm14LjAucnhxMC5kZWJ1Zy5jb21wX25kZXNjOiA1MTIKZGV2LnZteC4wLnJ4cTAu ZGVidWcuY29tcF9nZW46IDEK --------------030705050708030202060003 Content-Type: text/plain; name="dev_vmx_iperfserver-amd64_mtu9000.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dev_vmx_iperfserver-amd64_mtu9000.txt" ZGV2LnZteC4wLiVkZXNjOiBWTXdhcmUgVk1YTkVUMyBFdGhlcm5ldCBBZGFwdGVyCmRldi52 bXguMC4lZHJpdmVyOiB2bXgKZGV2LnZteC4wLiVsb2NhdGlvbjogc2xvdD0wIGZ1bmN0aW9u PTAgaGFuZGxlPVxfU0JfLlBDSTAuUEU0MS5TMUYwCmRldi52bXguMC4lcG5waW5mbzogdmVu ZG9yPTB4MTVhZCBkZXZpY2U9MHgwN2IwIHN1YnZlbmRvcj0weDE1YWQgc3ViZGV2aWNlPTB4 MDdiMCBjbGFzcz0weDAyMDAwMApkZXYudm14LjAuJXBhcmVudDogcGNpNApkZXYudm14LjAu bnR4cXVldWVzOiAxCmRldi52bXguMC5ucnhxdWV1ZXM6IDEKZGV2LnZteC4wLmNvbGxhcHNl ZDogMApkZXYudm14LjAubWdldGNsX2ZhaWxlZDogMApkZXYudm14LjAubWJ1Zl9sb2FkX2Zh aWxlZDogMApkZXYudm14LjAudHhxMC5yaW5nZnVsbDogMApkZXYudm14LjAudHhxMC5vZmZs b2FkX2ZhaWxlZDogMApkZXYudm14LjAudHhxMC5oc3RhdHMudHNvX3BhY2tldHM6IDAKZGV2 LnZteC4wLnR4cTAuaHN0YXRzLnRzb19ieXRlczogMApkZXYudm14LjAudHhxMC5oc3RhdHMu dWNhc3RfcGFja2V0czogMjU1OTE2CmRldi52bXguMC50eHEwLmhzdGF0cy51bmljYXN0X2J5 dGVzOiAxNzA0Mzc4MApkZXYudm14LjAudHhxMC5oc3RhdHMubWNhc3RfcGFja2V0czogMApk ZXYudm14LjAudHhxMC5oc3RhdHMubWNhc3RfYnl0ZXM6IDAKZGV2LnZteC4wLnR4cTAuaHN0 YXRzLmVycm9yOiAwCmRldi52bXguMC50eHEwLmhzdGF0cy5kaXNjYXJkOiAwCmRldi52bXgu MC50eHEwLmRlYnVnLmNtZF9oZWFkOiA0MjkKZGV2LnZteC4wLnR4cTAuZGVidWcuY21kX25l eHQ6IDQyOQpkZXYudm14LjAudHhxMC5kZWJ1Zy5jbWRfbmRlc2M6IDUxMgpkZXYudm14LjAu dHhxMC5kZWJ1Zy5jbWRfZ2VuOiAwCmRldi52bXguMC50eHEwLmRlYnVnLmNvbXBfbmV4dDog NDI5CmRldi52bXguMC50eHEwLmRlYnVnLmNvbXBfbmRlc2M6IDUxMgpkZXYudm14LjAudHhx MC5kZWJ1Zy5jb21wX2dlbjogMApkZXYudm14LjAucnhxMC5oc3RhdHMubHJvX3BhY2tldHM6 IDAKZGV2LnZteC4wLnJ4cTAuaHN0YXRzLmxyb19ieXRlczogMApkZXYudm14LjAucnhxMC5o c3RhdHMudWNhc3RfcGFja2V0czogNTAxMTg2CmRldi52bXguMC5yeHEwLmhzdGF0cy51bmlj YXN0X2J5dGVzOiA0MzcwMjQzODE2CmRldi52bXguMC5yeHEwLmhzdGF0cy5tY2FzdF9wYWNr ZXRzOiAwCmRldi52bXguMC5yeHEwLmhzdGF0cy5tY2FzdF9ieXRlczogMApkZXYudm14LjAu cnhxMC5oc3RhdHMuYmNhc3RfcGFja2V0czogOApkZXYudm14LjAucnhxMC5oc3RhdHMuYmNh c3RfYnl0ZXM6IDQ4MApkZXYudm14LjAucnhxMC5oc3RhdHMubm9idWZmZXI6IDI4NwpkZXYu dm14LjAucnhxMC5oc3RhdHMuZXJyb3I6IDAKZGV2LnZteC4wLnJ4cTAuZGVidWcuY21kMF9m aWxsOiAxNDcKZGV2LnZteC4wLnJ4cTAuZGVidWcuY21kMF9uZGVzYzogMjU2CmRldi52bXgu MC5yeHEwLmRlYnVnLmNtZDBfZ2VuOiAxCmRldi52bXguMC5yeHEwLmRlYnVnLmNtZDFfZmls bDogMjM0CmRldi52bXguMC5yeHEwLmRlYnVnLmNtZDFfbmRlc2M6IDI1NgpkZXYudm14LjAu cnhxMC5kZWJ1Zy5jbWQxX2dlbjogMQpkZXYudm14LjAucnhxMC5kZWJ1Zy5jb21wX25leHQ6 IDgwCmRldi52bXguMC5yeHEwLmRlYnVnLmNvbXBfbmRlc2M6IDUxMgpkZXYudm14LjAucnhx MC5kZWJ1Zy5jb21wX2dlbjogMAo= --------------030705050708030202060003-- --------------enigA68C03B9D347177ACD70FBCB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlIct7EACgkQLDqVQ9VXb8gmZwCfb+hB8luHCI5PK3Q1LGJacJ9B I0MAoL4Bj214AxpZ45K/+6nV5qtGQDKH =QsK5 -----END PGP SIGNATURE----- --------------enigA68C03B9D347177ACD70FBCB-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 27 14:47:48 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7BE7BAE0; Tue, 27 Aug 2013 14:47:48 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from smtpauth3.wiscmail.wisc.edu (wmauth3.doit.wisc.edu [144.92.197.226]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4ECD02CB8; Tue, 27 Aug 2013 14:47:48 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MS7009002AA5B00@smtpauth3.wiscmail.wisc.edu>; Tue, 27 Aug 2013 09:47:41 -0500 (CDT) X-Spam-PmxInfo: Server=avs-3, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.7.22.10622, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from wanderer.tachypleus.net (172-12-164-50.lightspeed.wlfrct.sbcglobal.net [172.12.164.50]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MS700FXT2E6MX40@smtpauth3.wiscmail.wisc.edu>; Tue, 27 Aug 2013 09:46:57 -0500 (CDT) Message-id: <521CBBDE.6030503@freebsd.org> Date: Tue, 27 Aug 2013 07:46:54 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130811 Thunderbird/17.0.8 To: Gerald Pfeifer Subject: Re: patch to add AES intrinsics to gcc References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <521751AF.6040905@gmail.com> In-reply-to: X-Enigmail-Version: 1.5.1 Cc: toolchain@freebsd.org, Volodymyr Kostyrko , =?ISO-8859-1?Q?Bernhard_Fr=F6hlich?= , John-Mark Gurney , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 27 Aug 2013 14:47:48 -0000 On 08/25/13 18:41, Gerald Pfeifer wrote: > On Fri, 23 Aug 2013, Volodymyr Kostyrko wrote: >> I object. Many ports that compiles perfectly on gcc 4.2.1 can't be >> compiled with lang/gcc. I checked this once and the number of ports >> that require strictly gcc 4.2.1 was bigger for me then number of >> ports that can't be compiled with clang but fill fine on lang/gcc. >> >> I'll gonna recheck whether lang/gcc42 is sufficient for them. But I >> have that bad feeling... > If there are ports that use USE_GCC=any and do not build with > lang/gcc, these should have USE_GCC=4.2 -- without a '+'! -- > not USE_GCC=any. > > It'll be great if you can fix any such port. It would be particularly nice if we had a port with FreeBSD's many patches to 4.2. lang/gcc42 (and 46 and lang/gcc) do not build on powerpc64, for example, while our in-tree GCC does. -Nathan From owner-freebsd-current@FreeBSD.ORG Tue Aug 27 14:53:07 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 594A4DAB; Tue, 27 Aug 2013 14:53:07 +0000 (UTC) (envelope-from bryanv@daemoninthecloset.org) Received: from torment.daemoninthecloset.org (torment.daemoninthecloset.org [94.242.209.234]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 198E32D1C; Tue, 27 Aug 2013 14:53:06 +0000 (UTC) Received: from sage.daemoninthecloset.org (unknown [70.114.209.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sage.daemoninthecloset.org", Issuer "daemoninthecloset.org" (verified OK)) by torment.daemoninthecloset.org (Postfix) with ESMTPS id B474D42C2632; Tue, 27 Aug 2013 16:58:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at daemoninthecloset.org X-Virus-Scanned: amavisd-new at daemoninthecloset.org Date: Tue, 27 Aug 2013 09:52:52 -0500 (CDT) From: Bryan Venteicher To: Harald Schmalzbauer Message-ID: <1428315986.19291.1377615172231.JavaMail.root@daemoninthecloset.org> In-Reply-To: <521CB7AC.90605@omnilan.de> References: <601099152.721.1375661537866.JavaMail.root@daemoninthecloset.org> <5214D37F.5000307@omnilan.de> <1117188271.19176.1377577117350.JavaMail.root@daemoninthecloset.org> <521CB7AC.90605@omnilan.de> Subject: Re: [CFT] VMware vmxnet3 ethernet driver MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [192.168.10.20] X-Mailer: Zimbra 8.0.2_GA_5569 (ZimbraWebClient - GC20 ([unknown])/8.0.2_GA_5569) Thread-Topic: VMware vmxnet3 ethernet driver Thread-Index: m3nkTpbhAoxSRywSkYqJdsIgyubJ+g== Cc: FreeBSD Stable , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 27 Aug 2013 14:53:07 -0000 ----- Original Message ----- > Bez=C3=BCglich Bryan Venteicher's Nachricht vom 27.08.2013 06:18 (localti= me): >=20 > ... >=20 > >> It seems if_vmx doesn't support jumbo frames. If I set mtu 9000, I get > >> =C2=BBvmx0: cannot populate Rx queue 0=C2=AB, I have no problems using= jumbo > >> frames with vmxnet3. > >> > > This could fail for two reasons - could not allocate an mbuf cluster, > > or the call to bus_dmamap_load_mbuf_sg() failed. For the former, you > > should check vmstat -z. For the later, the behavior of > > bus_dmamap_load_mbuf_sg() > > changed between 9.1 and 9.2, and I know it was broken for awhile. I don= 't > > recall exactly when I fixed it (I think shortly after I made the origin= al > > announcement). Could you retry with the files from HEAD @ [1]? Also, th= ere > > are new sysctl oids (dev.vmx.X.mbuf_load_failed & dev.vmx.X.mgetcl_fail= ed) > > for these errors. > > > > I just compiled the driver on 9.2-RC2 with the sources from HEAD and wa= s > > able to change the MTU to 9000. > > > > [1]- http://svnweb.freebsd.org/base/head/sys/dev/vmware/vmxnet3/ >=20 > Thanks a lot for your ongoing work! > I can confirm that with recent if_vmx.c from head and compiled for > 9.2-RC3, setting mtu to 9000 works as expected :-) >=20 >=20 > >> I took a oldish host (4x2,8GHz Core2[LGA775]) with recent software: ES= Xi > >> 5.1U1 and FreeBSD-9.2-RC2 > >> Two guests are connected to one MTU9000 "VMware Software Switch". > >> > > I've got a few performance things to still look at. What's the sysctl > > dev.vmx.X output for the if_vmx<->if_vmx tests? >=20 > Just repeated if_vmx simple iperf bench, results vary slightly from > standard 10sec run to run, but still noticable high Intr usage: > The intr usage is higher than the other drivers you compared against because if_vmx does the off-level processing in ithreads where as the others do it in a taskqueue. BTW: if_vmx can to LRO as well. I don't think the emulated e1000 can, but I bet the e1000e does. > if_vmx <-> if_vmx > 1.32 GBits/sec, load: 10-45%Sys 40-48%Intr >=20 > if_vmxJumbo <-> if_vmxJumbo > 5.01 GBits/sec, load: 10-45%Sys 40-48%Intr >=20 > Please find attached the different outputs of dev.vmx.X (the mtu9000 run = was > only 3.47GBits/sec in that case, took the numbers anyway) >=20 > wbr, >=20 > -Harry >=20 >=20 From owner-freebsd-current@FreeBSD.ORG Tue Aug 27 16:02:08 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BB3FBB8F for ; Tue, 27 Aug 2013 16:02:08 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 855902174 for ; Tue, 27 Aug 2013 16:02:08 +0000 (UTC) Received: by mail-ob0-f172.google.com with SMTP id er7so4948414obc.31 for ; Tue, 27 Aug 2013 09:02:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=RjLgAgFGzxRpBfDMfySdDBs3dsAfrObbKk0KTeQbkVg=; b=m9hp5r/w+KCKi0f5om8L9/WJQeoaTd+2FgkMEFWonaK0iFyJcglRC2Yarrb8Yy0DZU mor/SrOVrOSTV6Ym/846fIJj8ig381fKXGGFL2/vTE6SSQe+MosgO+dJEWlUrXhaYDaR Sm6x6X2vqHg5HEUA5j8qP/X9CqDJOwQ0yMzUg+liSNdmnQolTGKelquLPCwfLstmp578 TXKxrasdsauQUZqHAD6hBvuOLcY3QObc8w5DSQ3AU7cpbowEu7wWjUayQfsqkxeIoIlB rNau7CIaNXY0YgveCXoK7+wkEb2CA15PL3qr92BVkBdlUcdEJVVDQezSn4I2ADyiegLd PmOA== X-Gm-Message-State: ALoCoQkC94Clu8LrVOKUS7X7TNbv+8ApH3ndvRuFPVftbpzH+99x02awtKzEN8IgXncISi5M0a7p X-Received: by 10.50.77.72 with SMTP id q8mr10720558igw.14.1377619322181; Tue, 27 Aug 2013 09:02:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.158.74 with HTTP; Tue, 27 Aug 2013 09:01:30 -0700 (PDT) From: "Lundberg, Johannes" Date: Tue, 27 Aug 2013 17:01:30 +0100 Message-ID: Subject: Patch for 2013 MacBook Air PCIe SSD controller To: FreeBSD Current Content-Type: multipart/mixed; boundary=047d7bdc0b1655bc7d04e4effea5 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 27 Aug 2013 16:02:08 -0000 --047d7bdc0b1655bc7d04e4effea5 Content-Type: text/plain; charset=ISO-8859-1 This patch to sys/dev/ahci/ahci.c should make the SSD drive in the 2013's MacBook Airs detectable. Index: ahci.c =================================================================== --- ahci.c (revision 254924) +++ ahci.c (working copy) @@ -229,6 +229,7 @@ {0x91301b4b, 0x00, "Marvell 88SE9130", AHCI_Q_NOBSYRES|AHCI_Q_ALTSIG}, {0x91721b4b, 0x00, "Marvell 88SE9172", AHCI_Q_NOBSYRES}, {0x91821b4b, 0x00, "Marvell 88SE9182", AHCI_Q_NOBSYRES}, + {0x91831b4b, 0x00, "Marvell 88SS9183", AHCI_Q_NOBSYRES}, {0x91a01b4b, 0x00, "Marvell 88SE91Ax", AHCI_Q_NOBSYRES}, {0x92151b4b, 0x00, "Marvell 88SE9215", AHCI_Q_NOBSYRES}, {0x92201b4b, 0x00, "Marvell 88SE9220", AHCI_Q_NOBSYRES|AHCI_Q_ALTSIG}, Best regards Johannes Lundberg BRILLIANTSERVICE CO., LTD. --047d7bdc0b1655bc7d04e4effea5 Content-Type: text/plain; charset=US-ASCII; name="ahci_patch.txt" Content-Disposition: attachment; filename="ahci_patch.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hkvawgg60 SW5kZXg6IGFoY2kuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBhaGNpLmMJKHJldmlzaW9uIDI1NDkyNCkKKysr IGFoY2kuYwkod29ya2luZyBjb3B5KQpAQCAtMjI5LDYgKzIyOSw3IEBACiAJezB4OTEzMDFiNGIs IDB4MDAsICJNYXJ2ZWxsIDg4U0U5MTMwIiwgIEFIQ0lfUV9OT0JTWVJFU3xBSENJX1FfQUxUU0lH fSwKIAl7MHg5MTcyMWI0YiwgMHgwMCwgIk1hcnZlbGwgODhTRTkxNzIiLAlBSENJX1FfTk9CU1lS RVN9LAogCXsweDkxODIxYjRiLCAweDAwLCAiTWFydmVsbCA4OFNFOTE4MiIsCUFIQ0lfUV9OT0JT WVJFU30sCisJezB4OTE4MzFiNGIsIDB4MDAsICJNYXJ2ZWxsIDg4U1M5MTgzIiwJQUhDSV9RX05P QlNZUkVTfSwKIAl7MHg5MWEwMWI0YiwgMHgwMCwgIk1hcnZlbGwgODhTRTkxQXgiLAlBSENJX1Ff Tk9CU1lSRVN9LAogCXsweDkyMTUxYjRiLCAweDAwLCAiTWFydmVsbCA4OFNFOTIxNSIsICBBSENJ X1FfTk9CU1lSRVN9LAogCXsweDkyMjAxYjRiLCAweDAwLCAiTWFydmVsbCA4OFNFOTIyMCIsICBB SENJX1FfTk9CU1lSRVN8QUhDSV9RX0FMVFNJR30sCgo= --047d7bdc0b1655bc7d04e4effea5-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 27 17:28:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E6AC8CC4 for ; Tue, 27 Aug 2013 17:28:13 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AD75F268C for ; Tue, 27 Aug 2013 17:28:13 +0000 (UTC) Received: by mail-ob0-f181.google.com with SMTP id dn14so5104283obc.40 for ; Tue, 27 Aug 2013 10:28:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=f4wbQQQYZXtvE3rtRbf2U3tc6ASKbUFBP7S8mb7DBng=; b=mVQexIxY6dyDInNY5RaoNPX416fQWfPMZmQ0HzY8nfBKcagMYVHLLM5KZeNvifxO2Z kD6W//nuoL+96B0qS6XpsS5XCSfCP2m9r0HIEEqtd3R2f7voOb7gAxGsY1GQckKK0SKq 8Hxe9jawEE9jQjsEj/OdvXlUqoo9+0whiTAePoOkju4P8okzXCuiDnY43cYcDO7O/2XS VPoVCaLg9A4TOKHNZTE3bMfwV+ZmrojKLhJjAqwrZ1Z8fDRJQVAVMBbb0QyCKu3mvLKl j/T6BDpR5sNnzVL0xYVswC62PiZTnGThv5agOiKiiDDXyC2ODhuuDUGwFe/8drT24umL Cy/g== X-Gm-Message-State: ALoCoQk/lzSgdZ5mRrkE2URqHcW5vGotcslVWnM9lrNzItfdOeORNt7IQrU4vld4cOthDAKGW1VL X-Received: by 10.50.20.232 with SMTP id q8mr10842047ige.0.1377624109916; Tue, 27 Aug 2013 10:21:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.158.74 with HTTP; Tue, 27 Aug 2013 10:21:34 -0700 (PDT) In-Reply-To: References: <521B9CD7.8010902@bitfrost.no> <521C6C26.7050207@bitfrost.no> From: "Lundberg, Johannes" Date: Tue, 27 Aug 2013 18:21:34 +0100 Message-ID: Subject: Re: xhci broken on 10-CURRENT and 2013 MacBook Air? To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Hans Petter Selasky , FreeBSD Current , "freebsd-usb@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 27 Aug 2013 17:28:14 -0000 The SSD controller driver is hopefully fixed now with the patch I submitted to -current mailing list. I will compile a new system with usb as a loadable module so that it is easier to test different versions and possible fixes and then do some testing maybe tomorrow. Johannes Lundberg BRILLIANTSERVICE CO., LTD. On Tue, Aug 27, 2013 at 10:14 AM, Adrian Chadd wrote: > Hm! > > Is there a Linux driver for this SSD? Does Linux approximately boot on > this thing? > > > > -adrian > From owner-freebsd-current@FreeBSD.ORG Tue Aug 27 18:32:54 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D67F13A0 for ; Tue, 27 Aug 2013 18:32:54 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward8l.mail.yandex.net (forward8l.mail.yandex.net [IPv6:2a02:6b8:0:1819::8]) by mx1.freebsd.org (Postfix) with ESMTP id 9C7502A4E for ; Tue, 27 Aug 2013 18:32:54 +0000 (UTC) Received: from smtp3h.mail.yandex.net (smtp3h.mail.yandex.net [84.201.186.20]) by forward8l.mail.yandex.net (Yandex) with ESMTP id E16501A41C19 for ; Tue, 27 Aug 2013 22:32:51 +0400 (MSK) Received: from smtp3h.mail.yandex.net (localhost [127.0.0.1]) by smtp3h.mail.yandex.net (Yandex) with ESMTP id A1B7D1B4020B for ; Tue, 27 Aug 2013 22:32:51 +0400 (MSK) Received: from 93.91.10.81.tel.ru (93.91.10.81.tel.ru [93.91.10.81]) by smtp3h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id 4wKpaOozao-WpnWO06m; Tue, 27 Aug 2013 22:32:51 +0400 Message-ID: <521CF0D3.8040503@passap.ru> Date: Tue, 27 Aug 2013 22:32:51 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130806 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Subject: [installworld via r/o NFS] cannot create mapper.dir: Permission denied Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 27 Aug 2013 18:32:54 -0000 Hi All, While installing fresh CURRENT (make -C installworld) via NFS (exported -ro)...: ----- 192.168.119.49:/usr/src on /usr/src (nfs) 192.168.119.49:/usr/obj on /usr/obj (nfs) ----- ... I get the following error: ----- ===> share/examples/pf (install) install -o root -g wheel -m 444 faq-example1 faq-example2 faq-example3 ackpri queue1 queue2 queue3 queue4 pf.conf spamd /usr/share/examples/pf ===> share/i18n (install) ===> share/i18n/csmapper (install) > mapper.dir cannot create mapper.dir: Permission denied *** Error code 2 ----- -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Tue Aug 27 19:06:42 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 08DD1DC2 for ; Tue, 27 Aug 2013 19:06:42 +0000 (UTC) (envelope-from joel@freebsd.org) Received: from mail.vnode.se (mail.vnode.se [212.247.52.13]) by mx1.freebsd.org (Postfix) with ESMTP id BE4762C20 for ; Tue, 27 Aug 2013 19:06:41 +0000 (UTC) Received: from mail.vnode.se (localhost [127.0.0.1]) by mail.vnode.se (Postfix) with ESMTP id 969D0E3F07A; Tue, 27 Aug 2013 21:06:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at vnode.se Received: from mail.vnode.se ([127.0.0.1]) by mail.vnode.se (mail.vnode.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AgAOrc88bmo; Tue, 27 Aug 2013 21:06:31 +0200 (CEST) Received: from devbox.vnode.local (unknown [83.223.1.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.vnode.se (Postfix) with ESMTPSA id 2F80FE3F079; Tue, 27 Aug 2013 21:06:30 +0200 (CEST) Date: Tue, 27 Aug 2013 21:06:30 +0200 From: Joel Dahl To: Boris Samorodov Subject: Re: [installworld via r/o NFS] cannot create mapper.dir: Permission denied Message-ID: <20130827190629.GA72550@devbox.vnode.local> References: <521CF0D3.8040503@passap.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <521CF0D3.8040503@passap.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 27 Aug 2013 19:06:42 -0000 On Tue, Aug 27, 2013 at 10:32:51PM +0400, Boris Samorodov wrote: > Hi All, > > > While installing fresh CURRENT (make -C installworld) > via NFS (exported -ro)...: > ----- > 192.168.119.49:/usr/src on /usr/src (nfs) > 192.168.119.49:/usr/obj on /usr/obj (nfs) > ----- > > ... I get the following error: > ----- > ===> share/examples/pf (install) > install -o root -g wheel -m 444 faq-example1 faq-example2 faq-example3 > ackpri queue1 queue2 queue3 queue4 pf.conf spamd /usr/share/examples/pf > ===> share/i18n (install) > ===> share/i18n/csmapper (install) > > mapper.dir > cannot create mapper.dir: Permission denied > *** Error code 2 > ----- I've reported this several times. r254273 broke it. -- Joel From owner-freebsd-current@FreeBSD.ORG Tue Aug 27 19:48:05 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6AEC26B9 for ; Tue, 27 Aug 2013 19:48:05 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward8l.mail.yandex.net (forward8l.mail.yandex.net [IPv6:2a02:6b8:0:1819::8]) by mx1.freebsd.org (Postfix) with ESMTP id 2CE2F2E07 for ; Tue, 27 Aug 2013 19:48:05 +0000 (UTC) Received: from smtp12.mail.yandex.net (smtp12.mail.yandex.net [95.108.131.191]) by forward8l.mail.yandex.net (Yandex) with ESMTP id 15A9B1A40E93 for ; Tue, 27 Aug 2013 23:48:02 +0400 (MSK) Received: from smtp12.mail.yandex.net (localhost [127.0.0.1]) by smtp12.mail.yandex.net (Yandex) with ESMTP id C31C616A0503 for ; Tue, 27 Aug 2013 23:48:01 +0400 (MSK) Received: from 93.91.10.81.tel.ru (93.91.10.81.tel.ru [93.91.10.81]) by smtp12.mail.yandex.net (nwsmtp/Yandex) with ESMTP id n6tvpUIL7l-m1T8sbCT; Tue, 27 Aug 2013 23:48:01 +0400 Message-ID: <521D0271.6010905@passap.ru> Date: Tue, 27 Aug 2013 23:48:01 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130806 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Subject: [make installworld installkernel] does not honor break at installworld Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 27 Aug 2013 19:48:05 -0000 Hi All, while installing FreeBSD at a new disk the installworld phase breaks (see the thread "...cannot create mapper.dir: Permission denied"). However the command "make installworld installkernel" proceeds to installkernel phase. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Tue Aug 27 20:42:33 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D6ACC28E; Tue, 27 Aug 2013 20:42:33 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from ainaz.pair.com (ainaz.pair.com [209.68.2.66]) by mx1.freebsd.org (Postfix) with ESMTP id AD8DB2114; Tue, 27 Aug 2013 20:42:33 +0000 (UTC) Received: from trevally.dhcp.nue.suse.com (nat.nue.novell.com [195.135.221.2]) by ainaz.pair.com (Postfix) with ESMTPSA id EDFEF3F419; Tue, 27 Aug 2013 16:42:23 -0400 (EDT) Date: Tue, 27 Aug 2013 22:42:22 +0200 (CEST) From: Gerald Pfeifer To: Claude Buisson Subject: Re: patch to add AES intrinsics to gcc In-Reply-To: <521B54CF.3020905@orange.fr> Message-ID: References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> <5217DBAB.5030607@freebsd.org> <86032E72-A569-4946-B4F8-26F687067B31@bsdimp.com> <1380949A-254A-4222-BEDE-0C23E16E4F67@freebsd.org> <8C31A000-6806-4291-98A4-E8291E637BD2@bsdimp.com> <521B54CF.3020905@orange.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Tue, 27 Aug 2013 21:49:26 +0000 Cc: re@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 27 Aug 2013 20:42:33 -0000 On Mon, 26 Aug 2013, Claude Buisson wrote: > Perhaps you could have a look at the fact that lang/gcc is at 4.6.3, > and lang/gcc46 is no more a snapshot but a true release 4.6.4. I am aware of that. Owed to a strongly voiced desire by users, I am triggering a rebuild of lang/gcc as rarely as possible. So, instead of going from 4.6.4 and soon 4.7.x, I submitted an update to 4.7.3 to portmgr for an -exp run last weekend. > IMHO, lang/gcc must be discontinued, or updated to 4.6.4 and > lang/gcc46 discontinued ? Neither. :-) Of all lang/gcc* ports, lang/gcc is the one to use (and hence keep). And lang/gcc46, lang/gcc47,... will remain in place for a while for use by those interested in an older version (or broken ports requiring one) or those interested in tracker newer versions. Gerald From owner-freebsd-current@FreeBSD.ORG Tue Aug 27 22:58:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DE616D89 for ; Tue, 27 Aug 2013 22:58:35 +0000 (UTC) (envelope-from sean_bruno@yahoo.com) Received: from nm42-vm8.bullet.mail.bf1.yahoo.com (nm42-vm8.bullet.mail.bf1.yahoo.com [216.109.114.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 52BDC2967 for ; Tue, 27 Aug 2013 22:58:35 +0000 (UTC) Received: from [98.139.212.146] by nm42.bullet.mail.bf1.yahoo.com with NNFMP; 27 Aug 2013 22:58:34 -0000 Received: from [68.142.230.78] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 27 Aug 2013 22:58:34 -0000 Received: from [127.0.0.1] by smtp235.mail.bf1.yahoo.com with NNFMP; 27 Aug 2013 22:58:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1377644314; bh=8+Xg/PdlCK8keSiokwdhi521Yb76q4+YkJh8PAR5Rdc=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:Cc:Content-Type:Date:Message-ID:Mime-Version:X-Mailer; b=AkGGqn+5cQCawUtOuEu2kKD1Z80rrsdGJF/AgB3FdVpXCLsIyCGO+WfoKJPv0dTtjoSyzdbs0qEjnNeEAHzfVVJ3BQE66VHpnxdHsEXazerfqWBFiQxyKPnMcQWG4xOHn2vsSoJRGIdsy6r7Rb/gZvRby2OIvAsVfO2oaPG8OlI= X-Yahoo-Newman-Id: 180369.42802.bm@smtp235.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: o2r8n2UVM1l42i.wGqrjSEKHBCmfWvMjjtorC8xOHG_4KKM r9ie71lGnClJ6UCFrVytnfyvogUukSTzKMBFY4JIdHKBCNUNPncgErsxAvrt CrKLxmszKSVTaLshjyCxUcDU_hHPhQu2VAvqL._GTXyZvYdjY0nT9PPyly1O 48uRSR0vCTvrYg_WfX_RiRsgli2LD1vxjOHhNAMnconXrbdufRnqBvLdcQvS pje8cdO1d8CLN_E7DCRVJfppt_FmYozl9O_pEtB2LpAEpzQHzRxnlSSH6sDn Be3M04XGVnvcu8AUjgW13ETlZx0sMBob80FiM7YauzDctqmwu6EgtjungDQN McFC8y5doEzfVojtPBj0wNVXlKn0_W132zTIAOSN13u2bi0NhQecRuCmajWZ diSzIk3bSK0h0t08Gqhql3TYBHnK7pT7wqNJErtUEJhA.vBuE1DUXIhUT0Ro usNKjcOqW94FXxOFr1Tb9pEVup.i0bkGkI1Go3zk15BSAm1NrnpxnE4V0Cvj r6i4KgNWKOgadCXtR1VhtC.qWw7uXqKrSEcFIzSWYjJdXY5MCZzSTd048ZyF rXb9jvILUw4qyvsgUhsA22cGWoI0ANLXvgTnGyyaQTyo0VMKjgyNrEf12NPA YA2BIVm5NWkmkfFAgdlw3292D.Q0nHdK8fg-- X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4- X-Rocket-Received: from [10.73.160.242] (sean_bruno@209.131.62.116 with ) by smtp235.mail.bf1.yahoo.com with SMTP; 27 Aug 2013 22:58:34 +0000 UTC Subject: bsd patch regression? From: Sean Bruno To: freebsd-current@FreeBSD.org Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-WCz5xeUhJyMZDc486V24" Date: Tue, 27 Aug 2013 15:58:32 -0700 Message-ID: <1377644312.6359.27.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: Pedro Giffuni X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 22:58:35 -0000 --=-WCz5xeUhJyMZDc486V24 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Colin generated a patch for xen things that does some pretty typical behavior. bsdpatch really didn't handle it well and rejected some things and flat out refused to create sys/modules/xenhvm/Makefile for me. http://lists.freebsd.org/pipermail/freebsd-xen/2013-August/001697.html When applying this patch with gnupatch I get: http://people.freebsd.org/~sbruno/gnupatch.txt When applying this patch with bsdpatch I get: http://people.freebsd.org/~sbruno/bsdpatch.txt Any ideas here? --=-WCz5xeUhJyMZDc486V24 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (FreeBSD) iQEcBAABAgAGBQJSHS8YAAoJEBkJRdwI6BaHil0H/3P/MKm1FNejsu70D1SbvlPQ budZ9MwreeiChCerErb7y87q143TL8jA9VvcMBqRvXlZUnxjoKl42mF/ycS1uKa0 lUW6WTTJjCLuXKVsukUfNQBzrqYHLaFY5ArLi1Dn666i9zURSgROezpFwy842Ijv 3pjVBBI8REN4yLpbo+DMlKHHcF+cRQloeNi7JvWXMt7vhAlfnXRmDDiA316H+QDi +RXdW0MpACIRcS70Xp2WXBda6iJJpGqwgyODAVRxK2QTjw5WkXOjp7b0TuZJF9Nb zlqQN+IavBGZcfAFeIBhzTq5PwWOamj23crji9pAr2sLsts1gz5M0MWJGrTZBl8= =C78a -----END PGP SIGNATURE----- --=-WCz5xeUhJyMZDc486V24-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 27 23:01:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B3B3CF04; Tue, 27 Aug 2013 23:01:55 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6F69B29B0; Tue, 27 Aug 2013 23:01:55 +0000 (UTC) Received: by mail-oa0-f47.google.com with SMTP id g12so6655685oah.20 for ; Tue, 27 Aug 2013 16:01:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RfgC2KV0LKMGCVG6JqSomKnmu2YcHd1ug1xbQphfBjY=; b=xJ0oGELqGdexP4uTM3emTdeYm+EXwJyyj4/95xnkQxfitwBarRMCsLgWzVAl2JROJf aqq/O9XlLJg6aa6s1VD1byk/TQuE5diMpaOLcWjogvY7VushArV000eW4G2MvSA6x+5Q srL2syEeoNCn8xp15lQOYLxEaWbP0+Zc9BYO1kXf//IpkQJ1z9Hg7XzlTnAtJze1CBOa E+vjfaPQaPvnYTFdp40WLCEpxCFeAbHgsAxGWxE5DnyT2gYp8qUecVju2Vd4XZKCiK0G 7xSrWsmu4CSX9JCjMS9r/uekCsdiMGTu5WvYsZSwdzec+UQgKMfeu0l3e/Pax9smHGHw kilw== MIME-Version: 1.0 X-Received: by 10.182.71.37 with SMTP id r5mr4140311obu.22.1377644514789; Tue, 27 Aug 2013 16:01:54 -0700 (PDT) Received: by 10.76.2.110 with HTTP; Tue, 27 Aug 2013 16:01:54 -0700 (PDT) In-Reply-To: <20130825141942.GB19969@lonrach.local> References: <20130822202027.GH94127@funkthat.com> <20130823151615.GD41379@roberto02-aw.erc.corp.eurocontrol.int> <20130823180413.GL94127@funkthat.com> <20130823182752.GA15392@lonrach.local> <20130825141942.GB19969@lonrach.local> Date: Tue, 27 Aug 2013 19:01:54 -0400 Message-ID: Subject: Re: patch to improve AES-NI performance From: Outback Dingo To: Ollivier Robert Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 27 Aug 2013 23:01:55 -0000 On Sun, Aug 25, 2013 at 10:19 AM, Ollivier Robert wrote: > According to Ollivier Robert: > > You are right, I wanted to say r226837 which is the "code" one. > > FYI I've finally merged r226837,r226839 as r254856 in stable/9 as it is a > prerequesite to apply jmg's patch. I've asked re@ whether they would > consider this for 9.2. It is very late in the 9.2 release circle but that > patch has been in 10 for more than a year now... > > So this patch can now be applied to STABLE/9 for testing on a local system since these 3 revisions are now in?? > -- > Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- > roberto@keltia.freenix.fr > In memoriam to Ondine : http://ondine.keltia.net/ > _______________________________________________ > 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 Aug 28 00:02:29 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3FCBDF38; Wed, 28 Aug 2013 00:02:29 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E8A422CF8; Wed, 28 Aug 2013 00:02:28 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r7S02Kcf003662; Tue, 27 Aug 2013 20:02:25 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <521D3E0C.4060507@m5p.com> Date: Tue, 27 Aug 2013 20:02:20 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130716 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hans Petter Selasky Subject: Re: ulpt can't attach Lexmark E120 References: <5105527F.3010708@m5p.com> <201301271915.47712.hselasky@c2i.net> <510570C1.1060607@m5p.com> <201301272007.30682.hselasky@c2i.net> <5105AB16.2000607@m5p.com> <5215F4DF.6000305@m5p.com> <5215F743.8060403@bitfrost.no> <5216ACE5.7000500@m5p.com> <5216FE9F.2030608@bitfrost.no> <52174378.2020101@m5p.com> <521801E5.9000309@m5p.com> <52184F59.5080100@bitfrost.no> <5218F993.9050504@m5p.com> <5219C3FF.1070509@bitfrost.no> In-Reply-To: <5219C3FF.1070509@bitfrost.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Tue, 27 Aug 2013 20:02:25 -0400 (EDT) Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 28 Aug 2013 00:02:29 -0000 On 08/25/13 04:44, Hans Petter Selasky wrote: > On 08/24/13 20:21, George Mitchell wrote: >> >> Setting hw.usb.dwc_otg.debug to any value greater than 0 generates an >> unending stream of debug output and effectively locks up the chip >> scrolling the output on the display. Perhaps there are some specific >> debug messages I could put in ... -- George > > Hi, > > Can you try this patch: > > http://svnweb.freebsd.org/changeset/base/254828 > > --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" Sorry, no more progress yet. My RPi build system is generating emptyimages for some reason, so I will start over with it. -- George From owner-freebsd-current@FreeBSD.ORG Wed Aug 28 00:36:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 173D079E for ; Wed, 28 Aug 2013 00:36:37 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm8-vm0.bullet.mail.bf1.yahoo.com (nm8-vm0.bullet.mail.bf1.yahoo.com [98.139.213.95]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 950B62E64 for ; Wed, 28 Aug 2013 00:36:36 +0000 (UTC) Received: from [98.139.212.153] by nm8.bullet.mail.bf1.yahoo.com with NNFMP; 28 Aug 2013 00:36:29 -0000 Received: from [98.139.211.199] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 28 Aug 2013 00:36:28 -0000 Received: from [127.0.0.1] by smtp208.mail.bf1.yahoo.com with NNFMP; 28 Aug 2013 00:36:28 -0000 X-Yahoo-Newman-Id: 956976.9222.bm@smtp208.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: NawODkYVM1nKLknsQclgc2VJXD.KEoKM_yRgDNn20jnAerd TViDRHEm0SM8k1UbCKVLr4czu5WGwZUMthMq4Jpmnetoy_lCX7lZ2eBjHcpq dp4eugxw_bHI7grfuK49GVI0lUbYT9PjadvbLuVimQUpp42g5fdS1nLY088p 7P79xjktXIwR4X3eAsBnGqwOvVjhj2U2B6v9nUIExxFvMPlDk._GvsFKDqr1 Y6jShEAt_xtv9aCaxYW7p27iL1f63cDE_HMkbjxrEUL_3mNa4ghJKFAUxk1R KUyvS3FEdFUjdd2F5OnC1muXy_gejydsXyFyMuU7hvxUp49S5No12Rsgx5p2 SY1PpbqJGvbXEVC803Ru1RHMlcW5CejawH1v3LDGc44NDbEV7KHX_F8plwgb Ohy98YXaLWRg3DTaPogZNoiIc2DiBbZ8n6eBOXooQlp_6ozaK2QwZmoRbkD1 7ZBtpSMzY5oqOukReafCEzj8Bnnw99m4rvmmf6xcSxRLNElNVJHSrN6y.k7q 3Pny0Xg1TeaORnbnp8dmdN1ow4MsrRwZmea44I6mrM6V4ChxOxdg34FEpF2b QmshYl4b1MwCQVtCQpXxDvFbkFq4tjDKPGOf_mIXk3Ly3vby1eWvIuGHphMc i_6iZ9P87w5z8HQv3usRr1qkKUA-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf X-Rocket-Received: from [192.168.0.102] (pfg@190.157.126.109 with ) by smtp208.mail.bf1.yahoo.com with SMTP; 27 Aug 2013 17:36:28 -0700 PDT Message-ID: <521D460B.3040705@FreeBSD.org> Date: Tue, 27 Aug 2013 19:36:27 -0500 From: Pedro Giffuni Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: sbruno@freebsd.org Subject: Re: bsd patch regression? References: <1377644312.6359.27.camel@localhost> In-Reply-To: <1377644312.6359.27.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 28 Aug 2013 00:36:37 -0000 Hi Sean; El 27/08/2013 5:58 p. m., Sean Bruno escribió: > Colin generated a patch for xen things that does some pretty typical > behavior. bsdpatch really didn't handle it well and rejected some > things and flat out refused to create sys/modules/xenhvm/Makefile for > me. > > http://lists.freebsd.org/pipermail/freebsd-xen/2013-August/001697.html > > When applying this patch with gnupatch I get: > http://people.freebsd.org/~sbruno/gnupatch.txt > > > When applying this patch with bsdpatch I get: > http://people.freebsd.org/~sbruno/bsdpatch.txt > I note that you are using GNU patch from the ports tree. It would appear that both utilities reject the patches for: sys/amd64/conf/XENHVM sys/i386/conf/XENHVM bsdpatch is uglily more verbose and handles the rejected patches much less gracefully but it seems like gpatch also has issues with the same patches. I am not sure we can call this a regression: please note that bsd patch is meant to replace the ancient GNU patch that we had in the tree (it's still there under the name "gnupatch"). We ran an exp-run on ports and there was only a small regression related to the patch level which is a little stricter in BSD patch. > > Any ideas here? > Not very helpful but I suggest using "svn patch" when possible. :( Pedro. From owner-freebsd-current@FreeBSD.ORG Wed Aug 28 01:26:33 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DDAC8F1D; Wed, 28 Aug 2013 01:26:33 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9AD0A20A6; Wed, 28 Aug 2013 01:26:33 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r7S1QWu8001162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Aug 2013 18:26:32 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r7S1QWCn001161; Tue, 27 Aug 2013 18:26:32 -0700 (PDT) (envelope-from jmg) Date: Tue, 27 Aug 2013 18:26:32 -0700 From: John-Mark Gurney To: Outback Dingo Subject: Re: patch to improve AES-NI performance Message-ID: <20130828012632.GQ29777@funkthat.com> Mail-Followup-To: Outback Dingo , Ollivier Robert , freebsd-current@freebsd.org, freebsd-stable@freebsd.org References: <20130822202027.GH94127@funkthat.com> <20130823151615.GD41379@roberto02-aw.erc.corp.eurocontrol.int> <20130823180413.GL94127@funkthat.com> <20130823182752.GA15392@lonrach.local> <20130825141942.GB19969@lonrach.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 27 Aug 2013 18:26:32 -0700 (PDT) Cc: Ollivier Robert , freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 28 Aug 2013 01:26:33 -0000 Outback Dingo wrote this message on Tue, Aug 27, 2013 at 19:01 -0400: > On Sun, Aug 25, 2013 at 10:19 AM, Ollivier Robert > wrote: > > > According to Ollivier Robert: > > > You are right, I wanted to say r226837 which is the "code" one. > > > > FYI I've finally merged r226837,r226839 as r254856 in stable/9 as it is a > > prerequesite to apply jmg's patch. I've asked re@ whether they would > > consider this for 9.2. It is very late in the 9.2 release circle but that > > patch has been in 10 for more than a year now... > > > > > So this patch can now be applied to STABLE/9 for testing on a local system > since these 3 revisions are now in?? I've compile tested the patch, but not run tested it: https://people.freebsd.org/~jmg/aesni.9stable.patch Note that 9stable uses gcc by default and this patch required clang, so make sure you set WITH_CLANG=YES WITH_CLANG_IS_CC=YES, otherwise it won't compile... This patch only required minor changes from my original patch to apply.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Wed Aug 28 05:51:16 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C87FE704; Wed, 28 Aug 2013 05:51:16 +0000 (UTC) (envelope-from mailinglists@martinlaabs.de) Received: from relay01.alfahosting-server.de (relay01.alfahosting-server.de [109.237.142.236]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 868582C23; Wed, 28 Aug 2013 05:51:16 +0000 (UTC) Received: by relay01.alfahosting-server.de (Postfix, from userid 1001) id C24E532C1297; Wed, 28 Aug 2013 07:51:14 +0200 (CEST) X-Spam-DCC: : X-Spam-Level: X-Spam-Status: No, score=0.0 required=7.0 tests=BAYES_50 autolearn=disabled version=3.2.5 Received: from alfa3018.alfahosting-server.de (alfa3018.alfahosting-server.de [109.237.140.30]) by relay01.alfahosting-server.de (Postfix) with ESMTPS id 0F26732C17BE; Wed, 28 Aug 2013 07:51:12 +0200 (CEST) Received: from laabs.hf.ifn.et.tu-dresden.de (hfsync.ifn.et.tu-dresden.de [141.30.128.60]) by alfa3018.alfahosting-server.de (Postfix) with ESMTPSA id EB261515DE80; Wed, 28 Aug 2013 07:51:11 +0200 (CEST) Message-ID: <521D8FCF.3060204@martinlaabs.de> Date: Wed, 28 Aug 2013 07:51:11 +0200 From: Martin Laabs User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130809 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-arm Subject: Raspberry PI Kernel data abort Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Status: No X-Virus-Checker-Version: clamassassin 1.2.4 with ClamAV 0.97.3/17758/Wed Aug 28 04:36:35 2013 Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 28 Aug 2013 05:51:16 -0000 Hi, Sporadically the raspberry pi fails to mount its root mmc card. After power off and power on again works most of the time. However there seem to be also configurations that fail permanently. Unfortunately I have no image of a sd card that fails on every boot. Do you have any idea how to get more information whats going wrong? For details and the full boot log have a look to: http://www.freebsd.org/cgi/query-pr.cgi?pr=181601 Best regards, Martin Laabs From owner-freebsd-current@FreeBSD.ORG Wed Aug 28 05:57:53 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0A5FFAA5; Wed, 28 Aug 2013 05:57:53 +0000 (UTC) (envelope-from mailinglists@martinlaabs.de) Received: from relay01.alfahosting-server.de (relay01.alfahosting-server.de [109.237.142.236]) by mx1.freebsd.org (Postfix) with ESMTP id 872532C5D; Wed, 28 Aug 2013 05:57:52 +0000 (UTC) Received: by relay01.alfahosting-server.de (Postfix, from userid 1001) id 796A932C146B; Wed, 28 Aug 2013 07:57:50 +0200 (CEST) X-Spam-DCC: : X-Spam-Level: X-Spam-Status: No, score=0.0 required=7.0 tests=BAYES_50 autolearn=disabled version=3.2.5 Received: from alfa3018.alfahosting-server.de (alfa3018.alfahosting-server.de [109.237.140.30]) by relay01.alfahosting-server.de (Postfix) with ESMTPS id 870B832C1401; Wed, 28 Aug 2013 07:57:48 +0200 (CEST) Received: from laabs.hf.ifn.et.tu-dresden.de (hfsync.ifn.et.tu-dresden.de [141.30.128.60]) by alfa3018.alfahosting-server.de (Postfix) with ESMTPSA id 75308515C0B1; Wed, 28 Aug 2013 07:57:48 +0200 (CEST) Message-ID: <521D915C.8040209@martinlaabs.de> Date: Wed, 28 Aug 2013 07:57:48 +0200 From: Martin Laabs User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130809 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-arm Subject: Re: Raspberry PI Kernel data abort References: <521D8FCF.3060204@martinlaabs.de> In-Reply-To: <521D8FCF.3060204@martinlaabs.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Status: No X-Virus-Checker-Version: clamassassin 1.2.4 with ClamAV 0.97.3/17758/Wed Aug 28 04:36:35 2013 Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 28 Aug 2013 05:57:53 -0000 Sorry for the wrong subject. The problem with the data abort is another one that happens after DHCP address reception. The kernel is from my today nigh build from head (FreeBSD 10.0-CURRENT r254955). This problem might be related to the recent mbuf changes. The PR link is http://www.freebsd.org/cgi/query-pr.cgi?pr=181602 This is the log from my console: Mounting local file systems:. Writing entropy file:. Setting hostname: raspberry-pi. smsc0: chip 0xec00, rev. 0002 ue0: link state changed to DOWN ue0: link state changed to UP Starting Network: lo0 ue0. lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.1 netmask 0xff000000 nd6 options=21 ue0: flags=8843 metric 0 mtu 1500 options=80001 ether b8:27:eb:1d:b7:5a media: Ethernet autoselect (100baseTX ) status: active nd6 options=29 Starting devd. Starting dhclient. DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 7 DHCPOFFER from 192.168.1.250 DHCPOFFER from 192.168.1.250 DHCPREQUEST on ue0 to 255.255.255.255 port 67 DHCPACK from 192.168.1.250 bound to 192.168.1.54 -- renewal in 300 seconds. lock order reversal: (sleepable after non-sleepable) 1st 0xc2857d78 so_rcv (so_rcv) @ /usr/home/martin/Rasperry/head/sys/kern/uipc_socket.c:1594 2nd 0xc2899a30 vm map (user) (vm map (user)) @ /usr/home/martin/Rasperry/head/sys/vm/vm_map.c:3816 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc04652cc lr = 0xc012e474 (db_trace_self_wrapper+0x30) sp = 0xdd3ee818 fp = 0xdd3ee930 r10 = 0xc2857d78 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc = 0xc012e474 lr = 0xc0268974 (kdb_backtrace+0x38) sp = 0xdd3ee938 fp = 0xdd3ee940 r4 = 0xc05908a4 r5 = 0xc04dce80 r6 = 0xc04bd04d r7 = 0xc04c14dc kdb_backtrace() at kdb_backtrace+0x38 pc = 0xc0268974 lr = 0xc0282df8 (witness_checkorder+0xddc) sp = 0xdd3ee948 fp = 0xdd3ee998 r4 = 0xc04bd221 witness_checkorder() at witness_checkorder+0xddc pc = 0xc0282df8 lr = 0xc023aaf0 (_sx_slock+0x84) sp = 0xdd3ee9a0 fp = 0xdd3ee9c8 r4 = 0x00000ee8 r5 = 0xc04dce7d r6 = 0xc2899a30 r7 = 0xc2899a40 r8 = 0x00000000 r9 = 0x00000000 r10 = 0xdd3eeb2c _sx_slock() at _sx_slock+0x84 pc = 0xc023aaf0 lr = 0xc044579c (vm_map_lookup+0x74) sp = 0xdd3ee9d0 fp = 0xdd3eea08 r4 = 0xc28999e0 r5 = 0xc04dce7d r6 = 0x3601a000 r7 = 0x3601a000 r8 = 0x00000002 vm_map_lookup() at vm_map_lookup+0x74 pc = 0xc044579c lr = 0xc0439a18 (vm_fault_hold+0xe4) sp = 0xdd3eea10 fp = 0xdd3eeb80 r4 = 0xc28999e0 r5 = 0x00000002 r6 = 0xc2819960 r7 = 0x3601a000 r8 = 0xdd3eeb10 r9 = 0x00000000 r10 = 0xc06f7af0 vm_fault_hold() at vm_fault_hold+0xe4 pc = 0xc0439a18 lr = 0xc04398ec (vm_fault+0x88) sp = 0xdd3eeb88 fp = 0xdd3eeba8 r4 = 0xc28999e0 r5 = 0x00000002 r6 = 0xc2819960 r7 = 0x3601a000 r8 = 0x00000000 r9 = 0x00000002 r10 = 0xc06f7af0 vm_fault() at vm_fault+0x88 pc = 0xc04398ec lr = 0xc04760fc (data_abort_handler+0x2a8) sp = 0xdd3eebb0 fp = 0xdd3eec50 r4 = 0xc2872640 r5 = 0xc2819960 r6 = 0xc04e30cc r7 = 0xc28726e8 r8 = 0xdd3eec58 r9 = 0xdd3eeeb0 r10 = 0xc28999e0 data_abort_handler() at data_abort_handler+0x2a8 pc = 0xc04760fc lr = 0xc0466b04 (exception_exit) sp = 0xdd3eec58 fp = 0xdd3eed10 r4 = 0xc056b1cc r5 = 0xc2857da4 r6 = 0xc2857d00 r7 = 0x3601a8c0 r8 = 0x00000000 r9 = 0xc2857d88 r10 = 0xc272fd00 exception_exit() at exception_exit pc = 0xc0466b04 lr = 0xc2819960 (0xc2819960) sp = 0xdd3eecac fp = 0xdd3eed10 r0 = 0x3601a8c0 r1 = 0xc272fb00 r2 = 0xc04c14d9 r3 = 0x000005ef r4 = 0xc056b1cc r5 = 0xc2857da4 r6 = 0xc2857d00 r7 = 0x3601a8c0 r8 = 0x00000000 r9 = 0xc2857d88 r10 = 0xc272fd00 r12 = 0x00000000 soreceive_generic() at soreceive_generic+0x4a8 pc = 0xc02a9aec lr = 0xc02ab784 (soreceive+0x2c) sp = 0xdd3eed18 fp = 0xdd3eed20 r4 = 0xc2819960 r5 = 0x00000000 r6 = 0xdd3eed98 r7 = 0x00000000 r8 = 0x00000006 r9 = 0xc27c5c40 r10 = 0x00000800 soreceive() at soreceive+0x2c pc = 0xc02ab784 lr = 0xc028da28 (soo_read+0x2c) sp = 0xdd3eed28 fp = 0xdd3eed30 soo_read() at soo_read+0x2c pc = 0xc028da28 lr = 0xc0286aa4 (dofileread+0xa8) sp = 0xdd3eed38 fp = 0xdd3eed58 dofileread() at dofileread+0xa8 pc = 0xc0286aa4 lr = 0xc0286764 (kern_readv+0x60) sp = 0xdd3eed60 fp = 0xdd3eed88 r4 = 0xffffffff r5 = 0x00000000 r6 = 0x00000000 r7 = 0x00000006 r8 = 0xdd3eed98 r9 = 0xc2819960 r10 = 0x2081f0f0 kern_readv() at kern_readv+0x60 pc = 0xc0286764 lr = 0xc02866f4 (sys_read+0x4c) sp = 0xdd3eed90 fp = 0xdd3eedb8 r4 = 0xc2819960 r5 = 0x00000000 r6 = 0xbfffe5a0 r7 = 0x00000000 r8 = 0xdd3eee10 r9 = 0xc2872640 sys_read() at sys_read+0x4c pc = 0xc02866f4 lr = 0xc0476bc4 (swi_handler+0x284) sp = 0xdd3eedc0 fp = 0xdd3eee58 swi_handler() at swi_handler+0x284 pc = 0xc0476bc4 lr = 0xc0466928 (swi_entry+0x2c) sp = 0xdd3eee60 fp = 0xbfffedc0 r4 = 0x000378f8 r5 = 0x0002d258 r6 = 0xbfffe5a0 r7 = 0x00000003 r8 = 0x00000000 r9 = 0x521d3af3 swi_entry() at swi_entry+0x2c pc = 0xc0466928 lr = 0xc0466928 (swi_entry+0x2c) sp = 0xdd3eee60 fp = 0xbfffedc0 Unable to unwind further vm_fault(0xc28999e0, 3601a000, 2, 0) -> 5 Fatal kernel mode data abort: 'Translation Fault (S)' trapframe: 0xdd3eec58 FSR=00000805, FAR=3601a8c4, spsr=20000013 r0 =3601a8c0, r1 =c272fb00, r2 =c04c14d9, r3 =000005ef r4 =c056b1cc, r5 =c2857da4, r6 =c2857d00, r7 =3601a8c0 r8 =00000000, r9 =c2857d88, r10=c272fd00, r11=dd3eed10 r12=00000000, ssp=dd3eeca8, slr=c2819960, pc =c02a9aec [ thread pid 542 tid 100059 ] Stopped at soreceive_generic+0x4a8: str r1, [r0, #0x004] db> Best regards, Martin Laabs From owner-freebsd-current@FreeBSD.ORG Wed Aug 28 06:16:03 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C523A282; Wed, 28 Aug 2013 06:16:03 +0000 (UTC) (envelope-from mailinglists@martinlaabs.de) Received: from relay03.alfahosting-server.de (relay03.alfahosting-server.de [109.237.142.239]) by mx1.freebsd.org (Postfix) with ESMTP id 4D5432D4B; Wed, 28 Aug 2013 06:16:02 +0000 (UTC) Received: by relay03.alfahosting-server.de (Postfix, from userid 1001) id C1EB832C1391; Wed, 28 Aug 2013 08:03:57 +0200 (CEST) X-Spam-DCC: : X-Spam-Level: X-Spam-Status: No, score=0.0 required=7.0 tests=BAYES_50 autolearn=disabled version=3.2.5 Received: from alfa3018.alfahosting-server.de (alfa3018.alfahosting-server.de [109.237.140.30]) by relay03.alfahosting-server.de (Postfix) with ESMTPS id 93FFA32C15C2; Wed, 28 Aug 2013 08:03:54 +0200 (CEST) Received: from laabs.hf.ifn.et.tu-dresden.de (hfsync.ifn.et.tu-dresden.de [141.30.128.60]) by alfa3018.alfahosting-server.de (Postfix) with ESMTPSA id 69C7F515DE3D; Wed, 28 Aug 2013 08:03:54 +0200 (CEST) Message-ID: <521D92CA.8050008@martinlaabs.de> Date: Wed, 28 Aug 2013 08:03:54 +0200 From: Martin Laabs User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130809 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-arm Subject: Raspberry PI sporadically fails to mount mmc card Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Status: No X-Virus-Checker-Version: clamassassin 1.2.4 with ClamAV 0.97.3/17759/Wed Aug 28 06:44:22 2013 Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 28 Aug 2013 06:16:03 -0000 Hi, Sporadically the raspberry pi fails to mount its root mmc card. After power off and power on again it works most of the time. However there seem to be also configurations that fail permanently. Unfortunately I have no image of a sd card that fails on every boot. Do you have any idea how to get more information whats going wrong? I think the problem starts after mmcsd0 received a timeout. Before that there are three lock reversals but I am not sure if they have any connection to the timeouts: lock order reversals before the timeout: 1st 0xc06f3c0c entropy harvest mutex (entropy harvest mutex) @ /usr/home/martin/Rasperry/head/sys/dev/random/randomdev_soft.c:242 2nd 0xc25d7c20 uart_hwmtx (uart_hwmtx) @ /usr/home/martin/Rasperry/head/sys/dev/uart/uart_cpu.h:92 1st 0xc06f3c0c entropy harvest mutex (entropy harvest mutex) @ /usr/home/martin/Rasperry/head/sys/dev/random/randomdev_soft.c:242 2nd 0xc059198c sleepq chain (sleepq chain) @ /usr/home/martin/Rasperry/head/sys/kern/subr_sleepqueue.c:240 1st 0xc06f3c0c entropy harvest mutex (entropy harvest mutex) @ /usr/home/martin/Rasperry/head/sys/dev/random/randomdev_soft.c:242 2nd 0xc059198c sleepq chain (sleepq chain) @ /usr/home/martin/Rasperry/head/sys/kern/subr_sleepqueue.c:240 [...] usbus0: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 uhub0: 1 port with 1 removable, self powered mmcsd0: 8GB at mmc0 50.0MHz/4bit/65535-block WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. mmcsd0: Error indicated: 1 Timeout mmcsd0: Error indicated: 1 Timeout Root mount waiting for: usbus0 ugen0.2: at usbus0 uhub1: on usbus0 uhub1: MTT enabled Root mount waiting for: usbus0 uhub1: 3 ports with 2 removable, self powered Root mount waiting for: usbus0 ugen0.3: at usbus0 smsc0: on usbus0 Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... mountroot: waiting for device /dev/mmcsd0s2a ... smsc0: chip 0xec00, rev. 0002 miibus0: on smsc0 ukphy0: PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on smsc0 ue0: Ethernet address: b8:27:eb:1d:b7:5a Mounting from ufs:/dev/mmcsd0s2a failed with error 19. Loader variables: vfs.root.mountfrom=ufs:/dev/mmcsd0s2a vfs.root.mountfrom.options=rw,noatime Manual root filesystem specification: : [options] Mount using filesystem and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:tank cd9660:/dev/acd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/acd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) Abort manual input mountroot> For details and the full boot log have a look to: http://www.freebsd.org/cgi/query-pr.cgi?pr=181601 Best regards, Martin Laabs From owner-freebsd-current@FreeBSD.ORG Wed Aug 28 10:29:02 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5D925337 for ; Wed, 28 Aug 2013 10:29:02 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm15.bullet.mail.ird.yahoo.com (nm15.bullet.mail.ird.yahoo.com [77.238.189.68]) by mx1.freebsd.org (Postfix) with SMTP id 8EE7E2BA6 for ; Wed, 28 Aug 2013 10:29:01 +0000 (UTC) Received: from [77.238.189.53] by nm15.bullet.mail.ird.yahoo.com with NNFMP; 28 Aug 2013 10:28:53 -0000 Received: from [46.228.39.89] by tm6.bullet.mail.ird.yahoo.com with NNFMP; 28 Aug 2013 10:28:53 -0000 Received: from [127.0.0.1] by smtp126.mail.ir2.yahoo.com with NNFMP; 28 Aug 2013 10:28:53 -0000 X-Yahoo-Newman-Id: 855905.88657.bm@smtp126.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: IsQidAcVM1nudI7PuwqKJhGI1diX0bXXv6XJdL00mPoV2Cl w2Q_5tpL6G3.aKf4QVLQ28OI04MhXTArWLiVk5agTbHcV6cs.OyJogE.endL CLn4mOQXHjqzv1S6joNbIl2861SBADXjuIhrAYI0zHIzAOZxw27w1_sA446m fkKplsrwcseKxdiKpB4ffjvVDIUVAnBJPkCPe0f7XA1VZdJ2lHtzSXi8ePqF eX8V6naQZgQR6KkxfLwW86eO1Dl.q4MH6T4x33MhFEbl0aaQxQCh0Es_R38U 6.pj8_CFiHIrx6xOTg78rs89tOQoetDUijNsf.eT2VLsifTUTm3LnG9q55Ql SwaE3pfDjP..cHuqnKj.akIfVVoR4nEneEDEjUDmKmWslbrcWh4PvM.SEuPi PvdAuheaR4_3jR_qo3s3I9p4xNK5xVYpdscyjuNtgcrFg663v0jTkSisuYNV uDuA0yacqYNYdeUNrEcbyzc6tospPFb40ubmbFdHRkghuw1WIhDxqlJY6cUt 1kIBo0hmgU7PKaD3.ZNTfgOTPEavHNTU- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. X-Rocket-Received: from [192.168.119.11] (se@84.154.114.147 with ) by smtp126.mail.ir2.yahoo.com with SMTP; 28 Aug 2013 10:28:53 +0000 UTC Message-ID: <521DD0D8.5020609@freebsd.org> Date: Wed, 28 Aug 2013 12:28:40 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: bsd patch regression? References: <1377644312.6359.27.camel@localhost> In-Reply-To: <1377644312.6359.27.camel@localhost> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 28 Aug 2013 10:29:02 -0000 Am 28.08.2013 00:58, schrieb Sean Bruno: > Colin generated a patch for xen things that does some pretty > typical behavior. bsdpatch really didn't handle it well and > rejected some things and flat out refused to create > sys/modules/xenhvm/Makefile for me. I cannot reproduce the last point: sys/modules/xenhvm/Makefile has been created in my tests ... Regarding the XENHVM files: The diff contains unexpanded $FreeBSD$ lines, while the files in /sys/conf/{amd64,i386} have them expanded, e.g.: # $FreeBSD$ vs. # $FreeBSD: head/sys/amd64/conf/XENHVM 239228 2012-08-13 07:36:57Z cperciva $ You may want to repeat the test with correct $FreeBSD$ lines ... Regards, STefan From owner-freebsd-current@FreeBSD.ORG Wed Aug 28 15:05:46 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8B683808; Wed, 28 Aug 2013 15:05:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5183F2EC9; Wed, 28 Aug 2013 15:05:45 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r7SF5doS001449; Wed, 28 Aug 2013 11:05:39 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r7SF5YGj098436; Wed, 28 Aug 2013 15:05:34 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 28 Aug 2013 15:05:34 GMT Message-Id: <201308281505.r7SF5YGj098436@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 , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 15:05:46 -0000 TB --- 2013-08-28 14:18:29 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-28 14:18:29 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-08-28 14:18:29 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-08-28 14:18:29 - cleaning the object tree TB --- 2013-08-28 14:18:29 - /usr/local/bin/svn stat /src TB --- 2013-08-28 14:18:45 - At svn revision 254985 TB --- 2013-08-28 14:18:46 - building world TB --- 2013-08-28 14:18:46 - CROSS_BUILD_TESTING=YES TB --- 2013-08-28 14:18:46 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-28 14:18:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-28 14:18:46 - SRCCONF=/dev/null TB --- 2013-08-28 14:18:46 - TARGET=pc98 TB --- 2013-08-28 14:18:46 - TARGET_ARCH=i386 TB --- 2013-08-28 14:18:46 - TZ=UTC TB --- 2013-08-28 14:18:46 - __MAKE_CONF=/dev/null TB --- 2013-08-28 14:18:46 - cd /src TB --- 2013-08-28 14:18:46 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Aug 28 14:18:54 UTC 2013 >>> 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 [...] c++ -O2 -pipe -I/src/lib/clang/libllvmcodegen/../../../contrib/llvm/include -I/src/lib/clang/libllvmcodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmcodegen/../../../contrib/llvm/lib/CodeGen -I. -I/src/lib/clang/libllvmcodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"/obj/pc98.i386/src/tmp\" -I/obj/pc98.i386/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmcodegen/../../../contrib/llvm/lib/CodeGen/ScoreboardHazardRecognizer.cpp -o ScoreboardHazardRecognizer.o c++ -O2 -pipe -I/src/lib/clang/libllvmcodegen/../../../contrib/llvm/include -I/src/lib/clang/libllvmcodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmcodegen/../../../contrib/llvm/lib/CodeGen -I. -I/src/lib/clang/libllvmcodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"/obj/pc98.i386/src/tmp\" -I/obj/pc98.i386/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmcodegen/../../../contrib/llvm/lib/CodeGen/ShadowStackGC.cpp -o ShadowStackGC.o c++ -O2 -pipe -I/src/lib/clang/libllvmcodegen/../../../contrib/llvm/include -I/src/lib/clang/libllvmcodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmcodegen/../../../contrib/llvm/lib/CodeGen -I. -I/src/lib/clang/libllvmcodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"/obj/pc98.i386/src/tmp\" -I/obj/pc98.i386/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmcodegen/../../../contrib/llvm/lib/CodeGen/ShrinkWrapping.cpp -o ShrinkWrapping.o /src/lib/clang/libllvmcodegen/../../../contrib/llvm/lib/CodeGen/ShrinkWrapping.cpp: In member function 'bool llvm::PEI::calcRestorePlacements(llvm::MachineBasicBlock*, llvm::SmallVector&, llvm::DenseMap, llvm::DenseMapInfo >&)': /src/lib/clang/libllvmcodegen/../../../contrib/llvm/lib/CodeGen/ShrinkWrapping.cpp:740: internal compiler error: in var_ann, at tree-flow-inline.h:128 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop. bmake[3]: stopped in /src/lib/clang/libllvmcodegen *** Error code 1 Stop. bmake[2]: stopped in /src/lib/clang *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-28 15:05:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-28 15:05:34 - ERROR: failed to build world TB --- 2013-08-28 15:05:34 - 2435.99 user 271.71 system 2824.51 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Wed Aug 28 17:28:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C4AF14D9; Wed, 28 Aug 2013 17:28:22 +0000 (UTC) (envelope-from iskander@advancedhosters.com) Received: from int.advancedhosters.com (int.advancedhosters.com [213.174.132.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 54DED29C5; Wed, 28 Aug 2013 17:28:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=advancedhosters.com; s=mail; h=Sender:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=e6yXnJ8/HV0g1ccgzOsLTDMJhPas87wy9jCXAVI53i0=; b=r3OLAVuJXKJtL9FFuU6vbyoOpM7gqV0R9Xdni+g0FoOX14aRmrbtCXNT8pwEGL3UWDonEYS34/X+Was/LUvH3yQp09Xg5aSoYu0ecYKbZr8vPrTKWdoi8sclA7E2Ps0dAhcsuTCgzC3UdMBXTJXEWO4KU7fe/FsgJRNaV1jid8A=; Received: from client186-7.emplot.net.ua ([193.110.107.186] helo=iskander.advancedhosters.com) by int.advancedhosters.com with esmtpa (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VEjXY-0007pK-Ab; Wed, 28 Aug 2013 17:28:20 +0000 Message-ID: <521E332F.4000206@gmail.com> Date: Wed, 28 Aug 2013 20:28:15 +0300 From: Alexander User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130827 Thunderbird/17.0.8 MIME-Version: 1.0 To: Hans Petter Selasky Subject: Re: USB no proper work References: <520E8602.5050408@gmail.com> <520E8842.4020609@bitfrost.no> <520E8DE1.1090609@gmail.com> <520F16B6.1070106@bitfrost.no> <520FA7C3.2060708@FreeBSD.org> <520FF137.1020709@gmail.com> <520FF37D.6050002@bitfrost.no> <521277DB.4010200@gmail.com> <521278BC.5010009@bitfrost.no> In-Reply-To: <521278BC.5010009@bitfrost.no> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: iskander@advancedhosters.com Cc: Alexander Motin , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 28 Aug 2013 17:28:22 -0000 19.08.2013 22:57, Hans Petter Selasky пишет: > On 08/19/13 21:54, Alexander Panyushkin wrote: >> 18.08.2013 01:04, Hans Petter Selasky пишет: >>> On 08/17/13 23:55, Alexander Panyushkin wrote: >>>> 17.08.2013 19:41, Alexander Motin пишет: >>>>> On 17.08.2013 09:22, Hans Petter Selasky wrote: >>> >>>> >>>> On USB device FAT-32 file system. When I removed flash drive, the >>>> file >>>> system has been unmounted. >>> >>> Hi, >>> >>> The problem might be in the GELI module then. Did you test that >>> Alexander ? >>> >>> Aug 16 23:23:43 scorpion kernel: GEOM_ELI: Device gpt/swap0.eli >>> created. >>> Aug 16 23:23:43 scorpion kernel: GEOM_ELI: Encryption: AES-XTS 128 >>> Aug 16 23:23:43 scorpion kernel: GEOM_ELI: Crypto: software >>> >>> Hint: You can set the following knob to disable the USB waiting at >>> reboot. >>> >>> hw.usb.no_shutdown_wait=1 >>> >> If set hw.usb.no_shutdown_wait = 1 >> Reboot successful, but if detach and attach again, USB device not >> detecting. > > This test is an indication that the USB stack is waiting for the CAM > layer to finish detaching its clients. Maybe you can turn on cam > debugging to figure out who is leaking a ref. Alexander Motin knows how. > > --HPS > Hi This is debug information ugen3.4: at usbus3 umass0: on usbus3 da0 at umass-sim0 bus 0 scbus8 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 7580MB (15523840 512 byte sectors: 255H 63S/T 966C) da0: quirks=0x2 (noperiph:umass-sim0:0:0:0): debugging flags now 1 (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (da0:umass-sim0:0:0:0): Error 22, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (da0:umass-sim0:0:0:0): Error 22, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (da0:umass-sim0:0:0:0): Error 22, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (da0:umass-sim0:0:0:0): Error 22, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (da0:umass-sim0:0:0:0): Error 22, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (da0:umass-sim0:0:0:0): Error 22, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (da0:umass-sim0:0:0:0): Error 22, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (da0:umass-sim0:0:0:0): Error 22, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (da0:umass-sim0:0:0:0): Error 22, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (da0:umass-sim0:0:0:0): Error 22, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (da0:umass-sim0:0:0:0): Error 22, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (da0:umass-sim0:0:0:0): Error 22, Unretryable error ugen3.4: at usbus3 (disconnected) umass0: at uhub5, port 5, addr 4 (disconnected) (pass3:umass-sim0:0:0:0): Periph invalidated (sg0:umass-sim0:0:0:0): Periph invalidated (da0:umass-sim0:0:0:0): Periph invalidated (da0:umass-sim0:0:0:0): lost device - 0 outstanding, 2 refs (pass3:umass-sim0:0:0:0): Periph destroyed From owner-freebsd-current@FreeBSD.ORG Wed Aug 28 17:36:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6B0537BC for ; Wed, 28 Aug 2013 17:36:37 +0000 (UTC) (envelope-from iskander@advancedhosters.com) Received: from int.advancedhosters.com (int.advancedhosters.com [213.174.132.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 42B472A5D for ; Wed, 28 Aug 2013 17:36:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=advancedhosters.com; s=mail; h=Sender:Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=Yur8oVduDm7M5P498ZFJ3rSngK6dpKbBU6buWRIxroU=; b=bnojqsxS6dW4UdXtvVVCBJGbmFehAI6T8PD6VNTgR4ZDGVl/eA6hXyh+qNa+Idemai1dyAtJOAfqfPNpTRhTpHokQHP+1/ldgcx5tOBGMTzn+qhRcSg52L4uSwCZx0Wu4zvAcMwhzFxC980MWvIjU0rb1rrGioJ8kZaPcvGrnD8=; Received: from client186-7.emplot.net.ua ([193.110.107.186] helo=iskander.advancedhosters.com) by int.advancedhosters.com with esmtpa (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VEjHA-0006e9-LP for freebsd-current@freebsd.org; Wed, 28 Aug 2013 17:11:24 +0000 Message-ID: <521E2F37.9010306@gmail.com> Date: Wed, 28 Aug 2013 20:11:19 +0300 From: Alexander User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130827 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: i915kms.ko not loading Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: iskander@advancedhosters.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 28 Aug 2013 17:36:37 -0000 *uname -a* FreeBSD iskander.advancedhosters.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Tue Aug 27 23:53:04 EEST 2013 root@iskander.advancedhosters.com:/usr/obj/usr/src/sys/Kernel amd64 in *make.conf* X_WINDOW_SYSTEM=xorg WITH_NEW_XORG=true WITH_KMS=true xorg-* ports rebuild After *Xorg -configure* system is going to reboot problem in load module i915kms.ko if *kldload i915kms.ko* system is going to reboot *pciconf -lvb* vgapci0@pci0:0:2:0: class=0x030000 card=0x844d1043 chip=0x01528086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = 'Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller' class = display subclass = VGA bar [10] = type Memory, range 64, base 0xf7800000, size 4194304, enabled bar [18] = type Prefetchable Memory, range 64, base 0xe0000000, size 268435456, enabled bar [20] = type I/O Port, range 32, base 0xf000, size 64, enabled error in */var/log/messages* Aug 28 16:09:26 iskander dbus[1185]: [system] Activating service name='org.freedesktop.ConsoleKit' (using servicehelper) Aug 28 16:09:26 iskander dbus[1185]: [system] Activating service name='org.freedesktop.PolicyKit1' (using servicehelper) Aug 28 16:09:26 iskander dbus[1185]: [system] Successfully activated service 'org.freedesktop.PolicyKit1' Aug 28 16:09:26 iskander dbus[1185]: [system] Successfully activated service 'org.freedesktop.ConsoleKit' Aug 28 16:09:26 iskander console-kit-daemon[1206]: WARNING: kvm_getenvv failed: How to fix this problem? From owner-freebsd-current@FreeBSD.ORG Wed Aug 28 18:42:16 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A44F9123; Wed, 28 Aug 2013 18:42:16 +0000 (UTC) (envelope-from mailinglists@martinlaabs.de) Received: from relay04.alfahosting-server.de (relay04.alfahosting-server.de [109.237.142.240]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5DA4D2E74; Wed, 28 Aug 2013 18:42:16 +0000 (UTC) Received: by relay04.alfahosting-server.de (Postfix, from userid 1001) id AE3B732C079C; Wed, 28 Aug 2013 20:42:07 +0200 (CEST) X-Spam-DCC: : X-Spam-Level: X-Spam-Status: No, score=0.0 required=7.0 tests=BAYES_50 autolearn=disabled version=3.2.5 Received: from alfa3018.alfahosting-server.de (alfa3018.alfahosting-server.de [109.237.140.30]) by relay04.alfahosting-server.de (Postfix) with ESMTPS id 64E3232C083C; Wed, 28 Aug 2013 20:42:06 +0200 (CEST) Received: from [192.168.1.55] (p54B30A87.dip0.t-ipconnect.de [84.179.10.135]) by alfa3018.alfahosting-server.de (Postfix) with ESMTPSA id D0CE2515DE3D; Wed, 28 Aug 2013 20:42:05 +0200 (CEST) Message-ID: <521E447C.9000505@martinlaabs.de> Date: Wed, 28 Aug 2013 20:42:04 +0200 From: Martin Laabs User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130809 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ian Lepore Subject: Re: arm/181602: Raspberry PI kernel panic after DHCP References: <201308280544.r7S5id9t094480@oldred.freebsd.org> <1377691823.1111.235.camel@revolution.hippie.lan> In-Reply-To: <1377691823.1111.235.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Status: No X-Virus-Checker-Version: clamassassin 1.2.4 with ClamAV 0.97.3/17762/Wed Aug 28 18:42:58 2013 Cc: freebsd-arm@freebsd.org, freebsd-gnats-submit@FreeBSD.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 28 Aug 2013 18:42:16 -0000 On 28.08.2013 14:10, Ian Lepore wrote: > On Wed, 2013-08-28 at 05:44 +0000, Martin Laabs wrote: >>> Number: 181602 >>> Category: arm >>> Synopsis: Raspberry PI kernel panic after DHCP [...] > This problem was caused by recent changes to the layout of struct mbuf > and the structures embedded within it. Fixed in r254973. OK. I can confirm this for the Raspberry-Pi. Running a r254984 So from my side it is OK to close the bug. Best regards, Martin Laabs From owner-freebsd-current@FreeBSD.ORG Wed Aug 28 19:42:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9B19A287 for ; Wed, 28 Aug 2013 19:42:37 +0000 (UTC) (envelope-from vsityz@gmail.com) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 31460226A for ; Wed, 28 Aug 2013 19:42:37 +0000 (UTC) Received: by mail-ea0-f182.google.com with SMTP id o10so3225423eaj.27 for ; Wed, 28 Aug 2013 12:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=Yur8oVduDm7M5P498ZFJ3rSngK6dpKbBU6buWRIxroU=; b=vFthoIzaVBJNzyIYrae38POjIgNFGKAdKpc5hg3JnajW3kj1j7XXllnzB4lvxPRjuu F5slISuI2vQmNdz+3QzRzgsIS1Me65IHvc7CMiwo6ALaNg25x0w7e1r/MNIQYFqk8mS0 NosvJJiEeQTCnOdwjHl9xMozs5rhKUpcTKlMPDEJgXtcWtXdHuSonzuS21y9FxV2crXM +VWSIJZwy+EeSrGa09I01Df73nEFH+cxBi/ZK/rNzKDN3/bXjLtvQN8mQLTmAcFSaF6y uwYJG+qI4UdpyG6LeUiC8Eg3kwrSNpL66Q6/IItZ8AIRXz7lxUjQJZPuyqhIfX3nP7PM 1azQ== X-Received: by 10.14.22.68 with SMTP id s44mr4691950ees.74.1377718955562; Wed, 28 Aug 2013 12:42:35 -0700 (PDT) Received: from scorpion.kiev.ua ([130.180.220.174]) by mx.google.com with ESMTPSA id x47sm40087822eea.16.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 Aug 2013 12:42:34 -0700 (PDT) Message-ID: <521E52A6.6040205@gmail.com> Date: Wed, 28 Aug 2013 22:42:30 +0300 From: Alexander Panyushkin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130811 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: i915kms.ko not loading Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 28 Aug 2013 19:42:37 -0000 *uname -a* FreeBSD iskander.advancedhosters.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Tue Aug 27 23:53:04 EEST 2013 root@iskander.advancedhosters.com:/usr/obj/usr/src/sys/Kernel amd64 in *make.conf* X_WINDOW_SYSTEM=xorg WITH_NEW_XORG=true WITH_KMS=true xorg-* ports rebuild After *Xorg -configure* system is going to reboot problem in load module i915kms.ko if *kldload i915kms.ko* system is going to reboot *pciconf -lvb* vgapci0@pci0:0:2:0: class=0x030000 card=0x844d1043 chip=0x01528086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = 'Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller' class = display subclass = VGA bar [10] = type Memory, range 64, base 0xf7800000, size 4194304, enabled bar [18] = type Prefetchable Memory, range 64, base 0xe0000000, size 268435456, enabled bar [20] = type I/O Port, range 32, base 0xf000, size 64, enabled error in */var/log/messages* Aug 28 16:09:26 iskander dbus[1185]: [system] Activating service name='org.freedesktop.ConsoleKit' (using servicehelper) Aug 28 16:09:26 iskander dbus[1185]: [system] Activating service name='org.freedesktop.PolicyKit1' (using servicehelper) Aug 28 16:09:26 iskander dbus[1185]: [system] Successfully activated service 'org.freedesktop.PolicyKit1' Aug 28 16:09:26 iskander dbus[1185]: [system] Successfully activated service 'org.freedesktop.ConsoleKit' Aug 28 16:09:26 iskander console-kit-daemon[1206]: WARNING: kvm_getenvv failed: How to fix this problem? From owner-freebsd-current@FreeBSD.ORG Wed Aug 28 19:42:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BB61F39A; Wed, 28 Aug 2013 19:42:59 +0000 (UTC) (envelope-from vsityz@gmail.com) Received: from mail-ee0-x234.google.com (mail-ee0-x234.google.com [IPv6:2a00:1450:4013:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 120F82280; Wed, 28 Aug 2013 19:42:58 +0000 (UTC) Received: by mail-ee0-f52.google.com with SMTP id c41so3148234eek.39 for ; Wed, 28 Aug 2013 12:42:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=e6yXnJ8/HV0g1ccgzOsLTDMJhPas87wy9jCXAVI53i0=; b=ODZfN/jeSJuKlU9CWgPIh3lXDHsJbCqHqtmEQs1KQor5YD991jxynNyXzEbckbIxcA mAEnPptu7a91KFDC7sF45h9I09gEuHMa9kStcYnV3qQ83uRwSlCC0Csweq2ibbQJEoHH K9qZReytFKaVVWTF61r+y4TRU5I8JHMg08w0ilri/3bSlzWvTsfvRln4tZMlFFEHfcHV 1HE3Qb5VED4F7RZamNFvBTI1sVWgRfwluHBS3etGNZ6oV7Ibag7Lb0nEVyKmtIUW4cKa a7dfLhuCfR8+3yRQiBdBNaIzn0Zg1PGO+X5gspIUvny1eeA52NoNmX1StpuRamaG80y6 4caw== X-Received: by 10.14.127.4 with SMTP id c4mr4731679eei.61.1377718977267; Wed, 28 Aug 2013 12:42:57 -0700 (PDT) Received: from scorpion.kiev.ua ([130.180.220.174]) by mx.google.com with ESMTPSA id r48sm40071206eev.14.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 Aug 2013 12:42:56 -0700 (PDT) Message-ID: <521E52BB.1050001@gmail.com> Date: Wed, 28 Aug 2013 22:42:51 +0300 From: Alexander Panyushkin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130811 Thunderbird/17.0.8 MIME-Version: 1.0 To: Hans Petter Selasky Subject: Re: USB no proper work References: <520E8602.5050408@gmail.com> <520E8842.4020609@bitfrost.no> <520E8DE1.1090609@gmail.com> <520F16B6.1070106@bitfrost.no> <520FA7C3.2060708@FreeBSD.org> <520FF137.1020709@gmail.com> <520FF37D.6050002@bitfrost.no> <521277DB.4010200@gmail.com> <521278BC.5010009@bitfrost.no> In-Reply-To: <521278BC.5010009@bitfrost.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Alexander Motin , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 28 Aug 2013 19:42:59 -0000 19.08.2013 22:57, Hans Petter Selasky пишет: > On 08/19/13 21:54, Alexander Panyushkin wrote: >> 18.08.2013 01:04, Hans Petter Selasky пишет: >>> On 08/17/13 23:55, Alexander Panyushkin wrote: >>>> 17.08.2013 19:41, Alexander Motin пишет: >>>>> On 17.08.2013 09:22, Hans Petter Selasky wrote: >>> >>>> >>>> On USB device FAT-32 file system. When I removed flash drive, the >>>> file >>>> system has been unmounted. >>> >>> Hi, >>> >>> The problem might be in the GELI module then. Did you test that >>> Alexander ? >>> >>> Aug 16 23:23:43 scorpion kernel: GEOM_ELI: Device gpt/swap0.eli >>> created. >>> Aug 16 23:23:43 scorpion kernel: GEOM_ELI: Encryption: AES-XTS 128 >>> Aug 16 23:23:43 scorpion kernel: GEOM_ELI: Crypto: software >>> >>> Hint: You can set the following knob to disable the USB waiting at >>> reboot. >>> >>> hw.usb.no_shutdown_wait=1 >>> >> If set hw.usb.no_shutdown_wait = 1 >> Reboot successful, but if detach and attach again, USB device not >> detecting. > > This test is an indication that the USB stack is waiting for the CAM > layer to finish detaching its clients. Maybe you can turn on cam > debugging to figure out who is leaking a ref. Alexander Motin knows how. > > --HPS > Hi This is debug information ugen3.4: at usbus3 umass0: on usbus3 da0 at umass-sim0 bus 0 scbus8 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 7580MB (15523840 512 byte sectors: 255H 63S/T 966C) da0: quirks=0x2 (noperiph:umass-sim0:0:0:0): debugging flags now 1 (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (da0:umass-sim0:0:0:0): Error 22, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (da0:umass-sim0:0:0:0): Error 22, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (da0:umass-sim0:0:0:0): Error 22, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (da0:umass-sim0:0:0:0): Error 22, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (da0:umass-sim0:0:0:0): Error 22, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (da0:umass-sim0:0:0:0): Error 22, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (da0:umass-sim0:0:0:0): Error 22, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (da0:umass-sim0:0:0:0): Error 22, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (da0:umass-sim0:0:0:0): Error 22, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (da0:umass-sim0:0:0:0): Error 22, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (da0:umass-sim0:0:0:0): Error 22, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (da0:umass-sim0:0:0:0): Error 22, Unretryable error ugen3.4: at usbus3 (disconnected) umass0: at uhub5, port 5, addr 4 (disconnected) (pass3:umass-sim0:0:0:0): Periph invalidated (sg0:umass-sim0:0:0:0): Periph invalidated (da0:umass-sim0:0:0:0): Periph invalidated (da0:umass-sim0:0:0:0): lost device - 0 outstanding, 2 refs (pass3:umass-sim0:0:0:0): Periph destroyed From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 00:27:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3C81B6D0 for ; Thu, 29 Aug 2013 00:27:21 +0000 (UTC) (envelope-from gondim@bsdinfo.com.br) Received: from zeus.linuxinfo.com.br (zeus.linuxinfo.com.br [66.118.173.244]) by mx1.freebsd.org (Postfix) with ESMTP id E95DE23B1 for ; Thu, 29 Aug 2013 00:27:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zeus.linuxinfo.com.br (Postfix) with ESMTP id 944456068F for ; Wed, 28 Aug 2013 21:29:58 -0300 (BRT) X-Virus-Scanned: Debian amavisd-new at zeus Received: from zeus.linuxinfo.com.br ([127.0.0.1]) by localhost (zeus.linuxinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLJfZXk-XDf2 for ; Wed, 28 Aug 2013 21:29:57 -0300 (BRT) Received: from MacBook-de-Gondim-2.local (unknown [186.193.54.69]) by zeus.linuxinfo.com.br (Postfix) with ESMTPSA id 066FD604B8 for ; Wed, 28 Aug 2013 21:29:55 -0300 (BRT) Message-ID: <521E955C.4060308@bsdinfo.com.br> Date: Wed, 28 Aug 2013 21:27:08 -0300 From: Marcelo Gondim User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: The load does not decrease 1.0 References: <520E8602.5050408@gmail.com> <520E8842.4020609@bitfrost.no> <520E8DE1.1090609@gmail.com> <520F16B6.1070106@bitfrost.no> <520FA7C3.2060708@FreeBSD.org> <520FF137.1020709@gmail.com> <520FF37D.6050002@bitfrost.no> <521277DB.4010200@gmail.com> <521278BC.5010009@bitfrost.no> <521E52BB.1050001@gmail.com> In-Reply-To: <521E52BB.1050001@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 29 Aug 2013 00:27:21 -0000 I noticed that in this revision 254890 the system load is not less than 1.0. Revision 254497 did not occur. FreeBSD growthinfo01.localdomain 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r254890: Thu Aug 29 07:02:12 EDT 2013 root@growthinfo01.localdomain:/usr/obj/usr/src/sys/VMSRV amd64 last pid: 1534; load averages: 1.00, 0.97, 0.83 up 0+00:26:12 08:04:38 21 processes: 1 running, 20 sleeping CPU 0: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 1: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 2: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 3: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 4: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 5: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 6: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 7: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Mem: 14M Active, 13M Inact, 147M Wired, 26M Buf, 7681M Free Swap: 8192M Total, 8192M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 1524 root 1 20 0 81628K 6600K select 5 0:00 0.00% sshd 1413 root 1 20 0 23976K 4920K select 7 0:00 0.00% sendmail 1534 root 1 20 0 19764K 2760K CPU5 5 0:00 0.00% top 1531 growadmin 1 20 0 47632K 2684K wait 6 0:00 0.00% su 1532 root 1 20 0 23488K 3332K pause 2 0:00 0.00% csh 1311 root 1 20 0 14420K 2052K select 6 0:00 0.00% syslogd 1527 growadmin 1 20 0 81628K 6604K select 6 0:00 0.00% sshd 1420 root 1 20 0 16512K 2136K nanslp 5 0:00 0.00% cron 1528 growadmin 1 20 0 16984K 2564K wait 5 0:00 0.00% sh 1463 root 1 52 0 14416K 1900K ttyin 3 0:00 0.00% getty 1462 root 1 52 0 14416K 1900K ttyin 4 0:00 0.00% getty 1465 root 1 52 0 14416K 1900K ttyin 0 0:00 0.00% getty 1461 root 1 52 0 14416K 1900K ttyin 1 0:00 0.00% getty 1459 root 1 52 0 14416K 1900K ttyin 6 0:00 0.00% getty 1460 root 1 52 0 14416K 1900K ttyin 5 0:00 0.00% getty 1466 root 1 52 0 14416K 1900K ttyin 2 0:00 0.00% getty 1464 root 1 52 0 14416K 1900K ttyin 7 0:00 0.00% getty 1410 root 1 20 0 56360K 5896K select 0 0:00 0.00% sshd 1172 root 1 20 0 13204K 4300K select 1 0:00 0.00% devd 1416 smmsp 1 52 0 23976K 4888K pause 6 0:00 0.00% sendmail 141 root 1 52 0 12260K 1760K pause 7 0:00 0.00% adjkerntz From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 09:15:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1D5F452C; Thu, 29 Aug 2013 09:15:19 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-qe0-x22f.google.com (mail-qe0-x22f.google.com [IPv6:2607:f8b0:400d:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B50F921CB; Thu, 29 Aug 2013 09:15:18 +0000 (UTC) Received: by mail-qe0-f47.google.com with SMTP id b4so71839qen.20 for ; Thu, 29 Aug 2013 02:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=tA7Htti2OL1zeeRvjcrqUh80iH0lXzTmHQHqCjyxmwc=; b=I5PD/MNrvdzL4zzns3YpmbeGL0S8Aseo39AK9UiO6XpaOnFTdeBTkgMgwJUKphE9UA M12kN1c/4TmsOVwJXokGfWhIZzM0Eic7MO8JqE4MnPDaJs1ZKGvChnFXOCzpBiX/SPfy jLO7kMl6ApzNCfpIENNFA1zdAH7deNPVgmTP2/3qKP8KoY/HuL52ZjOcTtYnNkqGd7fy 6C/Ai3SO7AzRAwDtyCOlNSVK3kP2ZrUagtw1mN13UB31CjvxjzOcLXyg0p/2snXfzcy/ UWmCHf3jqlGewyHhZqrO9xOmY4RsuqC0lJAt66Iy9IEoPmAMUs6Y+0yNBiA1c4s+0xbp pTAg== MIME-Version: 1.0 X-Received: by 10.49.76.98 with SMTP id j2mr2587551qew.41.1377767717789; Thu, 29 Aug 2013 02:15:17 -0700 (PDT) Received: by 10.224.5.195 with HTTP; Thu, 29 Aug 2013 02:15:17 -0700 (PDT) Date: Thu, 29 Aug 2013 12:15:17 +0300 Message-ID: Subject: Why are cardbus drivers cbb(4) and pccard(4) still included in GENERIC? From: Kimmo Paasiala To: FreeBSD current , "freebsd-stable@freebsd.org" , freebsd-hardware@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 29 Aug 2013 09:15:19 -0000 In reference to this FreeBSD forums post: http://forums.freebsd.org/showpost.php?p=231135&postcount=4 Would it be a good time to remove those from GENERIC since the hardware they are for is becoming so seriously outdated? There's always an option to load those drivers as modules if needed. -Kimmo From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 09:25:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B0AFD983 for ; Thu, 29 Aug 2013 09:25:03 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from mail.made4.biz (unknown [IPv6:2001:41d0:1:7018::1:3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7611222AE for ; Thu, 29 Aug 2013 09:25:03 +0000 (UTC) Received: from [2001:1b48:10b:cafe:225:64ff:febe:589f] (helo=viking.yzserv.com) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VEyTM-000AqG-AY; Thu, 29 Aug 2013 11:25:00 +0200 Message-ID: <521F1367.8090002@FreeBSD.org> Date: Thu, 29 Aug 2013 11:24:55 +0200 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130813 Thunderbird/17.0.8 MIME-Version: 1.0 To: Alexander Panyushkin Subject: Re: i915kms.ko not loading References: <521E52A6.6040205@gmail.com> In-Reply-To: <521E52A6.6040205@gmail.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2UOJSRIJGVRGCCTODLPXC" Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 29 Aug 2013 09:25:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2UOJSRIJGVRGCCTODLPXC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 28.08.2013 21:42, Alexander Panyushkin wrote: > problem in load module i915kms.ko > if *kldload i915kms.ko* system is going to reboot Are you able to obtain a kernel core dump? They're saved in /var/crash during the next boot. If you have one, could you please send the last core.txt? This file contains a trace of the crash, the state of the computer at the time of the crash and dmesg's output. --=20 Jean-S=E9bastien P=E9dron ------enig2UOJSRIJGVRGCCTODLPXC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIfE2wACgkQa+xGJsFYOlOeaACgko+g5Mzga9aeE7PbSJDo1PTI cdsAoK9Pa17Ef11LQHL3bsvRoxQrQq/v =qHCZ -----END PGP SIGNATURE----- ------enig2UOJSRIJGVRGCCTODLPXC-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 10:16:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6DEA0F2B for ; Thu, 29 Aug 2013 10:16:38 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm3.ukr.net (fsm3.ukr.net [195.214.192.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 214FF276C for ; Thu, 29 Aug 2013 10:16:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:Mime-Version:Message-ID:Subject:To:From:Date; bh=fsDfrv5B2k7AhPSPJyW+JEDEowelVru++29gV+u+nbo=; b=AZJ078KlSziquNEET0UxVsHbErWws7sc+E0s2JQP+JKDadNNAc0MjF18ckC4FP3kdZ5KRmfTXEchIDAEaNBMaYlyYYoy14KwMxnnm7H9nQrEzNwsaPV51odl4xLxafkfLZ9IgRHVy8kby9XdFEe9B+r6zDS2+RiFMRxy4avuSZk=; Received: from [178.137.138.140] (helo=nonamehost.local) by fsm3.ukr.net with esmtpsa ID 1VEyqa-000JpM-9k for freebsd-current@freebsd.org; Thu, 29 Aug 2013 12:49:00 +0300 Date: Thu, 29 Aug 2013 12:48:46 +0300 From: Ivan Klymenko To: freebsd-current@freebsd.org Subject: make delete-old broken Message-ID: <20130829124846.08b8c11e@nonamehost.local> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Authentication-Result: IP=178.137.138.140; mail.from=fidaj@ukr.net; dkim=pass; header.d=ukr.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 29 Aug 2013 10:16:38 -0000 Hello. In the interval between revisions >= r254887 to r255016 make delete-old broken root@nonamehost:/ # cd /usr/src/ root@nonamehost:/usr/src # yes|make delete-old make[1]: "tools/build/mk/tools/build/mk/OptionalObsoleteFiles.inc" line 1603: Malformed conditional (${MK_GNU_PATCH} == no) make[1]: Fatal errors encountered -- cannot continue make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src I can not say exactly at what revision it happened - but it was noticed in revision r255016 From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 10:56:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 51952CF7; Thu, 29 Aug 2013 10:56:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8C1552BB2; Thu, 29 Aug 2013 10:56:55 +0000 (UTC) Received: by mail-wg0-f54.google.com with SMTP id e11so261723wgh.9 for ; Thu, 29 Aug 2013 03:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=rSHv0Hwxj5bF8tKec2UYNfuIn1G++WBwBxYqX5hwcbw=; b=h1G2fGQtGrhuqwKcuCdUfngLyY9iS1DytNl1IqaucnNRZr97ENQUbOgoEUJ7Beb+Bn LB/xwPPAZ5focdJ7JcC0jlLsFcHx6rjsB8VLCVnZQ2aSTXxsxVofx5l9sA97vWUXJWrb YiFWPiNnd7u3jqgDOOnUgWW6TQUnew0UXftUFPqzjrEYjoOKm0iIz/aAKCgkAfLflsuv sEPF9AHcWA0nqkllkVAlNMUqwlxwpJ4kVLNEHdSHozDl7c78oUvn42rWjEnqRM4mT5uS LqfjWWLeafMyyu00MWIWwKkJUqcyQ9/svA92rOIE64cHkMt1T/nVSK9/MhoBtaVClcPG 1Y1A== MIME-Version: 1.0 X-Received: by 10.194.11.67 with SMTP id o3mr5329237wjb.0.1377773813770; Thu, 29 Aug 2013 03:56:53 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.146.2 with HTTP; Thu, 29 Aug 2013 03:56:53 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 Aug 2013 03:56:53 -0700 X-Google-Sender-Auth: _v3zZf0fjZhtZYfU9HwMxmzXpTo Message-ID: Subject: Re: Why are cardbus drivers cbb(4) and pccard(4) still included in GENERIC? From: Adrian Chadd To: Kimmo Paasiala Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD current , "freebsd-stable@freebsd.org" , freebsd-hardware@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 29 Aug 2013 10:56:56 -0000 Hm! Are they dynamically loaded if you insert the cards? (Ie, has devd been taught about them as appropriate?) -adrian On 29 August 2013 02:15, Kimmo Paasiala wrote: > In reference to this FreeBSD forums post: > > http://forums.freebsd.org/showpost.php?p=231135&postcount=4 > > Would it be a good time to remove those from GENERIC since the > hardware they are for is becoming so seriously outdated? > > There's always an option to load those drivers as modules if needed. > > -Kimmo > _______________________________________________ > 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 Aug 29 11:42:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DDD4FCA2 for ; Thu, 29 Aug 2013 11:42:15 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from mx1.flashcable.ch (mx1.flashcable.ch [81.92.96.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 791322E97 for ; Thu, 29 Aug 2013 11:42:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mx1.flashcable.ch (8.13.8/8.13.8/Submit_local) with ESMTP id r7TBgDXY017180; Thu, 29 Aug 2013 13:42:13 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Received: from phpmailer (borderline21.nexus-ag.com [212.203.104.226]) by localhost with HTTPS (UebiMiau); Thu, 29 Aug 2013 13:42:13 +0200 Date: Thu, 29 Aug 2013 13:42:13 +0200 To: IvanKlymenko , freebsd-current@freebsd.org From: Andreas Tobler Subject: Re: make delete-old broken Message-ID: <7070ea1153ab17a4a7b5deb432de93b3@212.203.104.226> X-Priority: 3 X-Mailer: PHPMailer [version 1.73] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Andreas Tobler List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 11:42:15 -0000 --------- Original Message -------- From: Ivan Klymenko To: freebsd-current@freebsd.org Subject: make delete-old broken Date: 29/08/13 12:16 > Hello. > In the interval between revisions >= r254887 to r255016 > make delete-old broken > > root@nonamehost:/ # cd /usr/src/ > root@nonamehost:/usr/src # yes|make delete-old > make[1]: "tools/build/mk/tools/build/mk/OptionalObsoleteFiles.inc" line > 1603: Malformed conditional (${MK_GNU_PATCH} == no) make[1]: Fatal > errors encountered -- cannot continue make[1]: stopped in /usr/src > *** Error code 1 > > Stop. > make: stopped in /usr/src > > I can not say exactly at what revision it happened - but it was noticed > in revision r255016 Should be fixed now, 255018. Gruss, Andreas From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 11:51:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A75F467B for ; Thu, 29 Aug 2013 11:51:01 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.120]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5B3CE2006 for ; Thu, 29 Aug 2013 11:51:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=AMGl5tu0/y4ncji4xoJbB2xxZXNUAxcyUeO5QyC5EWQ=; b=RnvUnbsXh/DWQ+6suVN0UHC4OAJrPCufgMQwQA3b2btL4sQ0URjjnEC2CKhKhkdLUkBGU1z4M6SSc9MiTwFk2aVIuAwsb2hI7NDq7b0gq9D0s03j2Qyk84haog2ktsZxUt9SNX3A4pAJsK1hslxQxr85pIRTnUB179aeP09GcXk=; Received: from [178.137.138.140] (helo=nonamehost.local) by fsm1.ukr.net with esmtpsa ID 1VF0kI-0004rd-OL ; Thu, 29 Aug 2013 14:50:38 +0300 Date: Thu, 29 Aug 2013 14:50:37 +0300 From: Ivan Klymenko To: Andreas Tobler Subject: Re: make delete-old broken Message-ID: <20130829145037.68d5cbf0@nonamehost.local> In-Reply-To: <7070ea1153ab17a4a7b5deb432de93b3@212.203.104.226> References: <7070ea1153ab17a4a7b5deb432de93b3@212.203.104.226> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Authentication-Result: IP=178.137.138.140; mail.from=fidaj@ukr.net; dkim=pass; header.d=ukr.net Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 29 Aug 2013 11:51:01 -0000 =D0=92 Thu, 29 Aug 2013 13:42:13 +0200 Andreas Tobler =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >=20 > > I can not say exactly at what revision it happened - but it was > > noticed in revision r255016 >=20 >=20 > Should be fixed now, 255018. >=20 > Gruss, > Andreas >=20 Thank you. From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 14:58:10 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 614A359A; Thu, 29 Aug 2013 14:58:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3757E2DBB; Thu, 29 Aug 2013 14:58:10 +0000 (UTC) Received: from jhbbsd.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 45552B979; Thu, 29 Aug 2013 10:58:09 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: How to best overload the fileops ? Date: Thu, 29 Aug 2013 10:36:39 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <521508F4.6030502@rawbw.com> <1377290165.1111.85.camel@revolution.hippie.lan> <5217DFC0.7070708@rawbw.com> In-Reply-To: <5217DFC0.7070708@rawbw.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201308291036.39807.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 29 Aug 2013 10:58:09 -0400 (EDT) Cc: Mateusz Guzik , current@freebsd.org, Ian Lepore , Roman Divacky , Yuri , John-Mark Gurney X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 29 Aug 2013 14:58:10 -0000 On Friday, August 23, 2013 6:18:40 pm Yuri wrote: > On 08/23/2013 13:36, Ian Lepore wrote: > > I think the point is that devfs_ops_f provides several devfs-specific > > methods and then "inherits" the rest by referencing the standard > > vn_whatever functions. Since John recommended that you expose the > > fo_whatever methods, I think he's suggesting you build your ops table by > > providing your own close method and fill in the rest of the table with > > the now-exposed kqueue ops methods. > > So you are suggesting to just make kqueue fileops public? This was my > first suggestion, and this was rejected by Roman Divacky (who was > supposed to check it in) as very ugly. I did this through the method > kqueue_ops(), not directly though. > > So can we agree on way to be used here? Making the individual kqueue methods public is more consistent with other uses in the tree (notably devfs), so I think that is the best way. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 14:58:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8FA50605; Thu, 29 Aug 2013 14:58:15 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1432F2DBC; Thu, 29 Aug 2013 14:58:15 +0000 (UTC) Received: from jhbbsd.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 13E17B9A9; Thu, 29 Aug 2013 10:58:14 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: [rfc] migrate lagg to an rmlock Date: Thu, 29 Aug 2013 10:42:13 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <5218AA36.1080807@ipfw.ru> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201308291042.13282.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 29 Aug 2013 10:58:14 -0400 (EDT) Cc: FreeBSD Net , Adrian Chadd , Robert Watson , "Alexander V. Chernikov" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 29 Aug 2013 14:58:15 -0000 On Saturday, August 24, 2013 10:16:33 am Robert Watson wrote: > There are a number of other places in the kernel where migration to an rmlock > makes sense -- however, some care must be taken for four reasons: (1) while > read locks don't experience line contention, write locking becomes observably > e.g., rmlocks might not be suitable for tcbinfo; (2) rmlocks, unlike rwlocks, > more expensive so is not suitable for all rwlock line contention spots -- > implement reader priority propagation, so you must reason about; and (3) > historically, rmlocks have not fully implemented WITNESS so you may get less > good debugging output. if_lagg is a nice place to use rmlocks, as > reconfigurations are very rare, and it's really all about long-term data > stability. 3) should no longer be an issue. rmlocks now have full WITNESS and assertion support (including an rm_assert). However, one thing to consider is that rmlocks pin readers to CPUs while the read lock is held (which rwlocks do not do). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 14:58:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9C6A46B0; Thu, 29 Aug 2013 14:58:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7224F2DBD; Thu, 29 Aug 2013 14:58:20 +0000 (UTC) Received: from jhbbsd.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5F736B9B3; Thu, 29 Aug 2013 10:58:19 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: Why are cardbus drivers cbb(4) and pccard(4) still included in GENERIC? Date: Thu, 29 Aug 2013 10:54:02 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; 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: <201308291054.02641.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 29 Aug 2013 10:58:19 -0400 (EDT) Cc: Kimmo Paasiala , Adrian Chadd , "freebsd-stable@freebsd.org" , Warner Losh , freebsd-hardware@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 29 Aug 2013 14:58:20 -0000 On Thursday, August 29, 2013 6:56:53 am Adrian Chadd wrote: > Hm! Are they dynamically loaded if you insert the cards? > > (Ie, has devd been taught about them as appropriate?) These are drivers for the bridges, not for cards you plug into the bridges. If you autoloaded them at all you would load them during boot when you saw an appropriate PCI device. Currently we don't autoload any PCI drivers, so I don't think that should be a blocker for taking these out of GENERIC. Warner is probably the best person to ask. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 14:58:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A05048C6; Thu, 29 Aug 2013 14:58:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 748F82DBF; Thu, 29 Aug 2013 14:58:25 +0000 (UTC) Received: from jhbbsd.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 65DD0B9C1; Thu, 29 Aug 2013 10:58:24 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: GCC withdraw Date: Thu, 29 Aug 2013 10:57:42 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <20130822200902.GG94127@funkthat.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201308291057.43027.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 29 Aug 2013 10:58:24 -0400 (EDT) Cc: "Sam Fourman Jr." , toolchain@freebsd.org, David Chisnall , Boris Samorodov , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 29 Aug 2013 14:58:25 -0000 On Saturday, August 24, 2013 7:19:22 am David Chisnall wrote: > On 24 Aug 2013, at 11:30, "Sam Fourman Jr." wrote: > > > So I vote, let's not give ourselves the burden of "lugging" dead weight in > > base > > for another 5 years. (in 2017 do we still want to be worrying about gcc in > > base?) > > Perhaps more to the point, in 2017 do we want to be responsible for > maintaining a fork of a 2007 release of gcc and libstdc++? This is a red herring and I'd wish you'd stop bringing it up constantly. GCC has not needed constant care and feeding in the 7.x/8.x/9.x branches and it won't need it in 10.x either. I have not seen any convincing argument as to why leaving GCC in the base for 10.x impedes anything. Because clang isn't sufficient for so many non-x86 platforms we can't really start using clang-specific features yet anyway. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 15:35:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A3E7C29B; Thu, 29 Aug 2013 15:35:53 +0000 (UTC) (envelope-from iskander@advancedhosters.com) Received: from int.advancedhosters.com (int.advancedhosters.com [213.174.132.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 79A09215A; Thu, 29 Aug 2013 15:35:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=advancedhosters.com; s=mail; h=Sender:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=+3t1GFt7V+C25JW5R4u08fGSi/svUQu0wEG2uFp41KU=; b=Zdk7+ccJI9EMfk7PRhLgwPsWo29SNp+EO6gaDAA0LapkSFXnDyevpkV4pHC94Pqf2BPdyJCjmK2wF2bp+/U/Zrza1e4KabZoV/tpnFLXqURLgOVdciEAzJdIGMXQg8F97zNQusCXB4JvHguEnSF9b7m4tHs1Uhjtw/D9b9QkCPU=; Received: from client186-7.emplot.net.ua ([193.110.107.186] helo=iskander.advancedhosters.com) by int.advancedhosters.com with esmtpa (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VF4GF-000IA6-JU; Thu, 29 Aug 2013 15:35:51 +0000 Message-ID: <521F6A52.2060206@gmail.com> Date: Thu, 29 Aug 2013 18:35:46 +0300 From: Alexander User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130827 Thunderbird/17.0.8 MIME-Version: 1.0 To: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= Subject: Re: i915kms.ko not loading References: <521E52A6.6040205@gmail.com> <521F1367.8090002@FreeBSD.org> In-Reply-To: <521F1367.8090002@FreeBSD.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: iskander@advancedhosters.com Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 29 Aug 2013 15:35:53 -0000 29.08.2013 12:24, Jean-Sébastien Pédron пишет: > On 28.08.2013 21:42, Alexander Panyushkin wrote: >> problem in load module i915kms.ko >> if *kldload i915kms.ko* system is going to reboot > Are you able to obtain a kernel core dump? They're saved in /var/crash > during the next boot. > > If you have one, could you please send the last core.txt? This file > contains a trace of the crash, the state of the computer at the time of > the crash and dmesg's output. > in sysctl: kern.coredump: 1 kern.corefile: /var/coredumps/%U.%N.%P.core but coredump files not created. How to set for creating core files? From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 15:39:48 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 80A9A6B6 for ; Thu, 29 Aug 2013 15:39:48 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from mail.made4.biz (unknown [IPv6:2001:41d0:1:7018::1:3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4409521A9 for ; Thu, 29 Aug 2013 15:39:48 +0000 (UTC) Received: from [2001:1b48:10b:cafe:225:64ff:febe:589f] (helo=viking.yzserv.com) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VF4K1-000IZ6-JK; Thu, 29 Aug 2013 17:39:46 +0200 Message-ID: <521F6B41.4030704@FreeBSD.org> Date: Thu, 29 Aug 2013 17:39:45 +0200 From: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130813 Thunderbird/17.0.8 MIME-Version: 1.0 To: Alexander Subject: Re: i915kms.ko not loading References: <521E52A6.6040205@gmail.com> <521F1367.8090002@FreeBSD.org> <521F6A52.2060206@gmail.com> In-Reply-To: <521F6A52.2060206@gmail.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2VNNRABJPHQAPTRJIIBCV" Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 29 Aug 2013 15:39:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2VNNRABJPHQAPTRJIIBCV Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 29.08.2013 17:35, Alexander wrote: > in sysctl: > kern.coredump: 1 > kern.corefile: /var/coredumps/%U.%N.%P.core >=20 > but coredump files not created. >=20 > How to set for creating core files? You must add the following line to your /etc/rc.conf: dumpdev=3D"AUTO" Also add this line to your /etc/sysctl.conf: debug.debugger_on_panic=3D0 The core dump is written to the swap device when the crash occurs. During the next boot, it's written to the specified kern.corefile path. --=20 Jean-S=C3=A9bastien P=C3=A9dron ------enig2VNNRABJPHQAPTRJIIBCV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIfa0EACgkQa+xGJsFYOlMtlACeLxs/N1MKx3g8MLnAXBiW682R tRIAn2NJxWI1yNHe7MF/hQh38XGx8PoU =RPHr -----END PGP SIGNATURE----- ------enig2VNNRABJPHQAPTRJIIBCV-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 15:50:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 426E2DE9 for ; Thu, 29 Aug 2013 15:50:22 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 087BD2268 for ; Thu, 29 Aug 2013 15:50:21 +0000 (UTC) Received: by mail-ob0-f173.google.com with SMTP id ta17so664911obb.32 for ; Thu, 29 Aug 2013 08:50:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=WufppyoDJ8zP1DWHkXsFqxaCpMqK9Zlbk5hkFpuDsJQ=; b=EYlfowaNza1ewyf9sVNc0y2/aYP3Ei4jlM4TfhQ0mPZzhXL8dGiBaukqrH1FSLHoZ/ If0RqaTALChv2XgQMeEChUl4Bw7en+W0wgLJ7d/0WAP3z83W9BDgM3Y9YwL6YDfJvwxm YAyU6bbjI4WgpUSymF13PygS9Hw3VAeh+iM4/jrGjFlDrOGisEjJOraw1N1XCj7eAv48 l6Eqg3lhCY6ozeFxjfaGaf2CQGVUPqAYplVilImFa3hj4dDWs7ZzoHpjomC/zZYJvwsk ZXvYNgSZrijUX8ksvW/Yh1m/jH4RHdoO/1UVl4gFfcI5fhYR4NkeXC0RuQS7tjePlJzd 4DQg== X-Gm-Message-State: ALoCoQl98DSHBblNAH8Q/pW0bWsUBpMQL0lUdwDAhilgGpFDAKi420E7zGwjP3BZm2f2jn60YoLu X-Received: by 10.182.48.194 with SMTP id o2mr2259927obn.90.1377791415343; Thu, 29 Aug 2013 08:50:15 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id r3sm33040857oep.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Aug 2013 08:50:14 -0700 (PDT) Sender: Warner Losh Subject: Re: Why are cardbus drivers cbb(4) and pccard(4) still included in GENERIC? Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <201308291054.02641.jhb@freebsd.org> Date: Thu, 29 Aug 2013 09:50:11 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201308291054.02641.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1085) Cc: Adrian Chadd , "freebsd-stable@freebsd.org" , Kimmo Paasiala , freebsd-current@freebsd.org, freebsd-hardware@freebsd.org, Warner Losh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 29 Aug 2013 15:50:22 -0000 On Aug 29, 2013, at 8:54 AM, John Baldwin wrote: > On Thursday, August 29, 2013 6:56:53 am Adrian Chadd wrote: >> Hm! Are they dynamically loaded if you insert the cards? >>=20 >> (Ie, has devd been taught about them as appropriate?) >=20 > These are drivers for the bridges, not for cards you plug into the = bridges. =20 > If you autoloaded them at all you would load them during boot when you = saw an=20 > appropriate PCI device. Currently we don't autoload any PCI drivers, = so I=20 > don't think that should be a blocker for taking these out of GENERIC. >=20 > Warner is probably the best person to ask. We don't autoload them. The bridge code is tiny and can easily be = removed if you want to create a custom kernel. There's still plenty of = laptops that would be crippled if these were removed. Other drivers that = are even more obsolete that are still in GENERIC: esp sym trm adv adw aic bt asr ciss iir ida de cas dc gem hme nfe nve pcn (although many VM env like this) rl fs sis tl tx vr wb xl cs ed ex ep fe sn xe an wi urio uipaq aue cue kue rue So asking why cbb and cardbus are still there seems a little silly to = me. The basic problem is that our PCI and USB infrastructure doesn't include = the basic information necessarily to properly look at a directory of .ko = files and know what to autoload when it finds an unmatched device. PC = Card could easily do this, but doesn't (I have some doodles from a few = years ago that would put this stuff into an elf section that could (a) = be unloaded after probe (optionally) and (b) be read by automatic tools = to load just what's needed). USB is a lot closer than PCI, which is why = Hans' scripts work well enough to create uber-ugly devd config files. Rather than shooting randomly, perhaps some investigation about this = topic would be in order. We've talked it to death, but nobody has had = the time to STFU and implement something reasonable. Warner= From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 15:53:05 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C8371140 for ; Thu, 29 Aug 2013 15:53:05 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com [209.85.214.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8DC6F22ED for ; Thu, 29 Aug 2013 15:53:05 +0000 (UTC) Received: by mail-ob0-f178.google.com with SMTP id ef5so678169obb.9 for ; Thu, 29 Aug 2013 08:52:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=bMxC8CwjEN6j179q/GnMvngnd3tZDL1HNqhw0gxmGQ4=; b=ilqut2RenX+z9no28bPMZ8c+I/I5HmNRBoBE89rw9sn7H8P2KgHMt2YdYoWewomCmB C7NQ3Bs10Uyf+KiPnBi/9tnZMjg1KHPLX8arqIyddp4mja7nYvwyAs2Jl9bJlv+/bf/n epe4O2/X3gC4CjOye4dCXLrhc0bAz7czHxQENteCi7XPTgVZTo+In+vn7pXSsI9xICQ7 4E4UY/mf9iwfT9qdVGHcUsLY25kRojaZPzGY3cIvwFIZhU+b2P/0ZVHnDO3l/ATnKTQ8 9iwzk0/KzokNzVJg0t4owWgei5uM5nwWymhP3sglY6ZVUo0Y5IboM+azlIN6C8xkUdRw qQrQ== X-Gm-Message-State: ALoCoQkrlKGXY4cSTNYLcQA5YW3jsoHmsZ892rI2s0hobxQOtk4g+0GuQtYGfysdfbFlTAhZGF0h X-Received: by 10.182.71.82 with SMTP id s18mr3081962obu.9.1377791579361; Thu, 29 Aug 2013 08:52:59 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id rl1sm33101341oeb.7.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Aug 2013 08:52:58 -0700 (PDT) Sender: Warner Losh Subject: Re: Why are cardbus drivers cbb(4) and pccard(4) still included in GENERIC? Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Thu, 29 Aug 2013 09:52:56 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <92E50FD0-1A1D-4CD2-AB73-11D1F189D12D@bsdimp.com> References: To: Kimmo Paasiala X-Mailer: Apple Mail (2.1085) Cc: FreeBSD current , "freebsd-stable@freebsd.org" , freebsd-hardware@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 29 Aug 2013 15:53:05 -0000 On Aug 29, 2013, at 3:15 AM, Kimmo Paasiala wrote: > In reference to this FreeBSD forums post: >=20 > http://forums.freebsd.org/showpost.php?p=3D231135&postcount=3D4 >=20 > Would it be a good time to remove those from GENERIC since the > hardware they are for is becoming so seriously outdated? >=20 > There's always an option to load those drivers as modules if needed. No. It is not a good time to remove them. They aren't as out-dated as = you might think, and there's literally dozens of other devices in = GENERIC that have even less use today... Warner From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 15:59:54 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2EC0F969 for ; Thu, 29 Aug 2013 15:59:54 +0000 (UTC) (envelope-from bsd-src@helfman.org) Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0AFBD2378 for ; Thu, 29 Aug 2013 15:59:53 +0000 (UTC) Received: by mail-pb0-f43.google.com with SMTP id md4so636235pbc.30 for ; Thu, 29 Aug 2013 08:59:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:content-type; bh=U79thKBupuTDohUj1GNUivJqYbgKTx0U8Q/1vXSaMNs=; b=XNQH1/WiDBkukOaQocmCisDcI9VMAa2CrAc6M8XsTegEOA2JpkXmLcDT2gZnzg0Ogt /36jr29uBg6sHi8EXHfUC1v5jImV4Ai/rYpT+vfCGOi+jwZNHsZyJXQ3TS6gR7cdn/n+ Srq7ZshCjy5k4S0WMfu850+n3ViM6PhkzxyTomf74445xO1Ywgcwc/TOeB3/fxlr18mL WQ7HxAsDaQkh6hZ3enhYJxsufUVi9yrhQUHwXCPeYqbPe7Iab8Pq/lODoa1TEc7Cdj+J Bu776Rw6B/o6IiUimhGDQX7Um4wow+DcOJPYZgjIK6B7Dqz4uxro1z/pKrBYyk5PiMsZ l5+Q== X-Gm-Message-State: ALoCoQlHFzNFH4HqQ/OvS2t68wT2IMtAWOzHFfbLwofU0bxIJivEGn45MKsZ/6vUIAkYliZrNafd MIME-Version: 1.0 X-Received: by 10.66.178.143 with SMTP id cy15mr5285602pac.105.1377791993430; Thu, 29 Aug 2013 08:59:53 -0700 (PDT) Sender: bsd-src@helfman.org Received: by 10.70.100.165 with HTTP; Thu, 29 Aug 2013 08:59:53 -0700 (PDT) Date: Thu, 29 Aug 2013 08:59:53 -0700 X-Google-Sender-Auth: xwgoL2hw1GBnN6bdfPmk2gAhBuk Message-ID: Subject: RAND_MAX issue? From: Jason Helfman To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 29 Aug 2013 15:59:54 -0000 Hello All, I am working on trying to resolve a build issue with devel/libvirt, and posted to the libvirt mailing list, and received this feedback. Please read this thread, and if you have any thoughts I would be interested in any resolution. Here is a link to the thread: https://www.redhat.com/archives/libvir-list/2013-August/msg01544.html Thanks! -jgh -- Jason Helfman | FreeBSD Committer jgh@FreeBSD.org | http://people.freebsd.org/~jgh | The Power to Serve From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 16:00:24 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DB716A85 for ; Thu, 29 Aug 2013 16:00:23 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A08482392 for ; Thu, 29 Aug 2013 16:00:23 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id h1so813114oag.24 for ; Thu, 29 Aug 2013 09:00:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=/UhBaMQzsCkEvg6hrbtdN7tsQsTKlvYHTJTlzZ5a2Bk=; b=e5UM1PQjKMBumMHcHZ0+8qgGmpXbwOXak3h09NqqhlmSZgNnAQ23m/iiH6kT5ePNjb upuGRFcPNLMvMLW0rbmf7TKb4oQgFzRJIyUP7ZcOEcXK7nCs2PW1+NN5ZpKz26TxZFCl xBAc5DvkYiOT6FKh9g84+d54OYqwx34YSiIyPYZEfH+XFsJVfFplPxb6R2xE4dN1yeRr 7eo/0sefPvhdMHA+rYagbUyMsriXuNiQtyr7y2+q+yzZC7Lcy/P1V4NV0h2p1aKhies8 mcadHs7sIBuLOaaLl4fxoI7aR2/9RIcBkip5kzw7SCJuCcWjCBIbtbgmC0RB6ZgpKIaz /m4w== X-Gm-Message-State: ALoCoQlzi6+FjotG3jBfCYClO4KMZ6X5bmq4nqMpkacJJ2o3xmYbljFTLxBJMwylZu8hFCwjLFXP X-Received: by 10.60.70.134 with SMTP id m6mr3060094oeu.14.1377792022904; Thu, 29 Aug 2013 09:00:22 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id tz10sm32053985obc.10.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Aug 2013 09:00:22 -0700 (PDT) Sender: Warner Losh Subject: Re: GCC withdraw Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <201308291057.43027.jhb@freebsd.org> Date: Thu, 29 Aug 2013 10:00:19 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1085) Cc: FreeBSD Current , David Chisnall , toolchain@freebsd.org, freebsd-current@freebsd.org, "Sam Fourman Jr." , Boris Samorodov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 29 Aug 2013 16:00:24 -0000 On Aug 29, 2013, at 8:57 AM, John Baldwin wrote: > On Saturday, August 24, 2013 7:19:22 am David Chisnall wrote: >> On 24 Aug 2013, at 11:30, "Sam Fourman Jr." = wrote: >>=20 >>> So I vote, let's not give ourselves the burden of "lugging" dead = weight in >>> base >>> for another 5 years. (in 2017 do we still want to be worrying about = gcc in >>> base?) >>=20 >> Perhaps more to the point, in 2017 do we want to be responsible for >> maintaining a fork of a 2007 release of gcc and libstdc++? >=20 > This is a red herring and I'd wish you'd stop bringing it up = constantly. > GCC has not needed constant care and feeding in the 7.x/8.x/9.x = branches > and it won't need it in 10.x either. I have not seen any convincing > argument as to why leaving GCC in the base for 10.x impedes anything. > Because clang isn't sufficient for so many non-x86 platforms we can't > really start using clang-specific features yet anyway. Agreed. Gcc is still an absolute requirement on all non-x86 platforms = (including arm) due to the issues with clang. Some of these issues are = bugs in specific things (arm) that keep coming up (and keep getting = fixed), while others are more severe (sparc64 has no clang support, and = no way to generate a self-hosting system in the absence of a bootstrap = gcc in the base, even with the external toolchain support). gcc will absolutely be in the base for 10. That's the long-standing = agreement that we've had, and breaking it now at the 11th hour is going = to totally screw up !x86 platforms and really piss off a lot of = developers for no good reason. The time is long since past to change = this plan. This is the plan of record, and we need to stick to it: 10: clang default, where possible, gcc in base otherwise 11: clang default, full external toolchain support, including = self-hosting So the time for voting and carping has long since past. Warner= From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 16:01:34 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C9B47BB2 for ; Thu, 29 Aug 2013 16:01:34 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [64.147.113.26]) by mx1.freebsd.org (Postfix) with ESMTP id A2E6223D7 for ; Thu, 29 Aug 2013 16:01:34 +0000 (UTC) Received: from acm.poly.edu (localhost [127.0.0.1]) by acm.poly.edu (Postfix) with ESMTP id 8547D1F13AF for ; Thu, 29 Aug 2013 11:56:05 -0400 (EDT) Received: (qmail 38558 invoked from network); 29 Aug 2013 15:56:05 -0000 Received: from unknown (HELO ?10.50.50.212?) (spawk@64.147.100.2) by acm.poly.edu with CAMELLIA256-SHA encrypted SMTP; 29 Aug 2013 15:56:05 -0000 Message-ID: <521F6F4A.2080107@acm.poly.edu> Date: Thu, 29 Aug 2013 11:56:58 -0400 From: Boris Kochergin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130828 Thunderbird/17.0.8 MIME-Version: 1.0 Subject: Re: Why are cardbus drivers cbb(4) and pccard(4) still included in GENERIC? References: <92E50FD0-1A1D-4CD2-AB73-11D1F189D12D@bsdimp.com> In-Reply-To: <92E50FD0-1A1D-4CD2-AB73-11D1F189D12D@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD current , "freebsd-stable@freebsd.org" , freebsd-hardware@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 29 Aug 2013 16:01:34 -0000 On 08/29/13 11:52, Warner Losh wrote: > On Aug 29, 2013, at 3:15 AM, Kimmo Paasiala wrote: > >> In reference to this FreeBSD forums post: >> >> http://forums.freebsd.org/showpost.php?p=231135&postcount=4 >> >> Would it be a good time to remove those from GENERIC since the >> hardware they are for is becoming so seriously outdated? >> >> There's always an option to load those drivers as modules if needed. > No. It is not a good time to remove them. They aren't as out-dated as you might think, and there's literally dozens of other devices in GENERIC that have even less use today... > > Warner > Just thought I'd be a statistic and speak up to say that I am happily using the PCMCIA drivers on multiple 9.x/i386 machines, and plan to continue doing so through 10.x. -Boris From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 16:02:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E36A8E26; Thu, 29 Aug 2013 16:02:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B1B0E23FE; Thu, 29 Aug 2013 16:02:20 +0000 (UTC) Received: from jhbbsd.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7183BB924; Thu, 29 Aug 2013 12:02:19 -0400 (EDT) From: John Baldwin To: Scott Long Subject: Re: [rfc] migrate lagg to an rmlock Date: Thu, 29 Aug 2013 12:01:03 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <201308291042.13282.jhb@freebsd.org> <41614148-3900-4FE0-88AC-40F10DAE2030@yahoo.com> In-Reply-To: <41614148-3900-4FE0-88AC-40F10DAE2030@yahoo.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201308291201.04131.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 29 Aug 2013 12:02:19 -0400 (EDT) Cc: FreeBSD Net , Adrian Chadd , freebsd-current@freebsd.org, Robert Watson , "Alexander V. Chernikov" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 29 Aug 2013 16:02:21 -0000 On Thursday, August 29, 2013 11:37:08 am Scott Long wrote: > > On Aug 29, 2013, at 7:42 AM, John Baldwin wrote: > > > On Saturday, August 24, 2013 10:16:33 am Robert Watson wrote: > >> There are a number of other places in the kernel where migration to an rmlock > >> makes sense -- however, some care must be taken for four reasons: (1) while > >> read locks don't experience line contention, write locking becomes observably > >> e.g., rmlocks might not be suitable for tcbinfo; (2) rmlocks, unlike rwlocks, > >> more expensive so is not suitable for all rwlock line contention spots -- > >> implement reader priority propagation, so you must reason about; and (3) > >> historically, rmlocks have not fully implemented WITNESS so you may get less > >> good debugging output. if_lagg is a nice place to use rmlocks, as > >> reconfigurations are very rare, and it's really all about long-term data > >> stability. > > > > 3) should no longer be an issue. rmlocks now have full WITNESS and assertion > > support (including an rm_assert). > > > > However, one thing to consider is that rmlocks pin readers to CPUs while the > > read lock is held (which rwlocks do not do). > > And this is not a problem for the application that we're giving it in the > lagg driver. That is likely true. I was merely tweaking Robert's general guidelines re: rmlock. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 16:02:58 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AF689FD2 for ; Thu, 29 Aug 2013 16:02:58 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com [209.85.214.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 74677241D for ; Thu, 29 Aug 2013 16:02:58 +0000 (UTC) Received: by mail-ob0-f178.google.com with SMTP id ef5so679022obb.37 for ; Thu, 29 Aug 2013 09:02:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=9z81+8ESM1A0yIrLB6HtD0tcWXlCC0WMjaAf8JBlLMI=; b=bTAbbZP0X7tdIvr8sFsgErT+m24yEF7SlZIxFrCib9LzUNSxULq3iECWGqsuONIeZ7 NXo3+RcRz6KjV5jL/HvQg4PWgqfST+wIO6ZRcFgUZMVkWJSckW5oKM4MpGl2tXqUvyOM UKyvspbRMV4W398gGcjIaLrKCYDXXcyE7Q8z3jzGMUOxFM3Xr8Uk05Ftb4X4WOZKpC0g /oVsxNcnV0Q3QMYgkk/2SpfnEtoxZZpQ4DvnrpSjvDgVUNNEuTsSyiUJPXtIiPu/ng/E tTva4Sm5QWd5FKblWCJfLNQo9WZ5kNgJ3M1WR3u0QXYQ8wLmbk/AfnJzh045nSmhc2pP vm7A== X-Gm-Message-State: ALoCoQlUJG6jAWfXi2rTG0eZKjSWqYdXxUypVA4SOAqPFJYcHLUkQ0HVRaWJNJcr8wW+0wGizj4I X-Received: by 10.60.38.164 with SMTP id h4mr3075747oek.22.1377792177616; Thu, 29 Aug 2013 09:02:57 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id r3sm33102972oep.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Aug 2013 09:02:56 -0700 (PDT) Sender: Warner Losh Subject: Re: patch to add AES intrinsics to gcc Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <521CBBDE.6030503@freebsd.org> Date: Thu, 29 Aug 2013 10:02:54 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <521751AF.6040905@gmail.com> <521CBBDE.6030503@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1085) Cc: Gerald Pfeifer , current@freebsd.org, Volodymyr Kostyrko , toolchain@freebsd.org, =?iso-8859-1?Q?Bernhard_Fr=F6hlich?= , John-Mark Gurney X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 29 Aug 2013 16:02:58 -0000 On Aug 27, 2013, at 8:46 AM, Nathan Whitehorn wrote: > On 08/25/13 18:41, Gerald Pfeifer wrote: >> On Fri, 23 Aug 2013, Volodymyr Kostyrko wrote: >>> I object. Many ports that compiles perfectly on gcc 4.2.1 can't be=20= >>> compiled with lang/gcc. I checked this once and the number of ports=20= >>> that require strictly gcc 4.2.1 was bigger for me then number of=20 >>> ports that can't be compiled with clang but fill fine on lang/gcc. >>>=20 >>> I'll gonna recheck whether lang/gcc42 is sufficient for them. But I=20= >>> have that bad feeling... >> If there are ports that use USE_GCC=3Dany and do not build with >> lang/gcc, these should have USE_GCC=3D4.2 -- without a '+'! -- >> not USE_GCC=3Dany. >>=20 >> It'll be great if you can fix any such port. >=20 > It would be particularly nice if we had a port with FreeBSD's many > patches to 4.2. lang/gcc42 (and 46 and lang/gcc) do not build on > powerpc64, for example, while our in-tree GCC does. I think it would be more than "nice" to have. I'd argue that these = issues need to be addressed before we can claim to have a full = external-supported toolchain story that's integrated and well tested and = covers the needs of all our users. Warner From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 16:14:27 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A5BCB535; Thu, 29 Aug 2013 16:14:27 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1CE0624EE; Thu, 29 Aug 2013 16:14:27 +0000 (UTC) Received: by mail-qa0-f53.google.com with SMTP id i13so539102qae.19 for ; Thu, 29 Aug 2013 09:14:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=L755AofcUINNwdxYuM3P7OrUWkb8ecn/CWRKz+7P1eE=; b=OJ3CWTjDph/7o+XBsfMQcRKP+IGXAtQnAjUJVliKhbcKINrg7YfiHNDVqtxBHrv08e WGDSorj6bHKR7orVQFsDQj3KRebbZkEP4oklWBwN37DWar+gQfQmUF1vXTFqji5CTbki zdFS1tinuc+1aGlxmRDmhZO98aiQ0C7NwfDizeA5S8Qpy7IaX7wrdxV8tzZMtI57CzoQ doQFT3PTrNExvsgM/gQ5xLyIE5QYStkwLbpW9euYsghuVjWSoomWA+ghQd+m+U2pS02z O14yX+VrxVvAxk8JV2QsSN6ubDhULh7QLuXwmbPpKZBRNHRubZnRa+Xin8IffGhJ+8jw 9XbQ== MIME-Version: 1.0 X-Received: by 10.49.127.179 with SMTP id nh19mr4916627qeb.1.1377792866287; Thu, 29 Aug 2013 09:14:26 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.128.70 with HTTP; Thu, 29 Aug 2013 09:14:26 -0700 (PDT) In-Reply-To: References: <201308291054.02641.jhb@freebsd.org> Date: Thu, 29 Aug 2013 09:14:26 -0700 X-Google-Sender-Auth: 2jwJQpWQp_0eUlmzVO7urAFul0o Message-ID: Subject: Re: Why are cardbus drivers cbb(4) and pccard(4) still included in GENERIC? From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-stable@freebsd.org" , Kimmo Paasiala , freebsd-current , freebsd-hardware@freebsd.org, Warner Losh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 29 Aug 2013 16:14:27 -0000 .. after tinkering in the USB world, i wonder what's wrong with this: * created a basic markup / description language to encapsulate what PCI/USB probing requires; * generated both config files _and_ .c / .h files for drivers to include; * have the kernel build process do .device_description -> .c/.h (for compiling) ; devd.conf (for runtime loading); an elf section if you'd like; and loader-mumble.conf (for loader autoloading.) -adrian From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 16:26:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 946EABE7; Thu, 29 Aug 2013 16:26:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 64C6525E3; Thu, 29 Aug 2013 16:26:56 +0000 (UTC) Received: from jhbbsd.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 201E6B93B; Thu, 29 Aug 2013 12:26:55 -0400 (EDT) From: John Baldwin To: Davide Italiano Subject: Re: Question about socket timeouts Date: Thu, 29 Aug 2013 12:03:22 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <201308261505.06342.jhb@freebsd.org> In-Reply-To: <201308261505.06342.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201308291203.23055.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 29 Aug 2013 12:26:55 -0400 (EDT) Cc: Vitja Makarov , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 29 Aug 2013 16:26:56 -0000 On Monday, August 26, 2013 3:05:06 pm John Baldwin wrote: > On Monday, August 26, 2013 2:23:44 pm Davide Italiano wrote: > > Please consider the following patch: > > http://people.freebsd.org/~davide/review/socket_timeout.diff > > I've tested it and it works OK. I got a timeout which is ~= 25ms using > > the testcase provided by the user. > > The only doubt I have is about the range check, I've changed a bit > > because the 'integer' part of sbintime_t fits in 32-bits, but I'm not > > sure it's the best way of doing this. > > Nice! Bruce actually wants me to adjust the range check a bit (which will > fit in well with your changes I think). Please let me get that fix in > (so it can be part of the future MFC) and then you can commit this. Thanks! > > Actually, I think you still need to patch the sogetopt() case to work correctly > (it is still doing a manual conversion from 'val' to a timeval assuming it is > in 'hz' units). I'm done with my range check changes, please move forward with your change (though make sure you fix the sogetsockopt() case please). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 16:57:27 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D0AEF9DA for ; Thu, 29 Aug 2013 16:57:27 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9468D27FF for ; Thu, 29 Aug 2013 16:57:27 +0000 (UTC) Received: by mail-oa0-f50.google.com with SMTP id i4so952536oah.9 for ; Thu, 29 Aug 2013 09:57:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ud05ZE5HwalOMowLinY+f8RHwPh/eJtN+7YBkb2y0YA=; b=IuPiqxmj8lG28X0qP3N4qytYBImNh5rgQsA1YAM7MN5V3UK2WZT/ofRvJGeBq/rb4z Cx27k3K9AWHjx6NfPmK98qNEUIJcfkcq3iEAnewjLlgPStD9b/jXjuGJhtr4PO8UJRrl LXCtBb9qJYEIXAejW73XgsmGZmvFuWmFbov+AuaFU7k68IDQVBllQggCITiEwYTJHpaI m94BSZI4nLzfwFbRrUkEWSfpKsjsrIELvKbLW3UbOFjO+QrPZNN+xQXockDMnNbgFU3k yHQC+Zcr0+cfgT9qlaId82BsWUykWCxdo65z0H1owMWDfFCOMt4fnsCCSKrBhsMrEjLt wmMg== X-Gm-Message-State: ALoCoQnPAzNl3g+5NhhueHVCoSYauuLLxuLoY5iCCgc/V3jRk/8VHA+EpE8v+1gHHwRvdsRzpAPQ X-Received: by 10.60.115.226 with SMTP id jr2mr626422oeb.95.1377795441506; Thu, 29 Aug 2013 09:57:21 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id hl3sm32302657obb.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Aug 2013 09:57:20 -0700 (PDT) Sender: Warner Losh Subject: Re: GCC withdraw Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1377440469.1111.124.camel@revolution.hippie.lan> Date: Thu, 29 Aug 2013 10:57:18 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9B13FF68-35F4-4A7C-8AD3-F72BA28718E8@bsdimp.com> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> <20130824115158.GA88999@zxy.spb.ru> <20130824154217.GE3796@zxy.spb.ru> <20130824224204.GH3796@zxy.spb.ru> <1377440469.1111.124.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) Cc: FreeBSD Current , David Chisnall , toolchain@FreeBSD.org, Slawa Olhovchenkov , "Sam Fourman Jr." , Boris Samorodov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 29 Aug 2013 16:57:27 -0000 On Aug 25, 2013, at 8:21 AM, Ian Lepore wrote: > On Sat, 2013-08-24 at 23:44 +0100, David Chisnall wrote: >> On 24 Aug 2013, at 23:42, Slawa Olhovchenkov wrote: >>=20 >>> And i found PR about clang and mplayer: ports/176272 >>> This PR contains log with build error log. >>=20 >> Please file clang bugs at http://llvm.org/bugs/ >>=20 >> David > And THIS is a major reason why FreeBSD needs a compiler in base = instead > of all tools being ports. The last thing we need is to start = responding > to every problem with "this is not my problem, go file a report > upstream." If we're already doing it for the compiler that's supposed > to be the new supported tool, how much worse will peoples' experience = be > when we assert no ownership or responsibility for a toolchain at all? Especially when the external toolchain support is far from well = integrated, is lacking key features and needs much documentation on what = is there. One of the huge draws to FreeBSD is that you don't have to play = whack-a-mole with gcc/binutils/libc/etc. I'd sure hate to lose that. Warner From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 17:02:16 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 84270DD3; Thu, 29 Aug 2013 17:02:16 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3D567285F; Thu, 29 Aug 2013 17:02:15 +0000 (UTC) Received: from [192.168.0.2] (cpc27-cmbg15-2-0-cust235.5-4.cable.virginmedia.com [86.27.188.236]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r7TH2CeY002055 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Aug 2013 17:02:13 GMT (envelope-from theraven@FreeBSD.org) Content-Type: multipart/signed; boundary="Apple-Mail=_978AE49C-F592-44BA-A78D-AD85AE5E0E9A"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: GCC withdraw From: David Chisnall In-Reply-To: <201308291057.43027.jhb@freebsd.org> Date: Thu, 29 Aug 2013 18:02:06 +0100 Message-Id: <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1508) Cc: "Sam Fourman Jr." , toolchain@FreeBSD.org, "freebsd-current@freebsd.org CURRENT" , Boris Samorodov , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 29 Aug 2013 17:02:16 -0000 --Apple-Mail=_978AE49C-F592-44BA-A78D-AD85AE5E0E9A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 29 Aug 2013, at 15:57, John Baldwin wrote: > I have not seen any convincing > argument as to why leaving GCC in the base for 10.x impedes anything. > Because clang isn't sufficient for so many non-x86 platforms we can't > really start using clang-specific features yet anyway. Apparently I haven't been good at communicating, so I'll try to here. I = apologise for ignoring this thread for the last week: I've been rather = busy organising the DevSummit. The notes for the sessions will be = posted to various mailing lists soon (and summarised for a special = status report), but since the ports and toolchain build sessions are = already largely up you can check these on the wiki. You'll notice that = in both sessions the topic of removing gcc / libstdc++ was raised and = there was no objection (not sure if it's in the notes, but there was a = lot of support during the ports session from people who didn't want the = pain of maintaining compatibility with gcc-in-base, and especially with = g++/libstdc++ in base). =20 This is not a new plan, it is the plan that has been on the wiki and = discussed at at least two DevSummits that I have attended before this = week and probably others that I missed, as well as on various mailing = lists and in IRC. =20 To summarise the current issues: Our libstdc++ is ancient. It supports C++98 well, it kind-of supports = C++03. It doesn't support C++11 at all and never will, nor does it = support C++14. An increasing number of ports are depending on C++11, = because it provides much cleaner syntax than C++98 and so these are = being forced to depend on gcc46 or gcc47 to build. Unfortunately, = libstdc++ in ports is not ABI compatible with the libstdc++ that we = ship, which causes library ABI versions. This problem will only get = worse over the coming years. An increasing number of these ports do = build with libc++ (since it's the only option on OS X / iOS - most do = already and most of the fixes needed are just adding some inclusions = since libc++ doesn't leak C headers as much as libstdc++), so defaulting = to libc++ will reduce these problems over time. =20 Maintaining our libstdc++ is not a zero-effort operation. We have to = modify it whenever libc gains new features (e.g. POSIX2008 locales, new = libm functions) and this requires developer time tracking down the new = bugs (because the static configuration files no longer match the = included headers) and fixing them. Maintaining out gcc is also not a zero-effort operation. Even though it = is not the default compiler for amd64 or i386, we still have to add = support for new instructions to them, even if we only want to use them = in machine-dependent code on these architecture. =20 Our g++ in base can only work with libstdc++, not libc++. This means = that shipping gcc in 10.0 in base means that we'd be shipping two C++ = compilers, which preferred different standard libraries, with = incompatible ABIs. This is setting us up for a world of pain. When we enable LLDB during the 10.x timeframe (emaste has been working = hard, but it's probably not quite ready for 10.0), it will have to link = against both LLVM libraries and libc++ (as it uses C++11 and doesn't = work with our libc++). This is a minor issue, as the only requirement = here is that we switch to linking LLVM against libc++ instead of = libstdc++, but it is an example of one more piece of code that won't = build with our gcc that is in the base system (not yet enabled by = default). Clang 3.4 will not build with our gcc either (which will = cause some bootstrapping problems that we'll have to address for people = going from 9.x to 10.1, but the clang 3.3 in 9.2 should be useable as = long as we tweak the build system to use clang and not cc for the = bootstrap build). Lots of configure scripts will use gcc in preference to cc (or g++ in = preference to c++) if they find them in the same place. Many of these = no longer work with our old gcc, but do work with clang, adding more = effort to ports. According to the test runs that bapt did at the = DevSummit this week, we have more ports failing on 10 with gcc than on = 10 with gcc removed. Our gcc does not support the ARM EABI hard float variant. I misspoke = earlier when I thought it didn't support EABI at all, but it turns out = that it's only the case for hard-float. This is the ABI that we want to = be using on pretty much all ARMv6 and newer systems, because a lot of = ARM cores (such as the Cortex A8 in the Efika MX that the Foundation has = paid for FreeBSD to be ported on to use as a demo ARM device) require a = complete pipeline flush when moving between integer and floating point = registers and the soft-float variant of the ABI puts all arguments in = integer registers. This means that a simple function that takes a = rectangle (4 floating point values) as an argument will require 8 = pipeline flushes to call, which various Linux distributions have found = is crippling for graphical applications. =20 We want to start shipping binary packages for ARMv6. At the moment, = i386, amd64, and ARMv6 are the only architectures where you can get = cheap, off-the-shelf, hardware that looks enough like a normal computer = that you'd expect to be able to use a stock install, and so they are the = only platforms where the default build configuration makes a difference. = For all of these preferences, clang is the default and there is no = reason to prefer our gcc: if you actually want to use gcc (e.g. if you = care about the C99 floating point craziness, or you have OpenMP code to = build) then one of the gcc versions in ports will give you much better = code (and better error reporting). =20 Unlike clang, gcc is not intrinsically a cross compiler. This means = that if you are targeting a non-x86, non-ARM architecture then you are = already building a cross-gcc to use as part of your bootstrap process = and so not having the x86-only gcc on your host system does not cost you = anything. As someone who spends day-job time working on FreeBSD/MIPS, = I've never found the need to use the installed base-gcc (my life would = be much happier if we had some nice infrastructure for building packages = of the MIPS toolchain, headers, and shared libraries, but that's an = unrelated issue). =20 The tinderboxes will prevent any gcc-incompatible code from appearing in = the MI bits of the kernel. Optional parts of the userland can slowly = migrate to supporting newer language features. =20 Last but not quite least, people keep complaining about ever-increasing = build times and the size of the base system. Building a gcc and = libstdc++ by default every time, that we're telling people not to use, = won't help with that... I have not heard any compelling arguments for keeping gcc and libstdc++ = as part of the default install on x86, and I have listed a number of = reasons why doing so creates extra work for people who maintain the = toolchain and who work on ports. I intend to commit the change to = remove both from the default build and make libc++ the default STL for = clang++ as soon as I get an okay from bapt. =20 David --Apple-Mail=_978AE49C-F592-44BA-A78D-AD85AE5E0E9A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJSH36PAAoJEKx65DEEsqIdb7YQAJoGYPQdMLAPwhHHrLa3Rvl5 efXPgzzMs5vgVjLi3xd3PFy7jDJVeG9SoGOc+BhnC5mWM12aa6vtP21krogCHlkt O59ApLiPE0orcLcNQYgdqxGZmoKCGRHYrGtCd6Ztvp3pKfcgwmXPJ47VPRjntIDN TvFNNEO2GnKiHUpOZZVw5g6kYcQT6lz9gigjNzW2k/662T0quoiJSGwNW6wsf9Is NQDSxGh4SVPGrtAvShY6FW31a0iWyAn42q7TmIA9tgjQIiLVFn3MG4ijWDp2YDXV dIJe6SaC+YmRy5Y2ajf9lraKRB3eZaquUhT2VzWvTx3hbDh5ng+Wat81UuEC04KI 1srCjkkHRgV+U7PPD+sjz9FUxXdpaevpcn35WepOsKqF2M/j31tg1qeB+oIaovPM SDEgaR50QR9o/LKKFaqSJMnyyzIRdFRK8SiWz8BPFrrWPW79MS5jtH12Nd6nSAcq kIiyqYSMm0ZuuAiPSsVUEY1q0Dd3snajlT5dWrCl7bdSawV26uk/15lGDRiYo9I0 xsZ0oVQn4itkCQ9DS25OwdAR5w5gRy/tmnmIOm1C8YEUBfb+4BHq1YZlmLfAlkBz lvChjb41fnHKcjgJ3nGzk4+BoHelEc46Ggnc9uqMEF2muboeFPazm2gBbc/sAODm bFuhOfRbt4PHMXMNKv+r =zkC2 -----END PGP SIGNATURE----- --Apple-Mail=_978AE49C-F592-44BA-A78D-AD85AE5E0E9A-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 17:09:48 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C4AC43DE for ; Thu, 29 Aug 2013 17:09:48 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 88B4628DC for ; Thu, 29 Aug 2013 17:09:47 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id h1so956753oag.10 for ; Thu, 29 Aug 2013 10:09:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=SJDQgzFwJfs4GkD0feBRAHCot6kR8PbIW029am1uuZw=; b=RM3aiFQ508rkUw/2GGzl4DhrRETdFDrorFeeUCVjBPkm+Q/BVubA4Ovr7tL2F8Z3uN 0j9/RH5z8Z78m2T0FKqgNHmy/beIYkLIJIcr6d4ig0CT/KzIV4lB4X2ziuxgJQl29Pzh G/rAOOvFWx26Jpito0FBbGr/hDKpWOrJSybjqJs+o8RV0bRKmwvw5sVfOS4c+FUMFzST 5j6U49elW9lfUPp+/Rehs0Sie7wkrHVnVCd38xwqCcQKMLShoslEnRVFeIIN4YJsjQuk maubf+1iJ3Eur7Pg5KLf/B5vzOpBewz1iBSbIp2nyizixLfoTI02XZiO4UaNom6rXSUS lw+w== X-Gm-Message-State: ALoCoQkK8TRH4JGAaAMtAkyMoA2BqZvuW7Rgw/R6O0PS+AcMV5NnoJQ0m2AIrJHZxwXpHLMRCoQq X-Received: by 10.60.52.81 with SMTP id r17mr3360989oeo.3.1377795807801; Thu, 29 Aug 2013 10:03:27 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id uz16sm32335159obc.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Aug 2013 10:03:27 -0700 (PDT) Sender: Warner Losh Subject: Re: Why are cardbus drivers cbb(4) and pccard(4) still included in GENERIC? Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Thu, 29 Aug 2013 11:03:24 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <352C0CD1-909B-445A-A1F4-3942D3A3CE3B@bsdimp.com> References: <201308291054.02641.jhb@freebsd.org> To: Adrian Chadd X-Mailer: Apple Mail (2.1085) Cc: "freebsd-stable@freebsd.org" , Kimmo Paasiala , freebsd-current , freebsd-hardware@freebsd.org, Warner Losh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 29 Aug 2013 17:09:48 -0000 On Aug 29, 2013, at 10:14 AM, Adrian Chadd wrote: > .. after tinkering in the USB world, i wonder what's wrong with this: >=20 > * created a basic markup / description language to encapsulate what = PCI/USB probing requires; > * generated both config files _and_ .c / .h files for drivers to = include; > * have the kernel build process do .device_description -> .c/.h (for = compiling) ; devd.conf (for runtime loading); an elf section if you'd = like; and loader-mumble.conf (for loader autoloading.) It is needlessly complex? You seriously don't need 1/10th that = complexity. We've talked about solutions in the past. I even have something that = will automatically do the heavy lifting for compliant drivers (or did = before it decayed). What's needed is for someone to step in and drive it = to completion. Like I said, this has been talked to death at least half a dozen times. Warner From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 17:22:04 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DF1B3AFC for ; Thu, 29 Aug 2013 17:22:03 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A220E29DE for ; Thu, 29 Aug 2013 17:22:03 +0000 (UTC) Received: by mail-ob0-f170.google.com with SMTP id eh20so798579obb.1 for ; Thu, 29 Aug 2013 10:22:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=T1iQD6QrxM9x42tWOEQg+Q8k8Bb52BHKR7Ia+HQYb9I=; b=LNktS+BVGuQLubpjB/mCyBbD1oZ4bmvT06FudErfKEmYc6sap6HOmvFTpFRl8yuL7O ztt5CD9m5EAOMBIzoMvHVC+0vY32fx8czscwqRUy26tf0ucFqywjsjNCjpMrNpbbEhtr IJMF6MDAklwIa9smAPLOENSJaEiNbyiuLhUgHxIrpq6/4PN1JuE0tnxlqbSCGJ6ulXha /xvFysv36MY3R/dd//AOE0dXoWu0NOhnOut4KnD9dFOnRUiFbjxYJOC3ZJ0Rn4+PZv3I rZYs/YnGJDLLDDP3oIfENO81yh1kpDRZIF8CFT8sJ9GpjXavv1BR+uQwGgZbjRvq1Va9 QWWA== X-Gm-Message-State: ALoCoQnhdJB8C/MC1yYmvAkL33QPH7u5u6/GCTaClDePwQ5mDGs0o+D6HguqTAXq9xg4lu+k3nwU X-Received: by 10.60.51.7 with SMTP id g7mr3468744oeo.6.1377796922709; Thu, 29 Aug 2013 10:22:02 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id z5sm32455135obg.13.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Aug 2013 10:22:01 -0700 (PDT) Sender: Warner Losh Subject: Re: GCC withdraw Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> Date: Thu, 29 Aug 2013 11:21:59 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <0678F678-A140-4A69-AF46-EA1C036DAA1A@bsdimp.com> References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> To: David Chisnall X-Mailer: Apple Mail (2.1085) Cc: FreeBSD Current , toolchain@FreeBSD.org, "freebsd-current@freebsd.org CURRENT" , "Sam Fourman Jr." , Boris Samorodov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 29 Aug 2013 17:22:04 -0000 On Aug 29, 2013, at 11:02 AM, David Chisnall wrote: > On 29 Aug 2013, at 15:57, John Baldwin wrote: >=20 >> I have not seen any convincing >> argument as to why leaving GCC in the base for 10.x impedes anything. >> Because clang isn't sufficient for so many non-x86 platforms we can't >> really start using clang-specific features yet anyway. >=20 > Apparently I haven't been good at communicating, so I'll try to here. = I apologise for ignoring this thread for the last week: I've been rather = busy organising the DevSummit. The notes for the sessions will be = posted to various mailing lists soon (and summarised for a special = status report), but since the ports and toolchain build sessions are = already largely up you can check these on the wiki. You'll notice that = in both sessions the topic of removing gcc / libstdc++ was raised and = there was no objection (not sure if it's in the notes, but there was a = lot of support during the ports session from people who didn't want the = pain of maintaining compatibility with gcc-in-base, and especially with = g++/libstdc++ in base). =20 >=20 > This is not a new plan, it is the plan that has been on the wiki and = discussed at at least two DevSummits that I have attended before this = week and probably others that I missed, as well as on various mailing = lists and in IRC. =20 >=20 > To summarise the current issues: >=20 > Our libstdc++ is ancient. It supports C++98 well, it kind-of supports = C++03. It doesn't support C++11 at all and never will, nor does it = support C++14. An increasing number of ports are depending on C++11, = because it provides much cleaner syntax than C++98 and so these are = being forced to depend on gcc46 or gcc47 to build. Unfortunately, = libstdc++ in ports is not ABI compatible with the libstdc++ that we = ship, which causes library ABI versions. This problem will only get = worse over the coming years. An increasing number of these ports do = build with libc++ (since it's the only option on OS X / iOS - most do = already and most of the fixes needed are just adding some inclusions = since libc++ doesn't leak C headers as much as libstdc++), so defaulting = to libc++ will reduce these problems over time. =20 True, but this doesn't cause any problems for gcc, just g++. > Maintaining our libstdc++ is not a zero-effort operation. We have to = modify it whenever libc gains new features (e.g. POSIX2008 locales, new = libm functions) and this requires developer time tracking down the new = bugs (because the static configuration files no longer match the = included headers) and fixing them. Fair enough, but the number of these has been, to date, quite small. > Maintaining out gcc is also not a zero-effort operation. Even though = it is not the default compiler for amd64 or i386, we still have to add = support for new instructions to them, even if we only want to use them = in machine-dependent code on these architecture. =20 It actually is close to zero effort. The effort level is quite small, as = evidence by the small number of commits to gcc over time. Not zero, but = not as huge a deal as you make it out to be. However, we still need to make the efforts so long as it is part of the = base. > Our g++ in base can only work with libstdc++, not libc++. This means = that shipping gcc in 10.0 in base means that we'd be shipping two C++ = compilers, which preferred different standard libraries, with = incompatible ABIs. This is setting us up for a world of pain. This is a legitimate issue, for g++, not for gcc. But on !x86 targets = we'll need to continue to do this. > When we enable LLDB during the 10.x timeframe (emaste has been working = hard, but it's probably not quite ready for 10.0), it will have to link = against both LLVM libraries and libc++ (as it uses C++11 and doesn't = work with our libc++). This is a minor issue, as the only requirement = here is that we switch to linking LLVM against libc++ instead of = libstdc++, but it is an example of one more piece of code that won't = build with our gcc that is in the base system (not yet enabled by = default). Clang 3.4 will not build with our gcc either (which will = cause some bootstrapping problems that we'll have to address for people = going from 9.x to 10.1, but the clang 3.3 in 9.2 should be useable as = long as we tweak the build system to use clang and not cc for the = bootstrap build). Seems more like an issue for 11 not 10. Also, we need to be able to bootstrap the base tools with gcc, since = that's been the fallback bootstrap method for some time for people = upgrading from really old systems: build the system with clang disabled = the first time, and then use that to bootstrap clang since the gcc there = can build it. I'd hate to loose this fallback plan, but do recognize at = some point we must. > Lots of configure scripts will use gcc in preference to cc (or g++ in = preference to c++) if they find them in the same place. Many of these = no longer work with our old gcc, but do work with clang, adding more = effort to ports. According to the test runs that bapt did at the = DevSummit this week, we have more ports failing on 10 with gcc than on = 10 with gcc removed. Won't this still be an issue for !x86? > Our gcc does not support the ARM EABI hard float variant. I misspoke = earlier when I thought it didn't support EABI at all, but it turns out = that it's only the case for hard-float. This is the ABI that we want to = be using on pretty much all ARMv6 and newer systems, because a lot of = ARM cores (such as the Cortex A8 in the Efika MX that the Foundation has = paid for FreeBSD to be ported on to use as a demo ARM device) require a = complete pipeline flush when moving between integer and floating point = registers and the soft-float variant of the ABI puts all arguments in = integer registers. This means that a simple function that takes a = rectangle (4 floating point values) as an argument will require 8 = pipeline flushes to call, which various Linux distributions have found = is crippling for graphical applications. =20 True, but we're using it now for EABI w/o issue except for doing soft = floats. Yes, this is a problem, but we don't have all the infrastructure = in place to do hard floating point yet. So absent the required = infrastructure to do hard float, this point shouldn't have much weight. = What we do on ARM has no bearing on x86 anyway. So this is more of an interesting side note for future effort that has = no bearing at all on the issue at hand. > We want to start shipping binary packages for ARMv6. At the moment, = i386, amd64, and ARMv6 are the only architectures where you can get = cheap, off-the-shelf, hardware that looks enough like a normal computer = that you'd expect to be able to use a stock install, and so they are the = only platforms where the default build configuration makes a difference. = For all of these preferences, clang is the default and there is no = reason to prefer our gcc: if you actually want to use gcc (e.g. if you = care about the C99 floating point craziness, or you have OpenMP code to = build) then one of the gcc versions in ports will give you much better = code (and better error reporting). =20 clang generates good code on the ARM, but we still keep hitting issues = on the arm with it that go away when gcc is used. This argument, though = is not an argument for why gcc shouldn't be built, but rather why clang = should be default. Again, not relevant to the issues at hand. We've had = enough problems on arm that we must continue to have gcc easily and = readily available. > Unlike clang, gcc is not intrinsically a cross compiler. This means = that if you are targeting a non-x86, non-ARM architecture then you are = already building a cross-gcc to use as part of your bootstrap process = and so not having the x86-only gcc on your host system does not cost you = anything. As someone who spends day-job time working on FreeBSD/MIPS, = I've never found the need to use the installed base-gcc (my life would = be much happier if we had some nice infrastructure for building packages = of the MIPS toolchain, headers, and shared libraries, but that's an = unrelated issue). =20 This is total bollox. gcc is intrinsically a cross compiler and has been = since 2.0. Our use of it is so limited that you might think that gcc = isn't intrinsically a cross compiler. Also, I often install the base gcc compiler using the 'xdev' targets. = This allows me to hack together primitive port cross building support = because it installs all the right links for gnu configure based scripts = to generally work things out. Again, this is more of a use = (freebsd-arm-gcc vs gcc -Bfreebsd-arm) due to how we build gcc. We = could, in theory, build all the back ends into our gcc, but we chose a = long time ago not to do that. But this also is not a relevant point to your argument. It is a cool = feature that we build clang to include all the other targets, but not = relevant to whether to keep gcc in or out of the base system on x86. > The tinderboxes will prevent any gcc-incompatible code from appearing = in the MI bits of the kernel. Optional parts of the userland can slowly = migrate to supporting newer language features. =20 At the expense of the tree being broken more often, but this will be = true whether or not gcc is enabled by default. > Last but not quite least, people keep complaining about = ever-increasing build times and the size of the base system. Building a = gcc and libstdc++ by default every time, that we're telling people not = to use, won't help with that... Also an orthogonal issue. > I have not heard any compelling arguments for keeping gcc and = libstdc++ as part of the default install on x86, and I have listed a = number of reasons why doing so creates extra work for people who = maintain the toolchain and who work on ports. I intend to commit the = change to remove both from the default build and make libc++ the default = STL for clang++ as soon as I get an okay from bapt. =20 If you are going to do this, then doing it before 10 is best. The stdc++ = issue is a compelling one. The base gcc (not g++) is much less so. Warner= From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 17:39:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 22C5C4C7; Thu, 29 Aug 2013 17:39:01 +0000 (UTC) (envelope-from mueller6721@twc.com) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.122]) by mx1.freebsd.org (Postfix) with ESMTP id B7ADD2AF6; Thu, 29 Aug 2013 17:39:00 +0000 (UTC) X-Authority-Analysis: v=2.0 cv=fJG7LOme c=1 sm=0 a=68NkTaeYMVLl2m++3813FQ==:17 a=i4YerQ4AwY4A:10 a=HSsa_qBhwsUA:10 a=DvSzqBOGy98A:10 a=pedpZTtsAAAA:8 a=ayC55rCoAAAA:8 a=KGjhK52YXX0A:10 a=ORzfrLIX98MA:10 a=6I5d2MoRAAAA:8 a=hDxOVbXN1DwfdmFclnEA:9 a=jjUqNiGvsI0A:10 a=68NkTaeYMVLl2m++3813FQ==:117 X-Cloudmark-Score: 0 X-Authenticated-User: X-Originating-IP: 74.130.200.176 Received: from [74.130.200.176] ([74.130.200.176:44849] helo=localhost) by hrndva-oedge04.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id C6/82-27973-3378F125; Thu, 29 Aug 2013 17:38:59 +0000 Date: Thu, 29 Aug 2013 17:38:59 +0000 Message-ID: From: "Thomas Mueller" To: freebsd-current@freebsd.org Subject: Re: Why are cardbus drivers cbb(4) and pccard(4) still included in GENERIC? Cc: freebsd-stable@freebsd.org, freebsd-hardware@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 29 Aug 2013 17:39:01 -0000 > In reference to this FreeBSD forums post: > http://forums.freebsd.org/showpost.php?p=231135&postcount=4 > Would it be a good time to remove those from GENERIC since the > hardware they are for is becoming so seriously outdated? > There's always an option to load those drivers as modules if needed. > -Kimmo These looked useless to me on a desktop computer, but proved necessary to retain just to be able to compile NDIS support into the kernel. This is for a USB wireless adapter by Hiro that uses Realtek RTL8191S chip. Other responses on this topic reveal that these cardbus drivers are needed for many other drivers too. Tom From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 17:42:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 475C2BAA for ; Thu, 29 Aug 2013 17:42:32 +0000 (UTC) (envelope-from gondim@bsdinfo.com.br) Received: from zeus.linuxinfo.com.br (zeus.linuxinfo.com.br [66.118.173.244]) by mx1.freebsd.org (Postfix) with ESMTP id F3D4B2B7F for ; Thu, 29 Aug 2013 17:42:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zeus.linuxinfo.com.br (Postfix) with ESMTP id B498E60B97 for ; Thu, 29 Aug 2013 14:45:12 -0300 (BRT) X-Virus-Scanned: Debian amavisd-new at zeus Received: from zeus.linuxinfo.com.br ([127.0.0.1]) by localhost (zeus.linuxinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xryXlJ4IKRJX for ; Thu, 29 Aug 2013 14:45:11 -0300 (BRT) Received: from MacBook-de-Gondim-2.local (unknown [186.193.48.8]) by zeus.linuxinfo.com.br (Postfix) with ESMTPSA id 43D9160446 for ; Thu, 29 Aug 2013 14:45:09 -0300 (BRT) Message-ID: <521F8801.5030402@bsdinfo.com.br> Date: Thu, 29 Aug 2013 14:42:25 -0300 From: Marcelo Gondim User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: The load does not decrease 1.0 References: <520E8602.5050408@gmail.com> <520E8842.4020609@bitfrost.no> <520E8DE1.1090609@gmail.com> <520F16B6.1070106@bitfrost.no> <520FA7C3.2060708@FreeBSD.org> <520FF137.1020709@gmail.com> <520FF37D.6050002@bitfrost.no> <521277DB.4010200@gmail.com> <521278BC.5010009@bitfrost.no> <521E52BB.1050001@gmail.com> <521E955C.4060308@bsdinfo.com.br> In-Reply-To: <521E955C.4060308@bsdinfo.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 29 Aug 2013 17:42:32 -0000 Hi guys, This was corrected? :) Best regards, Em 28/08/13 21:27, Marcelo Gondim escreveu: > I noticed that in this revision 254890 the system load is not less > than 1.0. Revision 254497 did not occur. > > FreeBSD growthinfo01.localdomain 10.0-CURRENT FreeBSD 10.0-CURRENT #0 > r254890: Thu Aug 29 07:02:12 EDT 2013 > root@growthinfo01.localdomain:/usr/obj/usr/src/sys/VMSRV amd64 > > last pid: 1534; load averages: 1.00, 0.97, 0.83 up 0+00:26:12 > 08:04:38 > 21 processes: 1 running, 20 sleeping > CPU 0: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > CPU 1: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > CPU 2: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > CPU 3: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > CPU 4: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > CPU 5: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > CPU 6: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > CPU 7: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > Mem: 14M Active, 13M Inact, 147M Wired, 26M Buf, 7681M Free > Swap: 8192M Total, 8192M Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU > COMMAND > 1524 root 1 20 0 81628K 6600K select 5 0:00 0.00% sshd > 1413 root 1 20 0 23976K 4920K select 7 0:00 0.00% > sendmail > 1534 root 1 20 0 19764K 2760K CPU5 5 0:00 0.00% top > 1531 growadmin 1 20 0 47632K 2684K wait 6 0:00 0.00% su > 1532 root 1 20 0 23488K 3332K pause 2 0:00 0.00% csh > 1311 root 1 20 0 14420K 2052K select 6 0:00 0.00% > syslogd > 1527 growadmin 1 20 0 81628K 6604K select 6 0:00 0.00% sshd > 1420 root 1 20 0 16512K 2136K nanslp 5 0:00 0.00% cron > 1528 growadmin 1 20 0 16984K 2564K wait 5 0:00 0.00% sh > 1463 root 1 52 0 14416K 1900K ttyin 3 0:00 0.00% getty > 1462 root 1 52 0 14416K 1900K ttyin 4 0:00 0.00% getty > 1465 root 1 52 0 14416K 1900K ttyin 0 0:00 0.00% getty > 1461 root 1 52 0 14416K 1900K ttyin 1 0:00 0.00% getty > 1459 root 1 52 0 14416K 1900K ttyin 6 0:00 0.00% getty > 1460 root 1 52 0 14416K 1900K ttyin 5 0:00 0.00% getty > 1466 root 1 52 0 14416K 1900K ttyin 2 0:00 0.00% getty > 1464 root 1 52 0 14416K 1900K ttyin 7 0:00 0.00% getty > 1410 root 1 20 0 56360K 5896K select 0 0:00 0.00% sshd > 1172 root 1 20 0 13204K 4300K select 1 0:00 0.00% devd > 1416 smmsp 1 52 0 23976K 4888K pause 6 0:00 0.00% > sendmail > 141 root 1 52 0 12260K 1760K pause 7 0:00 0.00% > adjkerntz From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 17:46:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E334AFF4; Thu, 29 Aug 2013 17:46:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B6E222BD4; Thu, 29 Aug 2013 17:46:12 +0000 (UTC) Received: from jhbbsd.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3320FB94B; Thu, 29 Aug 2013 13:46:11 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: RAND_MAX issue? Date: Thu, 29 Aug 2013 13:05:09 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; 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: <201308291305.09931.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 29 Aug 2013 13:46:11 -0400 (EDT) Cc: Jason Helfman X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 29 Aug 2013 17:46:13 -0000 On Thursday, August 29, 2013 11:59:53 am Jason Helfman wrote: > Hello All, > > I am working on trying to resolve a build issue with devel/libvirt, and > posted to the libvirt mailing list, and received this feedback. Please read > this thread, and if you have any thoughts I would be interested in any > resolution. > > Here is a link to the thread: > https://www.redhat.com/archives/libvir-list/2013-August/msg01544.html > > Thanks! It mostly seems to not matter reading the followups. You would need to ask Bruce what he thinks about the assumption of RAND_MAX being 2^n-1 for some n. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 17:46:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 856F2184; Thu, 29 Aug 2013 17:46:18 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 59E112BDA; Thu, 29 Aug 2013 17:46:18 +0000 (UTC) Received: from jhbbsd.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 36B0DB980; Thu, 29 Aug 2013 13:46:17 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: i915kms.ko not loading Date: Thu, 29 Aug 2013 13:06:31 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <521E52A6.6040205@gmail.com> <521F6A52.2060206@gmail.com> <521F6B41.4030704@FreeBSD.org> In-Reply-To: <521F6B41.4030704@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Message-Id: <201308291306.31552.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 29 Aug 2013 13:46:17 -0400 (EDT) Cc: Alexander , =?iso-8859-15?q?Jean-S=E9bastien?= =?iso-8859-15?q?_P=E9dron?= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 29 Aug 2013 17:46:18 -0000 On Thursday, August 29, 2013 11:39:45 am Jean-S=E9bastien P=E9dron wrote: > On 29.08.2013 17:35, Alexander wrote: > > in sysctl: > > kern.coredump: 1 > > kern.corefile: /var/coredumps/%U.%N.%P.core > >=20 > > but coredump files not created. These control user process core dumps, not kernel crash dumps. > > How to set for creating core files? >=20 > You must add the following line to your /etc/rc.conf: > dumpdev=3D"AUTO" >=20 > Also add this line to your /etc/sysctl.conf: > debug.debugger_on_panic=3D0 >=20 > The core dump is written to the swap device when the crash occurs. > During the next boot, it's written to the specified kern.corefile path. This is mostly correct, but the cash dump is written to /var/crash, not the contents of kern.corefile. =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 17:46:23 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C2A5528D; Thu, 29 Aug 2013 17:46:23 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7EE4E2BE3; Thu, 29 Aug 2013 17:46:23 +0000 (UTC) Received: from jhbbsd.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 56E5AB989; Thu, 29 Aug 2013 13:46:22 -0400 (EDT) From: John Baldwin To: David Chisnall Subject: Re: GCC withdraw Date: Thu, 29 Aug 2013 13:44:25 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> In-Reply-To: <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201308291344.25562.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 29 Aug 2013 13:46:22 -0400 (EDT) Cc: "Sam Fourman Jr." , toolchain@freebsd.org, "freebsd-current@freebsd.org CURRENT" , Boris Samorodov , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 29 Aug 2013 17:46:23 -0000 On Thursday, August 29, 2013 1:02:06 pm David Chisnall wrote: > On 29 Aug 2013, at 15:57, John Baldwin wrote: > To summarise the current issues: > > Our libstdc++ is ancient. It supports C++98 well, it kind-of supports C++03. It doesn't support C++11 at all and never will, nor does it support C++14. An increasing number of ports are depending on C++11, because it provides much cleaner syntax than C++98 and so these are being forced to depend on gcc46 or gcc47 to build. Unfortunately, libstdc++ in ports is not ABI compatible with the libstdc++ that we ship, which causes library ABI versions. This problem will only get worse over the coming years. An increasing number of these ports do build with libc++ (since it's the only option on OS X / iOS - most do already and most of the fixes needed are just adding some inclusions since libc++ doesn't leak C headers as much as libstdc++), so defaulting to libc++ will reduce these problems over time. How does removing GCC from base change this? I already deal with having 3 different GCC versions at work by building them from ports and building things with the right rpath, etc. so I am familiar with this, and having GCC in the base doesn't make that problem any worse. In fact, I'd argue that this is an argument for not shipping an STL in the base system at all (though I'd be loathe to do that) if it is an argument for disabling GCC. > Maintaining our libstdc++ is not a zero-effort operation. We have to modify it whenever libc gains new features (e.g. POSIX2008 locales, new libm functions) and this requires developer time tracking down the new bugs (because the static configuration files no longer match the included headers) and fixing them. Strictly speaking you do not have to modify it in all cases. The recent change to make it work with log10 does not appear to have been a requirement to fix anything (at least judging from the log message). There does seem to have been about 10 changes to libstdc++ in the past year, though a few were 2-3 line changes in config.h which isn't but so earth-shattering. Also, unless you plan on desupporting all non-x86 platforms, you _still_ have to do all this work while those platforms require GCC anyway. Just turning off GCC on x86 doesn't change this problem one iota. And that point is actually relevant to many of the other concerns you raised. It's not at all clear what disabling GCC on x86 will buy you unless you are intending on short-changing support for GCC on non-x86. > Maintaining out gcc is also not a zero-effort operation. Even though it is not the default compiler for amd64 or i386, we still have to add support for new instructions to them, even if we only want to use them in machine- dependent code on these architecture. The new instructions (and I've added some) go into binutils, not gcc per se. Even the ARM ABI changes only touched Makefiles and one config header in contrib/gcc, not actual code changes. The code changes in contrib/gcc to add more AMD instrinics were done because someone felt like doing it, not because it was a requirement or blocking issue for someone. > When we enable LLDB during the 10.x timeframe (emaste has been working hard, but it's probably not quite ready for 10.0), it will have to link against both LLVM libraries and libc++ (as it uses C++11 and doesn't work with our libc++). This is a minor issue, as the only requirement here is that we switch to linking LLVM against libc++ instead of libstdc++, but it is an example of one more piece of code that won't build with our gcc that is in the base system (not yet enabled by default). Clang 3.4 will not build with our gcc either (which will cause some bootstrapping problems that we'll have to address for people going from 9.x to 10.1, but the clang 3.3 in 9.2 should be useable as long as we tweak the build system to use clang and not cc for the bootstrap build). Eh, it sounds like if you have to force them to use clang for 9.x bootstrapping that also solves your problem in 10, so it's the same amount of work either way. > Last but not quite least, people keep complaining about ever-increasing build times and the size of the base system. Building a gcc and libstdc++ by default every time, that we're telling people not to use, won't help with that... This is your worst argument as clang is known to take far longer than GCC to build. :) > I have not heard any compelling arguments for keeping gcc and libstdc++ as part of the default install on x86, and I have listed a number of reasons why doing so creates extra work for people who maintain the toolchain and who work on ports. I intend to commit the change to remove both from the default build and make libc++ the default STL for clang++ as soon as I get an okay from bapt. I posit that it only saves you work if you short-change non-x86 platforms, and that this will be harder to detect without gcc built on x86. I do think there is a decent chance that non-clang platforms will be more aggressively abandoned as a result of this change. Don't get me wrong, I don't love GCC per se, and on my laptop I've hacked the relevant ports so that everything is built with clang. I would also love to be able to build the base system with GCC 47 instead of 42, it just doesn't seem that we are there yet. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 17:52:16 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E10B8649; Thu, 29 Aug 2013 17:52:16 +0000 (UTC) (envelope-from iskander@advancedhosters.com) Received: from int.advancedhosters.com (int.advancedhosters.com [213.174.132.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B60602C67; Thu, 29 Aug 2013 17:52:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=advancedhosters.com; s=mail; h=Sender:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=X1H7V/kkdbi615yZp3TvMDIQzSIAQUpit8TRdATo+cE=; b=DyluyDlQB9J/4rac6fjwM17bWLvXP1v3nWcWD6kXYW1UoBRY0gxY5elFJCj8SJGimmCyo0l6ABpsuofrgT/viIWVVQJ7o/M27OY5MP44tAoP966Izo4n7iB8UWOQTTnTFLAi0vOzDEAL9nG5Trdh+EM+WTxHLpazCnmTgd7jKxM=; Received: from client186-7.emplot.net.ua ([193.110.107.186] helo=iskander.advancedhosters.com) by int.advancedhosters.com with esmtpa (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VF6O9-0004f1-G8; Thu, 29 Aug 2013 17:52:09 +0000 Message-ID: <521F8A35.3080801@gmail.com> Date: Thu, 29 Aug 2013 20:51:49 +0300 From: Alexander User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130827 Thunderbird/17.0.8 MIME-Version: 1.0 To: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= Subject: Re: i915kms.ko not loading References: <521E52A6.6040205@gmail.com> <521F1367.8090002@FreeBSD.org> <521F6A52.2060206@gmail.com> <521F6B41.4030704@FreeBSD.org> In-Reply-To: <521F6B41.4030704@FreeBSD.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: iskander@advancedhosters.com Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 29 Aug 2013 17:52:16 -0000 29.08.2013 18:39, Jean-Sébastien Pédron пишет: > On 29.08.2013 17:35, Alexander wrote: >> in sysctl: >> kern.coredump: 1 >> kern.corefile: /var/coredumps/%U.%N.%P.core >> >> but coredump files not created. >> >> How to set for creating core files? > You must add the following line to your /etc/rc.conf: > dumpdev="AUTO" > > Also add this line to your /etc/sysctl.conf: > debug.debugger_on_panic=0 > > The core dump is written to the swap device when the crash occurs. > During the next boot, it's written to the specified kern.corefile path. > I have swapinfo on zfs partition swapinfo -h Device 512-blocks Used Avail Capacity /dev/zvol/zroot/swap 16777216 0B 8.0G 0% ls -la /dev/zvol/zroot/swap crw-r----- 1 root operator 0x8b 29 авг 23:27 /dev/zvol/zroot/swap in /etc/rc.conf dumpdev="AUTO" dumpon_enable="YES" in /etc/sysctl.conf # CoreDump kern.coredump=1 kern.corefile=/var/coredumps/%U.%N.%P.core kern.sugid_coredump=1 When system booting, on console No suitable dump device was found. During the next boot, coredump not created. :( From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 15:37:49 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1EF9C5B3 for ; Thu, 29 Aug 2013 15:37:49 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm14-vm0.bullet.mail.bf1.yahoo.com (nm14-vm0.bullet.mail.bf1.yahoo.com [98.139.213.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ADE1C2187 for ; Thu, 29 Aug 2013 15:37:48 +0000 (UTC) Received: from [98.139.212.146] by nm14.bullet.mail.bf1.yahoo.com with NNFMP; 29 Aug 2013 15:37:41 -0000 Received: from [68.142.230.65] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 29 Aug 2013 15:37:41 -0000 Received: from [127.0.0.1] by smtp222.mail.bf1.yahoo.com with NNFMP; 29 Aug 2013 15:37:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1377790661; bh=sl2eof/Mq54DsMSXno1xhR4rB+OMdYDBqJioaWzAoJI=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=5nx67tQjcxswQuOUZtvuFUTji4snWQ8vKGCobZlla/wKprKSIXZucgcseXPtxw6IpAT6pQdUWVTpCmaiFJqjohx6D8nFFQ0clvx/oOs+r6HUcChmq9T9CyOeK6bdgi2fXa+m2ugPgy1f7o0yjY8MzjAH5tkjeRbtylxe8MPPGwA= X-Yahoo-Newman-Id: 508687.6034.bm@smtp222.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: zMjjfIIVM1nwUud_OaWyyfNc2uwkmn1U3bga6WLmaJ886ZJ mFcyxKf9A9K0uip.cX9.5LCYtBMK5PHk9981MniK5ueCwZbK1wEN5wCpq1AE fHMGpfdjuivwPcXX0ANpgauuue5rmEIXGs18M_tGKYsLHbB8F1QqqBrzGmQw O5U1DeIiLa1MBHsykyPzYvSGyLfxkS5W1eISdAjSlNLjJuRuDcA5a.9nGPs3 FAOFM.pb3k9ZB8UNPM5dSwgfGjyIHITfzEskSwnYPizsHmti7AzP25ahwg0t 95Qw_wiZuI4qPtKBJR3JcGR_7lVaswort6W4marwsh4L0zr9TtPIK1YlONP7 cZqwJh69eW48s1zb_Gpqld7waQPTk03qScPcSSrPIabrxiDY.rAkGnqJXER. Fl_MCNfVAe3MAAF89BwLW9G2Ak97mrnGzJq8oT1NTM_DTu_VHgClWPyTUqh2 c3rZfNXwUVn62rhmEN4b6cFkyc_CPB1xJlbWhBIIkRaJq5t6uywMx7hsV5dV bUmiw0X9kA3actusX5mAADFTRcN6ytJU- X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- X-Rocket-Received: from [172.16.7.246] (scott4long@173.13.138.133 with ) by smtp222.mail.bf1.yahoo.com with SMTP; 29 Aug 2013 15:37:41 +0000 UTC Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: [rfc] migrate lagg to an rmlock From: Scott Long In-Reply-To: <201308291042.13282.jhb@freebsd.org> Date: Thu, 29 Aug 2013 08:37:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <41614148-3900-4FE0-88AC-40F10DAE2030@yahoo.com> References: <5218AA36.1080807@ipfw.ru> <201308291042.13282.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Thu, 29 Aug 2013 19:09:09 +0000 Cc: FreeBSD Net , Adrian Chadd , freebsd-current@freebsd.org, Robert Watson , "Alexander V. Chernikov" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 29 Aug 2013 15:37:49 -0000 On Aug 29, 2013, at 7:42 AM, John Baldwin wrote: > On Saturday, August 24, 2013 10:16:33 am Robert Watson wrote: >> There are a number of other places in the kernel where migration to = an rmlock=20 >> makes sense -- however, some care must be taken for four reasons: (1) = while=20 >> read locks don't experience line contention, write locking becomes = observably=20 >> e.g., rmlocks might not be suitable for tcbinfo; (2) rmlocks, unlike = rwlocks,=20 >> more expensive so is not suitable for all rwlock line contention = spots --=20 >> implement reader priority propagation, so you must reason about; and = (3)=20 >> historically, rmlocks have not fully implemented WITNESS so you may = get less=20 >> good debugging output. if_lagg is a nice place to use rmlocks, as=20 >> reconfigurations are very rare, and it's really all about long-term = data=20 >> stability. >=20 > 3) should no longer be an issue. rmlocks now have full WITNESS and = assertion > support (including an rm_assert). >=20 > However, one thing to consider is that rmlocks pin readers to CPUs = while the > read lock is held (which rwlocks do not do). And this is not a problem for the application that we're giving it in = the lagg driver. Scott From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 19:18:54 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6E1C8294 for ; Thu, 29 Aug 2013 19:18:54 +0000 (UTC) (envelope-from mailer-daemon@vniz.net) Received: from mail-ee0-f50.google.com (mail-ee0-f50.google.com [74.125.83.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F34EF227F for ; Thu, 29 Aug 2013 19:18:53 +0000 (UTC) Received: by mail-ee0-f50.google.com with SMTP id d51so451520eek.23 for ; Thu, 29 Aug 2013 12:18:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=v2Fwtn/ZHQ1e/hY/rEgS8MO4+q0qCBNFyJGuk0ymuVE=; b=PR/oiWokVxKE8qHRdfkLqLs1yOgGoMN+PzVMvZqeViH7G/omKIQc+/bRYCCUdfK1Ul s8kTcGwWfIj4XLpes7DeQO4Q9S8dnNjqttjKX2/osALFLpEC/+a/EQQGKxxVbbAeUe1f a3bgWqus9anjqgGN9hyacaeuJ1WwhXTvrXy9vZlYYf7v+oIJ4aNgTr4CFh29ikAOZzjz AtV4dWTEr3Zp04XEkZwke8awtIYHyOp/i9Ybcs5Ao1QD45yJe584yvJMgE+VQVPzG/Id zMoUxsM3h/Az2ZChBPjfOVJ4NoK+Qma3N8+SXPq8P0tl68BSI5TG21X6mjUqcWrGQ826 OZoQ== X-Gm-Message-State: ALoCoQkO3I3y0x/gQO3zcIr+Fh9OS9H/z3xJkv9K8l23rXcDBKwYGi3+2iqjoJXbQYAScdDm7QE/ X-Received: by 10.14.208.194 with SMTP id q42mr6097490eeo.31.1377800185509; Thu, 29 Aug 2013 11:16:25 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by mx.google.com with ESMTPSA id bn13sm48174417eeb.11.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Aug 2013 11:16:24 -0700 (PDT) Message-ID: <521F8FF5.1050904@freebsd.org> Date: Thu, 29 Aug 2013 22:16:21 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: John Baldwin Subject: Re: RAND_MAX issue? References: <201308291305.09931.jhb@freebsd.org> In-Reply-To: <201308291305.09931.jhb@freebsd.org> OpenPGP: id=964474DD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Jason Helfman X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 29 Aug 2013 19:18:54 -0000 On 29.08.2013 21:05, John Baldwin wrote: > On Thursday, August 29, 2013 11:59:53 am Jason Helfman wrote: >> I am working on trying to resolve a build issue with devel/libvirt, and >> posted to the libvirt mailing list, and received this feedback. Please read >> this thread, and if you have any thoughts I would be interested in any >> resolution. >> >> Here is a link to the thread: >> https://www.redhat.com/archives/libvir-list/2013-August/msg01544.html >> >> Thanks! > > It mostly seems to not matter reading the followups. You would need to > ask Bruce what he thinks about the assumption of RAND_MAX being 2^n-1 > for some n. > The whole libvirt check looks like Linuxism based on wrong assumption "combining a small number of pseudorandom bits to make a larger pseudorandom number produce a uniform distribution". See explaining comments on POSIX site: http://austingroupbugs.net/view.php?id=743 BTW, they seems does not support new proposed addition to POSIX. Moreover, returning old range (as it was before) will bring false safety stopgap for combining with wrong result. Two possible fixes: increase libvirt's internal RAND_MAX (quick and dirty) or rewrite their incorrect combining (preferred). -- http://ache.vniz.net/ bitcoin:1G6ugdNY6e5jx1GVnAU2ntj2NEfmjKG85r From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 21:55:54 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EE7D951C for ; Thu, 29 Aug 2013 21:55:53 +0000 (UTC) (envelope-from mailer-daemon@vniz.net) Received: from mail-ee0-f51.google.com (mail-ee0-f51.google.com [74.125.83.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 807582D1A for ; Thu, 29 Aug 2013 21:55:53 +0000 (UTC) Received: by mail-ee0-f51.google.com with SMTP id c1so530106eek.10 for ; Thu, 29 Aug 2013 14:55:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=aJwkNlOiUSTyzcdh2u42R8i9WOPltqt0p/oCFSZ5fjQ=; b=C+GJHZR+xfTtQKH0QW9DPqRQOU0z7INLfEtjH1zSSTQurCnT77LBKN1jIDoJGtgSeI ElkHgzKcnYOqDhVkro/OH2ZId2/jn7KmPl3Ewwp56wIsz74WCufGYxeb0JsPXhfymGAM V5GBVxTYruuakkw3+SbKmaqhPXno0Pxm9L9EslPndedGHcmCCJ5ATKgQsB4I83m5qaE1 SxgjEWXpCGmAqy4XoOZKyNBVE6mIVTEwviOAgTyduChlsAInq7Gy4ZgTUZsv5VHzx6FX uvY+698fubz/C9XexDRpxxgvN5K3gICrdouNqGP1LHfKdeXEgDyfHHzbocJrMovz0/ob Y6Og== X-Gm-Message-State: ALoCoQkD5Rd/zEy7F6YuUBybEZuOHbd12VCm/x9o1Ly4ZH29MkaPIHbg0yii6+kyLAwnmJth2vqu X-Received: by 10.14.174.195 with SMTP id x43mr7203009eel.47.1377813345678; Thu, 29 Aug 2013 14:55:45 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by mx.google.com with ESMTPSA id bn13sm49565716eeb.11.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Aug 2013 14:55:45 -0700 (PDT) Message-ID: <521FC35D.6010503@freebsd.org> Date: Fri, 30 Aug 2013 01:55:41 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: John Baldwin Subject: Re: RAND_MAX issue? References: <201308291305.09931.jhb@freebsd.org> <521F8FF5.1050904@freebsd.org> In-Reply-To: <521F8FF5.1050904@freebsd.org> OpenPGP: id=964474DD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Jason Helfman X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 29 Aug 2013 21:55:54 -0000 On 29.08.2013 22:16, Andrey Chernov wrote: > On 29.08.2013 21:05, John Baldwin wrote: >> On Thursday, August 29, 2013 11:59:53 am Jason Helfman wrote: >>> I am working on trying to resolve a build issue with devel/libvirt, and >>> posted to the libvirt mailing list, and received this feedback. Please read >>> this thread, and if you have any thoughts I would be interested in any >>> resolution. >>> >>> Here is a link to the thread: >>> https://www.redhat.com/archives/libvir-list/2013-August/msg01544.html >>> >>> Thanks! >> >> It mostly seems to not matter reading the followups. You would need to >> ask Bruce what he thinks about the assumption of RAND_MAX being 2^n-1 >> for some n. >> > > The whole libvirt check looks like Linuxism based on wrong assumption Moreover, their code have totally wrong assumptions: https://www.redhat.com/archives/libvir-list/2013-August/msg01556.html "But I would MUCH rather prefer that FreeBSD revisit their decision, and guarantee that random output be evenly distributed across the full 31 bits to begin with." random() output always is full 31 bit and not related to RAND_MAX anyhow per POSIX. It is only GNU lib which uses RAND_MAX for both rand() and, incorrectly, for random() too. They confess it by themselves in this message: https://www.redhat.com/archives/libvir-list/2013-August/msg01559.html "Huh - the glibc man pages state that random_r returns RAND_MAX bits. random_r is a glibc extension: POSIX only requires rand(), rand_r(), and random(); but even with random(), POSIX has no requirements that it be related to RAND_MAX - so the fact that glibc equates random()/random_r() with RAND_MAX is also a glibc extension." So the correct fix is simple: remove check for RAND_MAX from their sources along with any RAND_MAX usage, since their code don't even use rand() but RAND_MAX is only for rand(). -- http://ache.vniz.net/ bitcoin:1G6ugdNY6e5jx1GVnAU2ntj2NEfmjKG85r From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 00:38:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 142AB901; Fri, 30 Aug 2013 00:38:59 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BE16E2644; Fri, 30 Aug 2013 00:38:58 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r7U0cmaA024641; Thu, 29 Aug 2013 20:38:54 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <521FE998.6020402@m5p.com> Date: Thu, 29 Aug 2013 20:38:48 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130716 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hans Petter Selasky Subject: Re: ulpt can't attach Lexmark E120 References: <5105527F.3010708@m5p.com> <201301271915.47712.hselasky@c2i.net> <510570C1.1060607@m5p.com> <201301272007.30682.hselasky@c2i.net> <5105AB16.2000607@m5p.com> <5215F4DF.6000305@m5p.com> <5215F743.8060403@bitfrost.no> <5216ACE5.7000500@m5p.com> <5216FE9F.2030608@bitfrost.no> <52174378.2020101@m5p.com> <521801E5.9000309@m5p.com> <52184F59.5080100@bitfrost.no> <5218F993.9050504@m5p.com> <5219C3FF.1070509@bitfrost.no> In-Reply-To: <5219C3FF.1070509@bitfrost.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Thu, 29 Aug 2013 20:38:54 -0400 (EDT) Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 00:38:59 -0000 On 08/25/13 04:44, Hans Petter Selasky wrote: > On 08/24/13 20:21, George Mitchell wrote: >> >> Setting hw.usb.dwc_otg.debug to any value greater than 0 generates an >> unending stream of debug output and effectively locks up the chip >> scrolling the output on the display. Perhaps there are some specific >> debug messages I could put in ... -- George > > Hi, > > Can you try this patch: > > http://svnweb.freebsd.org/changeset/base/254828 > > --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" Finally my RPi build system is working again and I can happily report that my Lexmark printer attaches successfully! Thank you! (And I note the patch has been checked into the repository.) -- George From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 01:46:33 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7292D9CE for ; Fri, 30 Aug 2013 01:46:33 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4BB012983 for ; Fri, 30 Aug 2013 01:46:33 +0000 (UTC) Received: by mail-pa0-f44.google.com with SMTP id fz6so1671047pac.17 for ; Thu, 29 Aug 2013 18:46:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:subject:message-id:reply-to:mime-version:content-type :content-disposition:user-agent; bh=DIoEP1et5As0cJIQgXz90iPBRXA7J1zjZGSXLPNzrpk=; b=nkzDHc4OYfGVAe0ztyZ/+tYhPTH9Y2Rt8xLCl2tJ/wMlIvz+g07N/RW+QgYvhLC48h UL7Rnd7rts3zNijlHpY+7OkScrgnc/MF3r6wHNC3Z8v68fUgNhcmP0mZYm37c6W2yh8/ mUjTAcC86hy5RXZEm4/1DYc5DvwCMoU0AbeuWjN7+P+7kL8xosOcRPS3FZDzGzcYG4Jy vLOV3LyGnqYm36YeKxCZvPHuTzz9dvI0B5Ibsx5uabWvALmd/rDy15noogn7/oWp2w13 hR5pbCeBPmXR7MabQFqO1LASfWhsxRVhF8GSoznGphL1rUNW3s8GTt+xUklM40J/r85Q rB7Q== X-Received: by 10.68.143.38 with SMTP id sb6mr6902012pbb.44.1377827192994; Thu, 29 Aug 2013 18:46:32 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id ct4sm31806722pbb.41.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 29 Aug 2013 18:46:32 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 30 Aug 2013 10:46:26 +0900 From: Yonghyeon PYUN Date: Fri, 30 Aug 2013 10:46:26 +0900 To: freebsd-current@FreeBSD.org Subject: CFT: bge(4) TX/RX checksum offloading Message-ID: <20130830014626.GA3107@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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: Fri, 30 Aug 2013 01:46:33 -0000 Hi, It was known that bge(4) generated wrong TCP/UDP checksum when the frame length was less then 60 bytes. So bge(4) implemented padding workaround for such runt frames. bge(4) also ignored H/W assisted TCP/UDP checksum result when the length of received frame was less than 60 bytes. This workaround came from NetBSD about 7 years ago. Recently I started to wonder why bge(4) needs such workaround given that 1) publicly available data sheet does not mention the issue and 2) Linux tg3 does not have any workaround for the issue. I also asked the question to Broadcom and I was told that they(both Linux and Windows software developers) can't recall they have the issue. Linux does not use IP checksum offloading feature of controller so it's possible for the controller to have IP checksum offloading issue on runt frames. But I was not able to reproduce the issue on my box. Here is the patch that removes the workaround in bge(4). http://people.freebsd.org/~yongari/bge/bge.csum.diff The diff was generated against HEAD but it will also apply cleanly to stable/9. If you use bge(4) devices, please give it a whirl and let me know how well it works on your configuration. Thanks. From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 01:57:13 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8D65EEBC for ; Fri, 30 Aug 2013 01:57:13 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 69EE12A15 for ; Fri, 30 Aug 2013 01:57:13 +0000 (UTC) Received: by mail-pb0-f43.google.com with SMTP id md4so1206285pbc.30 for ; Thu, 29 Aug 2013 18:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=eenTw8izQ+mTiZDOldWbyhEhnh+Y1xCD7yQ9u3IV52E=; b=m+hxcjSRbFtg6vigWXCGUpav9S+fM1pnBBwdCJp7u6w8SvXtsUWLgQ3dZRhKY/iPSz PLIRVR1E/2Lx0yKZH4fuNrm3V5Cv/mVB4EcKLxlpy8406Qpo5ASiGIGZp4iAwd3CHDI/ dshRJUHFegJqnCboAV0r2HIzuuF4yGbnyVP9uD514dyJRrNuj2CNMr1mSisPe2JPEEkq LC4efG7ArR+r7WMBJSHG1cEe5nnFRc/WN+gzpKebhI3BB5lXqGbSoPW/N0xKLIQHqrF7 VgzQDFZj+NoPnITQx5qjp8k6X4wc/RkDvSHRrt/xVIrEuTMRjwmhUKV4XsgiyTp+gsWm 1odg== MIME-Version: 1.0 X-Received: by 10.66.233.37 with SMTP id tt5mr7511272pac.95.1377827833104; Thu, 29 Aug 2013 18:57:13 -0700 (PDT) Received: by 10.68.212.138 with HTTP; Thu, 29 Aug 2013 18:57:13 -0700 (PDT) Date: Thu, 29 Aug 2013 21:57:13 -0400 Message-ID: Subject: if_tap(4) being inconsistent between svn updates From: Aryeh Friedman To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 01:57:13 -0000 I track -CURRENT (mostly for bhyve) and have found between updates that if_tap often requires different calling semantics to work... sometimes it needs and IP ad sometimes it doesn't it s the primary problem (on the same update it is consitent is only after installing new updates [not all new ones] this happens)... my guess is there is somehow some interaction between it and the rest of the kernel where the rest of the kernel sometimes requires and IP and sometimes not From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 06:09:31 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EB9FFF26 for ; Fri, 30 Aug 2013 06:09:30 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B7F24279F for ; Fri, 30 Aug 2013 06:09:30 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id 16so2248653iea.29 for ; Thu, 29 Aug 2013 23:09:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1lprgTrg5+1W9dmSh+bgOlSx2tjQMQhkJ7MSfDAyRio=; b=SrWz0MOtByd0uq7uitY+ts8Ik0zA0TO3bmU39sU+jyCJnzcXOCmTj8s03/Wya4Gb9e 2Ou/5bfMvBhDuhLqRxccQsCkG6J/KS7ZGZ0sWvKcxvYUTtCD4n87aY+uxI6+b0GDTL6M bFqFFwTGgut6RDWrhslbNwd1DZTHKTn3x7P8EBz/5TDk6zNa3z93nsgsBotpbH/Usr1l v8z0SjNSgtwC3DRyL3JjBHm/yo6vQZ6h3Ki+4JUiF9i1AeGlqeASggkw02NqZ3hE90pk 6z/LBg7YXE3Uort5SCLa/afIYRSxFmb45QGCn7Yec+XqCJgmOQK0FhoXT3C6tmyWaXdf 50Lw== X-Gm-Message-State: ALoCoQm4V9i+xiMojMdpcH+4+bYZNC5x+VbpxojmgCUDEQDsk04YysjYyjSsS5qmjBUNXPywbp5S MIME-Version: 1.0 X-Received: by 10.50.49.65 with SMTP id s1mr1049682ign.43.1377842963838; Thu, 29 Aug 2013 23:09:23 -0700 (PDT) Received: by 10.43.158.74 with HTTP; Thu, 29 Aug 2013 23:09:23 -0700 (PDT) In-Reply-To: References: <521B9CD7.8010902@bitfrost.no> <521C6C26.7050207@bitfrost.no> Date: Fri, 30 Aug 2013 08:09:23 +0200 Message-ID: Subject: Re: xhci broken on 10-CURRENT and 2013 MacBook Air? From: "Lundberg, Johannes" To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current , "freebsd-usb@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 06:09:31 -0000 What I got so far is this; USB driver from current stops after xhci0: 32 byte context size While driver from 9.1 continues to the next step which is usbus0 on xhci0 xhci0: usbpf: Attached ... I can try adding some printf's in the code and see if I get some more.. On Tuesday, August 27, 2013, Lundberg, Johannes wrote: > Hi Hans > > Sure, I will try it out later and mail the results. > > Now I'm running current with usb part reverted to 9.1. It gets me pass the > usb probing to the part that I really wanted to confirm. If FreeBSD > supports the SSD drive on the new MacBook Air. It seems that it doesn't so > that one more thing that we need to look into. > > > > Johannes Lundberg > BRILLIANTSERVICE CO., LTD. > > > On Tue, Aug 27, 2013 at 10:06 AM, Hans Petter Selasky > > wrote: > >> On 08/26/13 21:02, Lundberg, Johannes wrote: >> >>> Hi Hans >>> >>> Thanks but nothing of that makes any difference. Well, it's gonna be >>> difficult to find the diff I think... The oldest image I could find was >>> from May. >>> >>> What I'm doing now is compiling a bootonly.iso of current with a xhci.h/c >>> that's reverted to 9.1 release version to see if that will boot. >>> >>> >> Hi, >> >> If it just hangs, can be an IRQ looping issue. >> >> You can also try to boot using bootverbose and configure the xhci driver >> with debugging on in the sys/dev/usb/controller/xhci.c by default to see >> just what is exactly going on. >> >> If you can suggest a patch, that would be great. >> >> --HPS >> >> > -- Johannes Lundberg BRILLIANTSERVICE CO., LTD. From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 06:41:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F29D9791; Fri, 30 Aug 2013 06:41:06 +0000 (UTC) (envelope-from hps@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id 81B642988; Fri, 30 Aug 2013 06:41:06 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta.bitpro.no (Postfix) with ESMTP id 9BC5E7A11F; Fri, 30 Aug 2013 08:41:05 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id B701C8F4F2B; Fri, 30 Aug 2013 08:41:18 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktsQxUQBBvAx; Fri, 30 Aug 2013 08:41:18 +0200 (CEST) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) by mail.lockless.no (Postfix) with ESMTPSA id C62558F4F28; Fri, 30 Aug 2013 08:41:17 +0200 (CEST) Message-ID: <52203EC9.4060808@bitfrost.no> Date: Fri, 30 Aug 2013 08:42:17 +0200 From: Hans Petter Selasky Organization: Bitfrost A/S User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130522 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Lundberg, Johannes" Subject: Re: xhci broken on 10-CURRENT and 2013 MacBook Air? References: <521B9CD7.8010902@bitfrost.no> <521C6C26.7050207@bitfrost.no> In-Reply-To: Content-Type: multipart/mixed; boundary="------------030709090608070304030300" Cc: FreeBSD Current , "freebsd-usb@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 06:41:07 -0000 This is a multi-part message in MIME format. --------------030709090608070304030300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08/30/13 08:09, Lundberg, Johannes wrote: > What I got so far is this; > > USB driver from current stops after > xhci0: 32 byte context size > > While driver from 9.1 continues to the next step which is > usbus0 on xhci0 > xhci0: usbpf: Attached > ... > > I can try adding some printf's in the code and see if I get some more.. > Hi, There are only a few commits to the xhci driver since 9.1 was releases, so this should be easy to figure out. I'm doing a wild guess. Can you try the attached patch. It will ensure that any BIOS generated interrupts get cleared before we reset the controller. --HPS --------------030709090608070304030300 Content-Type: text/x-patch; name="xhci_irq.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xhci_irq.diff" === sys/dev/usb/controller/xhci.c ================================================================== --- sys/dev/usb/controller/xhci.c (revision 254832) +++ sys/dev/usb/controller/xhci.c (local) @@ -320,6 +320,12 @@ device_printf(sc->sc_bus.parent, "32 byte context size.\n"); } + temp = XREAD4(sc, oper, XHCI_USBSTS); + /* clear all pending interrupts */ + XWRITE4(sc, oper, XHCI_USBSTS, temp); + /* clear and disable leftover interrupts */ + XWRITE4(sc, runt, XHCI_IMAN(0), XHCI_IMAN_INTR_PEND); + /* Reset controller */ XWRITE4(sc, oper, XHCI_USBCMD, XHCI_CMD_HCRST); @@ -385,10 +391,6 @@ sc->sc_exit_lat_max = XHCI_HCS3_U1_DEL(temp) + XHCI_HCS3_U2_DEL(temp) + 250 /* us */; - temp = XREAD4(sc, oper, XHCI_USBSTS); - - /* clear interrupts */ - XWRITE4(sc, oper, XHCI_USBSTS, temp); /* disable all device notifications */ XWRITE4(sc, oper, XHCI_DNCTRL, 0); @@ -462,11 +464,8 @@ XWRITE4(sc, runt, XHCI_ERSTBA_HI(0), (uint32_t)(addr >> 32)); /* Setup interrupter registers */ + XWRITE4(sc, runt, XHCI_IMAN(0), XHCI_IMAN_INTR_ENA); - temp = XREAD4(sc, runt, XHCI_IMAN(0)); - temp |= XHCI_IMAN_INTR_ENA; - XWRITE4(sc, runt, XHCI_IMAN(0), temp); - /* setup command ring control base address */ addr = buf_res.physaddr; addr += (uintptr_t)&((struct xhci_hw_root *)0)->hwr_commands[0]; --------------030709090608070304030300-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 07:18:45 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0D7CE22E; Fri, 30 Aug 2013 07:18:45 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C51D02C14; Fri, 30 Aug 2013 07:18:44 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-245-177.lns20.per2.internode.on.net [121.45.245.177]) (authenticated bits=0) by vps1.elischer.org (8.14.6/8.14.6) with ESMTP id r7U7IaHg031377 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 30 Aug 2013 00:18:39 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <52204746.2070900@freebsd.org> Date: Fri, 30 Aug 2013 15:18:30 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: David Chisnall Subject: Re: GCC withdraw References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> In-Reply-To: <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , toolchain@FreeBSD.org, "freebsd-current@freebsd.org CURRENT" , "Sam Fourman Jr." , Boris Samorodov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 07:18:45 -0000 On 8/30/13 1:02 AM, David Chisnall wrote: > On 29 Aug 2013, at 15:57, John Baldwin wrote: > >> I have not seen any convincing >> argument as to why leaving GCC in the base for 10.x impedes anything. >> Because clang isn't sufficient for so many non-x86 platforms we can't >> really start using clang-specific features yet anyway. > Apparently I haven't been good at communicating, so I'll try to here. I apologise for ignoring this thread for the last week: I've been rather busy organising the DevSummit. The notes for the sessions will be posted to various mailing lists soon (and summarised for a special status report), but since the ports and toolchain build sessions are already largely up you can check these on the wiki. You'll notice that in both sessions the topic of removing gcc / libstdc++ was raised and there was no objection (not sure if it's in the notes, but there was a lot of support during the ports session from people who didn't want the pain of maintaining compatibility with gcc-in-base, and especially with g++/libstdc++ in base). > > This is not a new plan, it is the plan that has been on the wiki and discussed at at least two DevSummits that I have attended before this week and probably others that I missed, as well as on various mailing lists and in IRC. > > To summarise the current issues: > > Our libstdc++ is ancient. It supports C++98 well, it kind-of supports C++03. It doesn't support C++11 at all and never will, nor does it support C++14. An increasing number of ports are depending on C++11, because it provides much cleaner syntax than C++98 and so these are being forced to depend on gcc46 or gcc47 to build. Unfortunately, libstdc++ in ports is not ABI compatible with the libstdc++ that we ship, which causes library ABI versions. This problem will only get worse over the coming years. An increasing number of these ports do build with libc++ (since it's the only option on OS X / iOS - most do already and most of the fixes needed are just adding some inclusions since libc++ doesn't leak C headers as much as libstdc++), so defaulting to libc++ will reduce these problems over time. > > Maintaining our libstdc++ is not a zero-effort operation. We have to modify it whenever libc gains new features (e.g. POSIX2008 locales, new libm functions) and this requires developer time tracking down the new bugs (because the static configuration files no longer match the included headers) and fixing them. > > Maintaining out gcc is also not a zero-effort operation. Even though it is not the default compiler for amd64 or i386, we still have to add support for new instructions to them, even if we only want to use them in machine-dependent code on these architecture. > > Our g++ in base can only work with libstdc++, not libc++. This means that shipping gcc in 10.0 in base means that we'd be shipping two C++ compilers, which preferred different standard libraries, with incompatible ABIs. This is setting us up for a world of pain. > > When we enable LLDB during the 10.x timeframe (emaste has been working hard, but it's probably not quite ready for 10.0), it will have to link against both LLVM libraries and libc++ (as it uses C++11 and doesn't work with our libc++). This is a minor issue, as the only requirement here is that we switch to linking LLVM against libc++ instead of libstdc++, but it is an example of one more piece of code that won't build with our gcc that is in the base system (not yet enabled by default). Clang 3.4 will not build with our gcc either (which will cause some bootstrapping problems that we'll have to address for people going from 9.x to 10.1, but the clang 3.3 in 9.2 should be useable as long as we tweak the build system to use clang and not cc for the bootstrap build). > > Lots of configure scripts will use gcc in preference to cc (or g++ in preference to c++) if they find them in the same place. Many of these no longer work with our old gcc, but do work with clang, adding more effort to ports. According to the test runs that bapt did at the DevSummit this week, we have more ports failing on 10 with gcc than on 10 with gcc removed. > > Our gcc does not support the ARM EABI hard float variant. I misspoke earlier when I thought it didn't support EABI at all, but it turns out that it's only the case for hard-float. This is the ABI that we want to be using on pretty much all ARMv6 and newer systems, because a lot of ARM cores (such as the Cortex A8 in the Efika MX that the Foundation has paid for FreeBSD to be ported on to use as a demo ARM device) require a complete pipeline flush when moving between integer and floating point registers and the soft-float variant of the ABI puts all arguments in integer registers. This means that a simple function that takes a rectangle (4 floating point values) as an argument will require 8 pipeline flushes to call, which various Linux distributions have found is crippling for graphical applications. > > We want to start shipping binary packages for ARMv6. At the moment, i386, amd64, and ARMv6 are the only architectures where you can get cheap, off-the-shelf, hardware that looks enough like a normal computer that you'd expect to be able to use a stock install, and so they are the only platforms where the default build configuration makes a difference. For all of these preferences, clang is the default and there is no reason to prefer our gcc: if you actually want to use gcc (e.g. if you care about the C99 floating point craziness, or you have OpenMP code to build) then one of the gcc versions in ports will give you much better code (and better error reporting). > > Unlike clang, gcc is not intrinsically a cross compiler. This means that if you are targeting a non-x86, non-ARM architecture then you are already building a cross-gcc to use as part of your bootstrap process and so not having the x86-only gcc on your host system does not cost you anything. As someone who spends day-job time working on FreeBSD/MIPS, I've never found the need to use the installed base-gcc (my life would be much happier if we had some nice infrastructure for building packages of the MIPS toolchain, headers, and shared libraries, but that's an unrelated issue). > > The tinderboxes will prevent any gcc-incompatible code from appearing in the MI bits of the kernel. Optional parts of the userland can slowly migrate to supporting newer language features. > > Last but not quite least, people keep complaining about ever-increasing build times and the size of the base system. Building a gcc and libstdc++ by default every time, that we're telling people not to use, won't help with that... > > I have not heard any compelling arguments for keeping gcc and libstdc++ as part of the default install on x86, and I have listed a number of reasons why doing so creates extra work for people who maintain the toolchain and who work on ports. I intend to commit the change to remove both from the default build and make libc++ the default STL for clang++ as soon as I get an okay from bapt. > > David David, we all appreciate the work you are doing here but you are just not listening.. Many of the older and more experienced voices in the project are telling you "let it sit quietly as a non default lifeboat in 10.x and remove it in 11" This comes not from our dislike of clang but from our experience in the past. Clang is new. clang WILL HAVE BUGS. Having the old compiler in the tree will save people's hides and will also allow then to say "I compiled it with gcc and it worked as expected" without having to go to ports and follow some set of instructions. As far as I'm concerned we can even slate it for "possible removal in 10.2-- if clang has proven up to the task" as long as it's widely announced in 10.*0* and people know that it's coming.. We guarantee default behaviour won't change but we don't necessarily guarantee that NOTHING will change in a branch lifetime. Julian From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 07:33:32 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 594C7582; Fri, 30 Aug 2013 07:33:32 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 170CC2D0F; Fri, 30 Aug 2013 07:33:31 +0000 (UTC) Received: from [192.168.0.2] (cpc27-cmbg15-2-0-cust235.5-4.cable.virginmedia.com [86.27.188.236]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r7U7XPBX007290 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Aug 2013 07:33:26 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: GCC withdraw From: David Chisnall In-Reply-To: <201308291344.25562.jhb@freebsd.org> Date: Fri, 30 Aug 2013 08:33:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> <201308291344.25562.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1508) Cc: "Sam Fourman Jr." , toolchain@FreeBSD.org, "freebsd-current@freebsd.org CURRENT" , Boris Samorodov , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 07:33:32 -0000 On 29 Aug 2013, at 18:44, John Baldwin wrote: > How does removing GCC from base change this? I already deal with = having > 3 different GCC versions at work by building them from ports and = building > things with the right rpath, etc. so I am familiar with this, and = having > GCC in the base doesn't make that problem any worse. In fact, I'd = argue > that this is an argument for not shipping an STL in the base system at = all > (though I'd be loathe to do that) if it is an argument for disabling = GCC. It means that you don't need to patch configure scripts to tell them to = ignore gcc even if they find it. Please talk to port maintainers about = the amount of effort that they're being forced to put into this. = They'll still have to keep doing this until 9.x is EOL'd, but it would = be nice if they could then stop, rather than having to wait for 10.x to = also be EOL'd. >> Maintaining our libstdc++ is not a zero-effort operation. We have to = modify=20 > it whenever libc gains new features (e.g. POSIX2008 locales, new libm=20= > functions) and this requires developer time tracking down the new bugs=20= > (because the static configuration files no longer match the included = headers)=20 > and fixing them. >=20 > Strictly speaking you do not have to modify it in all cases. The = recent=20 > change to make it work with log10 does not appear to have been a = requirement=20 > to fix anything (at least judging from the log message). There does = seem to=20 > have been about 10 changes to libstdc++ in the past year, though a few = were=20 > 2-3 line changes in config.h which isn't but so earth-shattering. And each libc change that exposes anything that is used by libstdc++ = goes through the same cycle: - Commit - Wait for bug reports - Spend a few hours trying to work out why C++ programs are failing to = run or compile in odd ways - Commit a libstdc++ fix And, once again, the people who are advocating for gcc to remain in the = default install are not the ones doing this work. > Also, unless you plan on desupporting all non-x86 platforms, you = _still_ > have to do all this work while those platforms require GCC anyway. = Just > turning off GCC on x86 doesn't change this problem one iota. And that = point > is actually relevant to many of the other concerns you raised. It's = not at > all clear what disabling GCC on x86 will buy you unless you are = intending on > short-changing support for GCC on non-x86. It gives us a much cleaner deprecation strategy. Ports on tier-2 are = best effort. We don't need to be quite as careful to ensure that they = build with the base system compiler on tier-2 architectures. We don't = make as strong guarantees about compatibility on tier-2 architectures, = so removing gcc from their build at some point over the next five years = is fine, but this is not the case for tier 1 architectures, where we can = be reasonably expected to support anything that is in the base system = for the next five years. =20 If we remove it from the default install now, users don't expect it to = keep working for the lifetime of the 10.x branch. If we leave it in, = then they do. If tier-2 architectures are still using it for 10.0, = that's fine, because users of tier-2 architectures don't expect = everything to remain stable over the span of a release. =20 ARM is technically Tier-2, but for the purpose of this I'm including = modern ARM platforms (i.e. things like the Efika and Raspberry Pi, where = we hope to get re@-supported images soon - by 10.1 if not by 10.0), but = ARM EABI Hard-Float (the platform in question) is already supported by = clang and so has the same level of support as x86. =20 So let's be absolutely clear what we mean by non-x86: - Old ARM (ARMv4/ARMv5), most commonly used in microcontrollers which = don't have the power to run a full base system or arbitrary ports = anyway. =20 - MIPS, which is a few months of effort in LLVM to get completely = working. LLVM on MIPS is already self-hosting and I'm currently chasing = the remaining issues. We are planning on releasing an open source = MIPS64 implementation soon, and gcc will be the system compiler for the = first release, but we'll be switching to clang very soon for that - long = before 10.x goes EOL. MIPS has other serious issues (for example, gdb = doesn't work at all - it can't even find the memory regions that contain = the binary) and our ld is too old to support several of the GOT-related = optimisations required to build large programs, so gcc is the least of = its concerns, toolchain-wise. The MIPS binutils changes have not been = upstreamed, so this is somewhat problematic as we don't have any useable = toolchains for MIPS64, including gcc in base, for moderately-sized = applications. This should be addressed some time over the next 6-12 = months by switching MIPS over to LLVM / MCLinker. MIPS is perhaps the = most important one because the new owners of MIPS are investing in LLVM = quite heavily (they've been ramping up their LLVM development a lot over = the last year even before the purchase) and so it's important for us to = send a message to downstream FreeBSD/MIPS vendors that now is the time = to start thinking about switching toolchains. - PowerPC, which is a curiosity on old Apple hardware and is largely = used in embedded (mostly automotive?) applications beyond that. ANL = people are working hard on PowerPC 64 support for things like = BlueGene/Q, and PowerPC 32 is slowly coming along, although I think it's = missing a couple of things related to thread-local storage. For low-end = PowerPC32 embedded systems, most of the comments about ARMv4/5 apply. = For PowerPC64 - SPARC, which is effectively dead thanks to Oracle - Itanium, which is effectively dead thanks to Intel failing to learn = from their own mistakes By the way, I strongly resent the implication that I don't care about = non-x86 platforms, as I personally work on MIPS64 toolchain support and = have regular meetings with people at ARM about support there. >> Last but not quite least, people keep complaining about = ever-increasing=20 > build times and the size of the base system. Building a gcc and = libstdc++ by=20 > default every time, that we're telling people not to use, won't help = with=20 > that... >=20 > This is your worst argument as clang is known to take far longer than = GCC > to build. :) Not really. Clang + gcc takes longer to build than just clang. We can = also do a lot to fix clang build times by fixing our build systems to = properly expose the parallelism intrinsic in the build. I can build = LLVM+clang on my laptop in under 10 minutes with the upstream build = system, but doing it in the buildworld takes significantly longer. On a = 24-core system, it's under 3 minutes with the upstream build system, but = as long as on my laptop with ours. =20 > I posit that it only saves you work if you short-change non-x86 = platforms, > and that this will be harder to detect without gcc built on x86. I do = think > there is a decent chance that non-clang platforms will be more = aggressively > abandoned as a result of this change. By the end of the 10.x series, I expect non-clang platforms to be = SPARC64 and IA64. I don't think they need any help being abandoned - = their manufacturers seem to be facilitating this quite competently = without any assistance.=20 > Don't get me wrong, I don't love GCC per se, and on my laptop I've = hacked > the relevant ports so that everything is built with clang. I would = also > love to be able to build the base system with GCC 47 instead of 42, it = just > doesn't seem that we are there yet. The time to raise objections for this was when the plan was originally = raised over a year ago, or at any of the points when it's been discussed = in between. It is not after we're ready to flip the switch. David From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 07:35:20 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 30DDA6D8; Fri, 30 Aug 2013 07:35:20 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F169B2D32; Fri, 30 Aug 2013 07:35:19 +0000 (UTC) Received: from [192.168.0.2] (cpc27-cmbg15-2-0-cust235.5-4.cable.virginmedia.com [86.27.188.236]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r7U7ZG4Y007305 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Aug 2013 07:35:18 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: GCC withdraw From: David Chisnall In-Reply-To: <52204746.2070900@freebsd.org> Date: Fri, 30 Aug 2013 08:35:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> <52204746.2070900@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1508) Cc: "Sam Fourman Jr." , toolchain@FreeBSD.org, "freebsd-current@freebsd.org CURRENT" , Boris Samorodov , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 07:35:20 -0000 On 30 Aug 2013, at 08:18, Julian Elischer wrote: > As far as I'm concerned we can even slate it for > "possible removal in 10.2-- if clang has proven up to the task" I would be happy to ship gcc, as long as: - It's explicitly marked as deprecated and due for removal at some point = in the 10.x timeframe. - libstdc++ is gone (the amount of pain it's causing ports is = phenomenal). David From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 07:56:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E3B01234; Fri, 30 Aug 2013 07:56:38 +0000 (UTC) (envelope-from jonathan@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CBA872EF8; Fri, 30 Aug 2013 07:56:38 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r7U7uZVs066226; Fri, 30 Aug 2013 07:56:36 GMT (envelope-from jonathan@FreeBSD.org) Date: Fri, 30 Aug 2013 08:56:35 +0100 From: Jonathan Anderson To: David Chisnall Message-ID: <3C11736737A54D84B80B1D27406F8039@FreeBSD.org> In-Reply-To: References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> <52204746.2070900@freebsd.org> Subject: Re: GCC withdraw X-Mailer: sparrow 1.6.4 (build 1176) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: FreeBSD Current , Boris Samorodov , toolchain@freebsd.org, "=?utf-8?Q?freebsd-current=40freebsd.org_CURRENT?=" , "Sam Fourman Jr." X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 07:56:39 -0000 On Friday, 30 August 2013 at 08:35, David Chisnall wrote: > I would be happy to ship gcc, as long as: > > - It's explicitly marked as deprecated and due for removal at some point in the 10.x timeframe. > - libstdc++ is gone (the amount of pain it's causing ports is phenomenal). Wouldn't this mean that we can't build base using the shipped-in-base g++? If we have C++ in base, we don't ship libstdc++ and g++ can't work with libc++, then people wanting to compile the base system with gcc/g++ will have to install a libstdc++ package. I don't see how that's very different from requiring a gcc/g++ package. Jon -- Jonathan Anderson jonathan@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 07:59:15 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2DF6D3C8; Fri, 30 Aug 2013 07:59:15 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EB73B2F26; Fri, 30 Aug 2013 07:59:14 +0000 (UTC) Received: from [192.168.0.2] (cpc27-cmbg15-2-0-cust235.5-4.cable.virginmedia.com [86.27.188.236]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r7U7xBlG007438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Aug 2013 07:59:13 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: GCC withdraw From: David Chisnall In-Reply-To: <3C11736737A54D84B80B1D27406F8039@FreeBSD.org> Date: Fri, 30 Aug 2013 08:59:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <53AB1421-BC0C-4F29-B799-721553B3B1DA@FreeBSD.org> References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> <52204746.2070900@freebsd.org> <3C11736737A54D84B80B1D27406F8039@FreeBSD.org> To: Jonathan Anderson X-Mailer: Apple Mail (2.1508) Cc: "Sam Fourman Jr." , toolchain@FreeBSD.org, "freebsd-current@freebsd.org CURRENT" , Boris Samorodov , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 07:59:15 -0000 On 30 Aug 2013, at 08:56, Jonathan Anderson = wrote: > Wouldn't this mean that we can't build base using the shipped-in-base = g++? If we have C++ in base, we don't ship libstdc++ and g++ can't work = with libc++, then people wanting to compile the base system with gcc/g++ = will have to install a libstdc++ package. People wanting to build base with g++ will still have to explicitly = enable the build of libstdc++, yes. That's only really an issue for = 10.0 though, because in 10.1 we won't be able to build clang (or lldb) = with either g++ from base or our libstdc++ from base, as both use C++11 = features. David From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 09:35:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 35482BA0 for ; Fri, 30 Aug 2013 09:35:35 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 01FAD257C for ; Fri, 30 Aug 2013 09:35:34 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id k14so2830967iea.33 for ; Fri, 30 Aug 2013 02:35:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=eIAU+Oh4XvXwPRkcIfXfqenl3jH1sLtMkmzLKSC9IFs=; b=U2UGzg1M0ImpM4RyC5/8UPAE5hibrdpAjdeP3YaDEg9WnzbP6g4tTDxGX4+YPAzKtV lrwLXsJ493g7j6WBGl5r1GdFpShPzTEEcOFhwNQCPKYvILPsmd2WAs7NEx8EOXSwGtDU aeCMJaGjxi5xOHDWFynE60vuz+gADraJ/5CUS8ep+oekn7RUz8kiclceOMO0vlm0/tQi G950gE1Vywnh19HWCx9OuK5qEGmGabx8hycIj9bs6oXkALuv4cVrLZD7MS0RV45QB6jl MrVdHVynbSij62/LMRBHVUKNm3U7+SuYmdFyyBN/D0fNx8qcF5ZFj2bHHbwr2xS4y2y1 tHFA== X-Gm-Message-State: ALoCoQkyNuqUaA0n6w/xV83tUNkI7SPbPeXelte3vuEbf4J1MrPF437RHk7t512TVSS+RmE8Ip4n X-Received: by 10.50.39.84 with SMTP id n20mr1667901igk.14.1377855328376; Fri, 30 Aug 2013 02:35:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.158.74 with HTTP; Fri, 30 Aug 2013 02:35:12 -0700 (PDT) In-Reply-To: <52203EC9.4060808@bitfrost.no> References: <521B9CD7.8010902@bitfrost.no> <521C6C26.7050207@bitfrost.no> <52203EC9.4060808@bitfrost.no> From: "Lundberg, Johannes" Date: Fri, 30 Aug 2013 11:35:12 +0200 Message-ID: Subject: Re: xhci broken on 10-CURRENT and 2013 MacBook Air? To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current , "freebsd-usb@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 09:35:35 -0000 Hi Hans I tried the patch and the result is the same. However, I found the command that causes the freeze. Also, it is not always it freezes but maybe 9/10 reboots or more frequently. At the end of the function xhci_start_controller(..) there is a for loop: 487 for (i = 0; i != 100; i++) { 488 usb_pause_mtx(NULL, hz / 100); 489 temp = XREAD4(sc, oper, XHCI_USBSTS) & XHCI_STS_HCH; 490 if (!temp) 491 break; 492 } and it freezes at usb_pause_mtx(...) value of i is 0 value of hz is 1000 Johannes Lundberg BRILLIANTSERVICE CO., LTD. On Fri, Aug 30, 2013 at 8:42 AM, Hans Petter Selasky wrote: > On 08/30/13 08:09, Lundberg, Johannes wrote: > >> What I got so far is this; >> >> USB driver from current stops after >> xhci0: 32 byte context size >> >> While driver from 9.1 continues to the next step which is >> usbus0 on xhci0 >> xhci0: usbpf: Attached >> ... >> >> I can try adding some printf's in the code and see if I get some more.. >> >> > Hi, > > There are only a few commits to the xhci driver since 9.1 was releases, so > this should be easy to figure out. > > I'm doing a wild guess. Can you try the attached patch. It will ensure > that any BIOS generated interrupts get cleared before we reset the > controller. > > --HPS > > From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 10:11:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 58275CC1; Fri, 30 Aug 2013 10:11:55 +0000 (UTC) (envelope-from hps@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id D41E32814; Fri, 30 Aug 2013 10:11:54 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta.bitpro.no (Postfix) with ESMTP id BC84D7A234; Fri, 30 Aug 2013 12:11:52 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id B4FAB8F503B; Fri, 30 Aug 2013 12:12:05 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pejz1jwiK1cK; Fri, 30 Aug 2013 12:12:04 +0200 (CEST) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) by mail.lockless.no (Postfix) with ESMTPSA id C4E7B8F503A; Fri, 30 Aug 2013 12:12:04 +0200 (CEST) Message-ID: <52207030.8050107@bitfrost.no> Date: Fri, 30 Aug 2013 12:13:04 +0200 From: Hans Petter Selasky Organization: Bitfrost A/S User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130522 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Lundberg, Johannes" Subject: Re: xhci broken on 10-CURRENT and 2013 MacBook Air? References: <521B9CD7.8010902@bitfrost.no> <521C6C26.7050207@bitfrost.no> <52203EC9.4060808@bitfrost.no> In-Reply-To: Content-Type: multipart/mixed; boundary="------------070205030908040509070208" Cc: FreeBSD Current , "freebsd-usb@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 10:11:55 -0000 This is a multi-part message in MIME format. --------------070205030908040509070208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08/30/13 11:35, Lundberg, Johannes wrote: > Hi Hans > > I tried the patch and the result is the same. However, I found the command > that causes the freeze. Also, it is not always it freezes but maybe 9/10 > reboots or more frequently. > > At the end of the function xhci_start_controller(..) there is a for loop: > > 487 for (i = 0; i != 100; i++) { > 488 usb_pause_mtx(NULL, hz / 100); > 489 temp = XREAD4(sc, oper, XHCI_USBSTS) & XHCI_STS_HCH; > 490 if (!temp) > 491 break; > 492 } > > and it freezes at usb_pause_mtx(...) > value of i is 0 > value of hz is 1000 Hi, Can you try the attached patch? I think this is a problem inside DELAY(). Maybe you have to select another timing source for DELAY(), mav @ CC'ed? --HPS --------------070205030908040509070208 Content-Type: text/x-patch; name="pause_fix.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="pause_fix.diff" === sys/kern/kern_synch.c ================================================================== --- sys/kern/kern_synch.c (revision 254832) +++ sys/kern/kern_synch.c (local) @@ -356,11 +356,8 @@ int pause_sbt(const char *wmesg, sbintime_t sbt, sbintime_t pr, int flags) { - int sbt_sec; + KASSERT(sbt >= 0, ("pause: timeout must be >= 0")); - sbt_sec = sbintime_getsec(sbt); - KASSERT(sbt_sec >= 0, ("pause: timo must be >= 0")); - /* silently convert invalid timeouts */ if (sbt == 0) sbt = tick_sbt; @@ -370,11 +367,14 @@ * We delay one second at a time to avoid overflowing the * system specific DELAY() function(s): */ - while (sbt_sec > 0) { + while (sbt >= SBT_1S) { DELAY(1000000); - sbt_sec--; + sbt -= SBT_1S; } - DELAY((sbt & 0xffffffff) / SBT_1US); + /* Do the delay remainder */ + sbt /= SBT_1US; + if (sbt != 0) + DELAY(sbt); return (0); } return (_sleep(&pause_wchan[curcpu], NULL, 0, wmesg, sbt, pr, flags)); --------------070205030908040509070208-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 08:53:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6630C584 for ; Fri, 30 Aug 2013 08:53:19 +0000 (UTC) (envelope-from biddut.mitra@ovi.com) Received: from nm37.bullet.mail.ne1.yahoo.com (nm37.bullet.mail.ne1.yahoo.com [98.138.229.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 29945231E for ; Fri, 30 Aug 2013 08:53:18 +0000 (UTC) Received: from [127.0.0.1] by nm37.bullet.mail.ne1.yahoo.com with NNFMP; 30 Aug 2013 08:50:18 -0000 Received: from [98.138.101.129] by nm37.bullet.mail.ne1.yahoo.com with NNFMP; 30 Aug 2013 08:47:39 -0000 Received: from [66.196.81.171] by tm17.bullet.mail.ne1.yahoo.com with NNFMP; 30 Aug 2013 08:47:39 -0000 Received: from [98.139.212.233] by tm17.bullet.mail.bf1.yahoo.com with NNFMP; 30 Aug 2013 08:47:39 -0000 Received: from [127.0.0.1] by omp1042.mail.bf1.yahoo.com with NNFMP; 30 Aug 2013 08:47:39 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 398664.27240.bm@omp1042.mail.bf1.yahoo.com Received: (qmail 94333 invoked by uid 60001); 30 Aug 2013 08:47:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ovi.com; s=s1024; t=1377852459; bh=GNHFLPzkdLHbpg2z58hc8fDJSPaj3OMySPAa2BtjgbQ=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=Ldy4+LuZyDvySyLh2+oM1Ivo5m2p7inRoZYv2pAs9m3l8cJ2QISfx88QP3NXK5esv7qscXEpuAsNDQp8JBEOIRZeGP9RP+DlOtmaEocCveZzTqB9t0im6EzbX1aCtde9Gy0jtn5ngzxoDfpj18RlvDKB1SdgdFRuum734Z5p8dA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=ovi.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=cHw7i7SUxnesvlTt8wXXXR5PLkMqmtr+WNNcdtrBEalbs+CnJJhum1Zpru3jeG2ZB1BGZQ4UwoZnFcHj+cAu7BXjXbHhqvftGXhKAZnulQ1MoP/aU+su1xxKK12K97Ta9VmA3LwkwzQwzR5IkmMz2J6ysb+mRDe5275XKsICKIE=; X-YMail-OSG: b8qv.NoVM1nWIYa8zQ55bxbDn5rs2b9SrZMBNnRuX36mYBf Ipx_4.r67ZINkdM7_4KjrLynf3hXQbVHGyl9qyFsYuof2jmk_bxhZf9gC4dv 7YOHULRWOshYp_h9RYthGHj6RFCgPzikdfd7gfBpuWI5ZuhSuJYio9zzjsQD gf457zCHb4oa41Hw9GYy8tqEDxbqnYcM3bwPWPM_ZdG8ueBM1nM38mth5EJq 2GyJsl2PvJcsE6XCoxYSm4rF92hprthb4tZX80KOD5RNJQmZCKsSFabl5dSi 8iosY_QK2tnkFzgIjbHUpyWgNGqETFjCbLlzOA2PC77sVTUgmup.iNpw56Fy 92X2rLbj4V_r4sl_VDk_MDldBB5WLKcQG1gpvwVthZKqEA4eK6EXM_r03J3w lpGjTmMkkAjbrfWoV2qqUTpe0TK2LUpVnYGsF_zi35pRKwQjgxtwDFsCBpWM yJKPUDS5W.Zb3D1CpCh49in7_hXClynoW_FitPKNdeW.3s6vWRC0RBvK5TU2 uo6Paf8d7ik_fbWqoTVjb_UtWFHkr17b_mQC3TzqQ88hPTmQqn2E- Received: from [114.130.66.7] by web162103.mail.bf1.yahoo.com via HTTP; Fri, 30 Aug 2013 01:47:39 PDT X-Rocket-MIMEInfo: 002.001, IyB1bmFtZSAtYQpGcmVlQlNEIFJuRCAxMC4wLUNVUlJFTlQgRnJlZUJTRCAxMC4wLUNVUlJFTlQgIzAgcjI1NDc2NjogU2F0IEF1ZyAyNCAxNDozNjowOCBCRFQgMjAxM8KgwqDCoMKgIGJpZGR1dEBSbkQ6L3Vzci9vYmovdXNyL3NyYy9zeXMvR0VORVJJQ8KgIGkzODYKIyBzdm4gdXBkYXRlIC91c3Ivc3JjClNoYXJlZCBvYmplY3QgImxpYnNzbC5zby42IiBub3QgZm91bmQsIHJlcXVpcmVkIGJ5ICJsaWJzZXJmLTEuc28uMCIKCnNvbHV0aW9uCsKgcm9vdEBSbkQ6L3Vzci9zcmMgIyBsbiAtcyAvdXNyL2xpYi8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.156.576 Message-ID: <1377852459.92145.YahooMailNeo@web162103.mail.bf1.yahoo.com> Date: Fri, 30 Aug 2013 01:47:39 -0700 (PDT) From: biddut.mitra@ovi.com Subject: Shared object "libssl.so.6" not found solution To: "freebsd-current@freebsd.org" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 30 Aug 2013 11:32:19 +0000 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: biddut.mitra@ovi.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 08:53:19 -0000 # uname -a=0AFreeBSD RnD 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r254766: Sat = Aug 24 14:36:08 BDT 2013=A0=A0=A0=A0 biddut@RnD:/usr/obj/usr/src/sys/GENERI= C=A0 i386=0A# svn update /usr/src=0AShared object "libssl.so.6" not found, = required by "libserf-1.so.0"=0A=0Asolution=0A=A0root@RnD:/usr/src # ln -s /= usr/lib/libssl.so.7 /usr/lib/libssl.so.6=0Aroot@RnD:/usr/src # From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 11:38:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4F521349 for ; Fri, 30 Aug 2013 11:38:35 +0000 (UTC) (envelope-from florent@peterschmitt.fr) Received: from peterschmitt.fr (peterschmitt.fr [5.135.177.31]) by mx1.freebsd.org (Postfix) with ESMTP id 16D042CEC for ; Fri, 30 Aug 2013 11:38:34 +0000 (UTC) Received: from [192.168.0.128] (4ab54-4-88-163-248-31.fbx.proxad.net [88.163.248.31]) by peterschmitt.fr (Postfix) with ESMTPSA id B840A6665 for ; Fri, 30 Aug 2013 13:38:32 +0200 (CEST) Message-ID: <52208437.3050409@peterschmitt.fr> Date: Fri, 30 Aug 2013 13:38:31 +0200 From: Florent Peterschmitt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130806 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Shared object "libssl.so.6" not found solution References: <1377852459.92145.YahooMailNeo@web162103.mail.bf1.yahoo.com> In-Reply-To: <1377852459.92145.YahooMailNeo@web162103.mail.bf1.yahoo.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jsdHHiAriqhpRPFefFHv1NoOnTIAHLq2l" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 11:38:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jsdHHiAriqhpRPFefFHv1NoOnTIAHLq2l Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Le 30/08/2013 10:47, biddut.mitra@ovi.com a =E9crit : > # uname -a > FreeBSD RnD 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r254766: Sat Aug 24 14= :36:08 BDT 2013 biddut@RnD:/usr/obj/usr/src/sys/GENERIC i386 > # svn update /usr/src > Shared object "libssl.so.6" not found, required by "libserf-1.so.0" >=20 > solution > root@RnD:/usr/src # ln -s /usr/lib/libssl.so.7 /usr/lib/libssl.so.6 Uhu =D4.o That's *not* a solution, no more than a workaround, it's bad, i= t hurts brains=85 The real solution is to rebuild subversion. --=20 Florent Peterschmitt | Please: florent@peterschmitt.fr | * Avoid HTML/RTF in E-mail. +33 (0)6 64 33 97 92 | * Send PDF for documents. http://florent.peterschmitt.fr | * Trim your quotations. Really. Proudly powered by Open Source | Thank you :) --jsdHHiAriqhpRPFefFHv1NoOnTIAHLq2l Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSIIQ3AAoJEFr01BkajbiBNaEP/1w7tdwpdpU+Kyw9fZ9Thf+4 Jes6WZGt9q3NtFG2GtmutpDYTnEJ4b3qR1pvTjb0jKvtCFJrHE+Vu2T75Q5JqEr8 o5IFeii5CrgvWxfR0JfTdc9IQIa1qtFRNq1uwS9qllIlVwSywLGmgw6zSCz7USej za55r/SuIx3vHJGtZMQYmmz2oALytCcSG5iq8Zm8cA2jjIdZJrWeGOddbrVJl5uA mcakXZkpgufJJ0Hf8Oq2LnTvpCksA0EFyTUOnADuC9t5ymU+ZnuqQBgKb7Icrxhp Eyv/21Idi+Ay3unzt3pACZigjDiZWwdeiFIAt8vaEW30lC2x8IrsSK+f0iX0tmjx m3OT+e9XZ2zy/LQCfpp2Ob2fEO4RQmyGrRUij6VCYeAiEam9DWcVgPfuNVHl1CPM t0Gj/9IGW0bzT7x2XejOLvKJ3qnLKCg0gpxwO79wjFqg5qLMpB0lyIqwr6xBu7Me sNHOet/iID96p4OeQm697CM6n/KYM4l5xoIXgNtLbI20oiSmfg3R47LYd7hMJMNC J+w10Om9yw916gjpfnj/QLySv9GUcqkIFMYZX2TRWfHBLs3wagfagX/lQh+FJVF6 06xiyZfH+u3nReRlU1EIAUbG2kO24ziGkU+IeFr0XcRMb5py3nvS0SdtI/ZSPEiI gCRSe/RkU3Fi6M0HnIQH =fbFM -----END PGP SIGNATURE----- --jsdHHiAriqhpRPFefFHv1NoOnTIAHLq2l-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 11:39:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 19C46540 for ; Fri, 30 Aug 2013 11:39:58 +0000 (UTC) (envelope-from florent@peterschmitt.fr) Received: from peterschmitt.fr (peterschmitt.fr [5.135.177.31]) by mx1.freebsd.org (Postfix) with ESMTP id D46652D01 for ; Fri, 30 Aug 2013 11:39:57 +0000 (UTC) Received: from [192.168.0.128] (4ab54-4-88-163-248-31.fbx.proxad.net [88.163.248.31]) by peterschmitt.fr (Postfix) with ESMTPSA id 0675B667A for ; Fri, 30 Aug 2013 13:39:56 +0200 (CEST) Message-ID: <5220848C.6050109@peterschmitt.fr> Date: Fri, 30 Aug 2013 13:39:56 +0200 From: Florent Peterschmitt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130806 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Shared object "libssl.so.6" not found solution References: <1377852459.92145.YahooMailNeo@web162103.mail.bf1.yahoo.com> <52208437.3050409@peterschmitt.fr> In-Reply-To: <52208437.3050409@peterschmitt.fr> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="m1imUc1DfxDxFD1RdF8OinbDDjnlca4h1" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 11:39:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --m1imUc1DfxDxFD1RdF8OinbDDjnlca4h1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Le 30/08/2013 13:38, Florent Peterschmitt a =E9crit : > The real solution is to rebuild subversion. Woops, it's to rebuild www/serf --m1imUc1DfxDxFD1RdF8OinbDDjnlca4h1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSIISMAAoJEFr01BkajbiBZHMP/1lyZKMoCRrh7Anr3fUVgsW8 0apvUN3YQ3LFkidHeoJgO2TFytXOpsBGmmVOu4rcOymueYiLEbuwXLz4GcGr9mYe 3/kr1lxCoPvIU2vUtLEnh9P9Uob0HTak7k38wjIsWZkDM4C+0q31epQJPRMuxD2Z TmjlbN8WRngMDzl6RcXvgTKLTTqk+OR4j7ZQ3/7Va1sPFRjpVREFSenfOIw89GfY +X7IroM4XjN2eK3MEwokrZA5cQvyZ0MgxvvSK15HtxLJfTDofjOdVueHP5gKfKSK C671wNLqPiNgCroHAppyHZhxRPfj38ic/ocK9OA67vAvY55QWJ+4UeKzyOfK97e3 u6SEBvN/57mwnnuGkFM+218Pu4QUgEpkNmhOdqqgG+WmR+iAV1k0H6Zk+L3j8Eom q7ROAWekLgGvHT1anUeRvkM8BdPPRZ5Mv9Hg/KgxDWQtgb2b23Ep0+pHWlVsvNmc HoJdTjVBIZRP66SfNq+S4S17KxJOgIz7s7SQz4O6KHBIcbRhWfWGjd4rwH9FFyK6 VhQ+Ad7lrPgeqAWx4eZOzyOpgXtIjX/pPGZsRDZJl9m7cCPffHG2fEYjx76mjQpm xeCFJ94quoGKSQ86FxAe6XvNoFcSTFDfUS00cEe2LI4Y3Mlw0j4E5v/cF4Egq8QV UV6v6K0aWv9HKgoqtnV/ =Trmu -----END PGP SIGNATURE----- --m1imUc1DfxDxFD1RdF8OinbDDjnlca4h1-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 11:54:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 06D14C37 for ; Fri, 30 Aug 2013 11:54:37 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C721B2DEB for ; Fri, 30 Aug 2013 11:54:36 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id m16so2574133ieq.38 for ; Fri, 30 Aug 2013 04:54:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=pQRovuPWmWz+mqLe6fbANCj99HvL0VVdN1DQagEnEfM=; b=a1HGBIb50Obiu1s0YWKmCQsc8EuI4xTz0/ptaGugSUkph4qRmnlxQ+j6SetyoX6qeW WEfuqG3rU+rbaILClYchGWnSFbcXs0xl+YKW9pqIwVVy890Ssqt98q+47PY91NKzI0+5 hvjEkXp2AYcMZKCw6ma7nkLJ9IQwGmyPN2FDj9UqgeyWL4vGsmYi6Ec+wQ2IOwdnSk5S TSmmXPFo0H8ji/LZvrgr7zGYCSEpyqQy3cA3/6fssF7I5SDBrVyPVtEEGBOVnaQr5rlG 6mhdYmbq22H5uLpOflw+CDvjGLDe6+j8dBLSaBogvbX6YDnGfsDJpXOONARXgoSPssoV Z4zw== X-Gm-Message-State: ALoCoQkISBQxlUfuQ93JOkYyWfG5DrMEAP6jvniCKpDrE//L2Nc8ptXREMje6ICCYhj8mS3yx3da X-Received: by 10.42.223.134 with SMTP id ik6mr5067774icb.4.1377863670801; Fri, 30 Aug 2013 04:54:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.158.74 with HTTP; Fri, 30 Aug 2013 04:54:15 -0700 (PDT) In-Reply-To: <52207030.8050107@bitfrost.no> References: <521B9CD7.8010902@bitfrost.no> <521C6C26.7050207@bitfrost.no> <52203EC9.4060808@bitfrost.no> <52207030.8050107@bitfrost.no> From: "Lundberg, Johannes" Date: Fri, 30 Aug 2013 13:54:15 +0200 Message-ID: Subject: Re: xhci broken on 10-CURRENT and 2013 MacBook Air? To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current , "freebsd-usb@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 11:54:37 -0000 Still got the same behaviour after applying the patch... Johannes Lundberg BRILLIANTSERVICE CO., LTD. On Fri, Aug 30, 2013 at 12:13 PM, Hans Petter Selasky wrote: > On 08/30/13 11:35, Lundberg, Johannes wrote: > >> Hi Hans >> >> I tried the patch and the result is the same. However, I found the command >> that causes the freeze. Also, it is not always it freezes but maybe 9/10 >> reboots or more frequently. >> >> At the end of the function xhci_start_controller(..) there is a for loop: >> >> 487 for (i = 0; i != 100; i++) { >> 488 usb_pause_mtx(NULL, hz / 100); >> 489 temp = XREAD4(sc, oper, XHCI_USBSTS) & XHCI_STS_HCH; >> 490 if (!temp) >> 491 break; >> 492 } >> >> and it freezes at usb_pause_mtx(...) >> value of i is 0 >> value of hz is 1000 >> > > Hi, > > Can you try the attached patch? > > I think this is a problem inside DELAY(). Maybe you have to select another > timing source for DELAY(), mav @ CC'ed? > > --HPS > > From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 12:25:02 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 31F5C81C; Fri, 30 Aug 2013 12:25:02 +0000 (UTC) (envelope-from hps@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id AFB852FD9; Fri, 30 Aug 2013 12:25:01 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta.bitpro.no (Postfix) with ESMTP id 8C4FB7A1D6; Fri, 30 Aug 2013 14:24:59 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id B4F8E8F50DC; Fri, 30 Aug 2013 14:25:12 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I529+-rpETBs; Fri, 30 Aug 2013 14:25:12 +0200 (CEST) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) by mail.lockless.no (Postfix) with ESMTPSA id D94918F50DA; Fri, 30 Aug 2013 14:25:11 +0200 (CEST) Message-ID: <52208F63.4060308@bitfrost.no> Date: Fri, 30 Aug 2013 14:26:11 +0200 From: Hans Petter Selasky Organization: Bitfrost A/S User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130522 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Lundberg, Johannes" Subject: Re: xhci broken on 10-CURRENT and 2013 MacBook Air? References: <521B9CD7.8010902@bitfrost.no> <521C6C26.7050207@bitfrost.no> <52203EC9.4060808@bitfrost.no> <52207030.8050107@bitfrost.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Motin , FreeBSD Current , "freebsd-usb@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 12:25:02 -0000 On 08/30/13 13:54, Lundberg, Johannes wrote: > Still got the same behaviour after applying the patch... > > Johannes Lundberg > BRILLIANTSERVICE CO., LTD. I've seen something similar with my mac, that the boot menu counter is not always counting stable. I think this problem is inside the following function, if you say that the code is stuck inside pause(): sys/x86/isa/clock.c:DELAY() Maybe you can try this patch instead. Just apply it by hand: === sys/x86/isa/clock.c ================================================================== --- sys/x86/isa/clock.c (revision 254832) +++ sys/x86/isa/clock.c (local) @@ -262,6 +262,7 @@ timecounter_get_t *func; uint64_t end, freq, now; u_int last, mask, u; + int overflow = 0; tc = timecounter; freq = atomic_load_acq_64(&tsc_freq); @@ -281,6 +282,11 @@ sched_pin(); last = func(tc) & mask; do { + if (--overflow == 0) { + printf("DELAY overflow\n"); + break; + } + cpu_spinwait(); u = func(tc) & mask; if (u < last) @@ -304,6 +310,7 @@ DELAY(int n) { int delta, prev_tick, tick, ticks_left; + int overflow = 0; #ifdef DELAYDEBUG int getit_calls = 1; int n1; @@ -365,6 +372,10 @@ / 1000000; while (ticks_left > 0) { + if (--overflow == 0) { + printf("DELAY overflow\n"); + break; + } #ifdef KDB if (kdb_active) { #ifdef PC98 --HPS From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 12:27:39 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7BF35A0B for ; Fri, 30 Aug 2013 12:27:39 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 130C52016 for ; Fri, 30 Aug 2013 12:27:38 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id z11so1494452wgg.34 for ; Fri, 30 Aug 2013 05:27:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=LlqzitSTQbYlBk2NNKI7ULSZCxr5qS0rFhpsNThETTc=; b=DLZyQZgJczKnMzKrnbGWuf6Ei5V07Yp51ZeFqy7tMQ6s/4jsuyBcdLbuGOY2kH8vo0 xJcWyhZGVBNoz8giGp4t2aVDsYBGDVsBN6a+B9SIz34oOMT32aezbbHbnumrsnKIX0vw wdLW89XPwsVcQrzPxXEd1CAuqsbRqVGRyOgnWKHubnp8mmlG9XVdoPfcsVMIIs7OZjU1 NhmjKK30F/AEvM/R5F7BZgVXRSZmJzA0ukAB5P+xWsbelYf4JYt+3EBTI5iibpDnuTYq 51Rz6iQ9/CRSiT3jzGo6gbYU3tG7SFFO5BBDflCEmbe/QasyFMBdAh1dJN8Q5IhObT72 jZ5A== MIME-Version: 1.0 X-Received: by 10.180.37.164 with SMTP id z4mr2277637wij.30.1377865657284; Fri, 30 Aug 2013 05:27:37 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.146.2 with HTTP; Fri, 30 Aug 2013 05:27:37 -0700 (PDT) In-Reply-To: <5220848C.6050109@peterschmitt.fr> References: <1377852459.92145.YahooMailNeo@web162103.mail.bf1.yahoo.com> <52208437.3050409@peterschmitt.fr> <5220848C.6050109@peterschmitt.fr> Date: Fri, 30 Aug 2013 05:27:37 -0700 X-Google-Sender-Auth: UKOZ69DRWV2II2oNit_f6WDm3uI Message-ID: Subject: Re: Shared object "libssl.so.6" not found solution From: Adrian Chadd To: Florent Peterschmitt Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 12:27:39 -0000 ... well, this is why Peter committed svnlite to -HEAD. To avoid this kind of not-easy-to-recover-from breakage.. -adrian From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 13:19:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A56A63AA for ; Fri, 30 Aug 2013 13:19:44 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 70B6123F8 for ; Fri, 30 Aug 2013 13:19:44 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id c10so2725261ieb.31 for ; Fri, 30 Aug 2013 06:19:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=oZJ+3IzLFrt0LWypO0OwuaQ5cpFUTn9SQeKw7zkjgC0=; b=V6SITTAxQzlPRsySBq8XqVPPMgTA0Ero3Hr1r9ZnDBRlzvp52DyaULO5ryQ2z44EMW QvCJh8Pr9rGF510xN6KFTiA/vTcgm1p8vrUJ1TLsMSl8iArSj7DRfwCUuCjHP7KRNwNX Clo3KsUWrLvCRNfMBIDQTZcEn1Y1MnRGFeuvIHwrP6rnXkRZbq9/2e0wpNKvGfumyaH/ RHrhs+3cBpjHdZnPV+Yy9SByBjm1cd7IT+XwWf+exCozenELVIGBF/oLkNaKRQNyV5Mi ZOdUFo3r4cbr3bNn+Curo+PhgsKjhUmmjvPjp9OzXkb7OflirAVzwQMxAmlGlSm3YCQB 2Obg== X-Gm-Message-State: ALoCoQkRrEjaqXxrSgZcVwPO3dGDzXh7fLyac7or1xz4m32OVVnzcxgmB5pkMEhfzB/IF9GQr/Ys X-Received: by 10.50.20.232 with SMTP id q8mr2412431ige.0.1377868777921; Fri, 30 Aug 2013 06:19:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.158.74 with HTTP; Fri, 30 Aug 2013 06:19:22 -0700 (PDT) In-Reply-To: <52208F63.4060308@bitfrost.no> References: <521B9CD7.8010902@bitfrost.no> <521C6C26.7050207@bitfrost.no> <52203EC9.4060808@bitfrost.no> <52207030.8050107@bitfrost.no> <52208F63.4060308@bitfrost.no> From: "Lundberg, Johannes" Date: Fri, 30 Aug 2013 15:19:22 +0200 Message-ID: Subject: Re: xhci broken on 10-CURRENT and 2013 MacBook Air? To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Alexander Motin , FreeBSD Current , "freebsd-usb@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 13:19:44 -0000 Hi Hans I tried that too and no change... But, the variable overflow you introduced, it is never increased, right? So, it will never become zero... Johannes Lundberg BRILLIANTSERVICE CO., LTD. On Fri, Aug 30, 2013 at 2:26 PM, Hans Petter Selasky wrote: > On 08/30/13 13:54, Lundberg, Johannes wrote: > >> Still got the same behaviour after applying the patch... >> >> Johannes Lundberg >> BRILLIANTSERVICE CO., LTD. >> > >> > > I've seen something similar with my mac, that the boot menu counter is not > always counting stable. I think this problem is inside the following > function, if you say that the code is stuck inside pause(): > > sys/x86/isa/clock.c:DELAY() > > Maybe you can try this patch instead. Just apply it by hand: > > === sys/x86/isa/clock.c > ==============================**==============================**====== > --- sys/x86/isa/clock.c (revision 254832) > +++ sys/x86/isa/clock.c (local) > @@ -262,6 +262,7 @@ > timecounter_get_t *func; > uint64_t end, freq, now; > u_int last, mask, u; > + int overflow = 0; > > tc = timecounter; > freq = atomic_load_acq_64(&tsc_freq); > @@ -281,6 +282,11 @@ > sched_pin(); > last = func(tc) & mask; > do { > + if (--overflow == 0) { > + printf("DELAY overflow\n"); > + break; > + } > + > cpu_spinwait(); > u = func(tc) & mask; > if (u < last) > @@ -304,6 +310,7 @@ > DELAY(int n) > { > int delta, prev_tick, tick, ticks_left; > + int overflow = 0; > #ifdef DELAYDEBUG > int getit_calls = 1; > int n1; > @@ -365,6 +372,10 @@ > / 1000000; > > while (ticks_left > 0) { > + if (--overflow == 0) { > + printf("DELAY overflow\n"); > + break; > + } > #ifdef KDB > if (kdb_active) { > #ifdef PC98 > > > --HPS > From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 13:30:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1F08CCC2 for ; Fri, 30 Aug 2013 13:30:12 +0000 (UTC) (envelope-from geo.liaskos@gmail.com) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ADA9624FC for ; Fri, 30 Aug 2013 13:30:11 +0000 (UTC) Received: by mail-ee0-f44.google.com with SMTP id b47so928139eek.3 for ; Fri, 30 Aug 2013 06:30:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=2RynM5IfODeOnNTmDhsiPBl+MTwKNXM7HS+0YNH25Qg=; b=UZFr5LZe3CF1Qno/Q8o1EX6K4KjNorzwjnGNgw33ZmlWoHvQRrcCS6X7s8RsxqQaI/ yiJEE4whzXLdB55N9PcbmXt71CabAjhoiZkPCZzy30vw5SL4UjeCQAQcOg9Seew6IPt+ 4UTNIzyrZ4W62Cf3ExNjuobpmPm4ptnGdOmaQQfjKOXrn0PKeagGi4M2VQ2/toVVYyDr SS3Ev723wm5iWt6EMSo71vH6MyFXzlxEkCYAmmRJlhZEBRLlhq/O1R86E2kCZuS19PHs AXfCRS9qObFqwJufGk0hhE5B/EeydzKuZgcTZ1E4Vc1FGcWIPwX5a0kKJiBM2WaJTlZh 5cOw== MIME-Version: 1.0 X-Received: by 10.14.198.72 with SMTP id u48mr3804003een.55.1377869409408; Fri, 30 Aug 2013 06:30:09 -0700 (PDT) Received: by 10.223.72.5 with HTTP; Fri, 30 Aug 2013 06:30:09 -0700 (PDT) Date: Fri, 30 Aug 2013 16:30:09 +0300 Message-ID: Subject: Default kern.ipc.shm_allow_removed to 1 From: George Liaskos To: freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 13:30:12 -0000 Would it be feasible to change the default for 10? There is a lot of code that depends on the following behavior: void* address = shmat(shmkey, NULL /* desired address */, 0 /* flags */); // Here we mark the shared memory for deletion. Since we attached it in the // line above, it doesn't actually get deleted but, if we crash, this means // that the kernel will automatically clean it up for us. shmctl(shmkey, IPC_RMID, 0); if (address == kInvalidAddress) return NULL; The above snip is from Google Chrome, under FreeBSD with the current defaults that memory becomes unusable. If you don't follow that route it becomes extremely difficult to cleanup especially in a beast like Chrome. >From what I understand PC-BSD defaults to 1, OpenBSD and Linux also allow this behavior. Am I missing something obvious here? It seems to me that the pragmatic approach is to change this. Regards, George From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 13:31:16 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E874BDFD; Fri, 30 Aug 2013 13:31:16 +0000 (UTC) (envelope-from hps@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id 9E034253B; Fri, 30 Aug 2013 13:31:16 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta.bitpro.no (Postfix) with ESMTP id DF27E7A164; Fri, 30 Aug 2013 15:31:15 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 0D9F48F5134; Fri, 30 Aug 2013 15:31:29 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPy454qBpgSy; Fri, 30 Aug 2013 15:31:28 +0200 (CEST) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) by mail.lockless.no (Postfix) with ESMTPSA id C58FB8F5135; Fri, 30 Aug 2013 15:31:27 +0200 (CEST) Message-ID: <52209EEC.6060609@bitfrost.no> Date: Fri, 30 Aug 2013 15:32:28 +0200 From: Hans Petter Selasky Organization: Bitfrost A/S User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130522 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Lundberg, Johannes" Subject: Re: xhci broken on 10-CURRENT and 2013 MacBook Air? References: <521B9CD7.8010902@bitfrost.no> <521C6C26.7050207@bitfrost.no> <52203EC9.4060808@bitfrost.no> <52207030.8050107@bitfrost.no> <52208F63.4060308@bitfrost.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Motin , FreeBSD Current , "freebsd-usb@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 13:31:17 -0000 On 08/30/13 15:19, Lundberg, Johannes wrote: > Hi Hans > > I tried that too and no change... But, the variable overflow you > introduced, it is never increased, right? So, it will never become zero... > It will become zero when it wraps. Maybe 2**32 is too long. You could add a printf while it is running, and see if it goes == 1000000 for example. --HPS > Johannes Lundberg > BRILLIANTSERVICE CO., LTD. > > > On Fri, Aug 30, 2013 at 2:26 PM, Hans Petter Selasky wrote: > >> On 08/30/13 13:54, Lundberg, Johannes wrote: >> >>> Still got the same behaviour after applying the patch... >>> >>> Johannes Lundberg >>> BRILLIANTSERVICE CO., LTD. From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 13:38:51 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7E0A6267; Fri, 30 Aug 2013 13:38:51 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3B1042597; Fri, 30 Aug 2013 13:38:50 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r7UDchn0056534; Fri, 30 Aug 2013 13:38:43 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id qqzce2hvvfj8ufc7u4pem92s52; Fri, 30 Aug 2013 13:38:43 +0000 (UTC) (envelope-from tim@kientzle.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: GCC withdraw From: Tim Kientzle In-Reply-To: <53AB1421-BC0C-4F29-B799-721553B3B1DA@FreeBSD.org> Date: Fri, 30 Aug 2013 06:38:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <87CD56E4-98CE-4BA4-A9C6-433F9196A5B4@kientzle.com> References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> <52204746.2070900@freebsd.org> <3C11736737A54D84B80B1D27406F8039@FreeBSD.org> <53AB1421-BC0C-4F29-B799-721553B3B1DA@FreeBSD.org> To: David Chisnall X-Mailer: Apple Mail (2.1508) Cc: FreeBSD Current , toolchain@FreeBSD.org, "freebsd-current@freebsd.org CURRENT" , "Sam Fourman Jr." , Boris Samorodov , Jonathan Anderson X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 13:38:51 -0000 I've been reading this thread and must confess that I'm a little = confused about what exactly is being discussed. * I presume we've all agreed that "clang" is installed by default in = FreeBSD-10. * I presume everyone agrees that "cc" is "clang" in FreeBSD-10. * There obviously needs to be a "gcc" command in FreeBSD-10, since "cc" = and "gcc" are synonyms in so many people's finger-memory. Is the debate here just a question of whether "gcc" is "clang" or "the = *real* GCC"? Would it be feasible to install GCC as "gcc42" or something similar so people could still reach it regardless of what the "gcc" alias pointed to? On 30 Aug 2013, at 08:56, Jonathan Anderson = wrote: > ... then people wanting to compile the base system with gcc/g++ ... I'm still curious *why* some people want this? Personally, I would rather compile the base system with the *supported* compiler. Today, on FreeBSD-CURRENT/x86 and FreeBSD-CURRENT/amd64, that is clang. On Aug 30, 2013, at 12:18 AM, Julian Elischer = wrote: > Clang is new. clang WILL HAVE BUGS. Based on my own experience, I would put this rather differently: GCC and Clang are COMPILERS. Therefore, they have DIFFERENT BUGS. This is why I worry about having "cc" and "gcc" be different compilers. Tim From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 13:39:53 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A53663D4 for ; Fri, 30 Aug 2013 13:39:53 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7123125B2 for ; Fri, 30 Aug 2013 13:39:53 +0000 (UTC) Received: by mail-ie0-f176.google.com with SMTP id s9so3201956iec.21 for ; Fri, 30 Aug 2013 06:39:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=OZIkKJPVckF1Mb2YcBxCGDAHqDJi/revzQxAcw4LoX8=; b=CL7XNn36jIiyGd8Sar7UPwDuRMx1zer8XPojk36YeJy1wqPlj6+AXJQmcHYmOuxkFA uM4Y7niggzvZala/LnXwetUz2IJGYCDuPQ4X5r3PeOycKaqqP+7Kqle4gJxXxHAt5atY 1qYkQccu8a0eI6qCbsFaWccdJzDxrPix8dcvroUsCyxZxC82+QzO8YzXg5KrGajsJu/q txtq0ArqjWO/TPM1l8l3mwIFFpX2/8mz94A+sxcgtMRWONs3STCclb+uT3lHPVuZyxGH 01R20gnAQPo9T2P8KwUiAiybhEgWfnVdZh/Qul0KO8GDFlOe5EPx0WrWifTzbqtP1WW+ kIpA== X-Gm-Message-State: ALoCoQmwTjqK3bUGVPTIJjwCAfakqSSODyHtUnVXxVuFJh6syjCJusVFa4eoRXn1CAy++Fdc0Wq9 X-Received: by 10.50.115.103 with SMTP id jn7mr6150223igb.1.1377869992695; Fri, 30 Aug 2013 06:39:52 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id x6sm3978623igb.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Aug 2013 06:39:51 -0700 (PDT) Sender: Warner Losh Subject: Re: GCC withdraw Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Fri, 30 Aug 2013 07:39:48 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> <201308291344.25562.jhb@freebsd.org> To: David Chisnall X-Mailer: Apple Mail (2.1085) Cc: FreeBSD Current , toolchain@FreeBSD.org, "freebsd-current@freebsd.org CURRENT" , "Sam Fourman Jr." , Boris Samorodov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 13:39:53 -0000 I had a long, rambling reply to this that corrected many of the factual = errors made in it. But why bother. You have your world view, it doesn't = match what people are doing today and this mismatch is going to cause = people pain and suffering in the embedded world far beyond what you = think. And you've shown an extreme reluctance to accept that your world = view isn't quite right, and listen to people. This makes me sad, but I = recognize a lost cause when I see it. Do whatever the fuck you want, but it won't make your arguments right. = And it won't keep me from saying I told you so when your optimistic = timelines don't come to fruition, or the people processors you dismiss = as being too weak to run a full FreeBSD (despite the fact they are doing = it today) complain about the needless pain they are going through. Warner From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 13:42:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2AB7D559; Fri, 30 Aug 2013 13:42:15 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from mail.made4.biz (unknown [IPv6:2001:41d0:1:7018::1:3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E24E325FD; Fri, 30 Aug 2013 13:42:14 +0000 (UTC) Received: from [2001:1b48:10b:cafe:225:64ff:febe:589f] (helo=viking.yzserv.com) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VFOxo-000Num-Fn; Fri, 30 Aug 2013 15:42:13 +0200 Message-ID: <5220A12F.1090801@FreeBSD.org> Date: Fri, 30 Aug 2013 15:42:07 +0200 From: =?ISO-8859-15?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130813 Thunderbird/17.0.8 MIME-Version: 1.0 To: John Baldwin Subject: Re: i915kms.ko not loading References: <521E52A6.6040205@gmail.com> <521F6A52.2060206@gmail.com> <521F6B41.4030704@FreeBSD.org> <201308291306.31552.jhb@freebsd.org> In-Reply-To: <201308291306.31552.jhb@freebsd.org> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2PKVUXNLQIMSSUGDBLTMW" Cc: Alexander , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 13:42:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2PKVUXNLQIMSSUGDBLTMW Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable On 29.08.2013 19:06, John Baldwin wrote: > On Thursday, August 29, 2013 11:39:45 am Jean-S=E9bastien P=E9dron wrot= e: >> On 29.08.2013 17:35, Alexander wrote: >>> in sysctl: >>> kern.coredump: 1 >>> kern.corefile: /var/coredumps/%U.%N.%P.core >>> >>> but coredump files not created. >=20 > These control user process core dumps, not kernel crash dumps. You're right, thanks for correcting my answer. --=20 Jean-S=E9bastien P=E9dron ------enig2PKVUXNLQIMSSUGDBLTMW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIgoTQACgkQa+xGJsFYOlOdRQCgnto2TEPDNOGZZ7dGzlvCiIe3 ChIAoJFeWG2gEGR5mpj5B5RR6MR8rTZB =Utw8 -----END PGP SIGNATURE----- ------enig2PKVUXNLQIMSSUGDBLTMW-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 13:47:29 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 929867D6; Fri, 30 Aug 2013 13:47:29 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 630672641; Fri, 30 Aug 2013 13:47:29 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VFP2o-000KcQ-32; Fri, 30 Aug 2013 13:47:22 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r7UDlIuI057047; Fri, 30 Aug 2013 07:47:18 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX182YgFMbhY83L8ziagawriK Subject: Re: GCC withdraw From: Ian Lepore To: Warner Losh In-Reply-To: References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> <201308291344.25562.jhb@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Fri, 30 Aug 2013 07:47:18 -0600 Message-ID: <1377870438.1111.311.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , David Chisnall , toolchain@FreeBSD.org, "freebsd-current@freebsd.org CURRENT" , "Sam Fourman Jr." , Boris Samorodov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 13:47:29 -0000 On Fri, 2013-08-30 at 07:39 -0600, Warner Losh wrote: > I had a long, rambling reply to this that corrected many of the factual errors made in it. But why bother. You have your world view, it doesn't match what people are doing today and this mismatch is going to cause people pain and suffering in the embedded world far beyond what you think. And you've shown an extreme reluctance to accept that your world view isn't quite right, and listen to people. This makes me sad, but I recognize a lost cause when I see it. > > Do whatever the fuck you want, but it won't make your arguments right. And it won't keep me from saying I told you so when your optimistic timelines don't come to fruition, or the people processors you dismiss as being too weak to run a full FreeBSD (despite the fact they are doing it today) complain about the needless pain they are going through. > > Warner Actually, I have to put a +1 on this. I also had a long reply full of reality-based refutations of various "facts" from this thread, and I also just deleted it because clearly the discussion has become pointless. -- Ian From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 13:50:46 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D5117A82 for ; Fri, 30 Aug 2013 13:50:46 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from mail.made4.biz (unknown [IPv6:2001:41d0:1:7018::1:3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9872B2667 for ; Fri, 30 Aug 2013 13:50:46 +0000 (UTC) Received: from [2001:1b48:10b:cafe:225:64ff:febe:589f] (helo=viking.yzserv.com) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VFP64-000O4S-A0; Fri, 30 Aug 2013 15:50:44 +0200 Message-ID: <5220A334.3080205@FreeBSD.org> Date: Fri, 30 Aug 2013 15:50:44 +0200 From: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130813 Thunderbird/17.0.8 MIME-Version: 1.0 To: Alexander Subject: Re: i915kms.ko not loading References: <521E52A6.6040205@gmail.com> <521F1367.8090002@FreeBSD.org> <521F6A52.2060206@gmail.com> <521F6B41.4030704@FreeBSD.org> <521F8A35.3080801@gmail.com> In-Reply-To: <521F8A35.3080801@gmail.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2TRELXCPULGLNJLPDBPPQ" Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 13:50:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2TRELXCPULGLNJLPDBPPQ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 29.08.2013 19:51, Alexander wrote: > I have swapinfo on zfs partition I always heard that swap on ZFS is asking for trouble, because ZFS loves to use memory. So when the system is using swap space, ZFS has more work and therefore wants more RAM, whici is unavailable. Furthermore, I'm not sure if kernel core dumping on swap on ZFS is supported at all. The following discussion on the forum suggests it's not possible: http://forums.freebsd.org/showthread.php?t=3D37958 Can you plug another driver and setup swap on it? A USB drive/key should be fine. --=20 Jean-S=C3=A9bastien P=C3=A9dron ------enig2TRELXCPULGLNJLPDBPPQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIgozQACgkQa+xGJsFYOlP+KACeJz7Y5mtqjE57r6bfslQ4bzEx pz4AoJThhgl0aqebYzqrytBI+iBInchv =Quuh -----END PGP SIGNATURE----- ------enig2TRELXCPULGLNJLPDBPPQ-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 13:54:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7B26BD76 for ; Fri, 30 Aug 2013 13:54:07 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 44ADB26C3 for ; Fri, 30 Aug 2013 13:54:06 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id 9so3244240iec.2 for ; Fri, 30 Aug 2013 06:54:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ZFWryosK9HUcnvL6zhlZA8ZN72s3Yoi9n4zC/eZKcAs=; b=aj4Z5tNkpcRg7zkPmrsBxy8ICOqfbKm09IKnzJghFy6a41k18xPNgvFJil/mAlqs0M SRVEBULVvm2iQIq04LQaxkWcqe2B9PHAE5ORh05bNsxe56MsDnrzmQ04K2Rn7VUaMGGe +joGXtguJg2u88mTSUfS8EKEb7yjEKbTQY0SvE5qXUvva34UT5WhApE3aZx49tBFeJUR wg9rsjOi8V85Pk2fNg8utfXMu5kfqv9/HWTwYxxXDqmT1NiV6h4E6FwpNIirQohEd8mS uNtZBo6Jc3iHtQVblC92BObHKf7ekpDbDpCECeowqlKkmoCRCnrbgUJGB4HcKXDMT2P/ FelQ== X-Gm-Message-State: ALoCoQmpHCv8Yb6LX/EFpyjMB//7iuoozh+8uyWQUCt2k4Pj06ueAF0ocJMtm9kGxLxjuEosY2yA X-Received: by 10.50.124.65 with SMTP id mg1mr2389810igb.43.1377870846279; Fri, 30 Aug 2013 06:54:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.158.74 with HTTP; Fri, 30 Aug 2013 06:53:51 -0700 (PDT) In-Reply-To: <52209EEC.6060609@bitfrost.no> References: <521B9CD7.8010902@bitfrost.no> <521C6C26.7050207@bitfrost.no> <52203EC9.4060808@bitfrost.no> <52207030.8050107@bitfrost.no> <52208F63.4060308@bitfrost.no> <52209EEC.6060609@bitfrost.no> From: "Lundberg, Johannes" Date: Fri, 30 Aug 2013 15:53:51 +0200 Message-ID: Subject: Re: xhci broken on 10-CURRENT and 2013 MacBook Air? To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Alexander Motin , FreeBSD Current , "freebsd-usb@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 13:54:07 -0000 I added printf at every 100,000th iteration in both locations but I didn't get any output at all.. Seems it stuck in some other place. During my test I actually passed that stage a couple of times but still the xhci_do_command times out and I get the mountroot> prompt.... With the 9.1 driver I never get either of the errors. Johannes Lundberg BRILLIANTSERVICE CO., LTD. On Fri, Aug 30, 2013 at 3:32 PM, Hans Petter Selasky wrote: > On 08/30/13 15:19, Lundberg, Johannes wrote: > >> Hi Hans >> >> I tried that too and no change... But, the variable overflow you >> introduced, it is never increased, right? So, it will never become zero... >> >> > It will become zero when it wraps. Maybe 2**32 is too long. You could add > a printf while it is running, and see if it goes == 1000000 for example. > > --HPS > > Johannes Lundberg >> BRILLIANTSERVICE CO., LTD. >> > >> >> >> On Fri, Aug 30, 2013 at 2:26 PM, Hans Petter Selasky > >wrote: >> >> On 08/30/13 13:54, Lundberg, Johannes wrote: >>> >>> Still got the same behaviour after applying the patch... >>>> >>>> Johannes Lundberg >>>> BRILLIANTSERVICE CO., LTD. >>> http://www.**brilliantservice.co.jp >>>> > >>>> >>> > From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 14:13:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 747035A8; Fri, 30 Aug 2013 14:13:07 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward6l.mail.yandex.net (forward6l.mail.yandex.net [IPv6:2a02:6b8:0:1819::6]) by mx1.freebsd.org (Postfix) with ESMTP id 39339280E; Fri, 30 Aug 2013 14:13:07 +0000 (UTC) Received: from smtp12.mail.yandex.net (smtp12.mail.yandex.net [95.108.131.191]) by forward6l.mail.yandex.net (Yandex) with ESMTP id AFB5314E1418; Fri, 30 Aug 2013 18:13:04 +0400 (MSK) Received: from smtp12.mail.yandex.net (localhost [127.0.0.1]) by smtp12.mail.yandex.net (Yandex) with ESMTP id 5D84616A05D5; Fri, 30 Aug 2013 18:13:04 +0400 (MSK) Received: from 87.249.28.58.tel.ru (87.249.28.58.tel.ru [87.249.28.58]) by smtp12.mail.yandex.net (nwsmtp/Yandex) with ESMTP id CxNKhIF9yI-D32i1S9H; Fri, 30 Aug 2013 18:13:04 +0400 Message-ID: <5220A86F.40408@passap.ru> Date: Fri, 30 Aug 2013 18:13:03 +0400 From: Boris Samorodov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130811 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-current@freebsd.org, David Chisnall Subject: Re: GCC withdraw References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> <201308291344.25562.jhb@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 14:13:07 -0000 30.08.2013 11:33, David Chisnall пишет: > The time to raise objections for this was when the plan was originally raised over a year ago David, can you please point me to the original plan with gcc removal at 10.x? (I do remember only a plan to make clang the default compiler, but I may be wrong here) Thanks. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 14:14:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D8C70774; Fri, 30 Aug 2013 14:14:25 +0000 (UTC) (envelope-from hps@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id 636A5283A; Fri, 30 Aug 2013 14:14:25 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta.bitpro.no (Postfix) with ESMTP id BA64D7A315; Fri, 30 Aug 2013 16:14:24 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id E2BA38F5195; Fri, 30 Aug 2013 16:14:37 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzmQBWH-8MlA; Fri, 30 Aug 2013 16:14:37 +0200 (CEST) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) by mail.lockless.no (Postfix) with ESMTPSA id C39138F5194; Fri, 30 Aug 2013 16:14:36 +0200 (CEST) Message-ID: <5220A908.2000000@bitfrost.no> Date: Fri, 30 Aug 2013 16:15:36 +0200 From: Hans Petter Selasky Organization: Bitfrost A/S User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130522 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Lundberg, Johannes" Subject: Re: xhci broken on 10-CURRENT and 2013 MacBook Air? References: <521B9CD7.8010902@bitfrost.no> <521C6C26.7050207@bitfrost.no> <52203EC9.4060808@bitfrost.no> <52207030.8050107@bitfrost.no> <52208F63.4060308@bitfrost.no> <52209EEC.6060609@bitfrost.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Motin , FreeBSD Current , "freebsd-usb@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 14:14:25 -0000 On 08/30/13 15:53, Lundberg, Johannes wrote: > I added printf at every 100,000th iteration in both locations but I didn't > get any output at all.. Seems it stuck in some other place. > > During my test I actually passed that stage a couple of times but still the > xhci_do_command times out and I get the mountroot> prompt.... With the 9.1 > driver I never get either of the errors. > > > Johannes Lundberg > BRILLIANTSERVICE CO., LTD. Hi, If you have a git checkout of the FreeBSD source tree, you can try stripping away patches for xhci*.[ch] only, since end of December 2012. The 9- and 10- XHCI code should be almost the same, except for the streams mode support. Here is a list of patches you can try to revert if I get it right: commit 2969ec61bfd9be3fdcaa50432755d24df345874d Author: hselasky Date: Fri Jul 26 06:24:33 2013 +0000 MFC r253532: Fix an XHCI regression: The Block Event Interrupts, BEI, feature does not work like expected with the Renesas XHCI chipsets. Revert feature. While at it correct the TD SIZE computation in case of Zero Length Packet, ZLP, in the end of a multi frame USB transfer. PR: usb/180726 Approved by: re, hrs commit 7dbeb07e555c5e9649fac8079a4b3bcdd57b2cfc Author: hselasky Date: Tue Jun 11 06:18:51 2013 +0000 MFC r251249, r251251, r251252, r2512, r251254 and r251515: Correct XHCI DMA descriptor programming. Correct maximum IRQ rate. commit 1941cac2597eea224c9e0e76a789692dfa8dda91 Author: marius Date: Sat Mar 9 02:36:32 2013 +0000 MFC: r227309 (partial) Mark all SYSCTL_NODEs static that have no corresponding SYSCTL_DECLs. The SYSCTL_NODE macro defines a list that stores all child-elements of that node. If there's no SYSCTL_DECL macro anywhere else, there's no reason why it shouldn't be static. commit 9b2efd37b6d3afb84b234348094adf8cc533e2c6 Author: hselasky Date: Wed Feb 6 11:08:11 2013 +0000 MFC r246113 and r246126: Add missing NULL pointer check. Reported by: Lars Engels commit 63af294dc7c2db6a120eba9cec16fabec13aeec1 Author: hselasky Date: Mon Jan 21 07:25:38 2013 +0000 MFC r245132 and r245175: Optimise the XHCI interrupt handling. This patch will save CPU time when the XHCI interrupt is shared with other devices. Only check event rings when interrupt bits are set. Otherwise would indicate hiding possible hardware fault(s). Tested by: sos @ Submitted by: sos @ commit fa4f2cf0b90d6c5ce9eca2417e200fb693d6f239 Author: hselasky Date: Mon Jan 21 07:22:45 2013 +0000 MFC r243780: - Add support for Etron EJ168 USB 3.0 Host Controllers. This brand of controllers expects that the number of contexts specified in the input slot context points to an active endpoint context, else it refuses to operate. - Wrap one or two long lines. Tested by: Markus Pfeiffer (DragonFlyBSD) --HPS From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 14:41:32 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 61824EC5; Fri, 30 Aug 2013 14:41:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2EB182A1E; Fri, 30 Aug 2013 14:41:32 +0000 (UTC) Received: from jhbbsd.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BC2ACB939; Fri, 30 Aug 2013 10:41:30 -0400 (EDT) From: John Baldwin To: David Chisnall , Boris Samorodov Subject: Re: GCC withdraw Date: Fri, 30 Aug 2013 10:41:18 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <20130822200902.GG94127@funkthat.com> <201308291344.25562.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201308301041.18874.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 30 Aug 2013 10:41:30 -0400 (EDT) Cc: "Sam Fourman Jr." , toolchain@freebsd.org, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 14:41:32 -0000 Only a few comments in reply to avoid banging my head against a brick wall and then I'm done: On Friday, August 30, 2013 3:33:21 am David Chisnall wrote: > On 29 Aug 2013, at 18:44, John Baldwin wrote: > > Also, unless you plan on desupporting all non-x86 platforms, you _still_ > > have to do all this work while those platforms require GCC anyway. Just > > turning off GCC on x86 doesn't change this problem one iota. And that point > > is actually relevant to many of the other concerns you raised. It's not at > > all clear what disabling GCC on x86 will buy you unless you are intending on > > short-changing support for GCC on non-x86. > > It gives us a much cleaner deprecation strategy. Ports on tier-2 are best effort. We don't need to be quite as careful to ensure that they build with the base system compiler on tier-2 architectures. We don't make as strong guarantees about compatibility on tier-2 architectures, so removing gcc from their build at some point over the next five years is fine, but this is not the case for tier 1 architectures, where we can be reasonably expected to support anything that is in the base system for the next five years. > [snip] So my take away from this is that you have no plans to support any platform that doesn't support clang as you just expect ia64 and sparc64 to die and not be present in 11.0. That may be the best path, but I've certainly not seen that goal discussed publically. > > Don't get me wrong, I don't love GCC per se, and on my laptop I've hacked > > the relevant ports so that everything is built with clang. I would also > > love to be able to build the base system with GCC 47 instead of 42, it just > > doesn't seem that we are there yet. > > The time to raise objections for this was when the plan was originally raised over a year ago, or at any of the points when it's been discussed in between. It is not after we're ready to flip the switch. So I think the crux of the issue might be this: I have no doubt that this has been discussed extensively on toolchain@ and in toolchain-specific devsummit sessions. The proposal to disable GCC by default does not appear to have been discussed in a wider audience from what I can tell. (I can't find any relevant threads on arch@ or current@ prior to this one.) While this is a toolchain-specific decision, it is a very broad decision. Also, we aren't here because of a new thread started intentionally to say "Hey, we as the toolchain folks think we should disable GCC by default on 10 for x86". Instead, we started off in a thread about adding AES instructions to our binutils and out of left field there is an e-mail of "Oh, don't bother cause I'm disabling GCC next week" (paraphrase). Can you appreciate at all that this is a total surprise to people who aren't subscribed to toolchain@ and haven't been to a toolchain session at a devsummit and that this looks like a drive-by change? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 14:46:26 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 53C151F1; Fri, 30 Aug 2013 14:46:26 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D80AC2A73; Fri, 30 Aug 2013 14:46:25 +0000 (UTC) Received: by mail-ob0-f176.google.com with SMTP id uz19so1946326obc.7 for ; Fri, 30 Aug 2013 07:46:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=v5ywJ4sQcWV4PVkH9vjeVOYcjgBPZHFQ4FlpuvDXbx0=; b=yQeEuoYqBSBpmEfaIIQ3yEmxjlWQPsvYj9DOSaQnR9hmqpRlrtgLIBWoEQSDc24cBQ wNxasBI6Ek6vtmd6Or6g/5OQX/VlM4VUuioFZ4qx1sYwvDCWAsW9AXQxY20ASzbFTJaY uQYGVpbD7FrCB8IAzl9Ev5Nf99/4xlUePoxGktdkYMKT3thZwCkMLFjUHYkXD/GGJiIa v+iQQgkDThZjYoKPFdr3aOeJMAax5eA5cmKla/h96ZW8yQKEuZGT549fVuclmEaxPd+2 COYcP/BHCeqPbdefJFI/pBZxhzGFRFAEpvI4LI3ymd23hx7iu4kTFjEH1QmwdBmIt0sB 6knw== MIME-Version: 1.0 X-Received: by 10.60.62.4 with SMTP id u4mr7137857oer.35.1377873985129; Fri, 30 Aug 2013 07:46:25 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.182.75.9 with HTTP; Fri, 30 Aug 2013 07:46:24 -0700 (PDT) In-Reply-To: <1377870438.1111.311.camel@revolution.hippie.lan> References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> <201308291344.25562.jhb@freebsd.org> <1377870438.1111.311.camel@revolution.hippie.lan> Date: Fri, 30 Aug 2013 07:46:24 -0700 X-Google-Sender-Auth: VQnbYfaYNnDZUZk8khUeo6uiIQI Message-ID: Subject: Re: GCC withdraw From: Matthew Fleming To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current , David Chisnall , toolchain@freebsd.org, "freebsd-current@freebsd.org CURRENT" , "Sam Fourman Jr." , Boris Samorodov , Warner Losh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 14:46:26 -0000 On Fri, Aug 30, 2013 at 6:47 AM, Ian Lepore wrote: > On Fri, 2013-08-30 at 07:39 -0600, Warner Losh wrote: > > I had a long, rambling reply to this that corrected many of the factual > errors made in it. But why bother. You have your world view, it doesn't > match what people are doing today and this mismatch is going to cause > people pain and suffering in the embedded world far beyond what you think. > And you've shown an extreme reluctance to accept that your world view isn't > quite right, and listen to people. This makes me sad, but I recognize a > lost cause when I see it. > > > > Do whatever the fuck you want, but it won't make your arguments right. > And it won't keep me from saying I told you so when your optimistic > timelines don't come to fruition, or the people processors you dismiss as > being too weak to run a full FreeBSD (despite the fact they are doing it > today) complain about the needless pain they are going through. > > > > Warner > > Actually, I have to put a +1 on this. I also had a long reply full of > reality-based refutations of various "facts" from this thread, and I > also just deleted it because clearly the discussion has become > pointless. I don't really have any skin in this game; the vendor I work for uses x86 hardware, and we're not ready to be running on FreeBSD 10 yet. But as an "old guy" I really don't see why we'd change the plan of record so late. Nor do I think prioritizing ports over the base system on alternate architectures is the right play -- there's a lot of vendors who use FreeBSD on !x86. And there's a lot of vendors who don't use very many ports. And there's a lot of vendors putting money into the FreeBSD foundation, and into the hands of FreeBSD committers, to make it better. Vendors who, while it would be painful to switch, do have a choice of which OS to build their product around. Just my 2c. Actual value may differ. Cheers, matthew From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 14:53:44 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B371B682; Fri, 30 Aug 2013 14:53:44 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from smtpauth2.wiscmail.wisc.edu (wmauth2.doit.wisc.edu [144.92.197.222]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 83C1D2AF1; Fri, 30 Aug 2013 14:53:44 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MSC00900MK1M800@smtpauth2.wiscmail.wisc.edu>; Fri, 30 Aug 2013 09:53:43 -0500 (CDT) X-Spam-PmxInfo: Server=avs-2, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.8.30.144215, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from wanderer.tachypleus.net (172-12-164-50.lightspeed.wlfrct.sbcglobal.net [172.12.164.50]) by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MSC009BKMPG8530@smtpauth2.wiscmail.wisc.edu>; Fri, 30 Aug 2013 09:53:42 -0500 (CDT) Message-id: <5220B1F3.1030807@freebsd.org> Date: Fri, 30 Aug 2013 07:53:39 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130811 Thunderbird/17.0.8 To: David Chisnall Subject: Re: GCC withdraw References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> <52204746.2070900@freebsd.org> In-reply-to: X-Enigmail-Version: 1.5.1 Cc: FreeBSD Current , Boris Samorodov , toolchain@FreeBSD.org, "freebsd-current@freebsd.org CURRENT" , "Sam Fourman Jr." X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 14:53:44 -0000 On 08/30/13 00:35, David Chisnall wrote: > On 30 Aug 2013, at 08:18, Julian Elischer wrote: > >> As far as I'm concerned we can even slate it for >> "possible removal in 10.2-- if clang has proven up to the task" > I would be happy to ship gcc, as long as: > > - It's explicitly marked as deprecated and due for removal at some point in the 10.x timeframe. > - libstdc++ is gone (the amount of pain it's causing ports is phenomenal). > So the real driver here is switching to libc++. Is there really no way at all to use it with gcc? If, even with hacking, we could arrange that to work then it seems that all of our problems would go away. -Nathan From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 14:55:46 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DCDC57DF; Fri, 30 Aug 2013 14:55:46 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A7A2D2B17; Fri, 30 Aug 2013 14:55:46 +0000 (UTC) Received: from c120.sec.cl.cam.ac.uk (c120.sec.cl.cam.ac.uk [128.232.18.120]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r7UEtima009547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Aug 2013 14:55:45 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: GCC withdraw From: David Chisnall In-Reply-To: <5220B1F3.1030807@freebsd.org> Date: Fri, 30 Aug 2013 15:55:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> <52204746.2070900@freebsd.org> <5220B1F3.1030807@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1508) Cc: "Sam Fourman Jr." , toolchain@FreeBSD.org, "freebsd-current@freebsd.org CURRENT" , Boris Samorodov , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 14:55:46 -0000 On 30 Aug 2013, at 15:53, Nathan Whitehorn = wrote: > So the real driver here is switching to libc++. Is there really no way > at all to use it with gcc? If, even with hacking, we could arrange = that > to work then it seems that all of our problems would go away. If we can make our g++ compile C++11 code, then we can compile libc++ = with g++. This support requires significant modifications to the parser = (it adds a second Turing-complete compile-time language, for one...) and = so retrofitting C++11 support to g++ 4.2.1 is not going to happen. It's = taken upstream gcc a couple of years to get to the required level of = support. We don't have the manpower to replicate this. David From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 15:11:12 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F0376C01; Fri, 30 Aug 2013 15:11:11 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A268F2BFE; Fri, 30 Aug 2013 15:11:11 +0000 (UTC) Received: from c120.sec.cl.cam.ac.uk (c120.sec.cl.cam.ac.uk [128.232.18.120]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r7UFB816009699 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Aug 2013 15:11:10 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: GCC withdraw From: David Chisnall In-Reply-To: <201308301041.18874.jhb@freebsd.org> Date: Fri, 30 Aug 2013 16:11:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <54499653-7356-492E-A435-6CC766C90508@FreeBSD.org> References: <20130822200902.GG94127@funkthat.com> <201308291344.25562.jhb@freebsd.org> <201308301041.18874.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1508) Cc: "Sam Fourman Jr." , toolchain@FreeBSD.org, Boris Samorodov , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 15:11:12 -0000 On 30 Aug 2013, at 15:41, John Baldwin wrote: > So my take away from this is that you have no plans to support any = platform that > doesn't support clang as you just expect ia64 and sparc64 to die and = not be > present in 11.0. That may be the best path, but I've certainly not = seen that > goal discussed publically. I expect that platforms that don't have support from clang or some = external toolchain will die. If people care about IA64, then getting = Intel's compiler working as an external toolchain would probably be a = good idea (it generates vastly better code than gcc). If people care = about SPARC64, then either gcc from ports as an external toolchain, or = finishing up the SPARC64 back end in LLVM are options. Finishing the = SPARC64 back end is not that much effort (it's probably a couple of = person-months of work - getting the calling conventions right does = require some small tweaks to LLVM IR that I think someone's working on), = but it hasn't been done because no one appears to care quite enough to = make it a priority. >>> Don't get me wrong, I don't love GCC per se, and on my laptop I've = hacked >>> the relevant ports so that everything is built with clang. I would = also >>> love to be able to build the base system with GCC 47 instead of 42, = it just >>> doesn't seem that we are there yet. >>=20 >> The time to raise objections for this was when the plan was = originally raised over a year ago, or at any of the points when it's = been discussed in=20 > between. It is not after we're ready to flip the switch. >=20 > So I think the crux of the issue might be this: >=20 > I have no doubt that this has been discussed extensively on toolchain@ = and in > toolchain-specific devsummit sessions. The proposal to disable GCC by = default > does not appear to have been discussed in a wider audience from what I = can > tell. (I can't find any relevant threads on arch@ or current@ prior = to this > one.) While this is a toolchain-specific decision, it is a very broad > decision. Also, we aren't here because of a new thread started = intentionally > to say "Hey, we as the toolchain folks think we should disable GCC by = default > on 10 for x86". Instead, we started off in a thread about adding AES > instructions to our binutils and out of left field there is an e-mail = of > "Oh, don't bother cause I'm disabling GCC next week" (paraphrase). = Can you > appreciate at all that this is a total surprise to people who aren't > subscribed to toolchain@ and haven't been to a toolchain session at a=20= > devsummit and that this looks like a drive-by change? Yes, we certainly could have communicated this better. I was under the = impression that this was widespread common knowledge and something I've = personally discussed with various people including ports people on = several occasions. I would have made the commit a couple of months ago, = but getting the ports infrastructure back up to a state where it's easy = to test has been a blocker there. =20 If removing gcc from the standard install is going to cause major pain = for people, then we can leave it in for 10.0. I'm currently doing a = make tinderbox on the removal patch, modified to leave gcc in, and only = remove libstdc++, which is something that we definitely need to do = because it's causing an amount of pain that is only going to increase. = I have no plans to make anything in the base system (other than clang = itself, when 3.4 is imported) depend on libc++-only features (I'd love = to do it for dtc, but it has to run on embedded platforms that are going = to be stuck with libstdc++ in base for a while - at least a year, and = that's if we're lucky). =20 Anyway, Ian has reminded me that I'm getting stuck in sidetracks, so = here's an executive summary of what I'm ACTUALLY proposing: - On platforms where clang is cc, don't build libstdc++, make libc++ the = default. Provide libstdc++ from base as a 9-compat package. - On platforms where clang is cc, don't build gcc by default (I've = already agreed not to commit this part, since it seems very = controversial, although I'd like to better understand why it is so) - On platforms where clang is cc, allow building libstdc++ by setting = the WITH_GNUCXX flag - On platforms where clang is cc, allow building gcc by setting the = WITH_GCCflag - On platforms where clang is not cc, leave gcc as the default system = compiler - On platforms where clang is not cc, leave libstdc++ as the default = system STL, but encourage ports to start depending explicitly on = ports-libstdc++ so that they don't suffer from ABI mismatch issues. If your workflow depends on gcc on a clang-is-cc platform, then you are = free to install it. If your workflow depends on libstdc++ on a clang-is-cc platform, then = you are free to install it, clang will still use it if you specify = -stdlib=3Dlibstdc++. If your workflow depends on gcc or libstdc++ on any other platform, you = will see no difference. If you need to test whether building the base system or kernel with gcc = fixes things that are broken, then you are free to build = WITHOUT_CLANG_IS_CC and WITH_GCC and test it (or set WITH_GCC, install, = and then use XCC to use the installed gcc for testing. Or install one = of the lang/gcc ports and use XCC for testing). In the medium term, = this should continue to work until there is some compelling reason for = it to be broken (which is the topic of a future discussion, where I = would expect very compelling reasons to be required). =20 I am not proposing: - To delete gcc from the tree - To delete libstdc++ from the tree - To deprecate any architectures - To break any architectures - To commit loads of C++11 / C11 code to the base system and break the = build with gcc - To rely on any clang-specific extensions in base-system code - To remove anything from cdefs.h that allows stuff to work with gcc - To set fire to your cat David From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 15:40:02 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9B74E768; Fri, 30 Aug 2013 15:40:02 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 58DCE2D87; Fri, 30 Aug 2013 15:40:02 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id r7UFdwQx087822; Fri, 30 Aug 2013 08:39:58 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id r7UFdwul087821; Fri, 30 Aug 2013 08:39:58 -0700 (PDT) (envelope-from sgk) Date: Fri, 30 Aug 2013 08:39:58 -0700 From: Steve Kargl To: Tim Kientzle Subject: Re: GCC withdraw Message-ID: <20130830153958.GA87788@troutmask.apl.washington.edu> References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> <52204746.2070900@freebsd.org> <3C11736737A54D84B80B1D27406F8039@FreeBSD.org> <53AB1421-BC0C-4F29-B799-721553B3B1DA@FreeBSD.org> <87CD56E4-98CE-4BA4-A9C6-433F9196A5B4@kientzle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87CD56E4-98CE-4BA4-A9C6-433F9196A5B4@kientzle.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Current , David Chisnall , toolchain@FreeBSD.org, "freebsd-current@freebsd.org CURRENT" , "Sam Fourman Jr." , Boris Samorodov , Jonathan Anderson X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 15:40:02 -0000 On Fri, Aug 30, 2013 at 06:38:41AM -0700, Tim Kientzle wrote: > > On 30 Aug 2013, at 08:56, Jonathan Anderson wrote: > > > ... then people wanting to compile the base system with gcc/g++ ... > > > I'm still curious *why* some people want this? > Buildworld completes in 1/4th the amount of time with gcc and it consumes much less memory. -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 15:47:18 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A4848943; Fri, 30 Aug 2013 15:47:18 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7FECE2E06; Fri, 30 Aug 2013 15:47:18 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id r7UFlE8v087868; Fri, 30 Aug 2013 08:47:14 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id r7UFlEhh087867; Fri, 30 Aug 2013 08:47:14 -0700 (PDT) (envelope-from sgk) Date: Fri, 30 Aug 2013 08:47:14 -0700 From: Steve Kargl To: David Chisnall Subject: Re: GCC withdraw Message-ID: <20130830154714.GB87788@troutmask.apl.washington.edu> References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> <201308291344.25562.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Current , toolchain@FreeBSD.org, "freebsd-current@freebsd.org CURRENT" , "Sam Fourman Jr." , Boris Samorodov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 15:47:18 -0000 On Fri, Aug 30, 2013 at 08:33:21AM +0100, David Chisnall wrote: > On 29 Aug 2013, at 18:44, John Baldwin wrote: > > > default every time, that we're telling people not to use, won't help with > > that... > > > > This is your worst argument as clang is known to take far longer than GCC > > to build. :) > > Not really. Clang + gcc takes longer to build than just clang. Building gcc is in the noise. I've sent you number on this. John is correct. It takes much much longer to buildworld with clang. -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 16:05:03 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B57981D7; Fri, 30 Aug 2013 16:05:03 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 38DC82F1B; Fri, 30 Aug 2013 16:05:03 +0000 (UTC) Received: by mail-vc0-f171.google.com with SMTP id ij15so1479026vcb.30 for ; Fri, 30 Aug 2013 09:05:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XjCz5mN5/pHYNAP2gIxsEbQdDcWydOa6Iu4PILbXHNI=; b=S6jNpCMxBgoXPJgV4vkSLfGZPblL3Sde8EZGYBzf21RpKb3UmRs0EwMRAuuZ+vpOvi L+8UcJXOXxwuUc9pB5QYYkaTPnvC/s72L6gfOrKvzGHkgLLaMTKSzPwWUZXrYbXUFRbn 1PTS5sOGuBRSBHcqR5Y4MBGeXT4yiv9W8yTdecNrPsl5PIJe7rtCH+L+pTjV1UGge+o4 J8yeerow4YQNZ9DIX74LZRLBIcAHYmO/xMM+RamNwWhLazlC0NJMyOWfsiEWS6sVqW/l Pjd6oVWlRtYFdPiqd0eGeHXuzSGaPzi77LSzdPT2qTzMDkNF02HWEtLWWPUOUZl526gu rVXA== MIME-Version: 1.0 X-Received: by 10.220.75.73 with SMTP id x9mr162392vcj.38.1377878702316; Fri, 30 Aug 2013 09:05:02 -0700 (PDT) Received: by 10.58.118.104 with HTTP; Fri, 30 Aug 2013 09:05:02 -0700 (PDT) In-Reply-To: <54499653-7356-492E-A435-6CC766C90508@FreeBSD.org> References: <20130822200902.GG94127@funkthat.com> <201308291344.25562.jhb@freebsd.org> <201308301041.18874.jhb@freebsd.org> <54499653-7356-492E-A435-6CC766C90508@FreeBSD.org> Date: Fri, 30 Aug 2013 12:05:02 -0400 Message-ID: Subject: Re: GCC withdraw From: Mehmet Erol Sanliturk To: David Chisnall Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "Sam Fourman Jr." , toolchain@freebsd.org, Boris Samorodov , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 16:05:03 -0000 On Fri, Aug 30, 2013 at 11:11 AM, David Chisnall wrote: > On 30 Aug 2013, at 15:41, John Baldwin wrote: > > > So my take away from this is that you have no plans to support any > platform that > > doesn't support clang as you just expect ia64 and sparc64 to die and not > be > > present in 11.0. That may be the best path, but I've certainly not seen > that > > goal discussed publically. > > I expect that platforms that don't have support from clang or some > external toolchain will die. If people care about IA64, then getting > Intel's compiler working as an external toolchain would probably be a good > idea (it generates vastly better code than gcc). If people care about > SPARC64, then either gcc from ports as an external toolchain, or finishing > up the SPARC64 back end in LLVM are options. Finishing the SPARC64 back > end is not that much effort (it's probably a couple of person-months of > work - getting the calling conventions right does require some small tweaks > to LLVM IR that I think someone's working on), but it hasn't been done > because no one appears to care quite enough to make it a priority. > > >>> Don't get me wrong, I don't love GCC per se, and on my laptop I've > hacked > >>> the relevant ports so that everything is built with clang. I would > also > >>> love to be able to build the base system with GCC 47 instead of 42, it > just > >>> doesn't seem that we are there yet. > >> > >> The time to raise objections for this was when the plan was originally > raised over a year ago, or at any of the points when it's been discussed in > > between. It is not after we're ready to flip the switch. > > > > So I think the crux of the issue might be this: > > > > I have no doubt that this has been discussed extensively on toolchain@and in > > toolchain-specific devsummit sessions. The proposal to disable GCC by > default > > does not appear to have been discussed in a wider audience from what I > can > > tell. (I can't find any relevant threads on arch@ or current@ prior to > this > > one.) While this is a toolchain-specific decision, it is a very broad > > decision. Also, we aren't here because of a new thread started > intentionally > > to say "Hey, we as the toolchain folks think we should disable GCC by > default > > on 10 for x86". Instead, we started off in a thread about adding AES > > instructions to our binutils and out of left field there is an e-mail of > > "Oh, don't bother cause I'm disabling GCC next week" (paraphrase). Can > you > > appreciate at all that this is a total surprise to people who aren't > > subscribed to toolchain@ and haven't been to a toolchain session at a > > devsummit and that this looks like a drive-by change? > > Yes, we certainly could have communicated this better. I was under the > impression that this was widespread common knowledge and something I've > personally discussed with various people including ports people on several > occasions. I would have made the commit a couple of months ago, but > getting the ports infrastructure back up to a state where it's easy to test > has been a blocker there. > > If removing gcc from the standard install is going to cause major pain for > people, then we can leave it in for 10.0. I'm currently doing a make > tinderbox on the removal patch, modified to leave gcc in, and only remove > libstdc++, which is something that we definitely need to do because it's > causing an amount of pain that is only going to increase. I have no plans > to make anything in the base system (other than clang itself, when 3.4 is > imported) depend on libc++-only features (I'd love to do it for dtc, but it > has to run on embedded platforms that are going to be stuck with libstdc++ > in base for a while - at least a year, and that's if we're lucky). > > Anyway, Ian has reminded me that I'm getting stuck in sidetracks, so > here's an executive summary of what I'm ACTUALLY proposing: > > - On platforms where clang is cc, don't build libstdc++, make libc++ the > default. Provide libstdc++ from base as a 9-compat package. > > - On platforms where clang is cc, don't build gcc by default (I've already > agreed not to commit this part, since it seems very controversial, although > I'd like to better understand why it is so) > > - On platforms where clang is cc, allow building libstdc++ by setting the > WITH_GNUCXX flag > > - On platforms where clang is cc, allow building gcc by setting the > WITH_GCCflag > > - On platforms where clang is not cc, leave gcc as the default system > compiler > > - On platforms where clang is not cc, leave libstdc++ as the default > system STL, but encourage ports to start depending explicitly on > ports-libstdc++ so that they don't suffer from ABI mismatch issues. > > If your workflow depends on gcc on a clang-is-cc platform, then you are > free to install it. > If your workflow depends on libstdc++ on a clang-is-cc platform, then you > are free to install it, clang will still use it if you specify > -stdlib=libstdc++. > If your workflow depends on gcc or libstdc++ on any other platform, you > will see no difference. > If you need to test whether building the base system or kernel with gcc > fixes things that are broken, then you are free to build > WITHOUT_CLANG_IS_CC and WITH_GCC and test it (or set WITH_GCC, install, and > then use XCC to use the installed gcc for testing. Or install one of the > lang/gcc ports and use XCC for testing). In the medium term, this should > continue to work until there is some compelling reason for it to be broken > (which is the topic of a future discussion, where I would expect very > compelling reasons to be required). > > I am not proposing: > > - To delete gcc from the tree > > - To delete libstdc++ from the tree > > - To deprecate any architectures > > - To break any architectures > > - To commit loads of C++11 / C11 code to the base system and break the > build with gcc > > - To rely on any clang-specific extensions in base-system code > > - To remove anything from cdefs.h that allows stuff to work with gcc > > - To set fire to your cat > > David > > To be able to compile a source tree with different compilers is an important "Code Review Process" with the assumption that the source code is written exactly to adhere a standard and not using any extension of the used compilers ( if there are absolute necessity to use extensions such as "date" , "time" , etc . , these are collected into common routines ) . It is obvious that no any "human" expert can review a source tree like a "compiler" expert . A compiler may be considered an "expert" because expertise of programmers are transferred into it as much as possible . For this process , it is not important which compiler is selected for "production" release . This depends on goals of releases . For development and testing , many compilers may be used and their outputs may be compared . I am doing this for Fortran and Pascal . With respect to my experiences , to rely on a single compiler for any source tree is really a very UNRELIABLE programming practice . Sometimes , some compilers are producing very erroneous code . These cases are requiring special attention : By using also theoretical programming "human" expertise , these may be results of the following : Some parts of the source are not conforming to standards . There are some bugs which they are not recognized by other compilers . Messages during compilations are not sufficiently produced to inform about possible erroneous points . Some compilers are generating code which is not tracking run time exceptions . Some compilers at some special source statement combinations are producing erroneous code . Using different compilers are detecting such problems much easier than human programmers . Now , I am not able to think to write a program without using different compilers to test its outputs . By based on such experiences , my strong suggestion is that "Use as many compilers as possible ( even commercially available compilers if there exist some ) for the FreeBSD source tree after selecting a standard during development and testing ." This is the cheapest and most reliable "Code Review Process" . "Use a suitable compiler for the FreeBSD Project during releases ." Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 16:14:02 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DB4AE3DC for ; Fri, 30 Aug 2013 16:14:02 +0000 (UTC) (envelope-from biddut.mitra@ovi.com) Received: from nm39.bullet.mail.ne1.yahoo.com (nm39.bullet.mail.ne1.yahoo.com [98.138.229.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7B1532FA1 for ; Fri, 30 Aug 2013 16:14:01 +0000 (UTC) Received: from [127.0.0.1] by nm39.bullet.mail.ne1.yahoo.com with NNFMP; 30 Aug 2013 16:12:04 -0000 Received: from [98.138.90.56] by nm39.bullet.mail.ne1.yahoo.com with NNFMP; 30 Aug 2013 16:09:33 -0000 Received: from [98.139.212.149] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 30 Aug 2013 16:09:33 -0000 Received: from [98.139.212.214] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 30 Aug 2013 16:09:32 -0000 Received: from [127.0.0.1] by omp1023.mail.bf1.yahoo.com with NNFMP; 30 Aug 2013 16:09:32 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 856450.15274.bm@omp1023.mail.bf1.yahoo.com Received: (qmail 21818 invoked by uid 60001); 30 Aug 2013 16:09:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ovi.com; s=s1024; t=1377878970; bh=a/X5ySfU1yBM6YINtzhEP1qTPVNufEk0MEN1p7bYQ9g=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=PxBSz3EYDIzFC6sH3y/L3RLMVdTHLCuLHNjxme2loZcIK6bf7dAfgI53VDA6aB8+pG6jHA+qd0pvzzimRnnj6GS8fJLE3cJk7I/camupiqENwDuDZvyBPts3FAKdaIRYicyNRNBixGwx0JDK5Dsyvhuf6Man7sLPpHPFehf8gNU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=ovi.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=AZ10JrLPt4Ygpbu4Rg/qdUgZRPZZOrhIY0LWUq6ZgnG6OhcS8YQETAQjqvR157vFtFU5AtspqF64waX5Phrcxr3HZQRJdpNWUJ27Y4TAlSzJBgx4ip6Ikk/PfCWmqB030jksbgoIFw9UqUMwDSCZl7ZJsaTpCOWDpnBvRogSPzY=; X-YMail-OSG: rR0.B_kVM1msqKLjF8If3zuJcx6w.Mhvqr_Wow5Fcyl6M0Y hBGN9zCbhhnAmzhJ0pAnyDLNgDxwr1XerQKOeJGkzWulZQtx4291b6Lv5l7F dOc_NJWlZ_bHCC4yfn8wkNbv1I9vmNiQKjDjrFO5tSeFIsmucHTnh90XNSjF yaegksdV3m4DgqShyXA3BmeucncQZ5ba1k1dS.BwoXyOyP208IYscKNoLEXg 9DHo.KAYWka0A9qoM0LcdELrqFa8IBZ58PS.JRu.GsWpcV6Z7zUiUMAnp1Fx wh1zAFF5Yhdp_9fQ_iXjxPYdmAwOLxnfNXI20L3dR73MstrpZsyVpq8pEe8h XwLvPzwlW72Tk9ZvzZ09pVGLLD73oUNzQ3Y_0XApSPZejHAlYzll.N4ysMAI YLrXczOW.oxX9q.CKqH9j.bkvqKOKra9h3fpJwxy0DvQpetHcO57XrN0T046 qRzHkAvnEXXZqUAcrW3PSWmdCVNPLWYcj7FG.G96eVnaMvrpEjcuIgKIrrpj lcCUgkwel5Rh651sMJBG4woLKFseXf1GBdII0SBXK4XyslBBX894EbSv9tjO 8VZkWmT1sJk5JHYQzAXLaAaNIySxP1XNA.AlioxdyD6l0HL8ctzV6n5TVTB. muio_FAQZSyCaqhBo_0I984GramjvQQ0B4Q_.yTysBiNccWsV1u2AP3Kv08u 2a9RQERD7eapID9.9ddJPWCTC.foabjScMQLX0rxzecF3KXX3PF56cQMlaTN e_XKRkPV7EaY4xE5Wpz6pyg-- Received: from [114.130.67.23] by web162101.mail.bf1.yahoo.com via HTTP; Fri, 30 Aug 2013 09:09:30 PDT X-Rocket-MIMEInfo: 002.001, wqAgQ0PCoMKgwqDCoMKgwqAgZ3RoYXNoX3Rlc3QtZ3RoYXNoLXRlc3QubwrCoCBDQ0xEwqDCoMKgwqAgZ3RoYXNoLXRlc3QKwqAgQ0PCoMKgwqDCoMKgwqAgZ2lfZHVtcF90eXBlcy1nZHVtcC5vCsKgIENDwqDCoMKgwqDCoMKgIGdpX2R1bXBfdHlwZXMtZ2ktZHVtcC10eXBlcy5vCsKgIENDTETCoMKgwqDCoCBnaS1kdW1wLXR5cGVzCsKgIENDwqDCoMKgwqDCoMKgIGdsaWJfcHJpbnQtZ2xpYi1wcmludC5vCsKgIENDTETCoMKgwqDCoCBnbGliLXByaW50CsKgIEdFTsKgwqDCoMKgwqAgZy1pci1zY2FubmVyCgEwAQEBAQ-- X-Mailer: YahooMailWebService/0.8.156.576 Message-ID: <1377878970.21591.YahooMailNeo@web162101.mail.bf1.yahoo.com> Date: Fri, 30 Aug 2013 09:09:30 -0700 (PDT) From: biddut.mitra@ovi.com Subject: gobject-introspection-1.36.0_1 problem compiling causing xorg to fail To: "freebsd-current@freebsd.org" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 30 Aug 2013 16:20:41 +0000 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: biddut.mitra@ovi.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 16:14:02 -0000 =A0 CC=A0=A0=A0=A0=A0=A0 gthash_test-gthash-test.o=0A=A0 CCLD=A0=A0=A0=A0 g= thash-test=0A=A0 CC=A0=A0=A0=A0=A0=A0 gi_dump_types-gdump.o=0A=A0 CC=A0=A0= =A0=A0=A0=A0 gi_dump_types-gi-dump-types.o=0A=A0 CCLD=A0=A0=A0=A0 gi-dump-t= ypes=0A=A0 CC=A0=A0=A0=A0=A0=A0 glib_print-glib-print.o=0A=A0 CCLD=A0=A0=A0= =A0 glib-print=0A=A0 GEN=A0=A0=A0=A0=A0 g-ir-scanner=0A=A0 GEN=A0=A0=A0=A0= =A0 g-ir-annotation-tool=0A=A0 GISCAN GLib-2.0.gir=0AERROR:root:code for ha= sh md5 was not found.=0ATraceback (most recent call last):=0A=A0 File "/usr= /local/lib/python2.7/hashlib.py", line 139, in =0A=A0=A0=A0 globals= ()[__func_name] =3D __get_hash(__func_name)=0A=A0 File "/usr/local/lib/pyth= on2.7/hashlib.py", line 91, in __get_builtin_construc=0Ator=0A=A0=A0=A0 rai= se ValueError('unsupported hash type ' + name)=0AValueError: unsupported ha= sh type md5=0AERROR:root:code for hash sha1 was not found.=0ATraceback (mos= t recent call last):=0A=A0 File "/usr/local/lib/python2.7/hashlib.py", line= 139, in =0A=A0=A0=A0 globals()[__func_name] =3D __get_hash(__func_= name)=0A=A0 File "/usr/local/lib/python2.7/hashlib.py", line 91, in __get_b= uiltin_construc=0Ator=0A=A0=A0=A0 raise ValueError('unsupported hash type '= + name)=0AValueError: unsupported hash type sha1=0AERROR:root:code for has= h sha224 was not found.=0ATraceback (most recent call last):=0A=A0 File "/u= sr/local/lib/python2.7/hashlib.py", line 139, in =0A=A0=A0=A0 globa= ls()[__func_name] =3D __get_hash(__func_name)=0A=A0File "/usr/local/lib/pyt= hon2.7/hashlib.py", line 91, in __get_builtin_construc=0Ator=0A=A0=A0=A0 ra= ise ValueError('unsupported hash type ' + name)=0AValueError: unsupported h= ash type sha224=0AERROR:root:code for hash sha256 was not found.=0ATracebac= k (most recent call last):=0A=A0 File "/usr/local/lib/python2.7/hashlib.py"= , line 139, in =0A=A0=A0=A0 globals()[__func_name] =3D __get_hash(_= _func_name)=0A=A0 File "/usr/local/lib/python2.7/hashlib.py", line 91, in _= _get_builtin_construc=0Ator=0A=A0=A0=A0 raise ValueError('unsupported hash = type ' + name)=0AValueError: unsupported hash type sha256=0AERROR:root:code= for hash sha384 was not found.=0ATraceback (most recent call last):=0A=A0 = File "/usr/local/lib/python2.7/hashlib.py", line 139, in =0A=A0=A0= =A0 globals()[__func_name] =3D __get_hash(__func_name)=0A=A0 File "/usr/loc= al/lib/python2.7/hashlib.py", line 91, in __get_builtin_construc=0Ator=0A= =A0=A0=A0 raise ValueError('unsupported hash type ' + name)=0AValueError: u= nsupported hash type sha384=0AERROR:root:code for hash sha512 was not found= .=0ATraceback (most recent call last):=0A=A0 File "/usr/local/lib/python2.7= /hashlib.py", line 139, in =0A=A0=A0=A0 globals()[__func_name] =3D = __get_hash(__func_name)=0A=A0 File "/usr/local/lib/python2.7/hashlib.py", l= ine 91, in __get_builtin_construc=0Ator=0A=A0=A0=A0 raise ValueError('unsup= ported hash type ' + name)=0AValueError: unsupported hash type sha512=0ATra= ceback (most recent call last):=0A=A0 File "./g-ir-scanner", line 46, in =0A=A0=A0=A0 sys.exit(scanner_main(sys.argv))=0A=A0 File "./giscanner= /scannermain.py", line 443, in scanner_main=0A=A0=A0=A0 transformer =3D cre= ate_transformer(namespace, options)=0A=A0 File "./giscanner/scannermain.py"= , line 318, in create_transformer=0A=A0=A0=A0 accept_unprefixed=3Doptions.a= ccept_unprefixed)=0A=A0 File "./giscanner/transformer.py", line 52, in __in= it__=0A=A0=A0=A0 self._cachestore =3D CacheStore()=0A=A0 File "./giscanner/= cachestore.py", line 81, in __init__=0A=A0=A0=A0 self._check_cache_version(= )=0A=A0 File "./giscanner/cachestore.py", line 87, in _check_cache_version= =0A=A0=A0=A0 current_hash =3D _get_versionhash()=0A=A0 File "./giscanner/ca= chestore.py", line 41, in _get_versionhash=0A=A0=A0=A0 return hashlib.sha1(= ''.join(mtimes)).hexdigest()=0AAttributeError: 'module' object has no attri= bute 'sha1'=0Agmake[14]: *** [GLib-2.0.gir] Error 1=0Agmake[14]: Leaving di= rectory `/usr/ports/devel/gobject-introspection/work/gobject-introspection-= 1.36.0'=0Agmake[13]: *** [all-recursive] Error 1=0Agmake[13]: Leaving direc= tory `/usr/ports/devel/gobject-introspection/work/gobjec=0At-introspection-= 1.36.0'=0Agmake[12]: *** [all] Error 2=0Agmake[12]: Leaving directory `/usr= /ports/devel/gobject-introspection/work/gobjec=0At-introspection-1.36.0'=0A= *** Error code 1=0A=0AStop.=0Amake[11]: stopped in /usr/ports/devel/gobject= -introspection=0A*** Error code 1=0A=0AStop.=0Amake[10]: stopped in /usr/po= rts/sysutils/polkit=0A*** Error code 1=0A=0AStop.=0Amake[9]: stopped in /us= r/ports/sysutils/polkit=0A*** Error code 1=0A=0AStop.=0Amake[8]: stopped in= /usr/ports/sysutils/consolekit=0A*** Error code 1=0A=0AStop.=0Amake[7]: st= opped in /usr/ports/sysutils/hal=0A*** Error code 1=0A=0AStop.=0Amake[6]: s= topped in /usr/ports/sysutils/hal=0A*** Error code 1=0A=0AStop.=0Amake[5]: = stopped in /usr/ports/x11-servers/xorg-server=0A*** Error code 1=0A=0AStop.= =0Amake[4]: stopped in /usr/ports/x11-servers/xorg-server=0A*** Error code = 1=0A=0AStop.=0Amake[3]: stopped in /usr/ports/x11-drivers/xf86-input-mouse= =0A*** Error code 1=0A=0AStop.=0Amake[2]: stopped in /usr/ports/x11-drivers= /xorg-drivers=0A*** Error code 1=0A=0AStop.=0Amake[1]: stopped in /usr/port= s/x11-drivers/xorg-drivers=0A*** Error code 1=0A=0AStop.=0Amake: stopped in= /usr/ports/x11/xorg From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 16:26:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EFAD06F3 for ; Fri, 30 Aug 2013 16:26:11 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C1A57208A for ; Fri, 30 Aug 2013 16:26:11 +0000 (UTC) Received: by mail-ie0-f176.google.com with SMTP id s9so3485544iec.7 for ; Fri, 30 Aug 2013 09:26:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=ZwipgdEQWooakm10z5TlE9ifLDJ1vRYHqoRNV0mTi7A=; b=gRYFKTPKbF2VRI+7CXNGIUPDhMQBMwN6TBDeLsLBgoRVh5D1XsJxe2ISB6A6fsnOHM x0qsXyADqjuDTKZnp8NJOZ+6EdrZnV/qahT0siCxpKauNa10YCQ5ydIzW1WtKSlQwt2D yidVMBzaZtsxclrY9k0VHF5zD7N3yt4qJkYr7TSZlX92ACqhh3m0/r5QXRPPHDtj6E4v GGlcxlQMnep/0ag+SzWTI+xb8B5kAWovRrhiiMcNMp1d3138RJNviXXCtDrrX3oboVEL AAta7tgXAaveEIpVyDiH/tNM72izECIsrCVPkHutFEjLYaFbQX5nKfM4+ug6KNV+Jqu2 dYBA== X-Gm-Message-State: ALoCoQm1/HXwqAuDf9+BJ4QwptKUljVQhrbKJBquZzvpNo8CZDzw2yD/xKqTE4DdbBTGVUZ5A/ad X-Received: by 10.43.111.5 with SMTP id em5mr5300237icc.40.1377879970652; Fri, 30 Aug 2013 09:26:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.158.74 with HTTP; Fri, 30 Aug 2013 09:25:55 -0700 (PDT) From: "Lundberg, Johannes" Date: Fri, 30 Aug 2013 18:25:55 +0200 Message-ID: Subject: 2013 MacBook Air Project To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 16:26:12 -0000 Hi I thought I'd give a progress report on running FreeBSD 10 on a MacBook Air 11" 2013 model. PCI-E SSD DRIVE - Added device ID to device list. Should be committed to head already. - Failed to write partition table due to weird characters at the end in the SSD's identifier key. Solved by ugly hack (cutting off the ident string in the middle), fix not committed. SMP - No problem when booting from usb memory stick. However, have to disable smp in /boot/loader.conf with kern.smp.disabled="1" to boot from the SSD. USB - Reverted sys/dev/usb/controller/xhci* to 243780 to make it work. WIFI - Seems like this one is gonna be difficult due to Broadcom's proprietary driver.... ETHERNET - Thunderbolt adapter works fine but hot-plugging not supported so you need to connect it before booting. BLUETOOTH - Added device to usbdevs and ng_ubt.c. Device is recognised and ubt0 created but when running "service bluetooth start ubt0" I get "Unable to setup Bluetooth stack for device ubt0". Works fine with other generic bluetooth 4.0 usb dongle. No debugging done. Will install Xorg next week so report about that coming later. Best Regards Johannes Lundberg BRILLIANTSERVICE CO., LTD. From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 17:11:11 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 10585FD0; Fri, 30 Aug 2013 17:11:11 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CEE9322FB; Fri, 30 Aug 2013 17:11:10 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r7UHB333050737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Aug 2013 10:11:04 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r7UHB3bH050736; Fri, 30 Aug 2013 10:11:03 -0700 (PDT) (envelope-from jmg) Date: Fri, 30 Aug 2013 10:11:03 -0700 From: John-Mark Gurney To: =?iso-8859-1?Q?Jean-S=E9bastien_P=E9dron?= Subject: Re: i915kms.ko not loading Message-ID: <20130830171103.GB36239@funkthat.com> Mail-Followup-To: =?iso-8859-1?Q?Jean-S=E9bastien_P=E9dron?= , Alexander , freebsd-current@freebsd.org References: <521E52A6.6040205@gmail.com> <521F1367.8090002@FreeBSD.org> <521F6A52.2060206@gmail.com> <521F6B41.4030704@FreeBSD.org> <521F8A35.3080801@gmail.com> <5220A334.3080205@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5220A334.3080205@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 30 Aug 2013 10:11:04 -0700 (PDT) Cc: Alexander , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 17:11:11 -0000 Jean-Sbastien Pdron wrote this message on Fri, Aug 30, 2013 at 15:50 +0200: > On 29.08.2013 19:51, Alexander wrote: > > I have swapinfo on zfs partition > > I always heard that swap on ZFS is asking for trouble, because ZFS loves > to use memory. So when the system is using swap space, ZFS has more work > and therefore wants more RAM, whici is unavailable. > > Furthermore, I'm not sure if kernel core dumping on swap on ZFS is > supported at all. The following discussion on the forum suggests it's > not possible: > http://forums.freebsd.org/showthread.php?t=37958 > > Can you plug another driver and setup swap on it? A USB drive/key should > be fine. You don't need to use a swap device to dump to it... You can just set up the USB drive as the dump device only... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 17:45:57 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 654B9762; Fri, 30 Aug 2013 17:45:57 +0000 (UTC) (envelope-from iskander@advancedhosters.com) Received: from int.advancedhosters.com (int.advancedhosters.com [213.174.132.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 382AF24A2; Fri, 30 Aug 2013 17:45:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=advancedhosters.com; s=mail; h=Sender:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=MlrYfAHkxzVdbDfR9ptU8IdvIYS1T48/TJRXTNwqnEc=; b=nL7548JjmJzLXPQfU5U7kEFdjMLFCH9AEWfc8ao+JdbPbNRbSVD4UMt2udnmYdfv/iH9qk1FGCJF3T9Rep3fwOVXD6fYYCLAufEfzCMP8970flPKwQbBhwUclPkR571qsEVGVdXARvuczB525jnuJRsQANbtjs62192OcZu+7MY=; Received: from client186-7.emplot.net.ua ([193.110.107.186] helo=iskander.advancedhosters.com) by int.advancedhosters.com with esmtpa (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VFSlf-000NRw-9Y; Fri, 30 Aug 2013 17:45:55 +0000 Message-ID: <5220DA4E.3090100@gmail.com> Date: Fri, 30 Aug 2013 20:45:50 +0300 From: Alexander User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130827 Thunderbird/17.0.8 MIME-Version: 1.0 To: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= , freebsd-current@freebsd.org Subject: Re: i915kms.ko not loading References: <521E52A6.6040205@gmail.com> <521F1367.8090002@FreeBSD.org> <521F6A52.2060206@gmail.com> <521F6B41.4030704@FreeBSD.org> <521F8A35.3080801@gmail.com> <5220A334.3080205@FreeBSD.org> <20130830171103.GB36239@funkthat.com> In-Reply-To: <20130830171103.GB36239@funkthat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: iskander@advancedhosters.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 17:45:57 -0000 30.08.2013 20:11, John-Mark Gurney пишет: > Jean-Sbastien Pdron wrote this message on Fri, Aug 30, 2013 at 15:50 +0200: >> On 29.08.2013 19:51, Alexander wrote: >>> I have swapinfo on zfs partition >> I always heard that swap on ZFS is asking for trouble, because ZFS loves >> to use memory. So when the system is using swap space, ZFS has more work >> and therefore wants more RAM, whici is unavailable. >> >> Furthermore, I'm not sure if kernel core dumping on swap on ZFS is >> supported at all. The following discussion on the forum suggests it's >> not possible: >> http://forums.freebsd.org/showthread.php?t=37958 >> >> Can you plug another driver and setup swap on it? A USB drive/key should >> be fine. > You don't need to use a swap device to dump to it... You can just set > up the USB drive as the dump device only... > Hi I created the coredump files after create swap on new disk. But size very large. Where can I upload these files. ls -lah /var/crash ... -rw-r--r-- 1 root wheel 2B Aug 30 20:27 bounds -rw------- 1 root wheel 480B Aug 30 20:27 info.0 lrwxr-xr-x 1 root wheel 6B Aug 30 20:27 info.last -> info.0 -r--r--r-- 1 root wheel 5B Jul 19 2010 minfree -rw------- 1 root wheel 450M Aug 30 20:27 vmcore.0 lrwxr-xr-x 1 root wheel 8B Aug 30 20:27 vmcore.last -> vmcore.0 From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 19:00:54 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 43D775B9 for ; Fri, 30 Aug 2013 19:00:54 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from eu1sys200aog110.obsmtp.com (eu1sys200aog110.obsmtp.com [207.126.144.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9242728AF for ; Fri, 30 Aug 2013 19:00:53 +0000 (UTC) Received: from mail-we0-f179.google.com ([74.125.82.179]) (using TLSv1) by eu1sys200aob110.postini.com ([207.126.147.11]) with SMTP ID DSNKUiDr3d6JTa/8Jv2mx/qMtr0iwLedfpbC@postini.com; Fri, 30 Aug 2013 19:00:53 UTC Received: by mail-we0-f179.google.com with SMTP id t58so1964467wes.10 for ; Fri, 30 Aug 2013 12:00:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:message-id:to:subject:cc :reply-to:in-reply-to; bh=3+QqOpA7NU6/Dg62hwuwNHs5mg5ZHN2l59pNQL6r5G0=; b=g60ofUs1aHp/8d8Dc8ItYDAeUIG92ONuzhyrq/u70Bscl1iAsR963Jeq5NNXQXGvB/ bHBbOuauLCEL0hSAZXW5/CjrTgjC71bl1gvpI/OY2fyYGIaf+FTJpUMu7vy0Bn3fUCzq LACVhfoRSyJKARlJVtmYgal6mmSjyUosNeKJIxlvMWtsplgXV/WY6pC5RZXzcsRbMRBD taClxYuVWimu28kcSif2Lkqkf9H7nhZx/5t7M4a0FPEDVsMd8xv6Q1FwbnlL6Xi9FDDM Kua7antFIu2H2dqo3fDoG83HsV+J+oLoK80f7+a7oJ7MoYOmDIK9XQZko2fPMDGjr3ba QWdA== X-Received: by 10.180.75.205 with SMTP id e13mr3645706wiw.29.1377888830150; Fri, 30 Aug 2013 11:53:50 -0700 (PDT) X-Gm-Message-State: ALoCoQmjBrulazA5Qnl8W91B9XmVpg1gSBKFQpKZv9M8eXX0rdURBv63xhgRq0sHhW3HuHD1Df2pxLIkiSsYUYWShC7Yhi4zci/tkW93nEOaVEL4+eNpPxZ/Vhw20smJFH4uP6B53r1Jv3IHp+LWr9NpbhQuitXy4Cmjjni63Y6zRVlCrbzOJv8= X-Received: by 10.180.75.205 with SMTP id e13mr3645700wiw.29.1377888830096; Fri, 30 Aug 2013 11:53:50 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id o9sm6350816wiz.1.1969.12.31.16.00.00 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Aug 2013 11:53:49 -0700 (PDT) Sender: Anton Shterenlikht Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6) with ESMTP id r7UIrkEv026487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 30 Aug 2013 19:53:47 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6/Submit) id r7UIrkkg026486; Fri, 30 Aug 2013 19:53:46 +0100 (BST) (envelope-from mexas) Date: Fri, 30 Aug 2013 19:53:46 +0100 (BST) From: Anton Shterenlikht Message-Id: <201308301853.r7UIrkkg026486@mech-cluster241.men.bris.ac.uk> To: imp@bsdimp.com, jhb@FreeBSD.org Subject: Re: GCC withdraw In-Reply-To: Cc: current@freebsd.org, theraven@freebsd.org, toolchain@freebsd.org, freebsd-current@freebsd.org, sfourman@gmail.com, bsam@passap.ru X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bris.ac.uk List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 19:00:54 -0000 >Subject: Re: GCC withdraw >From: Warner Losh >Date: Thu, 29 Aug 2013 10:00:19 -0600 > Gcc is still an absolute requirement on all non-x86 platforms (including arm) due to the issues with clang. Some of these issues are bugs in specific things (arm) that keep coming up (and keep getting fixed), while others are more severe (sparc64 has no clang support, and don't forget ia64 Anton From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 19:20:07 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6DD93935; Fri, 30 Aug 2013 19:20:07 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 2319D2971; Fri, 30 Aug 2013 19:20:06 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1VFUGk-0005TP-Dz; Fri, 30 Aug 2013 23:22:06 +0400 Date: Fri, 30 Aug 2013 23:22:06 +0400 From: Slawa Olhovchenkov To: David Chisnall Subject: Re: GCC withdraw Message-ID: <20130830192206.GA20439@zxy.spb.ru> References: <20130822200902.GG94127@funkthat.com> <201308291344.25562.jhb@freebsd.org> <201308301041.18874.jhb@freebsd.org> <54499653-7356-492E-A435-6CC766C90508@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54499653-7356-492E-A435-6CC766C90508@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: "Sam Fourman Jr." , toolchain@FreeBSD.org, Boris Samorodov , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 19:20:07 -0000 On Fri, Aug 30, 2013 at 04:11:08PM +0100, David Chisnall wrote: > Anyway, Ian has reminded me that I'm getting stuck in sidetracks, so here's an executive summary of what I'm ACTUALLY proposing: > > - On platforms where clang is cc, don't build libstdc++, make libc++ the default. Provide libstdc++ from base as a 9-compat package. > > - On platforms where clang is cc, don't build gcc by default (I've already agreed not to commit this part, since it seems very controversial, although I'd like to better understand why it is so) And remember about breaking firewire+clang From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 19:32:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 26291FF2 for ; Fri, 30 Aug 2013 19:32:55 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from mail.made4.biz (unknown [IPv6:2001:41d0:1:7018::1:3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DFF0E2A68 for ; Fri, 30 Aug 2013 19:32:54 +0000 (UTC) Received: from 141.7.19.93.rev.sfr.net ([93.19.7.141] helo=[192.168.1.176]) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VFURA-000505-OA; Fri, 30 Aug 2013 21:32:53 +0200 Message-ID: <5220F367.3060606@FreeBSD.org> Date: Fri, 30 Aug 2013 21:32:55 +0200 From: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Alexander Subject: Re: i915kms.ko not loading References: <521E52A6.6040205@gmail.com> <521F1367.8090002@FreeBSD.org> <521F6A52.2060206@gmail.com> <521F6B41.4030704@FreeBSD.org> <521F8A35.3080801@gmail.com> <5220A334.3080205@FreeBSD.org> <20130830171103.GB36239@funkthat.com> <5220DA4E.3090100@gmail.com> In-Reply-To: <5220DA4E.3090100@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 19:32:55 -0000 Le 30/08/2013 19:45, Alexander a écrit : > Hi > I created the coredump files after create swap on new disk. > But size very large. Great! Could you please run: kgdb /boot/kernel/kernel /var/crash/vmcore.0 And, at gdb prompt: bt Then send the whole output (from the moment you run "kgdb" to the end of "bt" output) and your /var/log/messages file? -- Jean-Sébastien Pédron From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 21:16:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1FAA429A; Fri, 30 Aug 2013 21:16:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E13492FE1; Fri, 30 Aug 2013 21:16:06 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A1EB9B988; Fri, 30 Aug 2013 17:16:05 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: Default kern.ipc.shm_allow_removed to 1 Date: Fri, 30 Aug 2013 17:02:24 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; 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: <201308301702.24465.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 30 Aug 2013 17:16:05 -0400 (EDT) Cc: Alan Cox , George Liaskos X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 21:16:07 -0000 On Friday, August 30, 2013 9:30:09 am George Liaskos wrote: > Would it be feasible to change the default for 10? > > There is a lot of code that depends on the following behavior: > > void* address = shmat(shmkey, NULL /* desired address */, 0 /* flags */); > // Here we mark the shared memory for deletion. Since we attached it in the > // line above, it doesn't actually get deleted but, if we crash, this means > // that the kernel will automatically clean it up for us. > shmctl(shmkey, IPC_RMID, 0); > if (address == kInvalidAddress) > return NULL; > > The above snip is from Google Chrome, under FreeBSD with the current > defaults that memory becomes unusable. If you don't follow that route > it becomes extremely difficult to cleanup especially in a beast like > Chrome. > > From what I understand PC-BSD defaults to 1, OpenBSD and Linux also > allow this behavior. > > Am I missing something obvious here? It seems to me that the pragmatic > approach is to change this. Hmm, I can see why that is useful though it seems to violate POSIX. This claims that IPC_RMID should delete the segment immediately (which does not seem useful): http://pubs.opengroup.org/onlinepubs/007904975/functions/shmctl.html -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 21:38:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9353C99D for ; Fri, 30 Aug 2013 21:38:26 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 7FE89211B for ; Fri, 30 Aug 2013 21:38:26 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 80A661A3C2B; Fri, 30 Aug 2013 14:38:20 -0700 (PDT) Message-ID: <522110CB.5050501@mu.org> Date: Fri, 30 Aug 2013 14:38:19 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Lundberg, Johannes" Subject: Re: 2013 MacBook Air Project References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 21:38:26 -0000 This is so cool! Do you have a repo on github with these patches? On 8/30/13 9:25 AM, Lundberg, Johannes wrote: > Hi > > I thought I'd give a progress report on running FreeBSD 10 on a MacBook Air > 11" 2013 model. > > PCI-E SSD DRIVE > - Added device ID to device list. Should be committed to head already. > - Failed to write partition table due to weird characters at the end in the > SSD's identifier key. Solved by ugly hack (cutting off the ident string in > the middle), fix not committed. > > SMP > - No problem when booting from usb memory stick. However, have to disable > smp in /boot/loader.conf with kern.smp.disabled="1" to boot from the SSD. > > USB > - Reverted sys/dev/usb/controller/xhci* to 243780 to make it work. > > WIFI > - Seems like this one is gonna be difficult due to Broadcom's proprietary > driver.... > > ETHERNET > - Thunderbolt adapter works fine but hot-plugging not supported so you need > to connect it before booting. > > BLUETOOTH > - Added device to usbdevs and ng_ubt.c. Device is recognised and ubt0 > created but when running "service bluetooth start ubt0" I get "Unable to > setup Bluetooth stack for device ubt0". Works fine with other generic > bluetooth 4.0 usb dongle. No debugging done. > > Will install Xorg next week so report about that coming later. > > Best Regards > > Johannes Lundberg > BRILLIANTSERVICE CO., LTD. > _______________________________________________ > 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" > -- Alfred Perlstein From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 23:42:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C2831CB7 for ; Fri, 30 Aug 2013 23:42:25 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8B69627A2 for ; Fri, 30 Aug 2013 23:42:25 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id m16so3926558ieq.10 for ; Fri, 30 Aug 2013 16:42:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=pw9a1ZcUS4LqCHrPsv4G1H4L5io6PAMGiodaTyCyn3Y=; b=dVc+mMb17gzWXPXbrOBZ2htorG9HrqCbbpl90HS/1yqPfYLXFdxhVm38F/jxwAkdSQ A8aZmffDex9Qt4Q8XxUaHotW3RqgZ2TPPv3FzK2ece/Kf3ynovRfoKBP4D32mdPvRuOM ofe5DixmPhQ0aHFyYbtFORZU7j3kzMG/9T03mxdaNguWNdBWhwY4tsRPXfdwa5Cmxdsv bkmrd2C+euzawIjce4qUhyIsTsbPr7p3byM2zokZqKRWvbXisS3s+uPcdGVDqTHqUdAG 8CgFdgYaTNcZLiYwZ0ScTaW5HYVxhxHDfGfuM6ghU9+EmwFe9b0irNV278NT7azMRDQZ LGJg== X-Gm-Message-State: ALoCoQllR/uFNK81oFNOaYNcE9shwIFxQqfzs8LioU1Uwz3oTOWqUBgOUAZKIz34qRsVVgCvr7pq X-Received: by 10.50.122.102 with SMTP id lr6mr4383356igb.0.1377906144483; Fri, 30 Aug 2013 16:42:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.158.74 with HTTP; Fri, 30 Aug 2013 16:42:09 -0700 (PDT) In-Reply-To: <522110CB.5050501@mu.org> References: <522110CB.5050501@mu.org> From: "Lundberg, Johannes" Date: Sat, 31 Aug 2013 01:42:09 +0200 Message-ID: Subject: Re: 2013 MacBook Air Project To: Alfred Perlstein Content-Type: multipart/mixed; boundary=089e01538a8046b34904e532c65e X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 30 Aug 2013 23:42:25 -0000 --089e01538a8046b34904e532c65e Content-Type: text/plain; charset=ISO-8859-1 Thanks :) No github but I will attach the patches in this mail. Remember, the diskgeom patch is a ugly hack.... Johannes Lundberg BRILLIANTSERVICE CO., LTD. On Fri, Aug 30, 2013 at 11:38 PM, Alfred Perlstein wrote: > This is so cool! > > Do you have a repo on github with these patches? > > > On 8/30/13 9:25 AM, Lundberg, Johannes wrote: > >> Hi >> >> I thought I'd give a progress report on running FreeBSD 10 on a MacBook >> Air >> 11" 2013 model. >> >> PCI-E SSD DRIVE >> - Added device ID to device list. Should be committed to head already. >> - Failed to write partition table due to weird characters at the end in >> the >> SSD's identifier key. Solved by ugly hack (cutting off the ident string in >> the middle), fix not committed. >> >> SMP >> - No problem when booting from usb memory stick. However, have to disable >> smp in /boot/loader.conf with kern.smp.disabled="1" to boot from the SSD. >> >> USB >> - Reverted sys/dev/usb/controller/xhci* to 243780 to make it work. >> >> WIFI >> - Seems like this one is gonna be difficult due to Broadcom's proprietary >> driver.... >> >> ETHERNET >> - Thunderbolt adapter works fine but hot-plugging not supported so you >> need >> to connect it before booting. >> >> BLUETOOTH >> - Added device to usbdevs and ng_ubt.c. Device is recognised and ubt0 >> created but when running "service bluetooth start ubt0" I get "Unable to >> setup Bluetooth stack for device ubt0". Works fine with other generic >> bluetooth 4.0 usb dongle. No debugging done. >> >> Will install Xorg next week so report about that coming later. >> >> Best Regards >> >> Johannes Lundberg >> BRILLIANTSERVICE CO., LTD. >> > >> ______________________________**_________________ >> 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 " >> >> > > -- > Alfred Perlstein > > --089e01538a8046b34904e532c65e Content-Type: application/octet-stream; name="diskgeom.diff" Content-Disposition: attachment; filename="diskgeom.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hl01n7b50 SW5kZXg6IHN5cy9nZW9tL2dlb21fZGlzay5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9nZW9tL2dlb21f ZGlzay5jCShyZXZpc2lvbiAyNTQ5MjQpCisrKyBzeXMvZ2VvbS9nZW9tX2Rpc2suYwkod29ya2lu ZyBjb3B5KQpAQCAtNDI5LDcgKzQyOSw3IEBACiAJc3RydWN0IGRpc2sgKmRwOwogCXN0cnVjdCBn X2Rpc2tfc29mdGMgKnNjOwogCWNoYXIgKmJ1ZjsKLQlpbnQgcmVzID0gMDsKKy8vCWludCByZXMg PSAwOwogCiAJc2MgPSBncC0+c29mdGM7CiAJaWYgKHNjID09IE5VTEwgfHwgKGRwID0gc2MtPmRw KSA9PSBOVUxMKQpAQCAtNDQ4LDYgKzQ0OCw3IEBACiAJCQlidWYgPSBnX21hbGxvYyhESVNLX0lE RU5UX1NJWkUsIE1fV0FJVE9LKTsKIAkJCWJwID0gZ19hbGxvY19iaW8oKTsKIAkJCWJwLT5iaW9f ZGlzayA9IGRwOworLyoKIAkJCWJwLT5iaW9fYXR0cmlidXRlID0gIkdFT006OmlkZW50IjsKIAkJ CWJwLT5iaW9fbGVuZ3RoID0gRElTS19JREVOVF9TSVpFOwogCQkJYnAtPmJpb19kYXRhID0gYnVm OwpAQCAtNDU0LDYgKzQ1NSw4IEBACiAJCQlyZXMgPSBkcC0+ZF9nZXRhdHRyKGJwKTsKIAkJCXNi dWZfcHJpbnRmKHNiLCAiJXM8aWRlbnQ+JXM8L2lkZW50PlxuIiwgaW5kZW50LAogCQkJICAgIHJl cyA9PSAwID8gYnVmOiBkcC0+ZF9pZGVudCk7CisqLworCQkJc2J1Zl9wcmludGYoc2IsICIlczxp ZGVudD4wPC9pZGVudD5cbiIsIGluZGVudCk7CiAJCQlicC0+YmlvX2F0dHJpYnV0ZSA9ICJHRU9N OjpsdW5pZCI7CiAJCQlicC0+YmlvX2xlbmd0aCA9IERJU0tfSURFTlRfU0laRTsKIAkJCWJwLT5i aW9fZGF0YSA9IGJ1ZjsK --089e01538a8046b34904e532c65e Content-Type: application/octet-stream; name="machdep.diff" Content-Disposition: attachment; filename="machdep.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hl01n7bf1 SW5kZXg6IHN5cy9pMzg2L2kzODYvbWFjaGRlcC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9pMzg2L2kz ODYvbWFjaGRlcC5jCShyZXZpc2lvbiAyNTQ5MjQpCisrKyBzeXMvaTM4Ni9pMzg2L21hY2hkZXAu Ywkod29ya2luZyBjb3B5KQpAQCAtMjc3LDYgKzI3Nyw3IEBACiAJCSAgICBzdHJuY21wKHN5c2Vu diwgIk1hY0Jvb2tQcm8xLDEiLCAxMykgPT0gMCB8fAogCQkgICAgc3RybmNtcChzeXNlbnYsICJN YWNCb29rUHJvMSwyIiwgMTMpID09IDAgfHwKIAkJICAgIHN0cm5jbXAoc3lzZW52LCAiTWFjQm9v a1BybzMsMSIsIDEzKSA9PSAwIHx8CisJCSAgICBzdHJuY21wKHN5c2VudiwgIk1hY0Jvb2tBaXI2 LDEiLCAxMykgPT0gMCB8fAogCQkgICAgc3RybmNtcChzeXNlbnYsICJNYWNtaW5pMSwxIiwgMTAp ID09IDApIHsKIAkJCWlmIChib290dmVyYm9zZSkKIAkJCQlwcmludGYoIkRpc2FibGluZyBMRUdB Q1lfVVNCX0VOIGJpdCBvbiAiCg== --089e01538a8046b34904e532c65e Content-Type: application/octet-stream; name="netgraph.diff" Content-Disposition: attachment; filename="netgraph.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hl01n7bm2 SW5kZXg6IHN5cy9uZXRncmFwaC9ibHVldG9vdGgvZHJpdmVycy91YnQvbmdfdWJ0LmMKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQotLS0gc3lzL25ldGdyYXBoL2JsdWV0b290aC9kcml2ZXJzL3VidC9uZ191YnQuYwkocmV2 aXNpb24gMjU0OTI0KQorKysgc3lzL25ldGdyYXBoL2JsdWV0b290aC9kcml2ZXJzL3VidC9uZ191 YnQuYwkod29ya2luZyBjb3B5KQpAQCAtNDM3LDYgKzQzNywxMCBAQAogCSAgVVNCX0lGQUNFX0NM QVNTKFVJQ0xBU1NfVkVORE9SKSwKIAkgIFVTQl9JRkFDRV9TVUJDTEFTUyhVRFNVQkNMQVNTX1JG KSwKIAkgIFVTQl9JRkFDRV9QUk9UT0NPTChVRFBST1RPX0JMVUVUT09USCkgfSwKKworCS8qIE1h Y0Jvb2tBaXI2LDEgKi8KKwl7IFVTQl9WUEkoMHgwNWFjLCAweDgyOGYsIDApIH0sCisKIH07CiAK IC8qCg== --089e01538a8046b34904e532c65e Content-Type: application/octet-stream; name="usbdevs.diff" Content-Disposition: attachment; filename="usbdevs.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hl01n7bt3 SW5kZXg6IHN5cy9kZXYvdXNiL3VzYmRldnMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2Rldi91c2IvdXNi ZGV2cwkocmV2aXNpb24gMjU1MDczKQorKysgc3lzL2Rldi91c2IvdXNiZGV2cwkod29ya2luZyBj b3B5KQpAQCAtMTA3OCw2ICsxMDc4LDcgQEAKIHByb2R1Y3QgQVBQTEUgTU9VU0UJCTB4MDMwMQlN b3VzZSBNNDg0OAogcHJvZHVjdCBBUFBMRSBPUFRNT1VTRQkJMHgwMzAyCU9wdGljYWwgbW91c2UK IHByb2R1Y3QgQVBQTEUgTUlHSFRZTU9VU0UJMHgwMzA0CU1pZ2h0eSBNb3VzZQorcHJvZHVjdCBB UFBMRSBCVF9VU0IJCTB4ODI4ZglCbHVldG9vdGggVVNCIEhvc3QgQ29udHJvbGxlcgogcHJvZHVj dCBBUFBMRSBLQkRfSFVCCQkweDEwMDEJSHViIGluIEFwcGxlIFVTQiBLZXlib2FyZAogcHJvZHVj dCBBUFBMRSBFWFRfS0JEX0hVQgkweDEwMDMJSHViIGluIEFwcGxlIEV4dGVuZGVkIFVTQiBLZXli b2FyZAogcHJvZHVjdCBBUFBMRSBTUEVBS0VSUwkJMHgxMTAxCVNwZWFrZXJzCg== --089e01538a8046b34904e532c65e-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 31 07:09:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2923C87B for ; Sat, 31 Aug 2013 07:09:41 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E52A82F22 for ; Sat, 31 Aug 2013 07:09:40 +0000 (UTC) Received: by mail-ob0-f177.google.com with SMTP id f8so2732797obp.36 for ; Sat, 31 Aug 2013 00:09:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=CP0AQqLRRO6uyxLR0hjfLWRWeuJlaDFYEkPCbHtfA8E=; b=eQQElHFgr7mgcSSyAnuzkvy6rLTvlifNi4tDGuXmgG7qLriu//9BZUkzmd8zburuEP 924QZlzRhhy6n53b+vcYQ0vSaYnvtmNmElkt3hSLi8TiF/mq3rquGQeQK+Na7k8wkdyN sECVQ+E0Sc3LVgcgkWjRUgA41E9tQsQOMOHBtzCyYfAxvomNUAra9OJGfdq5eoLrw7uA q1gvHRkufWAe2euob3ZTJ3rWMxQ9hGgVDC348Oqq0f9fuEmE3Xw6q6sOScdd/FfYrH1i pAhtiBmpSI0FaTWmhTwz4IX8cL11BtsqT4h2mGv4ZcS48yJ1g556QS7iAl/zD/UGxOoc y01w== X-Gm-Message-State: ALoCoQm+2q1d/6pKxJ2I43L42GoIxFZaWgHNeAATpk6M+yoTZEcSad25gnOIQqgqlnzSDHpwc1jY X-Received: by 10.182.237.107 with SMTP id vb11mr9716034obc.84.1377932974488; Sat, 31 Aug 2013 00:09:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.50.163 with HTTP; Sat, 31 Aug 2013 00:09:18 -0700 (PDT) In-Reply-To: References: <522110CB.5050501@mu.org> From: "Lundberg, Johannes" Date: Sat, 31 Aug 2013 09:09:18 +0200 Message-ID: Subject: Re: 2013 MacBook Air Project To: Alfred Perlstein Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 31 Aug 2013 07:09:41 -0000 I forgot about the patch to sys/dev/ahci/ahci.c but it is already committed to head so just update that file to get access to the SSD controller. One line has been added: {0x91831b4b, 0x00, "Marvell 88SS9183", AHCI_Q_NOBSYRES}, Johannes Lundberg BRILLIANTSERVICE CO., LTD. On Sat, Aug 31, 2013 at 1:42 AM, Lundberg, Johannes < johannes@brilliantservice.co.jp> wrote: > Thanks :) > > No github but I will attach the patches in this mail. Remember, the > diskgeom patch is a ugly hack.... > > Johannes Lundberg > BRILLIANTSERVICE CO., LTD. > > > On Fri, Aug 30, 2013 at 11:38 PM, Alfred Perlstein wrote: > >> This is so cool! >> >> Do you have a repo on github with these patches? >> >> >> On 8/30/13 9:25 AM, Lundberg, Johannes wrote: >> >>> Hi >>> >>> I thought I'd give a progress report on running FreeBSD 10 on a MacBook >>> Air >>> 11" 2013 model. >>> >>> PCI-E SSD DRIVE >>> - Added device ID to device list. Should be committed to head already. >>> - Failed to write partition table due to weird characters at the end in >>> the >>> SSD's identifier key. Solved by ugly hack (cutting off the ident string >>> in >>> the middle), fix not committed. >>> >>> SMP >>> - No problem when booting from usb memory stick. However, have to disable >>> smp in /boot/loader.conf with kern.smp.disabled="1" to boot from the SSD. >>> >>> USB >>> - Reverted sys/dev/usb/controller/xhci* to 243780 to make it work. >>> >>> WIFI >>> - Seems like this one is gonna be difficult due to Broadcom's proprietary >>> driver.... >>> >>> ETHERNET >>> - Thunderbolt adapter works fine but hot-plugging not supported so you >>> need >>> to connect it before booting. >>> >>> BLUETOOTH >>> - Added device to usbdevs and ng_ubt.c. Device is recognised and ubt0 >>> created but when running "service bluetooth start ubt0" I get "Unable to >>> setup Bluetooth stack for device ubt0". Works fine with other generic >>> bluetooth 4.0 usb dongle. No debugging done. >>> >>> Will install Xorg next week so report about that coming later. >>> >>> Best Regards >>> >>> Johannes Lundberg >>> BRILLIANTSERVICE CO., LTD. >>> > >>> ______________________________**_________________ >>> 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 " >>> >>> >> >> -- >> Alfred Perlstein >> >> > From owner-freebsd-current@FreeBSD.ORG Sat Aug 31 07:10:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F19909A8 for ; Sat, 31 Aug 2013 07:10:41 +0000 (UTC) (envelope-from hps@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id 7C5F82F39 for ; Sat, 31 Aug 2013 07:10:41 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta.bitpro.no (Postfix) with ESMTP id 2EB397A276; Sat, 31 Aug 2013 09:10:34 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 75F938EC597; Sat, 31 Aug 2013 09:10:47 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ppyanR7Ygtj; Sat, 31 Aug 2013 09:10:46 +0200 (CEST) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) by mail.lockless.no (Postfix) with ESMTPSA id 96A6B8EC590; Sat, 31 Aug 2013 09:10:46 +0200 (CEST) Message-ID: <52219732.7070209@bitfrost.no> Date: Sat, 31 Aug 2013 09:11:46 +0200 From: Hans Petter Selasky Organization: Bitfrost A/S User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130522 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Lundberg, Johannes" Subject: Re: 2013 MacBook Air Project References: <522110CB.5050501@mu.org> In-Reply-To: Content-Type: multipart/mixed; boundary="------------070702070501050503080309" Cc: Alfred Perlstein , =?ISO-8859-1?Q?S=F8ren_Schmidt?= , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 31 Aug 2013 07:10:42 -0000 This is a multi-part message in MIME format. --------------070702070501050503080309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08/31/13 01:42, Lundberg, Johannes wrote: > + > + /* MacBookAir6,1 */ > + { USB_VPI(0x05ac, 0x828f, 0) }, > + > }; > Hi, I've updated the FreeBSD USB bluetooth driver with your ID, and a few more from Linux. I've attached an XHCI patch you can try. --HPS --------------070702070501050503080309 Content-Type: text/x-patch; name="xhci_irq.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xhci_irq.diff" === ./xhci.c ================================================================== --- ./xhci.c (revision 255094) +++ ./xhci.c (local) @@ -385,10 +385,6 @@ sc->sc_exit_lat_max = XHCI_HCS3_U1_DEL(temp) + XHCI_HCS3_U2_DEL(temp) + 250 /* us */; - temp = XREAD4(sc, oper, XHCI_USBSTS); - - /* clear interrupts */ - XWRITE4(sc, oper, XHCI_USBSTS, temp); /* disable all device notifications */ XWRITE4(sc, oper, XHCI_DNCTRL, 0); @@ -1479,7 +1475,9 @@ USB_BUS_LOCK(&sc->sc_bus); status = XREAD4(sc, oper, XHCI_USBSTS); - if (status == 0) + iman = XREAD4(sc, runt, XHCI_IMAN(0)); + + if (status == 0 && (iman & XHCI_IMAN_INTR_PEND) == 0) goto done; /* acknowledge interrupts */ @@ -1488,11 +1486,8 @@ DPRINTFN(16, "real interrupt (status=0x%08x)\n", status); - if (status & XHCI_STS_EINT) { + if (iman & XHCI_IMAN_INTR_PEND) { - /* acknowledge pending event */ - iman = XREAD4(sc, runt, XHCI_IMAN(0)); - /* reset interrupt */ XWRITE4(sc, runt, XHCI_IMAN(0), iman); --------------070702070501050503080309-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 31 07:33:32 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 05C82CAD; Sat, 31 Aug 2013 07:33:32 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CFB222096; Sat, 31 Aug 2013 07:33:31 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r7V7XUTI061470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Aug 2013 00:33:30 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r7V7XUEg061469; Sat, 31 Aug 2013 00:33:30 -0700 (PDT) (envelope-from jmg) Date: Sat, 31 Aug 2013 00:33:30 -0700 From: John-Mark Gurney To: John Baldwin Subject: Re: GCC withdraw Message-ID: <20130831073330.GC36239@funkthat.com> Mail-Followup-To: John Baldwin , David Chisnall , Boris Samorodov , "Sam Fourman Jr." , toolchain@freebsd.org, FreeBSD Current References: <20130822200902.GG94127@funkthat.com> <201308291344.25562.jhb@freebsd.org> <201308301041.18874.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201308301041.18874.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 31 Aug 2013 00:33:30 -0700 (PDT) Cc: "Sam Fourman Jr." , Boris Samorodov , David Chisnall , FreeBSD Current , toolchain@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 31 Aug 2013 07:33:32 -0000 John Baldwin wrote this message on Fri, Aug 30, 2013 at 10:41 -0400: > So I think the crux of the issue might be this: > > I have no doubt that this has been discussed extensively on toolchain@ and in > toolchain-specific devsummit sessions. The proposal to disable GCC by default > does not appear to have been discussed in a wider audience from what I can > tell. (I can't find any relevant threads on arch@ or current@ prior to this > one.) While this is a toolchain-specific decision, it is a very broad > decision. Also, we aren't here because of a new thread started intentionally > to say "Hey, we as the toolchain folks think we should disable GCC by default > on 10 for x86". Instead, we started off in a thread about adding AES > instructions to our binutils and out of left field there is an e-mail of > "Oh, don't bother cause I'm disabling GCC next week" (paraphrase). Can you > appreciate at all that this is a total surprise to people who aren't > subscribed to toolchain@ and haven't been to a toolchain session at a > devsummit and that this looks like a drive-by change? Why didn't this come up when John added XSAVE (a year ago) or Pedro Giffuni added amdfam10 support (3 months ago)? Plus, I've sent other patches earlier this year to -toolchain and made clear why I was adding them... Had I known that the policy was gcc was dead for HEAD (which btw, I was told multiple times that we were keeping gcc for 10 for i386/amd64), I would have just committed my kernel changes by now, but didn't want to break a (what I thought was) supported configuration... We need to communicate better on issues like these, since this isn't the first time one group of people made a decision w/o telling the rest of the community... For major items like this, we need to make sure the road map is published, either on www.freebsd.org or on the wiki and gets kept up to date... For example, the release schedule for 10 wasn't posted till over a week after the code slush was announced (which caught people, like myself, by surprise)... That's kinda the wrong order to do it in, the schedule should be posted well in advance so people know what to expect... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Sat Aug 31 07:52:42 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8C040215; Sat, 31 Aug 2013 07:52:42 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 469712176; Sat, 31 Aug 2013 07:52:41 +0000 (UTC) Received: from [192.168.0.2] (cpc27-cmbg15-2-0-cust235.5-4.cable.virginmedia.com [86.27.188.236]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r7V7qcp0015616 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 31 Aug 2013 07:52:40 GMT (envelope-from theraven@freebsd.org) Content-Type: multipart/signed; boundary="Apple-Mail=_15DB49B9-3C66-4919-82D8-B2BB93E5DFF6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: GCC withdraw From: David Chisnall In-Reply-To: <20130831073330.GC36239@funkthat.com> Date: Sat, 31 Aug 2013 08:52:34 +0100 Message-Id: <98D31DD3-8A1D-46ED-9BF6-9EBE39640860@freebsd.org> References: <20130822200902.GG94127@funkthat.com> <201308291344.25562.jhb@freebsd.org> <201308301041.18874.jhb@freebsd.org> <20130831073330.GC36239@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1508) Cc: "Sam Fourman Jr." , toolchain@freebsd.org, Boris Samorodov , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 31 Aug 2013 07:52:42 -0000 --Apple-Mail=_15DB49B9-3C66-4919-82D8-B2BB93E5DFF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 31 Aug 2013, at 08:33, John-Mark Gurney wrote: > Why didn't this come up when John added XSAVE (a year ago) or Pedro > Giffuni added amdfam10 support (3 months ago)? >=20 > Plus, I've sent other patches earlier this year to -toolchain and made > clear why I was adding them... Had I known that the policy was gcc = was > dead for HEAD (which btw, I was told multiple times that we were = keeping > gcc for 10 for i386/amd64), I would have just committed my kernel = changes > by now, but didn't want to break a (what I thought was) supported > configuration... gcc is not dead for 10.0, we're simply wanting to not ship it in binary = form by default. There is a BIG difference between saying 'if you want = gcc then you must explicitly opt in and build it yourself and it may not = be there for the entire 10.x series' and saying 'gcc is gone now, don't = expect any of FreeBSD to build with it'. We are absolutely not = proposing the latter for 10.0. =20 We still expect the 10.0 kernel and most of the userland (libc++ = excepted) to build with gcc. We expect this to be true for 10.1, and = probably 10.2, possibly even 10.3. I'd probably expect that at least = the kernel will build with gcc 4.2.1 for the entire timeframe. Some = modules may not, although for ease of debugging compiler bugs I'd = recommend that if they don't build with gcc 4.2.1 then at least they = build with upstream gcc. However, we want to be able to make it unsupported at some point in the = 10.x series when there is a polished alternative for every supported = architecture (either when they've moved to clang or when the XCC stuff = is fully documented in the handbook and tested in a large variety of = configurations and once our forked binutils and is available as a = package and we have cross-gcc that uses it). If this doesn't happen by = the time 10.x is EOL'd then I'll be sad, but we still have the fall-back = position of gcc in base for the entire 10.x. If it does happen, then we = can start more aggressively phasing out gcc in the base system. =20 > We need to communicate better on issues like these, since this isn't = the > first time one group of people made a decision w/o telling the rest > of the community... For major items like this, we need to make sure > the road map is published, either on www.freebsd.org or on the wiki = and > gets kept up to date... I agree. This is why I made sure that at the BSDCam DevSummit all of = the sessions had someone who was taking notes for their sessions on the = wiki: https://wiki.freebsd.org/201308DevSummit#Schedule-1 (Well, except, somewhat ironically, the docs team, who still haven't put = their notes on the wiki) It's also why I've taken charge of putting out special status reports = for each DevSummit for wider public consumption, like this one: http://www.freebsd.org/news/status/report-2013-05-devsummit.html I'd be interested in hearing any more suggestions about how we can = improve this. > For example, the release schedule for 10 wasn't posted till over a = week > after the code slush was announced (which caught people, like myself, = by > surprise)... That's kinda the wrong order to do it in, the schedule > should be posted well in advance so people know what to expect... This one you'll have to discuss with re@. I think that after 10.0 there = will be some more discussion about our release policy. =20 David --Apple-Mail=_15DB49B9-3C66-4919-82D8-B2BB93E5DFF6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJSIaDCAAoJEKx65DEEsqIddaIQAMoFVo3wnksWdRfZDNb0bDra hnga7Y6y02S3OVlHJUTtdvvLHTZC58lMSX1S3KHddbGYTgoirnpInPPd1Rqibq2X f980yOlvDksr8MqJvFdPRO7nxw/z+/iBhJaZlrwMJZ5MnZozZ9Lsr/EzRN9DdfaH aLBCWN7EjrYKJOaMPBH1nADYk8TfZw4iNLm18afSTAxd4hX1FHv5WivUsI869deg WQKk9Re5OuidQxl1Sc8c7Y0snXIK2OmNqmMXWjuKr+H2hLZN906lA6lrWxA5Ma4P NsoH/xPbK99dNAAjfA8L5uoqtempjAI8uerAuswbgf4kemwCeruwnvQl5cfsP5hd wcZ8EBkFYYKtonYtk8CTZ3d8cFkb++Rnxumc4DMbPIereeSA7oszIq6vbyewagft uDMtmg9fgP1u3aeJL8tTKXF0l0xTTa+kVRaOU3ahhT3/5VkAGPYZtbR9NuaX85Md 49HTe04u/kUKDNM8vSJCHE0EmAifAT1erEtjBaT8CQ49QlvpDsFtWeGKEQPL6KVv WIGhNfR9Cb/KzgfhLvTJ8a6MEtUTGBpdod0gEUvUtP2zWh84DpX+lDu135ZcvFPY Zok4qSE/2VK3J+wuq5ApFUH7NAXTnJrgTcyHdvKKGu1tWdnjYoDONrXKG4LFgcuD rxHM5svmJHs6TzqExqxo =er+m -----END PGP SIGNATURE----- --Apple-Mail=_15DB49B9-3C66-4919-82D8-B2BB93E5DFF6-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 31 11:40:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D5936F2 for ; Sat, 31 Aug 2013 11:40:59 +0000 (UTC) (envelope-from pawelbsd@gmail.com) Received: from mail-ee0-x22b.google.com (mail-ee0-x22b.google.com [IPv6:2a00:1450:4013:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0A38E2BED for ; Sat, 31 Aug 2013 11:40:58 +0000 (UTC) Received: by mail-ee0-f43.google.com with SMTP id e52so1377124eek.2 for ; Sat, 31 Aug 2013 04:40:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=zJVYT00aiSzMqC7iNbKIKwe/G/et6lRAASWdwnKBqHE=; b=u31oRhcCuRXk+I04yrXPaut95aEimo+klz4iUbhc/VdtqzFZXBYQVfbVxXrKuxpgJA WtJHl56knJvLrvIbyfYDB8kEHKv3H5ZXinJeDY0A/lSWoH6UZQ0H7QXm+iF2BXHMNBQo 4L26VsdA/0JWjNI5XAbz/lzQ9aZHGPf2kFDGEu6HBV6dJ33qytOzea00smR+4NqwHqEY TqhCbmUFjcZdi2Z/tXyLrwIW4txjbvN6sBNWFfBdpA5jYoePp8GT2qAM+LhyeWTYCJDP lopL8sQ8GYWj6x89tAMfaPP4B0ENbE/ng1J1ofb8FjB4bbrER9KwxPnQjzFGEu/Rd4sb OBwA== X-Received: by 10.14.199.3 with SMTP id w3mr20428079een.33.1377949256471; Sat, 31 Aug 2013 04:40:56 -0700 (PDT) Received: from localhost ([176.109.164.5]) by mx.google.com with ESMTPSA id r48sm4456521eev.14.1969.12.31.16.00.00 (version=SSLv3 cipher=RC4-SHA bits=128/128); Sat, 31 Aug 2013 04:40:54 -0700 (PDT) Sender: =?UTF-8?B?UGF3ZcWCIFDEmWthbGE=?= Date: Sat, 31 Aug 2013 13:38:13 +0200 From: Pawel Pekala To: freebsd-current@freebsd.org Subject: Re: urtw(4) disconnect problems Message-ID: <20130831133813.67ba001e@FreeBSD.org> In-Reply-To: <20130824133936.76e571bc@FreeBSD.org> References: <20130824133936.76e571bc@FreeBSD.org> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 31 Aug 2013 11:40:59 -0000 Dnia 2013-08-24, o godz. 13:39:36 Pawel Pekala napisa=B3(a): >Hi, > >I'm having problems with frequent disconnects of my AirLive WL-1600USB >hardware. After this happens the all reconnects fail and the only way >to fix it is to reboot the machine, while reboot I get this kernel >panic: > >http://people.freebsd.org/~pawel/urtw-panic.jpg More detailed logs after setting wlandebug flags to debug: Aug 31 12:00:34 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:00:34 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:00:34 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:00:34 blaviken kernel: wlan0: send probe req on channel 1 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:34 blaviken kernel: wlan0: send probe req on channel 1 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:34 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:00:34 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:00:34 blaviken kernel: wlan0: send probe req on channel 6 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:34 blaviken kernel: wlan0: send probe req on channel 6 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:34 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:00:35 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:00:35 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] pwr save q over= flow, drops 168 (size 50) [..] Aug 31 12:00:35 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] pwr save q over= flow, drops 217 (size 50) Aug 31 12:00:35 blaviken kernel: wlan0: send probe req on channel 11 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:35 blaviken kernel: wlan0: send probe req on channel 11 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:35 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] pwr save q over= flow, drops 218 (size 50) [..] Aug 31 12:00:35 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] pwr save q over= flow, drops 372 (size 50) Aug 31 12:00:35 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:00:35 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:00:35 blaviken kernel: wlan0: send probe req on channel 7 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:35 blaviken kernel: wlan0: send probe req on channel 7 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:35 blaviken kernel: wlan0: send probe req on channel 52 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:35 blaviken kernel: wlan0: send probe req on channel 52 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:36 blaviken kernel: wlan0: send probe req on channel 56 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:36 blaviken kernel: wlan0: send probe req on channel 56 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:36 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:00:36 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:00:36 blaviken kernel: wlan0: send probe req on channel 60 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:36 blaviken kernel: wlan0: send probe req on channel 60 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:36 blaviken kernel: wlan0: send probe req on channel 64 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:36 blaviken kernel: wlan0: send probe req on channel 64 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:37 blaviken kernel: wlan0: send probe req on channel 36 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:37 blaviken kernel: wlan0: send probe req on channel 36 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:37 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:00:37 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:00:37 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:00:37 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:00:37 blaviken kernel: wlan0: send probe req on channel 40 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:37 blaviken kernel: wlan0: send probe req on channel 40 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:37 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 14 Aug 31 12:00:37 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:00:38 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:00:38 blaviken kernel: wlan0: send probe req on channel 44 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:38 blaviken kernel: wlan0: send probe req on channel 44 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:38 blaviken kernel: wlan0: send probe req on channel 48 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:38 blaviken kernel: wlan0: send probe req on channel 48 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:38 blaviken kernel: wlan0: send probe req on channel 2 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:38 blaviken kernel: wlan0: send probe req on channel 2 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:39 blaviken kernel: wlan0: send probe req on channel 3 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:39 blaviken kernel: wlan0: send probe req on channel 3 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:39 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:00:39 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:00:39 blaviken kernel: wlan0: send probe req on channel 4 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:39 blaviken kernel: wlan0: send probe req on channel 4 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:39 blaviken kernel: wlan0: send probe req on channel 5 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:39 blaviken kernel: wlan0: send probe req on channel 5 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:39 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:00:39 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:00:40 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] pwr save q over= flow, drops 373 (size 50) [..] Aug 31 12:00:40 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] pwr save q over= flow, drops 393 (size 50) Aug 31 12:00:40 blaviken kernel: wlan0: send probe req on channel 8 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:40 blaviken kernel: wlan0: send probe req on channel 8 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:40 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] pwr save q over= flow, drops 394 (size 50) [..] Aug 31 12:00:40 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] pwr save q over= flow, drops 429 (size 50) Aug 31 12:00:40 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:00:40 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:00:40 blaviken kernel: wlan0: send probe req on channel 9 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:40 blaviken kernel: wlan0: send probe req on channel 9 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:40 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:00:40 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:00:40 blaviken kernel: wlan0: send probe req on channel 10 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:40 blaviken kernel: wlan0: send probe req on channel 10 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:41 blaviken kernel: wlan0: send probe req on channel 149 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:41 blaviken kernel: wlan0: send probe req on channel 149 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:41 blaviken kernel: wlan0: send probe req on channel 153 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:41 blaviken kernel: wlan0: send probe req on channel 153 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:41 blaviken kernel: wlan0: send probe req on channel 157 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:41 blaviken kernel: wlan0: send probe req on channel 157 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:42 blaviken kernel: wlan0: send probe req on channel 161 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:42 blaviken kernel: wlan0: send probe req on channel 161 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:42 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:00:42 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:00:42 blaviken kernel: wlan0: send probe req on channel 100 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:42 blaviken kernel: wlan0: send probe req on channel 100 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:42 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:00:42 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:00:43 blaviken kernel: wlan0: send probe req on channel 104 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:43 blaviken kernel: wlan0: send probe req on channel 104 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:43 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:00:43 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:00:43 blaviken kernel: wlan0: send probe req on channel 108 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:43 blaviken kernel: wlan0: send probe req on channel 108 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:43 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:00:43 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:00:44 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:00:44 blaviken kernel: wlan0: send probe req on channel 112 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:44 blaviken kernel: wlan0: send probe req on channel 112 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:44 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:00:44 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:00:44 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 16 Aug 31 12:00:44 blaviken kernel: wlan0: send probe req on channel 116 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:44 blaviken kernel: wlan0: send probe req on channel 116 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:44 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 14 Aug 31 12:00:44 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:00:44 blaviken kernel: wlan0: send probe req on channel 120 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:44 blaviken kernel: wlan0: send probe req on channel 120 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:44 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:00:44 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:00:45 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 14 Aug 31 12:00:45 blaviken kernel: wlan0: send probe req on channel 124 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:45 blaviken kernel: wlan0: send probe req on channel 124 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:45 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:00:45 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:00:45 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:00:45 blaviken kernel: wlan0: send probe req on channel 128 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:45 blaviken kernel: wlan0: send probe req on channel 128 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:45 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:00:45 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:00:45 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:00:45 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:00:46 blaviken kernel: wlan0: send probe req on channel 132 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:46 blaviken kernel: wlan0: send probe req on channel 132 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:46 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:00:46 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 14 Aug 31 12:00:46 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 16 Aug 31 12:00:46 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:00:46 blaviken kernel: wlan0: send probe req on channel 136 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:46 blaviken kernel: wlan0: send probe req on channel 136 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:46 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 14 Aug 31 12:00:46 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 16 Aug 31 12:00:46 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 14 Aug 31 12:00:46 blaviken kernel: wlan0: send probe req on channel 140 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:46 blaviken kernel: wlan0: send probe req on channel 140 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:00:46 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:00:46 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:00:46 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:05:46 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:05:46 blaviken kernel: wlan0: send probe req on channel 1 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:46 blaviken kernel: wlan0: send probe req on channel 1 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:46 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:05:47 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:05:47 blaviken kernel: wlan0: send probe req on channel 6 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:47 blaviken kernel: wlan0: send probe req on channel 6 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:47 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:05:47 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 14 Aug 31 12:05:47 blaviken kernel: wlan0: send probe req on channel 11 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:47 blaviken kernel: wlan0: send probe req on channel 11 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:47 blaviken kernel: wlan0: send probe req on channel 7 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:47 blaviken kernel: wlan0: send probe req on channel 7 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:47 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 14 Aug 31 12:05:47 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:05:48 blaviken kernel: wlan0: send probe req on channel 52 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:48 blaviken kernel: wlan0: send probe req on channel 52 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:48 blaviken kernel: wlan0: send probe req on channel 56 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:48 blaviken kernel: wlan0: send probe req on channel 56 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:48 blaviken kernel: wlan0: send probe req on channel 60 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:48 blaviken kernel: wlan0: send probe req on channel 60 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:48 blaviken kernel: wlan0: send probe req on channel 64 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:48 blaviken kernel: wlan0: send probe req on channel 64 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:49 blaviken kernel: wlan0: send probe req on channel 36 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:49 blaviken kernel: wlan0: send probe req on channel 36 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:49 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:05:49 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:05:49 blaviken kernel: wlan0: send probe req on channel 40 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:49 blaviken kernel: wlan0: send probe req on channel 40 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:49 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:05:49 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:05:49 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:05:50 blaviken kernel: wlan0: send probe req on channel 44 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:50 blaviken kernel: wlan0: send probe req on channel 44 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:50 blaviken kernel: wlan0: send probe req on channel 48 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:50 blaviken kernel: wlan0: send probe req on channel 48 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:50 blaviken kernel: wlan0: send probe req on channel 2 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:50 blaviken kernel: wlan0: send probe req on channel 2 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:50 blaviken kernel: wlan0: send probe req on channel 3 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:50 blaviken kernel: wlan0: send probe req on channel 3 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:51 blaviken kernel: wlan0: send probe req on channel 4 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:51 blaviken kernel: wlan0: send probe req on channel 4 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:51 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] pwr save q over= flow, drops 430 (size 50) [..] Aug 31 12:05:51 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] pwr save q over= flow, drops 546 (size 50) Aug 31 12:05:51 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:05:51 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:05:51 blaviken kernel: wlan0: send probe req on channel 5 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:51 blaviken kernel: wlan0: send probe req on channel 5 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:52 blaviken kernel: wlan0: send probe req on channel 8 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:52 blaviken kernel: wlan0: send probe req on channel 8 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:52 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 16 Aug 31 12:05:52 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 14 Aug 31 12:05:52 blaviken kernel: wlan0: send probe req on channel 9 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:52 blaviken kernel: wlan0: send probe req on channel 9 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:52 blaviken kernel: wlan0: send probe req on channel 10 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:52 blaviken kernel: wlan0: send probe req on channel 10 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:52 blaviken kernel: wlan0: send probe req on channel 149 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:52 blaviken kernel: wlan0: send probe req on channel 149 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:53 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:05:53 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:05:53 blaviken kernel: wlan0: send probe req on channel 153 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:53 blaviken kernel: wlan0: send probe req on channel 153 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:54 blaviken kernel: wlan0: send probe req on channel 157 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:54 blaviken kernel: wlan0: send probe req on channel 157 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:54 blaviken kernel: wlan0: send probe req on channel 161 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:54 blaviken kernel: wlan0: send probe req on channel 161 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:54 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:05:54 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:05:54 blaviken kernel: wlan0: send probe req on channel 100 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:54 blaviken kernel: wlan0: send probe req on channel 100 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:54 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:05:55 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:05:55 blaviken kernel: wlan0: send probe req on channel 104 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:55 blaviken kernel: wlan0: send probe req on channel 104 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:55 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 16 Aug 31 12:05:55 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:05:55 blaviken kernel: wlan0: send probe req on channel 108 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:55 blaviken kernel: wlan0: send probe req on channel 108 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:55 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 16 Aug 31 12:05:55 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:05:55 blaviken kernel: wlan0: send probe req on channel 112 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:55 blaviken kernel: wlan0: send probe req on channel 112 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:55 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 14 Aug 31 12:05:55 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:05:55 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:05:56 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:05:56 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:05:56 blaviken kernel: wlan0: send probe req on channel 116 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:56 blaviken kernel: wlan0: send probe req on channel 116 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:56 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:05:56 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:05:57 blaviken kernel: wlan0: send probe req on channel 120 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:57 blaviken kernel: wlan0: send probe req on channel 120 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:57 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 16 Aug 31 12:05:57 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:05:57 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:05:57 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] pwr save q over= flow, drops 547 (size 50) [..] Aug 31 12:05:57 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] pwr save q over= flow, drops 629 (size 50) Aug 31 12:05:57 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:05:57 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:05:57 blaviken kernel: wlan0: send probe req on channel 124 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:57 blaviken kernel: wlan0: send probe req on channel 124 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:57 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 14 Aug 31 12:05:57 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 16 Aug 31 12:05:58 blaviken kernel: wlan0: send probe req on channel 128 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:58 blaviken kernel: wlan0: send probe req on channel 128 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:58 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:05:58 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:05:58 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 14 Aug 31 12:05:58 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 16 Aug 31 12:05:58 blaviken kernel: wlan0: send probe req on channel 132 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:58 blaviken kernel: wlan0: send probe req on channel 132 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:58 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:05:58 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:05:58 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:05:58 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:05:58 blaviken kernel: wlan0: send probe req on channel 136 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:58 blaviken kernel: wlan0: send probe req on channel 136 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:58 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:05:58 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:05:58 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 14 Aug 31 12:05:59 blaviken kernel: wlan0: send probe req on channel 140 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:59 blaviken kernel: wlan0: send probe req on channel 140 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:05:59 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:10:59 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:10:59 blaviken kernel: wlan0: send probe req on channel 1 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:10:59 blaviken kernel: wlan0: send probe req on channel 1 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:10:59 blaviken kernel: wlan0: send probe req on channel 6 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:10:59 blaviken kernel: wlan0: send probe req on channel 6 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:10:59 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:10:59 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:10:59 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:10:59 blaviken kernel: wlan0: send probe req on channel 11 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:10:59 blaviken kernel: wlan0: send probe req on channel 11 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:10:59 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:11:00 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:11:00 blaviken kernel: wlan0: send probe req on channel 7 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:00 blaviken kernel: wlan0: send probe req on channel 7 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:00 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:11:01 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:11:01 blaviken kernel: wlan0: send probe req on channel 52 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:01 blaviken kernel: wlan0: send probe req on channel 52 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:01 blaviken kernel: wlan0: send probe req on channel 56 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:01 blaviken kernel: wlan0: send probe req on channel 56 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:01 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] pwr save q over= flow, drops 630 (size 50) [..] Aug 31 12:11:01 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] pwr save q over= flow, drops 1476 (size 50) Aug 31 12:11:01 blaviken kernel: wlan0: send probe req on channel 60 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:01 blaviken kernel: wlan0: send probe req on channel 60 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:01 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] pwr save q over= flow, drops 1477 (size 50) [..] Aug 31 12:11:02 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] pwr save q over= flow, drops 1926 (size 50) Aug 31 12:11:02 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:11:02 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:11:02 blaviken kernel: wlan0: send probe req on channel 64 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:02 blaviken kernel: wlan0: send probe req on channel 64 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:02 blaviken kernel: wlan0: send probe req on channel 36 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:02 blaviken kernel: wlan0: send probe req on channel 36 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:02 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:11:02 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:11:03 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 16 Aug 31 12:11:03 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] pwr save q over= flow, drops 1927 (size 50) [..] Aug 31 12:11:03 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] pwr save q over= flow, drops 1998 (size 50) Aug 31 12:11:03 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:11:03 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:11:03 blaviken kernel: wlan0: send probe req on channel 40 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:03 blaviken kernel: wlan0: send probe req on channel 40 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:03 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 14 Aug 31 12:11:03 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:11:04 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:11:04 blaviken kernel: wlan0: send probe req on channel 44 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:04 blaviken kernel: wlan0: send probe req on channel 44 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:04 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] pwr save q over= flow, drops 1999 (size 50) [..] Aug 31 12:11:04 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] pwr save q over= flow, drops 2275 (size 50) Aug 31 12:11:04 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:11:04 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:11:04 blaviken kernel: wlan0: send probe req on channel 48 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:04 blaviken kernel: wlan0: send probe req on channel 48 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:05 blaviken kernel: wlan0: send probe req on channel 2 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:05 blaviken kernel: wlan0: send probe req on channel 2 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:05 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] pwr save q over= flow, drops 2276 (size 50) [..] Aug 31 12:11:05 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] pwr save q over= flow, drops 3011 (size 50) Aug 31 12:11:05 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:11:05 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:11:05 blaviken kernel: wlan0: send probe req on channel 3 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:05 blaviken kernel: wlan0: send probe req on channel 3 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:05 blaviken kernel: wlan0: send probe req on channel 4 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:05 blaviken kernel: wlan0: send probe req on channel 4 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:06 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:11:06 blaviken kernel: wlan0: send probe req on channel 5 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:06 blaviken kernel: wlan0: send probe req on channel 5 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:06 blaviken kernel: wlan0: send probe req on channel 8 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:06 blaviken kernel: wlan0: send probe req on channel 8 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:06 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:11:06 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:11:07 blaviken kernel: wlan0: send probe req on channel 9 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:07 blaviken kernel: wlan0: send probe req on channel 9 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:07 blaviken kernel: wlan0: send probe req on channel 10 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:07 blaviken kernel: wlan0: send probe req on channel 10 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:07 blaviken kernel: wlan0: send probe req on channel 149 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:07 blaviken kernel: wlan0: send probe req on channel 149 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:07 blaviken kernel: wlan0: send probe req on channel 153 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:07 blaviken kernel: wlan0: send probe req on channel 153 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:08 blaviken kernel: wlan0: send probe req on channel 157 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:08 blaviken kernel: wlan0: send probe req on channel 157 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:08 blaviken kernel: wlan0: send probe req on channel 161 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:08 blaviken kernel: wlan0: send probe req on channel 161 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:08 blaviken kernel: wlan0: send probe req on channel 100 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:08 blaviken kernel: wlan0: send probe req on channel 100 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:08 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:11:09 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:11:09 blaviken kernel: wlan0: send probe req on channel 104 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:09 blaviken kernel: wlan0: send probe req on channel 104 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:09 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:11:09 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:11:09 blaviken kernel: wlan0: send probe req on channel 108 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:09 blaviken kernel: wlan0: send probe req on channel 108 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:09 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:11:09 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 14 Aug 31 12:11:09 blaviken kernel: wlan0: send probe req on channel 112 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:09 blaviken kernel: wlan0: send probe req on channel 112 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:09 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:11:09 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:11:09 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 14 Aug 31 12:11:09 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:11:10 blaviken kernel: wlan0: send probe req on channel 116 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:10 blaviken kernel: wlan0: send probe req on channel 116 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:10 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:11:10 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:11:10 blaviken kernel: wlan0: send probe req on channel 120 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:10 blaviken kernel: wlan0: send probe req on channel 120 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:10 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 14 Aug 31 12:11:10 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 14 Aug 31 12:11:10 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 14 Aug 31 12:11:10 blaviken kernel: wlan0: send probe req on channel 124 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:10 blaviken kernel: wlan0: send probe req on channel 124 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:11 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:11:11 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:11:11 blaviken kernel: wlan0: send probe req on channel 128 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:11 blaviken kernel: wlan0: send probe req on channel 128 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:11 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 14 Aug 31 12:11:11 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:11:11 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:11:11 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:11:11 blaviken kernel: wlan0: send probe req on channel 132 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:11 blaviken kernel: wlan0: send probe req on channel 132 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:11 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 16 Aug 31 12:11:11 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:11:11 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:11:12 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:11:12 blaviken kernel: wlan0: send probe req on channel 136 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:12 blaviken kernel: wlan0: send probe req on channel 136 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:12 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:11:12 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:11:12 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 14 Aug 31 12:11:12 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:11:12 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:11:12 blaviken kernel: wlan0: send probe req on channel 140 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:12 blaviken kernel: wlan0: send probe req on channel 140 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:11:12 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:11:12 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:11:12 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:11:13 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:16:13 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:16:13 blaviken kernel: wlan0: send probe req on channel 1 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:13 blaviken kernel: wlan0: send probe req on channel 1 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:13 blaviken kernel: wlan0: send probe req on channel 6 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:13 blaviken kernel: wlan0: send probe req on channel 6 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:13 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:16:13 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:16:13 blaviken kernel: wlan0: send probe req on channel 11 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:13 blaviken kernel: wlan0: send probe req on channel 11 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:13 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:16:13 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:16:14 blaviken kernel: wlan0: send probe req on channel 7 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:14 blaviken kernel: wlan0: send probe req on channel 7 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:14 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 16 Aug 31 12:16:14 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:16:14 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] pwr save q over= flow, drops 3012 (size 50) [..] Aug 31 12:16:14 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] pwr save q over= flow, drops 3289 (size 50) Aug 31 12:16:14 blaviken kernel: wlan0: send probe req on channel 52 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:14 blaviken kernel: wlan0: send probe req on channel 52 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:14 blaviken kernel: wlan0: send probe req on channel 56 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:14 blaviken kernel: wlan0: send probe req on channel 56 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:15 blaviken kernel: wlan0: send probe req on channel 60 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:15 blaviken kernel: wlan0: send probe req on channel 60 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:15 blaviken kernel: wlan0: send probe req on channel 64 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:15 blaviken kernel: wlan0: send probe req on channel 64 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:15 blaviken kernel: r save q overflow, drops 3352 (size 50) Aug 31 12:16:15 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] pwr save q over= flow, drops 3353 (size 50) [..] Aug 31 12:16:15 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] pwr save q over= flow, drops 4774 (size 50) Aug 31 12:16:15 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:16:15 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:16:15 blaviken kernel: wlan0: send probe req on channel 36 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:15 blaviken kernel: wlan0: send probe req on channel 36 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:15 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:16:16 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:16:16 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:16:16 blaviken kernel: wlan0: send probe req on channel 40 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:16 blaviken kernel: wlan0: send probe req on channel 40 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:16 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:16:16 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:16:16 blaviken kernel: wlan0: send probe req on channel 44 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:16 blaviken kernel: wlan0: send probe req on channel 44 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:17 blaviken kernel: wlan0: send probe req on channel 48 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:17 blaviken kernel: wlan0: send probe req on channel 48 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:17 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:16:17 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:16:17 blaviken kernel: wlan0: send probe req on channel 2 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:17 blaviken kernel: wlan0: send probe req on channel 2 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:18 blaviken kernel: wlan0: send probe req on channel 3 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:18 blaviken kernel: wlan0: send probe req on channel 3 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:18 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:16:18 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:16:18 blaviken kernel: wlan0: send probe req on channel 4 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:18 blaviken kernel: wlan0: send probe req on channel 4 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:18 blaviken kernel: wlan0: send probe req on channel 5 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:18 blaviken kernel: wlan0: send probe req on channel 5 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:19 blaviken kernel: wlan0: send probe req on channel 8 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:19 blaviken kernel: wlan0: send probe req on channel 8 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:19 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:16:19 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:16:19 blaviken kernel: wlan0: send probe req on channel 9 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:19 blaviken kernel: wlan0: send probe req on channel 9 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:19 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:16:20 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:16:20 blaviken kernel: wlan0: send probe req on channel 10 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:20 blaviken kernel: wlan0: send probe req on channel 10 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:20 blaviken kernel: wlan0: send probe req on channel 149 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:20 blaviken kernel: wlan0: send probe req on channel 149 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:20 blaviken kernel: wlan0: send probe req on channel 153 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:20 blaviken kernel: wlan0: send probe req on channel 153 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:21 blaviken kernel: wlan0: send probe req on channel 157 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:21 blaviken kernel: wlan0: send probe req on channel 157 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:21 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:16:21 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:16:21 blaviken kernel: wlan0: send probe req on channel 161 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:21 blaviken kernel: wlan0: send probe req on channel 161 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:21 blaviken kernel: wlan0: send probe req on channel 100 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:21 blaviken kernel: wlan0: send probe req on channel 100 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:21 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:16:21 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 16 Aug 31 12:16:21 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:16:22 blaviken kernel: wlan0: send probe req on channel 104 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:22 blaviken kernel: wlan0: send probe req on channel 104 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:22 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:16:22 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:16:22 blaviken kernel: wlan0: send probe req on channel 108 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:22 blaviken kernel: wlan0: send probe req on channel 108 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:22 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:16:22 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:16:22 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:16:22 blaviken kernel: wlan0: send probe req on channel 112 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:22 blaviken kernel: wlan0: send probe req on channel 112 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:22 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:16:22 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 14 Aug 31 12:16:22 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:16:22 blaviken kernel: wlan0: send probe req on channel 116 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:22 blaviken kernel: wlan0: send probe req on channel 116 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:22 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:16:23 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:16:23 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:16:23 blaviken kernel: wlan0: send probe req on channel 120 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:23 blaviken kernel: wlan0: send probe req on channel 120 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:23 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:16:23 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 14 Aug 31 12:16:23 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 14 Aug 31 12:16:23 blaviken kernel: wlan0: send probe req on channel 124 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:23 blaviken kernel: wlan0: send probe req on channel 124 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:23 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 14 Aug 31 12:16:23 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 16 Aug 31 12:16:23 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 14 Aug 31 12:16:23 blaviken kernel: wlan0: send probe req on channel 128 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:23 blaviken kernel: wlan0: send probe req on channel 128 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:23 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:16:23 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:16:24 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 14 Aug 31 12:16:24 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:16:24 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:16:24 blaviken kernel: wlan0: send probe req on channel 132 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:24 blaviken kernel: wlan0: send probe req on channel 132 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:24 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:16:24 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:16:24 blaviken kernel: wlan0: send probe req on channel 136 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:24 blaviken kernel: wlan0: send probe req on channel 136 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:24 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:16:24 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:16:24 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:16:25 blaviken kernel: wlan0: send probe req on channel 140 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:25 blaviken kernel: wlan0: send probe req on channel 140 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:16:25 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 16 Aug 31 12:16:25 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:16:25 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 14 Aug 31 12:16:25 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:21:25 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:21:25 blaviken kernel: wlan0: send probe req on channel 1 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:25 blaviken kernel: wlan0: send probe req on channel 1 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:25 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:21:26 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:21:26 blaviken kernel: wlan0: send probe req on channel 6 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:26 blaviken kernel: wlan0: send probe req on channel 6 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:26 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 14 Aug 31 12:21:26 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:21:26 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:21:26 blaviken kernel: wlan0: send probe req on channel 11 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:26 blaviken kernel: wlan0: send probe req on channel 11 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:27 blaviken kernel: wlan0: send probe req on channel 7 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:27 blaviken kernel: wlan0: send probe req on channel 7 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:27 blaviken kernel: wlan0: send probe req on channel 52 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:27 blaviken kernel: wlan0: send probe req on channel 52 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:27 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] pwr save q over= flow, drops 4775 (size 50) [..] Aug 31 12:21:27 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] pwr save q over= flow, drops 5034 (size 50) Aug 31 12:21:27 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:21:27 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:21:27 blaviken kernel: wlan0: send probe req on channel 56 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:27 blaviken kernel: wlan0: send probe req on channel 56 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:28 blaviken kernel: wlan0: send probe req on channel 60 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:28 blaviken kernel: wlan0: send probe req on channel 60 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:28 blaviken kernel: wlan0: send probe req on channel 64 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:28 blaviken kernel: wlan0: send probe req on channel 64 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:28 blaviken kernel: wlan0: send probe req on channel 36 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:28 blaviken kernel: wlan0: send probe req on channel 36 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:28 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:21:28 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 16 Aug 31 12:21:28 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:21:29 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:21:29 blaviken kernel: wlan0: send probe req on channel 40 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:29 blaviken kernel: wlan0: send probe req on channel 40 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:29 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 14 Aug 31 12:21:29 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 14 Aug 31 12:21:29 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:21:29 blaviken kernel: wlan0: send probe req on channel 44 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:29 blaviken kernel: wlan0: send probe req on channel 44 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:29 blaviken kernel: wlan0: send probe req on channel 48 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:29 blaviken kernel: wlan0: send probe req on channel 48 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:30 blaviken kernel: wlan0: send probe req on channel 2 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:30 blaviken kernel: wlan0: send probe req on channel 2 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:30 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:21:30 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:21:30 blaviken kernel: wlan0: send probe req on channel 3 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:30 blaviken kernel: wlan0: send probe req on channel 3 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:31 blaviken kernel: wlan0: send probe req on channel 4 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:31 blaviken kernel: wlan0: send probe req on channel 4 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:31 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] pwr save q over= flow, drops 5035 (size 50) [..] Aug 31 12:21:31 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] pwr save q over= flow, drops 7845 (size 50) Aug 31 12:21:31 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:21:31 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:21:31 blaviken kernel: wlan0: send probe req on channel 8 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:31 blaviken kernel: wlan0: send probe req on channel 8 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:31 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:21:32 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:21:32 blaviken kernel: wlan0: send probe req on channel 9 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:32 blaviken kernel: wlan0: send probe req on channel 9 bssid f= f:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:32 blaviken kernel: wlan0: send probe req on channel 10 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:32 blaviken kernel: wlan0: send probe req on channel 10 bssid = ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:32 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:21:33 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:21:33 blaviken kernel: wlan0: send probe req on channel 149 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:33 blaviken kernel: wlan0: send probe req on channel 149 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:33 blaviken kernel: wlan0: send probe req on channel 153 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:33 blaviken kernel: wlan0: send probe req on channel 153 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:33 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:21:33 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:21:33 blaviken kernel: wlan0: send probe req on channel 157 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:33 blaviken kernel: wlan0: send probe req on channel 157 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:34 blaviken kernel: wlan0: send probe req on channel 161 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:34 blaviken kernel: wlan0: send probe req on channel 161 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:34 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:21:34 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:21:34 blaviken kernel: wlan0: send probe req on channel 100 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:34 blaviken kernel: wlan0: send probe req on channel 100 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:34 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:21:34 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:21:34 blaviken kernel: wlan0: send probe req on channel 104 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:34 blaviken kernel: wlan0: send probe req on channel 104 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:35 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:21:35 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:21:35 blaviken kernel: wlan0: send probe req on channel 108 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:35 blaviken kernel: wlan0: send probe req on channel 108 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:35 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 16 Aug 31 12:21:35 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 14 Aug 31 12:21:35 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:21:35 blaviken kernel: wlan0: send probe req on channel 112 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:35 blaviken kernel: wlan0: send probe req on channel 112 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:35 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:21:35 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:21:35 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:21:36 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt ena Aug 31 12:21:36 blaviken kernel: wlan0: send probe req on channel 116 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:36 blaviken kernel: wlan0: send probe req on channel 116 bssid= ff:ff:ff:ff:ff:ff ssid "" Aug 31 12:21:36 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:21:36 blaviken kernel: wlan0: received beacon from bc:ae:c5:c4:8c= :98 rssi 15 Aug 31 12:21:36 blaviken kernel: overflow, drops 10615 (size 50) Aug 31 12:21:36 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] pwr save q over= flow, drops 10616 (size 50) [..] Aug 31 12:21:36 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] pwr save q over= flow, drops 10662 (size 50) Aug 31 12:21:36 blaviken kernel: wlan0: received probe_resp from bc:ae:c5:c= 4:8c:98 rssi 15 Aug 31 12:21:36 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] pwr save q over= flow, drops 10663 (size 50) [..] Aug 31 12:21:36 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] pwr save q over= flow, drops 12014 (size 50) Aug 31 12:21:36 blaviken kernel: wlan0: [bc:ae:c5:c4:8c:98] send null data = frame on channel 6, pwr mgt dis Aug 31 12:21:39 blaviken kernel: wlan0: beacon miss, mode STA state RUN Aug 31 12:21:39 blaviken kernel: wlan0: send probe req on channel 6 bssid b= c:ae:c5:c4:8c:98 ssid "Slowicza" Aug 31 12:21:40 blaviken kernel: wlan0: beacon miss, mode STA state RUN Aug 31 12:21:40 blaviken kernel: wlan0: link state changed to DOWN Aug 31 12:21:40 blaviken wpa_supplicant[1384]: wlan0: CTRL-EVENT-DISCONNECT= ED bssid=3Dbc:ae:c5:c4:8c:98 reason=3D0 --=20 pozdrawiam / with regards Pawe=B3 P=EAkala From owner-freebsd-current@FreeBSD.ORG Sat Aug 31 17:07:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5781419A for ; Sat, 31 Aug 2013 17:07:06 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E19BB2B36 for ; Sat, 31 Aug 2013 17:07:05 +0000 (UTC) Received: by mail-we0-f171.google.com with SMTP id p57so2526604wes.2 for ; Sat, 31 Aug 2013 10:07:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=kt6VUKeLjiJEPJjMqKJktpzqDjcmDFRy/cSU9cn16OM=; b=wdIVKcANrIHn1Uqt2QcRzqnqvr7kC6ZuzTkoB+MUw+fvE4Fs5GSLrH4oblxdzYonLG X5+7ye2x5UqmNKZ4ys4hjftAz5MQuVmYpz6pl2xm1WHUaVDx1kXayEokteWosxLDatza mDrBI10Cpy2+4cU10f5Qp+zcgwYfiksfoHlQk3c98SuqDtyO4VqvnfIq8YMO+qQWW8pn Qj+Hm7CNS+Z4LYIISXYBb622x1O9zPMM3aS6xvHPCy5hrvAfbKTzewHOB9cgHsJJWyPS /9/K0xEFjJpRgIqrhCilD0sFuk4wxSaT//ZNnpuoJGgtjoBeb0YpWX0iaOtRkoSt4J4m j6kA== MIME-Version: 1.0 X-Received: by 10.194.250.6 with SMTP id yy6mr15882009wjc.13.1377968823612; Sat, 31 Aug 2013 10:07:03 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.146.2 with HTTP; Sat, 31 Aug 2013 10:07:03 -0700 (PDT) In-Reply-To: References: Date: Sat, 31 Aug 2013 10:07:03 -0700 X-Google-Sender-Auth: xNppxLyAgQCNz9dGjbjg2_0MVl8 Message-ID: Subject: Re: 2013 MacBook Air Project From: Adrian Chadd To: "Lundberg, Johannes" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 31 Aug 2013 17:07:06 -0000 I've begun trying to hunt down someone at Broadcom to talk about the 11ac driver. Wish me luck. (And install/run FreeBSD on mac hardware..) -adrian On 30 August 2013 09:25, Lundberg, Johannes wrote: > Hi > > I thought I'd give a progress report on running FreeBSD 10 on a MacBook Air > 11" 2013 model. > > PCI-E SSD DRIVE > - Added device ID to device list. Should be committed to head already. > - Failed to write partition table due to weird characters at the end in the > SSD's identifier key. Solved by ugly hack (cutting off the ident string in > the middle), fix not committed. > > SMP > - No problem when booting from usb memory stick. However, have to disable > smp in /boot/loader.conf with kern.smp.disabled="1" to boot from the SSD. > > USB > - Reverted sys/dev/usb/controller/xhci* to 243780 to make it work. > > WIFI > - Seems like this one is gonna be difficult due to Broadcom's proprietary > driver.... > > ETHERNET > - Thunderbolt adapter works fine but hot-plugging not supported so you need > to connect it before booting. > > BLUETOOTH > - Added device to usbdevs and ng_ubt.c. Device is recognised and ubt0 > created but when running "service bluetooth start ubt0" I get "Unable to > setup Bluetooth stack for device ubt0". Works fine with other generic > bluetooth 4.0 usb dongle. No debugging done. > > Will install Xorg next week so report about that coming later. > > Best Regards > > Johannes Lundberg > BRILLIANTSERVICE CO., LTD. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sat Aug 31 17:07:54 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C5D502A8 for ; Sat, 31 Aug 2013 17:07:54 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 514E92B48 for ; Sat, 31 Aug 2013 17:07:54 +0000 (UTC) Received: by mail-ve0-f173.google.com with SMTP id cy12so2123492veb.4 for ; Sat, 31 Aug 2013 10:07:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=h2DznriqMZDIZZmhKqJRiUJrzXoSMWX3gXUoElIjUpU=; b=WdkSh0gIufv146QMwqHn7OdJRR9bUoYmIOnKYX/iLJCvTHcnpRLBzAL32CqXcWRKOo 1Uv+29eRRuTPsC5FWwj3ypzxoE+HNCgdNP6h/EF5k0zj9bHcSp4drnxbnzrBneYhEFEZ jrBegtF31YkOHIip0B6DzR35RDKwsAg+brLqfGsFvKpG5T8Cu+qyjv7zA1UA1vQh2UCD wOduNslnnf7m2OGq3TamxJsmvDrum+Fr8zMXguLB5QRjQvZM2wP9ugjC/GCr+9ERllWs mN1ouceVXLSRS/f/HXv97w907iM8F5Gd3kKTHcATfpkDrfV0tKBMf8uJt8NzjQ302zp/ jEGw== MIME-Version: 1.0 X-Received: by 10.220.88.13 with SMTP id y13mr14308893vcl.20.1377968873412; Sat, 31 Aug 2013 10:07:53 -0700 (PDT) Received: by 10.220.96.78 with HTTP; Sat, 31 Aug 2013 10:07:53 -0700 (PDT) Date: Sat, 31 Aug 2013 13:07:53 -0400 Message-ID: Subject: LSI SAS2008 mps(4) 4TB disk only shows 2TB on CURRENT r255089 From: "Sam Fourman Jr." To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 31 Aug 2013 17:07:54 -0000 Hello list I have two issues that may in fact be both related to the LSI SAS2008 card or the mps(4) driver. this server is running FreeBSD 10.0-CURRENT #0 r255089 1) All of the SSD disks are showing up at SATA2 300MB's but the card is in fact a 6GB Sata3 card.. 2) a Westren Digital 4TB disk only shows 2TB (connected to the LSI controller) full dmesg here https://gist.github.com/sfourman/6399419 full pciconf here https://gist.github.com/sfourman/6399454 Below is some disk info, $ sudo camcontrol identify da6 pass6: ATA-8 SATA 3.x device pass6: 300.000MB/s transfers, Command Queueing Enabled protocol ATA/ATAPI-8 SATA 3.x device model WDC WD4000FYYZ-01UL1B0 firmware revision 01.01K01 serial number WD-WCC130721596 WWN 50014ee25de95b67 cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 268435455 sectors LBA48 supported 7814037168 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 media RPM 7200 Feature Support Enabled Value Vendor read ahead yes yes write cache yes yes flush cache yes yes overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management yes yes 128/0x80 automatic acoustic management no no media status notification no no power-up in Standby yes no write-read-verify no no unload yes yes free-fall no no Data Set Management (DSM/TRIM) no Host Protected Area (HPA) yes no 7814037168/7814037168 HPA - Security no $ sudo gpart create -s gpt /dev/da6 da6 created $ gpart show => 34 234441581 da0 GPT (111G) 34 128 1 freebsd-boot (64k) 162 224395136 2 freebsd-ufs (107G) 224395298 8388608 3 freebsd-swap (4.0G) 232783906 1657709 - free - (809M) => 34 4294967227 da6 GPT (2T) 34 4294967227 - free - (2T) $ sudo gpart add -a 4k -t freebsd-zfs -l backup da6 da6p1 added $ $ $ $ $ $ gpart show => 34 234441581 da0 GPT (111G) 34 128 1 freebsd-boot (64k) 162 224395136 2 freebsd-ufs (107G) 224395298 8388608 3 freebsd-swap (4.0G) 232783906 1657709 - free - (809M) => 34 4294967227 da6 GPT (2T) 34 6 - free - (3.0k) 40 4294967216 1 freebsd-zfs (2T) 4294967256 5 - free - (2.5k) -- Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Sat Aug 31 18:42:27 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D5D426ED for ; Sat, 31 Aug 2013 18:42:27 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A436E2EF1 for ; Sat, 31 Aug 2013 18:42:27 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id x14so5530992ief.39 for ; Sat, 31 Aug 2013 11:42:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=2NQUTQWzkWzLlB07d/kRCWPxhdWErs8vvgWlaSw4w90=; b=Th7x7f/ssLU/jA8l1Z80PZGFdUs1BPFyrNHLFHuK/MCiydA5OVgUwVYWkSK/qril3X h6ofbeU92UtIFNxkwJHySXBNanMf02WtxDceNXtTHOF4jXHs7/Vgvb8LhhksZvEZ/PvN fQhCmhntkazusZp1vmnKAFFIVplobYgXFPXSEUQWXAqBKFCJmKTT12gBN1NtxEwxveMS kitJ/3eQnF8R/Pc+5XdY28Gbl0wZtej8Q+5HLLf4SqG1kjIJLS7NMeRcjsc/CVvdKxyj vLtffSMDfTZU66B8bPhvJupvARVSsocUum8FzNgG67AGvQW+8RNC8hLJ0RV7hp4yUhMK j1Wg== X-Gm-Message-State: ALoCoQkaEGw4XXu7yjyXmwJGEEwK/qKgKdvpzXeaSUbFW1qJHRqOgmcEf3nEaQ/56cIp9A8fzPrv X-Received: by 10.50.20.232 with SMTP id q8mr6945716ige.0.1377974541093; Sat, 31 Aug 2013 11:42:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.158.74 with HTTP; Sat, 31 Aug 2013 11:42:06 -0700 (PDT) In-Reply-To: <52219732.7070209@bitfrost.no> References: <522110CB.5050501@mu.org> <52219732.7070209@bitfrost.no> From: "Lundberg, Johannes" Date: Sat, 31 Aug 2013 20:42:06 +0200 Message-ID: Subject: Re: 2013 MacBook Air Project To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Alfred Perlstein , =?ISO-8859-1?Q?S=F8ren_Schmidt?= , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 31 Aug 2013 18:42:28 -0000 Hi Hans Thanks for adding the device! And, sorry but the patch didn't make any difference :( Johannes Lundberg BRILLIANTSERVICE CO., LTD. On Sat, Aug 31, 2013 at 9:11 AM, Hans Petter Selasky wrote: > On 08/31/13 01:42, Lundberg, Johannes wrote: > >> + >> + /* MacBookAir6,1 */ >> + { USB_VPI(0x05ac, 0x828f, 0) }, >> + >> }; >> >> > Hi, > > I've updated the FreeBSD USB bluetooth driver with your ID, and a few more > from Linux. > > I've attached an XHCI patch you can try. > > --HPS > From owner-freebsd-current@FreeBSD.ORG Sat Aug 31 18:44:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E88DF80D for ; Sat, 31 Aug 2013 18:44:35 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B7BF92F0C for ; Sat, 31 Aug 2013 18:44:35 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id a14so5725344iee.12 for ; Sat, 31 Aug 2013 11:44:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=LnqSxevQeC45/VZSQQOg7m4b+GHDJ3eYracHEhmNThE=; b=fKKstTceUb9qWDc7La1H6CXBU7i50kSqVxttsttYlicNs/au5SpH8f8r2oxsJMUNQ3 jXmz8wCSCcfTRXjK1QvPfiH2eOAiV/WJv00JC4iw9CAPpiVxRajDv8gd8jzUzZMJ2FVj yTUHEhNCNnxOaJmhK+WIw4eEh1zsnJGOrLD8wZppNoyYigZI5XK47NUATlAgS/ZQUejE BLWtuBmspG/uF5GV9PN8EMzfk1iaIW/GGIJunxuDpLVux5Gfe459H7SD/pzpP1sBUC8F nC/x4GOvHgBNAgYAd0/6QXl0G+uRPWv2qx8r4EscZzGO8Moh0C7tevchiC1qWh07axUF BloA== X-Gm-Message-State: ALoCoQlGW/uJq16x1WhvDF2GorxS88ytdHhrc6Fsaq+K+7PCA3WhJcnduPq3j2BaIqykopceE5Fv X-Received: by 10.50.122.102 with SMTP id lr6mr6950391igb.0.1377974669160; Sat, 31 Aug 2013 11:44:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.158.74 with HTTP; Sat, 31 Aug 2013 11:44:14 -0700 (PDT) In-Reply-To: References: From: "Lundberg, Johannes" Date: Sat, 31 Aug 2013 20:44:14 +0200 Message-ID: Subject: Re: 2013 MacBook Air Project To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 31 Aug 2013 18:44:36 -0000 Hi Adrian That's great! Good luck to you :) Johannes Lundberg BRILLIANTSERVICE CO., LTD. On Sat, Aug 31, 2013 at 7:07 PM, Adrian Chadd wrote: > I've begun trying to hunt down someone at Broadcom to talk about the 11ac > driver. > > Wish me luck. > > (And install/run FreeBSD on mac hardware..) > > > > -adrian > > > On 30 August 2013 09:25, Lundberg, Johannes < > johannes@brilliantservice.co.jp> wrote: > >> Hi >> >> I thought I'd give a progress report on running FreeBSD 10 on a MacBook >> Air >> 11" 2013 model. >> >> PCI-E SSD DRIVE >> - Added device ID to device list. Should be committed to head already. >> - Failed to write partition table due to weird characters at the end in >> the >> SSD's identifier key. Solved by ugly hack (cutting off the ident string in >> the middle), fix not committed. >> >> SMP >> - No problem when booting from usb memory stick. However, have to disable >> smp in /boot/loader.conf with kern.smp.disabled="1" to boot from the SSD. >> >> USB >> - Reverted sys/dev/usb/controller/xhci* to 243780 to make it work. >> >> WIFI >> - Seems like this one is gonna be difficult due to Broadcom's proprietary >> driver.... >> >> ETHERNET >> - Thunderbolt adapter works fine but hot-plugging not supported so you >> need >> to connect it before booting. >> >> BLUETOOTH >> - Added device to usbdevs and ng_ubt.c. Device is recognised and ubt0 >> created but when running "service bluetooth start ubt0" I get "Unable to >> setup Bluetooth stack for device ubt0". Works fine with other generic >> bluetooth 4.0 usb dongle. No debugging done. >> >> Will install Xorg next week so report about that coming later. >> >> Best Regards >> >> Johannes Lundberg >> >> BRILLIANTSERVICE CO., LTD. >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org >> " >> > > From owner-freebsd-current@FreeBSD.ORG Sat Aug 31 21:09:33 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E33B3D3A for ; Sat, 31 Aug 2013 21:09:33 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 77AF324A4 for ; Sat, 31 Aug 2013 21:09:33 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id a12so2567590wgh.28 for ; Sat, 31 Aug 2013 14:09:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=X9ZR/Jvrq2Bdp6afpWsLPXVdVf0rBrE92qlDEYE/Cis=; b=oLl9cOEyCbXJBCtUPDeKdc+4PuV1Rp0shR7mMKY1RvYfdJ23ySGB0E5+sHp7h84Ujq iL1Kj45oPvFqxc0fiM26VtcS4zbv9LWQHZjh1Nw/JnNkgzm13OorVqkU5J4cKNHrR6+i B+Sun7wdzJVWECKRX0LDUJOnHKvC0ZZxkP+tyCRvZ3GJxPjzvKjfATsU8E+VQE85YxsI OV/V7ZG3tEi/Mx5zgUjhPQKa4+U44d/u+LibHhAC/LcC3bNSIibZQkQj3MOQyquiPh7I YxiD6HvJZ4j2RWMW9s62Jsc88RLbRVbjDDt0sw0DrNQ5aqgs2Om9BUfsJOt02KIPllxq RMLQ== MIME-Version: 1.0 X-Received: by 10.194.235.138 with SMTP id um10mr16499474wjc.30.1377983371744; Sat, 31 Aug 2013 14:09:31 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.146.2 with HTTP; Sat, 31 Aug 2013 14:09:31 -0700 (PDT) In-Reply-To: References: Date: Sat, 31 Aug 2013 14:09:31 -0700 X-Google-Sender-Auth: sjIaBRi4izVKSV6IsU7dsmacYXw Message-ID: Subject: Re: 2013 MacBook Air Project From: Adrian Chadd To: "Lundberg, Johannes" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 31 Aug 2013 21:09:34 -0000 On 31 August 2013 11:44, Lundberg, Johannes wrote: > Hi Adrian > > That's great! Good luck to you :) > > Yup. I hope I get some positive responses from Broadcom. I really don't want to port the Linux driver(s), it's just plain silly. -adrian From owner-freebsd-current@FreeBSD.ORG Sat Aug 31 22:05:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 530225D0; Sat, 31 Aug 2013 22:05:28 +0000 (UTC) (envelope-from pkubaj@riseup.net) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 357BD26D7; Sat, 31 Aug 2013 22:05:27 +0000 (UTC) Received: from fulvetta.riseup.net (fulvetta-pn.riseup.net [10.0.1.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Gandi Standard SSL CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id CC83E4CF22; Sat, 31 Aug 2013 14:55:50 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: pkubaj@fulvetta.riseup.net) with ESMTPSA id 7A6FC62A Message-ID: <5222664F.2020504@riseup.net> Date: Sat, 31 Aug 2013 23:55:27 +0200 From: Piotr Kubaj User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130809 Thunderbird/17.0.8 MIME-Version: 1.0 To: adrian@freebsd.org Subject: Re: 2013 MacBook Air Project X-Enigmail-Version: 1.5.1 OpenPGP: id=11B1F63E Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2DJHHCILHNXDVVQUNFARS" X-Virus-Scanned: clamav-milter 0.97.8 at mx1 X-Virus-Status: Clean X-Mailman-Approved-At: Sat, 31 Aug 2013 23:02:26 +0000 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 31 Aug 2013 22:05:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2DJHHCILHNXDVVQUNFARS Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Considering how "well" they used to support Linux in the past and how long it took them to publish a proper driver (they released open driver for their devices only 3 years ago), I don't believe they will give support for FreeBSD any soon. ------enig2DJHHCILHNXDVVQUNFARS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSImZPAAoJEC9nKukRsfY+TsgP/i/ZSyJj24cFT6P/66w+Pmf7 f1l4ril9QD2IFdTKtI+QyEaW993plyTMbi200I/o3RscBghlNFDrEFjdv9PTqQ0C 8Axo/3CZdk1RayTEA/YLbz6SAkarvK4Oj7tElyLAZUEZcDtaRXt+eQMRLSByxnBE 5bkbPz186vx5EXmUm45V/1aU5Y+PSEm8XAENmGVb689+/RZCnv9zt36I7kiBgAKj o/+wh6h9YtpLKTdZvp5D6fZnLqvKMnWImzyqnltdk6Z25XhS9u4m5B37H3FPVZbs vlKB2vTRbbr5fYk0NDwPQG75NSlthfoY/nitH+/0JJ3JA+rG3W2xRS8/x6socwLY FxQWmWjHfCAx9qom1YyWsWy5Sln14rksHdHREDdKBxtIs8hWMSDBOxclQevnB4FV ftUGmA/YylGBqQPowKRBT6hl5NOlFcj9xQFxv6GUWB5om4tz1K5Bf7bqF0a8SYSq ZRYbovvLzp74IUn1evkZmFIN0UA80rsnuidrHwQ5gw/MDS3MJPgCD8QD9E5Yq4DO kNBYG/LTnsm7dVEbs+BLlzcItTR01HLWaeYct4pYILyKWP4X80vw1cgfCIuWg4EO 3nKlawKHB9kiNnCzRLjkYRbnN9wfYDRQ6iHttdxV+SGAmWxU3qP4HLwNi8BFi1mQ UDAq3A0q/mgHknb6jC/S =VqyE -----END PGP SIGNATURE----- ------enig2DJHHCILHNXDVVQUNFARS--