From owner-freebsd-stable@FreeBSD.ORG Sun Oct 14 02:13:33 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0A718768; Sun, 14 Oct 2012 02:13:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id BEC998FC0C; Sun, 14 Oct 2012 02:13:32 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q9E2DW1k046723; Sun, 14 Oct 2012 02:13:32 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q9E2DWbx046722; Sun, 14 Oct 2012 02:13:32 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 14 Oct 2012 02:13:32 GMT Message-Id: <201210140213.q9E2DWbx046722@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 02:13:33 -0000 TB --- 2012-10-14 02:13:00 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-10-14 02:13:00 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-10-14 02:13:00 - starting RELENG_8 tinderbox run for mips/mips TB --- 2012-10-14 02:13:00 - cleaning the object tree TB --- 2012-10-14 02:13:01 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2012-10-14 02:13:01 - cd /tinderbox/RELENG_8/mips/mips TB --- 2012-10-14 02:13:01 - /usr/local/bin/svn cleanup /src TB --- 2012-10-14 02:13:10 - /usr/local/bin/svn update /src TB --- 2012-10-14 02:13:17 - At svn revision 241519S TB --- 2012-10-14 02:13:18 - building world TB --- 2012-10-14 02:13:18 - CROSS_BUILD_TESTING=YES TB --- 2012-10-14 02:13:18 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-14 02:13:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-14 02:13:18 - SRCCONF=/dev/null TB --- 2012-10-14 02:13:18 - TARGET=mips TB --- 2012-10-14 02:13:18 - TARGET_ARCH=mips TB --- 2012-10-14 02:13:18 - TZ=UTC TB --- 2012-10-14 02:13:18 - __MAKE_CONF=/dev/null TB --- 2012-10-14 02:13:18 - cd /src TB --- 2012-10-14 02:13:18 - /usr/bin/make -B buildworld >>> World build started on Sun Oct 14 02:13:19 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] cc -O2 -pipe -I/obj/mips/src/tmp/legacy/usr/include -c /src/games/fortune/strfile/strfile.c cc -O2 -pipe -I/obj/mips/src/tmp/legacy/usr/include -static -L/obj/mips/src/tmp/legacy/usr/lib -o strfile strfile.o -legacy sh /src/tools/install.sh -s -o root -g wheel -m 555 strfile /obj/mips/src/tmp/legacy/usr/games ===> gnu/usr.bin/gperf (obj,depend,all,install) /obj/mips/src/tmp/src/gnu/usr.bin/gperf created for /src/gnu/usr.bin/gperf ===> gnu/usr.bin/gperf/doc (obj) /obj/mips/src/tmp/src/gnu/usr.bin/gperf/doc created for /src/gnu/usr.bin/gperf/doc make: don't know how to make iterator.cc. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-10-14 02:13:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-10-14 02:13:32 - ERROR: failed to build world TB --- 2012-10-14 02:13:32 - 13.10 user 8.51 system 31.62 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-mips-mips.full From owner-freebsd-stable@FreeBSD.ORG Sun Oct 14 06:03:24 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 13100112; Sun, 14 Oct 2012 06:03:24 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id C2F0B8FC0A; Sun, 14 Oct 2012 06:03:23 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q9E63NDP034004; Sun, 14 Oct 2012 06:03:23 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q9E63NfN033991; Sun, 14 Oct 2012 06:03:23 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 14 Oct 2012 06:03:23 GMT Message-Id: <201210140603.q9E63NfN033991@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 06:03:24 -0000 TB --- 2012-10-14 06:02:49 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-10-14 06:02:49 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-10-14 06:02:49 - starting RELENG_8 tinderbox run for mips/mips TB --- 2012-10-14 06:02:49 - cleaning the object tree TB --- 2012-10-14 06:02:50 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2012-10-14 06:02:50 - cd /tinderbox/RELENG_8/mips/mips TB --- 2012-10-14 06:02:50 - /usr/local/bin/svn cleanup /src TB --- 2012-10-14 06:02:59 - /usr/local/bin/svn update /src TB --- 2012-10-14 06:03:09 - At svn revision 241522S TB --- 2012-10-14 06:03:10 - building world TB --- 2012-10-14 06:03:10 - CROSS_BUILD_TESTING=YES TB --- 2012-10-14 06:03:10 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-14 06:03:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-14 06:03:10 - SRCCONF=/dev/null TB --- 2012-10-14 06:03:10 - TARGET=mips TB --- 2012-10-14 06:03:10 - TARGET_ARCH=mips TB --- 2012-10-14 06:03:10 - TZ=UTC TB --- 2012-10-14 06:03:10 - __MAKE_CONF=/dev/null TB --- 2012-10-14 06:03:10 - cd /src TB --- 2012-10-14 06:03:10 - /usr/bin/make -B buildworld >>> World build started on Sun Oct 14 06:03:10 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] cc -O2 -pipe -I/obj/mips/src/tmp/legacy/usr/include -c /src/games/fortune/strfile/strfile.c cc -O2 -pipe -I/obj/mips/src/tmp/legacy/usr/include -static -L/obj/mips/src/tmp/legacy/usr/lib -o strfile strfile.o -legacy sh /src/tools/install.sh -s -o root -g wheel -m 555 strfile /obj/mips/src/tmp/legacy/usr/games ===> gnu/usr.bin/gperf (obj,depend,all,install) /obj/mips/src/tmp/src/gnu/usr.bin/gperf created for /src/gnu/usr.bin/gperf ===> gnu/usr.bin/gperf/doc (obj) /obj/mips/src/tmp/src/gnu/usr.bin/gperf/doc created for /src/gnu/usr.bin/gperf/doc make: don't know how to make iterator.cc. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-10-14 06:03:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-10-14 06:03:23 - ERROR: failed to build world TB --- 2012-10-14 06:03:23 - 13.10 user 8.40 system 34.04 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-mips-mips.full From owner-freebsd-stable@FreeBSD.ORG Sun Oct 14 10:00:05 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B44D1C46; Sun, 14 Oct 2012 10:00:05 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 6FDA48FC12; Sun, 14 Oct 2012 10:00:05 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q9EA04Eq031197; Sun, 14 Oct 2012 10:00:04 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q9EA046Q031195; Sun, 14 Oct 2012 10:00:04 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 14 Oct 2012 10:00:04 GMT Message-Id: <201210141000.q9EA046Q031195@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 10:00:05 -0000 TB --- 2012-10-14 09:57:40 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-10-14 09:57:40 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-10-14 09:57:40 - starting RELENG_8 tinderbox run for mips/mips TB --- 2012-10-14 09:57:40 - cleaning the object tree TB --- 2012-10-14 09:57:41 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2012-10-14 09:57:41 - cd /tinderbox/RELENG_8/mips/mips TB --- 2012-10-14 09:57:41 - /usr/local/bin/svn cleanup /src TB --- 2012-10-14 09:57:51 - /usr/local/bin/svn update /src TB --- 2012-10-14 09:59:16 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-10-14 09:59:16 - WARNING: sleeping 30 s and retrying... TB --- 2012-10-14 09:59:46 - /usr/local/bin/svn update /src TB --- 2012-10-14 09:59:53 - At svn revision 241538S TB --- 2012-10-14 09:59:54 - building world TB --- 2012-10-14 09:59:54 - CROSS_BUILD_TESTING=YES TB --- 2012-10-14 09:59:54 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-14 09:59:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-14 09:59:54 - SRCCONF=/dev/null TB --- 2012-10-14 09:59:54 - TARGET=mips TB --- 2012-10-14 09:59:54 - TARGET_ARCH=mips TB --- 2012-10-14 09:59:54 - TZ=UTC TB --- 2012-10-14 09:59:54 - __MAKE_CONF=/dev/null TB --- 2012-10-14 09:59:54 - cd /src TB --- 2012-10-14 09:59:54 - /usr/bin/make -B buildworld >>> World build started on Sun Oct 14 09:59:55 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] cc -O2 -pipe -I/obj/mips/src/tmp/legacy/usr/include -c /src/games/fortune/strfile/strfile.c cc -O2 -pipe -I/obj/mips/src/tmp/legacy/usr/include -static -L/obj/mips/src/tmp/legacy/usr/lib -o strfile strfile.o -legacy sh /src/tools/install.sh -s -o root -g wheel -m 555 strfile /obj/mips/src/tmp/legacy/usr/games ===> gnu/usr.bin/gperf (obj,depend,all,install) /obj/mips/src/tmp/src/gnu/usr.bin/gperf created for /src/gnu/usr.bin/gperf ===> gnu/usr.bin/gperf/doc (obj) /obj/mips/src/tmp/src/gnu/usr.bin/gperf/doc created for /src/gnu/usr.bin/gperf/doc make: don't know how to make iterator.cc. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-10-14 10:00:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-10-14 10:00:04 - ERROR: failed to build world TB --- 2012-10-14 10:00:04 - 12.34 user 7.92 system 144.12 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-mips-mips.full From owner-freebsd-stable@FreeBSD.ORG Sun Oct 14 13:58:28 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 382076FA; Sun, 14 Oct 2012 13:58:28 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id EABFA8FC08; Sun, 14 Oct 2012 13:58:27 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q9EDwRaX006822; Sun, 14 Oct 2012 13:58:27 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q9EDwREu006818; Sun, 14 Oct 2012 13:58:27 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 14 Oct 2012 13:58:27 GMT Message-Id: <201210141358.q9EDwREu006818@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 13:58:28 -0000 TB --- 2012-10-14 13:57:53 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-10-14 13:57:53 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-10-14 13:57:53 - starting RELENG_8 tinderbox run for mips/mips TB --- 2012-10-14 13:57:53 - cleaning the object tree TB --- 2012-10-14 13:57:54 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2012-10-14 13:57:54 - cd /tinderbox/RELENG_8/mips/mips TB --- 2012-10-14 13:57:54 - /usr/local/bin/svn cleanup /src TB --- 2012-10-14 13:58:03 - /usr/local/bin/svn update /src TB --- 2012-10-14 13:58:13 - At svn revision 241543S TB --- 2012-10-14 13:58:14 - building world TB --- 2012-10-14 13:58:14 - CROSS_BUILD_TESTING=YES TB --- 2012-10-14 13:58:14 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-14 13:58:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-14 13:58:14 - SRCCONF=/dev/null TB --- 2012-10-14 13:58:14 - TARGET=mips TB --- 2012-10-14 13:58:14 - TARGET_ARCH=mips TB --- 2012-10-14 13:58:14 - TZ=UTC TB --- 2012-10-14 13:58:14 - __MAKE_CONF=/dev/null TB --- 2012-10-14 13:58:14 - cd /src TB --- 2012-10-14 13:58:14 - /usr/bin/make -B buildworld >>> World build started on Sun Oct 14 13:58:14 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] cc -O2 -pipe -I/obj/mips/src/tmp/legacy/usr/include -c /src/games/fortune/strfile/strfile.c cc -O2 -pipe -I/obj/mips/src/tmp/legacy/usr/include -static -L/obj/mips/src/tmp/legacy/usr/lib -o strfile strfile.o -legacy sh /src/tools/install.sh -s -o root -g wheel -m 555 strfile /obj/mips/src/tmp/legacy/usr/games ===> gnu/usr.bin/gperf (obj,depend,all,install) /obj/mips/src/tmp/src/gnu/usr.bin/gperf created for /src/gnu/usr.bin/gperf ===> gnu/usr.bin/gperf/doc (obj) /obj/mips/src/tmp/src/gnu/usr.bin/gperf/doc created for /src/gnu/usr.bin/gperf/doc make: don't know how to make iterator.cc. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-10-14 13:58:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-10-14 13:58:27 - ERROR: failed to build world TB --- 2012-10-14 13:58:27 - 13.34 user 8.21 system 33.91 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-mips-mips.full From owner-freebsd-stable@FreeBSD.ORG Sun Oct 14 15:35:15 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 01EF05B4 for ; Sun, 14 Oct 2012 15:35:15 +0000 (UTC) (envelope-from mailreturn@smtp.ymlp42.net) Received: from smtp.ymlp42.net (smtp.ymlp42.net [85.158.212.98]) by mx1.freebsd.org (Postfix) with SMTP id 4F8628FC19 for ; Sun, 14 Oct 2012 15:35:13 +0000 (UTC) Received: (qmail 21186 invoked by uid 0); 14 Oct 2012 15:35:12 -0000 Date: Sun, 14 Oct 2012 17:35:12 +0200 To: freebsd-stable@freebsd.org From: Immobilier Tel-Aviv Subject: Alex Losky: Les annonces sur notre site. Octobre 2012 Message-ID: <5344337ebc3b3ae69fa4058b18800aa1@smtp.ymlp42.net> X-YMLPcode: 7myj+7465+1113535 MIME-Version: 1.0 Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: contact@concept-nadlan.biz List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 15:35:15 -0000 --------------------------------------------------------------------------= ------ Cette newsletter vous a =C3=A9t=C3=A9 envoy=C3=A9e au format graphique = HTML. Si vous lisez cette version, alors votre logiciel de messagerie = pr=C3=A9f=C3=A8re les e-mails au format texte. Vous pouvez lire la version originale en ligne: http://ymlp301.net/z8N6cQ --------------------------------------------------------------------------= ------ Visualiser le message en ligne ( http://losky.co.il/projets-doc/telaviv/email09-12-webversion.html ) _____________________________ Unsubscribe / D=C3=A9sinscription: = http://ymlp301.net/ugeyywjwgsguuumbmbgwjhbggmequss From owner-freebsd-stable@FreeBSD.ORG Sun Oct 14 17:54:01 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 07D3F77A; Sun, 14 Oct 2012 17:54:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id B8F6A8FC17; Sun, 14 Oct 2012 17:54:00 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q9EHs0dP095003; Sun, 14 Oct 2012 17:54:00 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q9EHs0Hi094896; Sun, 14 Oct 2012 17:54:00 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 14 Oct 2012 17:54:00 GMT Message-Id: <201210141754.q9EHs0Hi094896@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 17:54:01 -0000 TB --- 2012-10-14 17:53:24 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-10-14 17:53:24 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-10-14 17:53:24 - starting RELENG_8 tinderbox run for mips/mips TB --- 2012-10-14 17:53:24 - cleaning the object tree TB --- 2012-10-14 17:53:25 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2012-10-14 17:53:25 - cd /tinderbox/RELENG_8/mips/mips TB --- 2012-10-14 17:53:25 - /usr/local/bin/svn cleanup /src TB --- 2012-10-14 17:53:38 - /usr/local/bin/svn update /src TB --- 2012-10-14 17:53:45 - At svn revision 241553S TB --- 2012-10-14 17:53:46 - building world TB --- 2012-10-14 17:53:46 - CROSS_BUILD_TESTING=YES TB --- 2012-10-14 17:53:46 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-14 17:53:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-14 17:53:46 - SRCCONF=/dev/null TB --- 2012-10-14 17:53:46 - TARGET=mips TB --- 2012-10-14 17:53:46 - TARGET_ARCH=mips TB --- 2012-10-14 17:53:46 - TZ=UTC TB --- 2012-10-14 17:53:46 - __MAKE_CONF=/dev/null TB --- 2012-10-14 17:53:46 - cd /src TB --- 2012-10-14 17:53:46 - /usr/bin/make -B buildworld >>> World build started on Sun Oct 14 17:53:47 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] cc -O2 -pipe -I/obj/mips/src/tmp/legacy/usr/include -c /src/games/fortune/strfile/strfile.c cc -O2 -pipe -I/obj/mips/src/tmp/legacy/usr/include -static -L/obj/mips/src/tmp/legacy/usr/lib -o strfile strfile.o -legacy sh /src/tools/install.sh -s -o root -g wheel -m 555 strfile /obj/mips/src/tmp/legacy/usr/games ===> gnu/usr.bin/gperf (obj,depend,all,install) /obj/mips/src/tmp/src/gnu/usr.bin/gperf created for /src/gnu/usr.bin/gperf ===> gnu/usr.bin/gperf/doc (obj) /obj/mips/src/tmp/src/gnu/usr.bin/gperf/doc created for /src/gnu/usr.bin/gperf/doc make: don't know how to make iterator.cc. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-10-14 17:54:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-10-14 17:54:00 - ERROR: failed to build world TB --- 2012-10-14 17:54:00 - 13.46 user 8.05 system 35.87 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-mips-mips.full From owner-freebsd-stable@FreeBSD.ORG Sun Oct 14 18:32:01 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 180A35F4 for ; Sun, 14 Oct 2012 18:32:01 +0000 (UTC) (envelope-from vhaisman@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 944368FC0A for ; Sun, 14 Oct 2012 18:32:00 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id c50so2778089eek.13 for ; Sun, 14 Oct 2012 11:31:53 -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:references :in-reply-to:x-enigmail-version:content-type; bh=FRHePe39T4QZjx7IsZOpb/ivPreMF9h6JYzr98QCD+8=; b=yF/4T7k7sw378z+Rgh9VGi9cz9dj6RbFGUC936fx1ofNXChKnVgpP+gLo9j2E8qms0 f2J6oY5GytUXB3byKQOzw3D+OUmd93HnLie0uJe4hzb/3DfRfyVnfbftHDBNw8wNDUcG 8yEaRRFSSjSHr4fWcerUf3hXSEJ3yTxnyev3kKlrpyXyFBoMCuRMNz2qx+Qk8mwjO+qk gVjbvyWVAG4leFauR+P1ijJjEC1SQFJU9bshFCZ4GtKqNH2JhzBtboZr76i6GLL1jnWS ud0iIuruCyEa/BvSy1AdGDcPVKCbO2P3wyPNXVai4UoYfmjo5PonCHDK00l4PeapVunR hfuw== Received: by 10.14.200.134 with SMTP id z6mr12968828een.33.1350239513420; Sun, 14 Oct 2012 11:31:53 -0700 (PDT) Received: from [10.0.0.1] (242.91.broadband5.iol.cz. [88.100.91.242]) by mx.google.com with ESMTPS id v3sm21395158een.1.2012.10.14.11.31.51 (version=SSLv3 cipher=OTHER); Sun, 14 Oct 2012 11:31:52 -0700 (PDT) Message-ID: <507B050E.5080608@gmail.com> Date: Sun, 14 Oct 2012 20:31:42 +0200 From: =?ISO-8859-1?Q?V=E1clav_Zeman?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: [releng_8 tinderbox] failure on mips/mips References: <201210141754.q9EHs0Hi094896@freebsd-legacy2.sentex.ca> In-Reply-To: <201210141754.q9EHs0Hi094896@freebsd-legacy2.sentex.ca> X-Enigmail-Version: 1.4.5 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig306A8D19303CF1DB7F762CEC" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 18:32:01 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig306A8D19303CF1DB7F762CEC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 10/14/2012 07:54 PM, FreeBSD Tinderbox wrote: > TB --- 2012-10-14 17:53:24 - tinderbox 2.9 running on freebsd-legacy2.s= entex.ca > TB --- 2012-10-14 17:53:24 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELE= ASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell= =2Ecse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > TB --- 2012-10-14 17:53:24 - starting RELENG_8 tinderbox run for mips/m= ips > TB --- 2012-10-14 17:53:24 - cleaning the object tree > TB --- 2012-10-14 17:53:25 - checking out /src from svn://svn.freebsd.o= rg/base/stable/8 > TB --- 2012-10-14 17:53:25 - cd /tinderbox/RELENG_8/mips/mips > TB --- 2012-10-14 17:53:25 - /usr/local/bin/svn cleanup /src > TB --- 2012-10-14 17:53:38 - /usr/local/bin/svn update /src > TB --- 2012-10-14 17:53:45 - At svn revision 241553S > TB --- 2012-10-14 17:53:46 - building world > TB --- 2012-10-14 17:53:46 - CROSS_BUILD_TESTING=3DYES > TB --- 2012-10-14 17:53:46 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2012-10-14 17:53:46 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2012-10-14 17:53:46 - SRCCONF=3D/dev/null > TB --- 2012-10-14 17:53:46 - TARGET=3Dmips > TB --- 2012-10-14 17:53:46 - TARGET_ARCH=3Dmips > TB --- 2012-10-14 17:53:46 - TZ=3DUTC > TB --- 2012-10-14 17:53:46 - __MAKE_CONF=3D/dev/null > TB --- 2012-10-14 17:53:46 - cd /src > TB --- 2012-10-14 17:53:46 - /usr/bin/make -B buildworld >>>> World build started on Sun Oct 14 17:53:47 UTC 2012 >>>> Rebuilding the temporary build tree >>>> stage 1.1: legacy release compatibility shims >>>> stage 1.2: bootstrap tools > [...] > cc -O2 -pipe -I/obj/mips/src/tmp/legacy/usr/include -c /src/games/for= tune/strfile/strfile.c > cc -O2 -pipe -I/obj/mips/src/tmp/legacy/usr/include -static -L/obj/m= ips/src/tmp/legacy/usr/lib -o strfile strfile.o -legacy > sh /src/tools/install.sh -s -o root -g wheel -m 555 strfile /obj/mips= /src/tmp/legacy/usr/games > =3D=3D=3D> gnu/usr.bin/gperf (obj,depend,all,install) > /obj/mips/src/tmp/src/gnu/usr.bin/gperf created for /src/gnu/usr.bin/gp= erf > =3D=3D=3D> gnu/usr.bin/gperf/doc (obj) > /obj/mips/src/tmp/src/gnu/usr.bin/gperf/doc created for /src/gnu/usr.bi= n/gperf/doc > make: don't know how to make iterator.cc. Stop > *** Error code 2 > > Stop in /src. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2012-10-14 17:54:00 - WARNING: /usr/bin/make returned exit code = 1=20 > TB --- 2012-10-14 17:54:00 - ERROR: failed to build world > TB --- 2012-10-14 17:54:00 - 13.46 user 8.05 system 35.87 real > > > http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-mips-mips.full= \ This has been spamming the list for a few days now. Can nobody do anything about it, like actually fixing the problem? --=20 VZ --------------enig306A8D19303CF1DB7F762CEC 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.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iF4EAREIAAYFAlB7BRYACgkQ6OWUyaYNY6NNYwD9Hlkiu75PReg9RZfWU2qdw+5U FzsZJgfhsbti53MdCnQA/3yor7RLRWfjL9DqqL7RJdqNrz0/q0T2h/l7YxTcNxhf =FXtd -----END PGP SIGNATURE----- --------------enig306A8D19303CF1DB7F762CEC-- From owner-freebsd-stable@FreeBSD.ORG Sun Oct 14 21:43:44 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2B0309F6; Sun, 14 Oct 2012 21:43:44 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id DD8C68FC14; Sun, 14 Oct 2012 21:43:43 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q9ELhh5c078775; Sun, 14 Oct 2012 21:43:43 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q9ELhhMR078774; Sun, 14 Oct 2012 21:43:43 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 14 Oct 2012 21:43:43 GMT Message-Id: <201210142143.q9ELhhMR078774@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 21:43:44 -0000 TB --- 2012-10-14 21:43:06 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-10-14 21:43:06 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-10-14 21:43:06 - starting RELENG_8 tinderbox run for mips/mips TB --- 2012-10-14 21:43:06 - cleaning the object tree TB --- 2012-10-14 21:43:07 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2012-10-14 21:43:07 - cd /tinderbox/RELENG_8/mips/mips TB --- 2012-10-14 21:43:07 - /usr/local/bin/svn cleanup /src TB --- 2012-10-14 21:43:21 - /usr/local/bin/svn update /src TB --- 2012-10-14 21:43:28 - At svn revision 241559S TB --- 2012-10-14 21:43:29 - building world TB --- 2012-10-14 21:43:29 - CROSS_BUILD_TESTING=YES TB --- 2012-10-14 21:43:29 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-14 21:43:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-14 21:43:29 - SRCCONF=/dev/null TB --- 2012-10-14 21:43:29 - TARGET=mips TB --- 2012-10-14 21:43:29 - TARGET_ARCH=mips TB --- 2012-10-14 21:43:29 - TZ=UTC TB --- 2012-10-14 21:43:29 - __MAKE_CONF=/dev/null TB --- 2012-10-14 21:43:29 - cd /src TB --- 2012-10-14 21:43:29 - /usr/bin/make -B buildworld >>> World build started on Sun Oct 14 21:43:30 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] cc -O2 -pipe -I/obj/mips/src/tmp/legacy/usr/include -c /src/games/fortune/strfile/strfile.c cc -O2 -pipe -I/obj/mips/src/tmp/legacy/usr/include -static -L/obj/mips/src/tmp/legacy/usr/lib -o strfile strfile.o -legacy sh /src/tools/install.sh -s -o root -g wheel -m 555 strfile /obj/mips/src/tmp/legacy/usr/games ===> gnu/usr.bin/gperf (obj,depend,all,install) /obj/mips/src/tmp/src/gnu/usr.bin/gperf created for /src/gnu/usr.bin/gperf ===> gnu/usr.bin/gperf/doc (obj) /obj/mips/src/tmp/src/gnu/usr.bin/gperf/doc created for /src/gnu/usr.bin/gperf/doc make: don't know how to make iterator.cc. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-10-14 21:43:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-10-14 21:43:43 - ERROR: failed to build world TB --- 2012-10-14 21:43:43 - 13.07 user 8.40 system 37.15 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-mips-mips.full From owner-freebsd-stable@FreeBSD.ORG Mon Oct 15 01:38:47 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 862D9108; Mon, 15 Oct 2012 01:38:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 42E808FC18; Mon, 15 Oct 2012 01:38:47 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q9F1ckrS079202; Mon, 15 Oct 2012 01:38:46 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q9F1ckwq079193; Mon, 15 Oct 2012 01:38:46 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 15 Oct 2012 01:38:46 GMT Message-Id: <201210150138.q9F1ckwq079193@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 01:38:47 -0000 TB --- 2012-10-15 01:33:10 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-10-15 01:33:10 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-10-15 01:33:10 - starting RELENG_8 tinderbox run for mips/mips TB --- 2012-10-15 01:33:10 - cleaning the object tree TB --- 2012-10-15 01:33:11 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2012-10-15 01:33:11 - cd /tinderbox/RELENG_8/mips/mips TB --- 2012-10-15 01:33:11 - /usr/local/bin/svn cleanup /src TB --- 2012-10-15 01:33:21 - /usr/local/bin/svn update /src TB --- 2012-10-15 01:37:59 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-10-15 01:37:59 - WARNING: sleeping 30 s and retrying... TB --- 2012-10-15 01:38:29 - /usr/local/bin/svn update /src TB --- 2012-10-15 01:38:35 - At svn revision 241571S TB --- 2012-10-15 01:38:36 - building world TB --- 2012-10-15 01:38:36 - CROSS_BUILD_TESTING=YES TB --- 2012-10-15 01:38:36 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-15 01:38:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-15 01:38:36 - SRCCONF=/dev/null TB --- 2012-10-15 01:38:36 - TARGET=mips TB --- 2012-10-15 01:38:36 - TARGET_ARCH=mips TB --- 2012-10-15 01:38:36 - TZ=UTC TB --- 2012-10-15 01:38:36 - __MAKE_CONF=/dev/null TB --- 2012-10-15 01:38:36 - cd /src TB --- 2012-10-15 01:38:36 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 15 01:38:37 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] cc -O2 -pipe -I/obj/mips/src/tmp/legacy/usr/include -c /src/games/fortune/strfile/strfile.c cc -O2 -pipe -I/obj/mips/src/tmp/legacy/usr/include -static -L/obj/mips/src/tmp/legacy/usr/lib -o strfile strfile.o -legacy sh /src/tools/install.sh -s -o root -g wheel -m 555 strfile /obj/mips/src/tmp/legacy/usr/games ===> gnu/usr.bin/gperf (obj,depend,all,install) /obj/mips/src/tmp/src/gnu/usr.bin/gperf created for /src/gnu/usr.bin/gperf ===> gnu/usr.bin/gperf/doc (obj) /obj/mips/src/tmp/src/gnu/usr.bin/gperf/doc created for /src/gnu/usr.bin/gperf/doc make: don't know how to make iterator.cc. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-10-15 01:38:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-10-15 01:38:46 - ERROR: failed to build world TB --- 2012-10-15 01:38:46 - 12.28 user 7.82 system 335.74 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-mips-mips.full From owner-freebsd-stable@FreeBSD.ORG Mon Oct 15 05:33:55 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 53E8C414; Mon, 15 Oct 2012 05:33:55 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 0F92A8FC0A; Mon, 15 Oct 2012 05:33:54 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q9F5XsHC052590; Mon, 15 Oct 2012 05:33:54 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q9F5XseR052564; Mon, 15 Oct 2012 05:33:54 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 15 Oct 2012 05:33:54 GMT Message-Id: <201210150533.q9F5XseR052564@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 05:33:55 -0000 TB --- 2012-10-15 05:33:20 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-10-15 05:33:20 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-10-15 05:33:20 - starting RELENG_8 tinderbox run for mips/mips TB --- 2012-10-15 05:33:20 - cleaning the object tree TB --- 2012-10-15 05:33:22 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2012-10-15 05:33:22 - cd /tinderbox/RELENG_8/mips/mips TB --- 2012-10-15 05:33:22 - /usr/local/bin/svn cleanup /src TB --- 2012-10-15 05:33:31 - /usr/local/bin/svn update /src TB --- 2012-10-15 05:33:40 - At svn revision 241572S TB --- 2012-10-15 05:33:41 - building world TB --- 2012-10-15 05:33:41 - CROSS_BUILD_TESTING=YES TB --- 2012-10-15 05:33:41 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-15 05:33:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-15 05:33:41 - SRCCONF=/dev/null TB --- 2012-10-15 05:33:41 - TARGET=mips TB --- 2012-10-15 05:33:41 - TARGET_ARCH=mips TB --- 2012-10-15 05:33:41 - TZ=UTC TB --- 2012-10-15 05:33:41 - __MAKE_CONF=/dev/null TB --- 2012-10-15 05:33:41 - cd /src TB --- 2012-10-15 05:33:41 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 15 05:33:41 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] cc -O2 -pipe -I/obj/mips/src/tmp/legacy/usr/include -c /src/games/fortune/strfile/strfile.c cc -O2 -pipe -I/obj/mips/src/tmp/legacy/usr/include -static -L/obj/mips/src/tmp/legacy/usr/lib -o strfile strfile.o -legacy sh /src/tools/install.sh -s -o root -g wheel -m 555 strfile /obj/mips/src/tmp/legacy/usr/games ===> gnu/usr.bin/gperf (obj,depend,all,install) /obj/mips/src/tmp/src/gnu/usr.bin/gperf created for /src/gnu/usr.bin/gperf ===> gnu/usr.bin/gperf/doc (obj) /obj/mips/src/tmp/src/gnu/usr.bin/gperf/doc created for /src/gnu/usr.bin/gperf/doc make: don't know how to make iterator.cc. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-10-15 05:33:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-10-15 05:33:54 - ERROR: failed to build world TB --- 2012-10-15 05:33:54 - 13.41 user 8.21 system 34.29 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-mips-mips.full From owner-freebsd-stable@FreeBSD.ORG Mon Oct 15 08:33:38 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E1FAE8FA for ; Mon, 15 Oct 2012 08:33:38 +0000 (UTC) (envelope-from www-data@mail.repulonap.hu) Received: from repulonap.hu (www.repulonap.hu [217.116.43.66]) by mx1.freebsd.org (Postfix) with ESMTP id 138918FC0A for ; Mon, 15 Oct 2012 08:33:37 +0000 (UTC) Received: by repulonap.hu (Postfix, from userid 33) id 8F3A424CE2A; Mon, 15 Oct 2012 10:33:36 +0200 (CEST) To: stable@freebsd.org Subject: Datarecovery - Garancia a sikeres =?ISO-8859-2?Q?adatment=E9sre!?= From: DATARECOVERY Message-ID: Date: Mon, 15 Oct 2012 10:33:36 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; ="?ISO-8859-2?Q?charset=3D\"ISO-8859-2\"?=" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 08:33:39 -0000 [mail_header.jpg] [1] Datarecovery - Garancia a sikeres adatmentésre! A beszállítás és a vizsgálat ingyenes és fizetnie csak sikeres mentés esetén kell! [lost.jpg] Mindenki átélte már azt a pillanatot, amikor több órányi munka után a rendszer vagy az adott alkalmazás hirtelen összeomlik, a dokumentumunk így pedig sérül vagy elérhetetlen lesz. Néha a rendszer kiírja a hiba okát, néha pedig egyszeru"en csak lefagy. Ezek a kellemetlen helyzetek mind adatai elvesztéséhez vezethetnek. A látszat ellenére nincs minden veszve. Mi vissza tudjuk állítani az elveszett adatait! Szintén vállaljuk jelszóval védett fájlok olvashatóvá tételét, ha esetleg elfelejtették volna a jelszót.Sérült fájlrendszerek esetében például az alábbi alkalmazások adatait vagyunk képesek visszaállítani: - Office (Word, Excel, PowerPoint, Access) - elektronikus levelezés (Outlook, Outlook Express, Netscape, Mozilla) - tömörtett állományok (ZIP, RAR, ACE) stb. [data-recovery-explained.jpg] Egyedülálló technológiánknak köszönheto"en a RAID tömbökro"l történo" adatmentés terén minden egyes esetben 100 százalékos helyreállítást sikerült elérnünk. Ehhez nem kell ismernünk a RAID tömb konkrét konfigurálását és az eredeti vezérlo"re sincs szükségünk Szakértelmünket külföldi megrendelo"ink is elismerik, ugyanis az o" adatmentésre szakosodott vállalkozásaik sokszor nem tudtak nekik segíteni. Garanciáink: * Közel 100% sikerarány! * Ingyenes kiszállás! * Ingyenes állapotfelmérés! * Közép-Európában páratlan felszereltségu" laboratórium! * NON-STOP SZOLGÁLTATÁS - a nap 24 órájában az év 365 napján! * EXPRESSZ ADATMENTÉS - NON-STOP dolgozunk, amíg megrendelését nem teljesítettük. Munkaido" végét, hétvégét és ünnepeket nem ismerünk. * Fizetni csak a sikeres adatmentés esetében kell! * Ingyenes biztonsági mentés a visszaállított adatokról. * Mindenre kiterjedo" adatvédelem ; bizalmas adatok biztonságára ügyelünk. * Más adatmento" cégeket is kiszolgálunk! [samsung_logo%20(1).jpg] Mivel cégünk hivatalos Samsung adatmento" partnerré vált minden médiára vonatkozóan, a Samsung és Seagate termékek garanciaido"n belüli adatmentés miatt történo" megbontását továbbra is garanciavesztés nélkül végezzük! Amennyiben felkeltettük érdeklo"dését és szeretné igénybe venni szolgáltatásainkat keresse kollégánkat az alábbi elérheto"ségeken! Kapcsolattartó : Bercsényi László Tel.: +3670/977-8379 e-mail: [2]bercsenyi.laszlo@sziliciumalmok.hu [3] TOVÁBB Ez egy automatikusan generált e-mail, az erre küldött válaszok nem kerülnek feldolgozásra. Ezúton tudatjuk önnel, hogy e-mail címe nyilvános e-mail címjegyzékbo"l vagy az adott honlapról (e-mail hírlevél listára való jelentkezés, játék vagy adatgyu"jto" modul, hivatalos Facebook oldal) került levelezési listánkba. Hozzájárul-e ahhoz, hogy szolgáltatásainkról szóló hírlevelünket továbbra is eljuttassuk Önhöz, és ezúton tájékoztassuk legfrissebb ajánlatainkról? Kérjük, hogy nemleges válasz esetén kattintson a levél alján található "Leiratkozom a hírlevélro"l" címu" linkre, annak érdekében, hogy a leheto" leggyorsabban eltávolíthassuk listánkról. Amennyiben levelünkkel zavartuk, ezúton szeretnénk elnézést kérni! Az üzenet kizárólag a Címzett Személynek, vagy cégnek szól. Azon Személyek, vagy Cégek, akik nem címzettjei, jogosultjai ennek az üzenetnek, nem olvashatják, továbbíthatják, nem dolgozhatják fel azt, illetve nem érezhetik magukat megszólítva. Amennyiben ezt az üzenetet valamely, az internet sajátosságainak következtében felmerülo" okból tévesen kapta meg, úgy kérjük, semmisítse meg és értesítse az üzenet küldo"jét, köszönjük! A 2008. évi XLVIII. tv. (a gazdasági reklámtevékenység alapveto" feltételeiro"l és egyes korlátairól, röviden Grt.) az Országgyu"lés 2008. június 9-i ülésnapján elfogadott törvény, mely 6. paragrafusa alapján kéretlen elektronikus, üzletszerzést célzó reklámüzenet (azaz spam) csak természetes személynek nem küldheto" elo"zetes beleegyezés nélkül. 2001. évi CVIII. törvény az elektronikus kereskedelmi szolgáltatások, valamint az információs társadalommal összefüggo" szolgáltatások egyes kérdéseiro"l 14. § (3) Önmagában nem mino"sül elektronikus hirdetésnek a) vállalkozás, egyéb szervezet vagy személy tevékenységéhez közvetlen hozzáférést leheto"vé tevo" információ közlése, különösen a domain név vagy az elektronikus levelezési cím, b) vállalkozás, szervezet vagy személy árujára vagy arculatára vonatkozó, a vállalkozástól, szervezetto"l vagy személyto"l független közlés, különösen abban az esetben, ha a közlés anyagi ellenszolgáltatás nélkül történik. [4]Leíratkozom a hírlevélro"l! Amennyiben technikai okok miatt nem mu"ködne a fenti link vagy kapcsolatba szeretne lépni velünk, kérjük, az [5]hirlevel.leiratkozas@sziliciumalmok.hu e-mailen jelezze és töröljük címlistánkról. [mail_footer.png] References 1. http://www.silicondreams.hu/rovatok/datarecovery/datarecovery_garancia_a_sikeres_adatmentesre/#utm_source=sziliciumalmok&utm_medium=84&utm_term=Datarecovery - Garancia a sikeres adatment%C3%A9sre!&utm_content=Datarecovery - Garancia a sikeres adatment%C3%A9sre!&utm_campaign=stable@freebsd.org 2. mailto:bercsenyi.laszlo@sziliciumalmok.hu 3. http://www.silicondreams.hu/rovatok/datarecovery/datarecovery_garancia_a_sikeres_adatmentesre/#utm_source=sziliciumalmok&utm_medium=84&utm_term=Datarecovery - Garancia a sikeres adatment%C3%A9sre!&utm_content=Datarecovery - Garancia a sikeres adatment%C3%A9sre!&utm_campaign=stable@freebsd.org 4. http://www.silicondreams.hu/unsubscribe.php?email=stable@freebsd.org&vCode=2389932 5. mailto:hirlevel.leiratkozas@sziliciumalmok.hu From owner-freebsd-stable@FreeBSD.ORG Mon Oct 15 09:28:55 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C8B234B; Mon, 15 Oct 2012 09:28:55 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 3A2818FC16; Mon, 15 Oct 2012 09:28:55 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q9F9SsdX038265; Mon, 15 Oct 2012 09:28:54 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q9F9SsuG038261; Mon, 15 Oct 2012 09:28:54 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 15 Oct 2012 09:28:54 GMT Message-Id: <201210150928.q9F9SsuG038261@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 09:28:55 -0000 TB --- 2012-10-15 09:28:22 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-10-15 09:28:22 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-10-15 09:28:22 - starting RELENG_8 tinderbox run for mips/mips TB --- 2012-10-15 09:28:22 - cleaning the object tree TB --- 2012-10-15 09:28:23 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2012-10-15 09:28:23 - cd /tinderbox/RELENG_8/mips/mips TB --- 2012-10-15 09:28:23 - /usr/local/bin/svn cleanup /src TB --- 2012-10-15 09:28:32 - /usr/local/bin/svn update /src TB --- 2012-10-15 09:28:39 - At svn revision 241576S TB --- 2012-10-15 09:28:40 - building world TB --- 2012-10-15 09:28:40 - CROSS_BUILD_TESTING=YES TB --- 2012-10-15 09:28:40 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-15 09:28:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-15 09:28:40 - SRCCONF=/dev/null TB --- 2012-10-15 09:28:40 - TARGET=mips TB --- 2012-10-15 09:28:40 - TARGET_ARCH=mips TB --- 2012-10-15 09:28:40 - TZ=UTC TB --- 2012-10-15 09:28:40 - __MAKE_CONF=/dev/null TB --- 2012-10-15 09:28:40 - cd /src TB --- 2012-10-15 09:28:40 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 15 09:28:41 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] cc -O2 -pipe -I/obj/mips/src/tmp/legacy/usr/include -c /src/games/fortune/strfile/strfile.c cc -O2 -pipe -I/obj/mips/src/tmp/legacy/usr/include -static -L/obj/mips/src/tmp/legacy/usr/lib -o strfile strfile.o -legacy sh /src/tools/install.sh -s -o root -g wheel -m 555 strfile /obj/mips/src/tmp/legacy/usr/games ===> gnu/usr.bin/gperf (obj,depend,all,install) /obj/mips/src/tmp/src/gnu/usr.bin/gperf created for /src/gnu/usr.bin/gperf ===> gnu/usr.bin/gperf/doc (obj) /obj/mips/src/tmp/src/gnu/usr.bin/gperf/doc created for /src/gnu/usr.bin/gperf/doc make: don't know how to make iterator.cc. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-10-15 09:28:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-10-15 09:28:54 - ERROR: failed to build world TB --- 2012-10-15 09:28:54 - 13.34 user 8.33 system 32.21 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-mips-mips.full From owner-freebsd-stable@FreeBSD.ORG Mon Oct 15 13:23:42 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 037ACBB3; Mon, 15 Oct 2012 13:23:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id B2EFD8FC16; Mon, 15 Oct 2012 13:23:41 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q9FDNfK8024683; Mon, 15 Oct 2012 13:23:41 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q9FDNfaq024682; Mon, 15 Oct 2012 13:23:41 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 15 Oct 2012 13:23:41 GMT Message-Id: <201210151323.q9FDNfaq024682@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 13:23:42 -0000 TB --- 2012-10-15 13:23:08 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-10-15 13:23:08 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-10-15 13:23:08 - starting RELENG_8 tinderbox run for mips/mips TB --- 2012-10-15 13:23:08 - cleaning the object tree TB --- 2012-10-15 13:23:09 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2012-10-15 13:23:09 - cd /tinderbox/RELENG_8/mips/mips TB --- 2012-10-15 13:23:09 - /usr/local/bin/svn cleanup /src TB --- 2012-10-15 13:23:18 - /usr/local/bin/svn update /src TB --- 2012-10-15 13:23:26 - At svn revision 241581S TB --- 2012-10-15 13:23:27 - building world TB --- 2012-10-15 13:23:27 - CROSS_BUILD_TESTING=YES TB --- 2012-10-15 13:23:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-15 13:23:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-15 13:23:27 - SRCCONF=/dev/null TB --- 2012-10-15 13:23:27 - TARGET=mips TB --- 2012-10-15 13:23:27 - TARGET_ARCH=mips TB --- 2012-10-15 13:23:27 - TZ=UTC TB --- 2012-10-15 13:23:27 - __MAKE_CONF=/dev/null TB --- 2012-10-15 13:23:27 - cd /src TB --- 2012-10-15 13:23:27 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 15 13:23:28 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] cc -O2 -pipe -I/obj/mips/src/tmp/legacy/usr/include -c /src/games/fortune/strfile/strfile.c cc -O2 -pipe -I/obj/mips/src/tmp/legacy/usr/include -static -L/obj/mips/src/tmp/legacy/usr/lib -o strfile strfile.o -legacy sh /src/tools/install.sh -s -o root -g wheel -m 555 strfile /obj/mips/src/tmp/legacy/usr/games ===> gnu/usr.bin/gperf (obj,depend,all,install) /obj/mips/src/tmp/src/gnu/usr.bin/gperf created for /src/gnu/usr.bin/gperf ===> gnu/usr.bin/gperf/doc (obj) /obj/mips/src/tmp/src/gnu/usr.bin/gperf/doc created for /src/gnu/usr.bin/gperf/doc make: don't know how to make iterator.cc. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-10-15 13:23:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-10-15 13:23:41 - ERROR: failed to build world TB --- 2012-10-15 13:23:41 - 12.98 user 8.45 system 32.64 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-mips-mips.full From owner-freebsd-stable@FreeBSD.ORG Mon Oct 15 21:05:26 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8B2FB4E1 for ; Mon, 15 Oct 2012 21:05:26 +0000 (UTC) (envelope-from jamesda@aol.com) Received: from mk-filter-3-a-1.mail.uk.tiscali.com (mk-filter-3-a-1.mail.tiscali.co.uk [212.74.100.54]) by mx1.freebsd.org (Postfix) with ESMTP id 161D18FC08 for ; Mon, 15 Oct 2012 21:05:25 +0000 (UTC) X-Trace: 811649904/mk-filter-3.mail.uk.tiscali.com/B2C/$THROTTLED_STATIC/b2c-CUSTOMER-STATIC-IP/80.46.38.142/None/jamesda@aol.com X-SBRS: None X-RemoteIP: 80.46.38.142 X-IP-MAIL-FROM: jamesda@aol.com X-SMTP-AUTH: X-Originating-Country: GB/UNITED KINGDOM X-MUA: X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQfACR5fFBQLiaO/2dsb2JhbABFg0+FSaN4gTOSTYIcFiArgTMBCQUBhXoHghgJAQERBJtFhlSIS4gFASMECol6hEWBVAEBhU2DDYMhA4gjkxiBD4FUhx9fgwk X-IronPort-AV: E=Sophos;i="4.80,590,1344207600"; d="scan'208";a="811649904" Received: from 80-46-38-142.static.dsl.as9105.com (HELO roadreclamation.co.uk) ([80.46.38.142]) by smtp.tiscali.co.uk with ESMTP; 15 Oct 2012 22:04:16 +0100 Received: from DFP-RDS.DoverMed.local ([74.95.91.51]) by roadreclamation.co.uk with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Oct 2012 21:58:55 +0100 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Description: Mail message body Subject: HI To: freebsd-stable@freebsd.org From: jamesda@aol.com Date: Mon, 15 Oct 2012 16:58:54 -0400 Message-ID: X-OriginalArrivalTime: 15 Oct 2012 20:58:56.0093 (UTC) FILETIME=[E3F898D0:01CDAB17] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: jamesdawu733@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 21:05:26 -0000 Mystery Shopper Wanted in USA Earn $200 per assignment Provide the following for application Name Address State City Zip Code Sex Cell Phone Home Phone Age Thanks Darell Miller From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 01:24:53 2012 Return-Path: Delivered-To: stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F3A5F829 for ; Tue, 16 Oct 2012 01:24:52 +0000 (UTC) (envelope-from web9044@vm1003.netio.cz) Received: from vm1003.netio.cz (85-118-130-76.static.masterinter.net [85.118.130.76]) by mx1.freebsd.org (Postfix) with ESMTP id A8A768FC0A for ; Tue, 16 Oct 2012 01:24:52 +0000 (UTC) Received: from localhost (vm1003.netio.cz [127.0.0.1]) by vm1003.netio.cz (Postfix) with ESMTP id A6ACC93D73 for ; Tue, 16 Oct 2012 03:15:01 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at vm1003 Received: from vm1003.netio.cz ([127.0.0.1]) by localhost (vm1003.netio.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ew4RUdVvJ4wj for ; Tue, 16 Oct 2012 03:15:01 +0200 (CEST) Received: by vm1003.netio.cz (Postfix, from userid 9044) id D407E1D588; Tue, 16 Oct 2012 03:14:48 +0200 (CEST) To: stable@FreeBSD.ORG Subject: National Australia Bank Message X-PHP-Originating-Script: 9044:ken(1).php From: National Australia Bank Message-ID: X-Priority: 1 X-MSmail-Priority: High X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Date: Tue, 16 Oct 2012 03:14:48 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: National Australia Bank List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 01:24:53 -0000 Dear National Australia Bank - NAB Customer, We're making some exciting changes that will make your online banking experience even better, We therefore request you to verify your account. [1]Click Here To Verify Your Account Regards, Š 2012 National Australia Bank - NAB . All rights reserved References 1. http://www.indebomen.nl//wp-content/themes/picnic/cache/images/updatere..php From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 05:29:09 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F429BC1 for ; Tue, 16 Oct 2012 05:29:09 +0000 (UTC) (envelope-from info@cv-inter.com) Received: from mailgw13.surf-town.net (mail1.surf-town.net [212.97.132.41]) by mx1.freebsd.org (Postfix) with ESMTP id AB3928FC0A for ; Tue, 16 Oct 2012 05:29:08 +0000 (UTC) Received: by mailgw13.surf-town.net (Postfix, from userid 65534) id 37F14402BF; Tue, 16 Oct 2012 07:29:07 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mailgw13.surf-town.net (Postfix) with ESMTP id 241543FFCD for ; Tue, 16 Oct 2012 07:29:07 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mailgw13.surf-town.net X-Spam-Flag: NO X-Spam-Score: 0.231 X-Spam-Level: X-Spam-Status: No, score=0.231 tagged_above=-999 required=7 tests=[ALL_TRUSTED=-1.44, DCC_CHECK=1.37, HTML_MESSAGE=0.001, SARE_WEOFFER=0.3] autolearn=unavailable Received: from mailgw13.surf-town.net ([127.0.0.1]) by localhost (mailgw13.surf-town.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id agc19jHVwtyB for ; Tue, 16 Oct 2012 07:29:07 +0200 (CEST) Received: from [10.119.0.174] (94-23-72-210.ovh.net [94.23.72.210]) by mailgw13.surf-town.net (Postfix) with ESMTPA id AD3143FF1C for ; Tue, 16 Oct 2012 07:29:04 +0200 (CEST) From: "QATAR - FINANCE" To: "stable" Subject: Loan offer at interest rate of 2 % per annun. Message-ID: <37c3a4130b5a3941b834bf8b28d0b5f1@MAXILASE-PC> Date: Tue, 16 Oct 2012 05:29:39 +0000 MIME-Version: 1.0 X-Priority: 1 X-Mailer: Microsoft Office Outlook 13.0 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-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: qatar@infomaniak.ch List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 05:29:09 -0000 Loan offer at interest rate of 2 % per annun. =0D=0A=0D=0ADo = you need a loan to clear your debts/bills, or start up a business? = Then consider your financial problems over. In today's economic = climate, finding reliable funding sources can be frustrating = and full of disappointments, but with our sophisticated loan = repayment plan, everyone Smiles home.=0D=0AQatar Loan Finance = Foundation provides financing for alternative energy, commercial = real estate projects and personal financing; thus, arranging = a loan with us is simple and straightforward, convenient and = fast. We can give you an immediate 'in principle' decision and = we'll find you some of the most competitive personal loan rates = available.=0D=0AWe Offer guaranteed loan services of any amount = and to any part of the world for (individuals, companies, realtors = and corporate bodies) at our superb interest rate of 2%. Our = team of loan experts first listens to our client's requirements = and then provides them with best loan solutions.=0D=0A=0D=0A=0D=0AWe = Offer LOANS ranging from 100.000 euros Min. to 500 000 000 euros = Max. at 2 % interest rate per annun, Loans for developing your = business expansion. We are certified, trustworthy, reliable, = efficient, Fast and dynamic. and a co-operate financier for = real estate and any kinds of business financing, we give out = long term loan for five to ten years maximum.=0D=0A=0D=0APlease = if you are interested in our financial offer, do not hesitate = to contact us at qatar@infomaniak.ch for more informations =0D=0A =0D= =0AEmir SHEIK HAMAD BIN KHALIFA AL THANI =0D=0AQatar Loan Finance = Foundation From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 09:25:08 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B663778 for ; Tue, 16 Oct 2012 09:25:08 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 056058FC08 for ; Tue, 16 Oct 2012 09:25:06 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id q9G9QC7P063107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Oct 2012 11:26:14 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <507D27DC.5030104@omnilan.de> Date: Tue, 16 Oct 2012 11:24:44 +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: freebsd-stable Subject: mpt irq timeout problem after reboot - only if non-verbose booting !?! X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9E41760E4C813310F94CC698" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 09:25:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9E41760E4C813310F94CC698 Content-Type: multipart/mixed; boundary="------------020508020906000204040408" This is a multi-part message in MIME format. --------------020508020906000204040408 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, I have 9.1-RC2 running in an ESXi 5.1 guest. I use 'lsisas' as virtual SCSI-Controller and mpt attaches and finds 1068= E. Everything is working fine until the first 'shutdown -r now': The second boot pauses for ~2 minutes after probing disks and continues with this error: mpt0: Timedout requests already complete. Interrupts may not be functioni= ng. This problem was also obeserved with real 1068 hardware: http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/063937.h= tml When I power off the virtual machine instead of rebooting, the problem doesn't occur. Accidentally I found a workarround ;-) : If I set 'verbose_boot' in loader.conf, the problem vanisehs!?!?!? Any idea how =E2=80=9Everbose_boot=E2=80=9C affects the operation of the = mpt driver? Thanks, -Harry --------------020508020906000204040408 Content-Type: text/plain; name="flint-verbose_dmesg.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="flint-verbose_dmesg.txt" VGFibGUgJ0ZBQ1AnIGF0IDB4YmZlZmVlOTgKVGFibGUgJ0JPT1QnIGF0IDB4YmZlZjAxZmMK VGFibGUgJ0FQSUMnIGF0IDB4YmZlZjAxODIKQVBJQzogRm91bmQgdGFibGUgYXQgMHhiZmVm MDE4MgpBUElDOiBVc2luZyB0aGUgTUFEVCBlbnVtZXJhdG9yLgpNQURUOiBGb3VuZCBDUFUg QVBJQyBJRCAwIEFDUEkgSUQgMDogZW5hYmxlZApTTVA6IEFkZGVkIENQVSAwIChBUCkKTUFE VDogRm91bmQgQ1BVIEFQSUMgSUQgMSBBQ1BJIElEIDE6IGVuYWJsZWQKU01QOiBBZGRlZCBD UFUgMSAoQVApCk1BRFQ6IEZvdW5kIENQVSBBUElDIElEIDIgQUNQSSBJRCAyOiBlbmFibGVk ClNNUDogQWRkZWQgQ1BVIDIgKEFQKQpNQURUOiBGb3VuZCBDUFUgQVBJQyBJRCAzIEFDUEkg SUQgMzogZW5hYmxlZApTTVA6IEFkZGVkIENQVSAzIChBUCkKQ29weXJpZ2h0IChjKSAxOTky LTIwMTIgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChjKSAxOTc5LCAxOTgwLCAx OTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAxOTk0CglUaGUgUmVn ZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmlnaHRzIHJlc2Vy dmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZyZWVCU0Qg Rm91bmRhdGlvbi4KRnJlZUJTRCA5LjEtUkMyICMxMSByMjQxNTAzTTogU2F0IE9jdCAxMyAx NTo1NjowMiBDRVNUIDIwMTIKICAgIGFkbWluQGd1bmRpLnZubC53ZG4ub21uaWxhbi5uZXQ6 L3Vzci9sb2NhbC9zaGFyZS9kZXBsb3ktdG9vbHMvb2JqLWFtZDY0L1ZNV0FSRS91c3IvbG9j YWwvc2hhcmUvZGVwbG95LXRvb2xzL1JFTEVOR185XzEvc3JjL3N5cy9WTVdBUkUuZmxpbnQg YW1kNjQKUHJlbG9hZGVkIGVsZiBrZXJuZWwgIi9ib290L2tlcm5lbC9rZXJuZWwiIGF0IDB4 ZmZmZmZmZmY4MGY5NTAwMC4KUHJlbG9hZGVkIGVsZiBvYmogbW9kdWxlICIvYm9vdC9rZXJu ZWwvemZzLmtvIiBhdCAweGZmZmZmZmZmODBmOTUyMTAuClByZWxvYWRlZCBlbGYgb2JqIG1v ZHVsZSAiL2Jvb3Qva2VybmVsL29wZW5zb2xhcmlzLmtvIiBhdCAweGZmZmZmZmZmODBmOTU4 YjguClByZWxvYWRlZCAvYm9vdC96ZnMvenBvb2wuY2FjaGUgIi9ib290L3pmcy96cG9vbC5j YWNoZSIgYXQgMHhmZmZmZmZmZjgwZjk1ZWU4LgpQcmVsb2FkZWQgZWxmIG9iaiBtb2R1bGUg Ii9ib290L2tlcm5lbC9hZXNuaS5rbyIgYXQgMHhmZmZmZmZmZjgwZjk1ZjQ4LgpQcmVsb2Fk ZWQgZWxmIG9iaiBtb2R1bGUgIi9ib290L21vZHVsZXMvdm14bmV0My5rbyIgYXQgMHhmZmZm ZmZmZjgwZjk2NTcwLgpQcmVsb2FkZWQgZWxmIG9iaiBtb2R1bGUgIi9ib290L2tlcm5lbC9t cHMua28iIGF0IDB4ZmZmZmZmZmY4MGY5NmFlMC4KSHlwZXJ2aXNvcjogT3JpZ2luID0gIlZN d2FyZVZNd2FyZSIKQ1BVOiBJbnRlbChSKSBYZW9uKFIpIENQVSBFMy0xMjcwIFYyIEAgMy41 MEdIeiAoMzQ5Mi4wNy1NSHogSzgtY2xhc3MgQ1BVKQogIE9yaWdpbiA9ICJHZW51aW5lSW50 ZWwiICBJZCA9IDB4MzA2YTkgIEZhbWlseSA9IDYgIE1vZGVsID0gM2EgIFN0ZXBwaW5nID0g OQogIEZlYXR1cmVzPTB4MWZhM2ZiZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQQUUsTUNF LENYOCxBUElDLFNFUCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsRFRTLE1NWCxGWFNS LFNTRSxTU0UyLFNTLEhUVD4KICBGZWF0dXJlczI9MHhmZWJhMjIwMzxTU0UzLFBDTE1VTFFE USxTU1NFMyxDWDE2LFBDSUQsU1NFNC4xLFNTRTQuMix4MkFQSUMsUE9QQ05ULEFFU05JLFhT QVZFLE9TWFNBVkUsQVZYLEYxNkMsUkRSQU5ELEhWPgogIEFNRCBGZWF0dXJlcz0weDI4MTAw ODAwPFNZU0NBTEwsTlgsUkRUU0NQLExNPgogIEFNRCBGZWF0dXJlczI9MHgxPExBSEY+CiAg VFNDOiBQLXN0YXRlIGludmFyaWFudApyZWFsIG1lbW9yeSAgPSA4NTg5OTM0NTkyICg4MTky IE1CKQpQaHlzaWNhbCBtZW1vcnkgY2h1bmsocyk6CjB4MDAwMDAwMDAwMDAwMTAwMCAtIDB4 MDAwMDAwMDAwMDA5YmZmZiwgNjM0ODgwIGJ5dGVzICgxNTUgcGFnZXMpCjB4MDAwMDAwMDAw MDEwMDAwMCAtIDB4MDAwMDAwMDAwMDFmZmZmZiwgMTA0ODU3NiBieXRlcyAoMjU2IHBhZ2Vz KQoweDAwMDAwMDAwMDBmY2IwMDAgLSAweDAwMDAwMDAwYmZlZGZmZmYsIDMyMDM0ODU2OTYg Ynl0ZXMgKDc4MjEwMSBwYWdlcykKMHgwMDAwMDAwMGJmZjAwMDAwIC0gMHgwMDAwMDAwMGJm ZmZmZmZmLCAxMDQ4NTc2IGJ5dGVzICgyNTYgcGFnZXMpCjB4MDAwMDAwMDEwMDAwMDAwMCAt IDB4MDAwMDAwMDIyZjExZmZmZiwgNTA4NDY3NjA5NiBieXRlcyAoMTI0MTM3NiBwYWdlcykK YXZhaWwgbWVtb3J5ID0gODIzNDY1MTY0OCAoNzg1MyBNQikKSU5UUjogQWRkaW5nIGxvY2Fs IEFQSUMgMCBhcyBhIHRhcmdldApFdmVudCB0aW1lciAiTEFQSUMiIHF1YWxpdHkgNjAwCkFD UEkgQVBJQyBUYWJsZTogPFBUTFREICAJIEFQSUMgID4KSU5UUjogQWRkaW5nIGxvY2FsIEFQ SUMgMCBhcyBhIHRhcmdldApJTlRSOiBBZGRpbmcgbG9jYWwgQVBJQyAxIGFzIGEgdGFyZ2V0 CklOVFI6IEFkZGluZyBsb2NhbCBBUElDIDIgYXMgYSB0YXJnZXQKSU5UUjogQWRkaW5nIGxv Y2FsIEFQSUMgMyBhcyBhIHRhcmdldApGcmVlQlNEL1NNUDogTXVsdGlwcm9jZXNzb3IgU3lz dGVtIERldGVjdGVkOiA0IENQVXMKRnJlZUJTRC9TTVA6IDEgcGFja2FnZShzKSB4IDQgY29y ZShzKQogY3B1MCAoQlNQKTogQVBJQyBJRDogIDAKIGNwdTEgKEFQKTogQVBJQyBJRDogIDEK IGNwdTIgKEFQKTogQVBJQyBJRDogIDIKIGNwdTMgKEFQKTogQVBJQyBJRDogIDMKQVBJQzog Q1BVIDAgaGFzIEFDUEkgSUQgMApBUElDOiBDUFUgMSBoYXMgQUNQSSBJRCAxCkFQSUM6IENQ VSAyIGhhcyBBQ1BJIElEIDIKQVBJQzogQ1BVIDMgaGFzIEFDUEkgSUQgMwp4ODZiaW9zOiAg SVZUIDB4MDAwMDAwLTB4MDAwNGZmIGF0IDB4ZmZmZmZlMDAwMDAwMDAwMAp4ODZiaW9zOiBT U0VHIDB4MDAxMDAwLTB4MDAxZmZmIGF0IDB4ZmZmZmZmODAwMDIzMDAwMAp4ODZiaW9zOiBF QkRBIDB4MDlmMDAwLTB4MDlmZmZmIGF0IDB4ZmZmZmZlMDAwMDA5ZjAwMAp4ODZiaW9zOiAg Uk9NIDB4MGEwMDAwLTB4MGZlZmZmIGF0IDB4ZmZmZmZlMDAwMDBhMDAwMApVTEU6IHNldHVw IGNwdSAwClVMRTogc2V0dXAgY3B1IDEKVUxFOiBzZXR1cCBjcHUgMgpVTEU6IHNldHVwIGNw dSAzCkFDUEk6IFJTRFAgMHhmNmI4MCAwMDAyNCAodjAyIFBUTFREICkKQUNQSTogWFNEVCAw eGJmZWVmZjNjIDAwMDVDICh2MDEgSU5URUwgIDQ0MEJYICAgIDA2MDQwMDAwIFZNVyAgMDEz MjQyNzIpCkFDUEk6IEZBQ1AgMHhiZmVmZWU5OCAwMDBGNCAodjA0IElOVEVMICA0NDBCWCAg ICAwNjA0MDAwMCBQVEwgIDAwMEY0MjQwKQpBQ1BJOiBEU0RUIDB4YmZlZjAyMjQgMEVDNzQg KHYwMSBQVExURCAgQ3VzdG9tICAgMDYwNDAwMDAgTVNGVCAwMzAwMDAwMSkKQUNQSTogRkFD UyAweGJmZWZmZmMwIDAwMDQwCkFDUEk6IEJPT1QgMHhiZmVmMDFmYyAwMDAyOCAodjAxIFBU TFREICAkU0JGVEJMJCAwNjA0MDAwMCAgTFRQIDAwMDAwMDAxKQpBQ1BJOiBBUElDIDB4YmZl ZjAxODIgMDAwN0EgKHYwMSBQVExURCAgPyBBUElDICAgMDYwNDAwMDAgIExUUCAwMDAwMDAw MCkKQUNQSTogTUNGRyAweGJmZWYwMTQ2IDAwMDNDICh2MDEgUFRMVEQgICRQQ0lUQkwkIDA2 MDQwMDAwICBMVFAgMDAwMDAwMDEpCkFDUEk6IFNSQVQgMHhiZmVmMDA1ZSAwMDBFOCAodjAy IFZNV0FSRSBNRU1QTFVHICAwNjA0MDAwMCBWTVcgIDAwMDAwMDAxKQpBQ1BJOiBIUEVUIDB4 YmZlZjAwMjYgMDAwMzggKHYwMSBWTVdBUkUgVk1XIEhQRVQgMDYwNDAwMDAgVk1XICAwMDAw MDAwMSkKQUNQSTogV0FFVCAweGJmZWVmZmQ4IDAwMDI4ICh2MDEgVk1XQVJFIFZNVyBXQUVU IDA2MDQwMDAwIFZNVyAgMDAwMDAwMDEpCk1BRFQ6IEZvdW5kIElPIEFQSUMgSUQgNCwgSW50 ZXJydXB0IDAgYXQgMHhmZWMwMDAwMAppb2FwaWMwOiBSb3V0aW5nIGV4dGVybmFsIDgyNTlB J3MgLT4gaW50cGluIDAKTUFEVDogSW50ZXJydXB0IG92ZXJyaWRlOiBzb3VyY2UgMCwgaXJx IDIKaW9hcGljMDogUm91dGluZyBJUlEgMCAtPiBpbnRwaW4gMgpsYXBpYzA6IFJvdXRpbmcg Tk1JIC0+IExJTlQxCmxhcGljMDogTElOVDEgdHJpZ2dlcjogZWRnZQpsYXBpYzA6IExJTlQx IHBvbGFyaXR5OiBoaWdoCmxhcGljMTogUm91dGluZyBOTUkgLT4gTElOVDEKbGFwaWMxOiBM SU5UMSB0cmlnZ2VyOiBlZGdlCmxhcGljMTogTElOVDEgcG9sYXJpdHk6IGhpZ2gKbGFwaWMy OiBSb3V0aW5nIE5NSSAtPiBMSU5UMQpsYXBpYzI6IExJTlQxIHRyaWdnZXI6IGVkZ2UKbGFw aWMyOiBMSU5UMSBwb2xhcml0eTogaGlnaApsYXBpYzM6IFJvdXRpbmcgTk1JIC0+IExJTlQx CmxhcGljMzogTElOVDEgdHJpZ2dlcjogZWRnZQpsYXBpYzM6IExJTlQxIHBvbGFyaXR5OiBo aWdoCk1BRFQ6IEZvcmNpbmcgYWN0aXZlLWxvdyBwb2xhcml0eSBhbmQgbGV2ZWwgdHJpZ2dl ciBmb3IgU0NJCmlvYXBpYzA6IGludHBpbiA5IHBvbGFyaXR5OiBsb3cKaW9hcGljMDogaW50 cGluIDkgdHJpZ2dlcjogbGV2ZWwKaW9hcGljMCA8VmVyc2lvbiAxLjE+IGlycXMgMC0yMyBv biBtb3RoZXJib2FyZApjcHUwIEJTUDoKICAgICBJRDogMHgwMDAwMDAwMCAgIFZFUjogMHgw MDA1MDAxNSBMRFI6IDB4MDAwMDAwMDAgREZSOiAweGZmZmZmZmZmCiAgbGludDA6IDB4MDAw MTA3MDAgbGludDE6IDB4MDAwMDA0MDAgVFBSOiAweDAwMDAwMDAwIFNWUjogMHgwMDAwMDFm ZgogIHRpbWVyOiAweDAwMDEwMGVmIHRoZXJtOiAweDAwMDEwMDAwIGVycjogMHgwMDAwMDBm MCBwbWM6IDB4MDAwMTA0MDAKVkVTQTogSU5UIDB4MTAgdmVjdG9yIDB4YzAwMDoweDBhZmUK VkVTQTogaW5mb3JtYXRpb24gYmxvY2sKMDAwMCAgIDU2IDQ1IDUzIDQxIDAwIDAyIDc4IDVh IDAwIGMwIDAzIDAwIDAwIDAwIDk2IDZjCjAwMTAgICAwMCBjMCA0MCAwMCAwMCAwMiA2YyA1 YSAwMCBjMCA1NSA1YSAwMCBjMCA1MSA1YQowMDIwICAgMDAgYzAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKMDAzMCAgIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCjAwNDAgICAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAowMDUwICAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKMDA2MCAgIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCjAwNzAgICAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAowMDgwICAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKMDA5MCAgIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCjAwYTAgICAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAowMGIwICAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKMDBjMCAgIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCjAwZDAgICAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAowMGUwICAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKMDBmMCAgIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCjAxMDAgICAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAowMTEwICAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKMDEyMCAgIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCjAxMzAgICAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAowMTQwICAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKMDE1MCAgIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCjAxNjAgICAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAowMTcwICAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKMDE4MCAg IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCjAxOTAg ICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAowMWEw ICAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKMDFi MCAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCjAx YzAgICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAow MWQwICAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAK MDFlMCAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw CjAxZjAgICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MApWRVNBOiA1MCBtb2RlKHMpIGZvdW5kClZFU0E6IHYyLjAsIDQwOTZrIG1lbW9yeSwgZmxh Z3M6MHgzLCBtb2RlIHRhYmxlOjB4ZmZmZmZlMDAwMDBjNmM5NiAoYzAwMDZjOTYpClZFU0E6 IFYgTSB3YXJlLCBJbmMuIFZCRSBzdXBwb3J0IDIuMApWRVNBOiBWTXdhcmUsIEluYyBWTXdh cmUgdmlydHVhbCBtYWNoaW5lIDIuMAppbzogPEkvTz4KbmZzbG9jazogcHNldWRvLWRldmlj ZQpyYW5kb206IDxlbnRyb3B5IHNvdXJjZSwgSGFyZHdhcmUsIEludGVsIEl2eUJyaWRnZSsg Uk5HPgpjcnlwdG86IDxjcnlwdG8gY29yZT4KbWVtOiA8bWVtb3J5PgpudWxsOiA8bnVsbCBk ZXZpY2UsIHplcm8gZGV2aWNlPgpjdGw6IENBTSBUYXJnZXQgTGF5ZXIgbG9hZGVkCnNtYmlv czA6IDxTeXN0ZW0gTWFuYWdlbWVudCBCSU9TPiBhdCBpb21lbSAweGY2YjMwLTB4ZjZiNGUg b24gbW90aGVyYm9hcmQKc21iaW9zMDogVmVyc2lvbjogMi40CmNyeXB0b3NvZnQwOiA8c29m dHdhcmUgY3J5cHRvPiBvbiBtb3RoZXJib2FyZApjcnlwdG86IGFzc2lnbiBjcnlwdG9zb2Z0 MCBkcml2ZXIgaWQgMCwgZmxhZ3MgMTAwNjYzMjk2CmNyeXB0bzogY3J5cHRvc29mdDAgcmVn aXN0ZXJzIGFsZyAxIGZsYWdzIDAgbWF4b3BsZW4gMApjcnlwdG86IGNyeXB0b3NvZnQwIHJl Z2lzdGVycyBhbGcgMiBmbGFncyAwIG1heG9wbGVuIDAKY3J5cHRvOiBjcnlwdG9zb2Z0MCBy ZWdpc3RlcnMgYWxnIDMgZmxhZ3MgMCBtYXhvcGxlbiAwCmNyeXB0bzogY3J5cHRvc29mdDAg cmVnaXN0ZXJzIGFsZyA0IGZsYWdzIDAgbWF4b3BsZW4gMApjcnlwdG86IGNyeXB0b3NvZnQw IHJlZ2lzdGVycyBhbGcgNSBmbGFncyAwIG1heG9wbGVuIDAKY3J5cHRvOiBjcnlwdG9zb2Z0 MCByZWdpc3RlcnMgYWxnIDE2IGZsYWdzIDAgbWF4b3BsZW4gMApjcnlwdG86IGNyeXB0b3Nv ZnQwIHJlZ2lzdGVycyBhbGcgNiBmbGFncyAwIG1heG9wbGVuIDAKY3J5cHRvOiBjcnlwdG9z b2Z0MCByZWdpc3RlcnMgYWxnIDcgZmxhZ3MgMCBtYXhvcGxlbiAwCmNyeXB0bzogY3J5cHRv c29mdDAgcmVnaXN0ZXJzIGFsZyAxOCBmbGFncyAwIG1heG9wbGVuIDAKY3J5cHRvOiBjcnlw dG9zb2Z0MCByZWdpc3RlcnMgYWxnIDE5IGZsYWdzIDAgbWF4b3BsZW4gMApjcnlwdG86IGNy eXB0b3NvZnQwIHJlZ2lzdGVycyBhbGcgMjAgZmxhZ3MgMCBtYXhvcGxlbiAwCmNyeXB0bzog Y3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyA4IGZsYWdzIDAgbWF4b3BsZW4gMApjcnlwdG86 IGNyeXB0b3NvZnQwIHJlZ2lzdGVycyBhbGcgMTUgZmxhZ3MgMCBtYXhvcGxlbiAwCmNyeXB0 bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyA5IGZsYWdzIDAgbWF4b3BsZW4gMApjcnlw dG86IGNyeXB0b3NvZnQwIHJlZ2lzdGVycyBhbGcgMTAgZmxhZ3MgMCBtYXhvcGxlbiAwCmNy eXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyAxMyBmbGFncyAwIG1heG9wbGVuIDAK Y3J5cHRvOiBjcnlwdG9zb2Z0MCByZWdpc3RlcnMgYWxnIDE0IGZsYWdzIDAgbWF4b3BsZW4g MApjcnlwdG86IGNyeXB0b3NvZnQwIHJlZ2lzdGVycyBhbGcgMTEgZmxhZ3MgMCBtYXhvcGxl biAwCmNyeXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyAyMiBmbGFncyAwIG1heG9w bGVuIDAKY3J5cHRvOiBjcnlwdG9zb2Z0MCByZWdpc3RlcnMgYWxnIDIxIGZsYWdzIDAgbWF4 b3BsZW4gMApjcnlwdG86IGNyeXB0b3NvZnQwIHJlZ2lzdGVycyBhbGcgMTcgZmxhZ3MgMCBt YXhvcGxlbiAwCmFlc25pMDogPEFFUy1DQkMsQUVTLVhUUz4gb24gbW90aGVyYm9hcmQKY3J5 cHRvOiBhc3NpZ24gYWVzbmkwIGRyaXZlciBpZCAxLCBmbGFncyAxNjc3NzIxNgpjcnlwdG86 IGFlc25pMCByZWdpc3RlcnMgYWxnIDExIGZsYWdzIDAgbWF4b3BsZW4gMApjcnlwdG86IGFl c25pMCByZWdpc3RlcnMgYWxnIDIyIGZsYWdzIDAgbWF4b3BsZW4gMAphY3BpMDogPElOVEVM IDQ0MEJYPiBvbiBtb3RoZXJib2FyZApQQ0llOiBNZW1vcnkgTWFwcGVkIGNvbmZpZ3VyYXRp b24gYmFzZSBAIDB4ZTAwMDAwMDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gOSAoSVNBIElS USA5KSB0byBsYXBpYyAwIHZlY3RvciA0OAphY3BpMDogUG93ZXIgQnV0dG9uIChmaXhlZCkK aHBldDA6IDxIaWdoIFByZWNpc2lvbiBFdmVudCBUaW1lcj4gaW9tZW0gMHhmZWQwMDAwMC0w eGZlZDAwM2ZmIG9uIGFjcGkwCmhwZXQwOiB2ZW5kb3IgMHg4MDg2LCByZXYgMHgxLCAxNDMx ODE4MEh6IDY0Yml0LCAxNiB0aW1lcnMsIGxlZ2FjeSByb3V0ZQpocGV0MDogIHQwOiBpcnFz IDB4MDBmMDAwMDAgKDApLCA2NGJpdCwgcGVyaW9kaWMKaHBldDA6ICB0MTogaXJxcyAweDAw ZjAwMDAwICgwKSwgNjRiaXQsIHBlcmlvZGljCmhwZXQwOiAgdDI6IGlycXMgMHgwMGYwMDAw MCAoMCksIDY0Yml0LCBwZXJpb2RpYwpocGV0MDogIHQzOiBpcnFzIDB4MDBmMDAwMDAgKDAp LCA2NGJpdCwgcGVyaW9kaWMKaHBldDA6ICB0NDogaXJxcyAweDAwZjAwMDAwICgwKSwgNjRi aXQsIHBlcmlvZGljCmhwZXQwOiAgdDU6IGlycXMgMHgwMGYwMDAwMCAoMCksIDY0Yml0LCBw ZXJpb2RpYwpocGV0MDogIHQ2OiBpcnFzIDB4MDBmMDAwMDAgKDApLCA2NGJpdCwgcGVyaW9k aWMKaHBldDA6ICB0NzogaXJxcyAweDAwZjAwMDAwICgwKSwgNjRiaXQsIHBlcmlvZGljCmhw ZXQwOiAgdDg6IGlycXMgMHgwMGYwMDAwMCAoMCksIDY0Yml0LCBwZXJpb2RpYwpocGV0MDog IHQ5OiBpcnFzIDB4MDBmMDAwMDAgKDApLCA2NGJpdCwgcGVyaW9kaWMKaHBldDA6ICB0MTA6 IGlycXMgMHgwMGYwMDAwMCAoMCksIDY0Yml0LCBwZXJpb2RpYwpocGV0MDogIHQxMTogaXJx cyAweDAwZjAwMDAwICgwKSwgNjRiaXQsIHBlcmlvZGljCmhwZXQwOiAgdDEyOiBpcnFzIDB4 MDBmMDAwMDAgKDApLCA2NGJpdCwgcGVyaW9kaWMKaHBldDA6ICB0MTM6IGlycXMgMHgwMGYw MDAwMCAoMCksIDY0Yml0LCBwZXJpb2RpYwpocGV0MDogIHQxNDogaXJxcyAweDAwZjAwMDAw ICgwKSwgNjRiaXQsIHBlcmlvZGljCmhwZXQwOiAgdDE1OiBpcnFzIDB4MDBmMDAwMDAgKDAp LCA2NGJpdCwgcGVyaW9kaWMKVGltZWNvdW50ZXIgIkhQRVQiIGZyZXF1ZW5jeSAxNDMxODE4 MCBIeiBxdWFsaXR5IDk1MApjcHUwOiBQcm9jZXNzb3IgXFxfU0JfLkNQMDAgKEFDUEkgSUQg MCkgLT4gQVBJQyBJRCAwCmNwdTA6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1MDogc3dpdGNo aW5nIHRvIGdlbmVyaWMgQ3ggbW9kZQpjcHUxOiBQcm9jZXNzb3IgXFxfU0JfLkNQMDMgKEFD UEkgSUQgMykgLT4gQVBJQyBJRCAzCmNwdTE6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1Mjog UHJvY2Vzc29yIFxcX1NCXy5DUDAyIChBQ1BJIElEIDIpIC0+IEFQSUMgSUQgMgpjcHUyOiA8 QUNQSSBDUFU+IG9uIGFjcGkwCmNwdTM6IFByb2Nlc3NvciBcXF9TQl8uQ1AwMSAoQUNQSSBJ RCAxKSAtPiBBUElDIElEIDEKY3B1MzogPEFDUEkgQ1BVPiBvbiBhY3BpMAphdHRpbWVyMDog PEFUIHRpbWVyPiBwb3J0IDB4NDAtMHg0MyBpcnEgMCBvbiBhY3BpMApUaW1lY291bnRlciAi aTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMAppb2FwaWMwOiByb3V0aW5n IGludHBpbiAyIChJU0EgSVJRIDApIHRvIGxhcGljIDAgdmVjdG9yIDQ5CkV2ZW50IHRpbWVy ICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0eSAxMDAKYXRydGMwOiA8QVQg cmVhbHRpbWUgY2xvY2s+IHBvcnQgMHg3MC0weDcxIGlycSA4IG9uIGFjcGkwCmF0cnRjMDog cmVnaXN0ZXJlZCBhcyBhIHRpbWUtb2YtZGF5IGNsb2NrIChyZXNvbHV0aW9uIDEwMDAwMDB1 cywgYWRqdXN0bWVudCAwLjUwMDAwMDAwMHMpCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDgg KElTQSBJUlEgOCkgdG8gbGFwaWMgMCB2ZWN0b3IgNTAKRXZlbnQgdGltZXIgIlJUQyIgZnJl cXVlbmN5IDMyNzY4IEh6IHF1YWxpdHkgMApBQ1BJIHRpbWVyOiAxLzEgMS8xIDEvMSAxLzEg MS8xIDEvMSAxLzUgMS8xIDEvNSAxLzEgLT4gMTAKVGltZWNvdW50ZXIgIkFDUEktZmFzdCIg ZnJlcXVlbmN5IDM1Nzk1NDUgSHogcXVhbGl0eSA5MDAKYWNwaV90aW1lcjA6IDwyNC1iaXQg dGltZXIgYXQgMy41Nzk1NDVNSHo+IHBvcnQgMHgxMDA4LTB4MTAwYiBvbiBhY3BpMApwY2lf bGluazA6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJv YmUgICAgICAgMCAgICA5ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTQgMTUKICBW YWxpZGF0aW9uICAgICAgICAgIDAgICAgOSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDEx IDE0IDE1CiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA2 IDcgOSAxMCAxMSAxNCAxNQpwY2lfbGluazE6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJl ZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgICA3ICAgTiAgICAgMCAgMyA0IDUg NiA3IDkgMTAgMTEgMTQgMTUKICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAgNyAgIE4gICAg IDAgIDMgNCA1IDYgNyA5IDEwIDExIDE0IDE1CiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAy NTUgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxNCAxNQpwY2lfbGluazI6ICAgICAg ICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAg IDExICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTQgMTUKICBWYWxpZGF0aW9uICAg ICAgICAgIDAgICAxMSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDE0IDE1CiAgQWZ0 ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAx NCAxNQpwY2lfbGluazM6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIElu aXRpYWwgUHJvYmUgICAgICAgMCAgIDEwICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEg MTQgMTUKICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAxMCAgIE4gICAgIDAgIDMgNCA1IDYg NyA5IDEwIDExIDE0IDE1CiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAw ICAzIDQgNSA2IDcgOSAxMCAxMSAxNCAxNQpwY2liMDogPEFDUEkgSG9zdC1QQ0kgYnJpZGdl PiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkwCnBjaWIwOiBkZWNvZGluZyAzIHJhbmdlIDB4 YTAwMDAtMHhiZmZmZgpwY2liMDogZGVjb2RpbmcgMyByYW5nZSAweGNjMDAwLTB4Y2ZmZmYK cGNpYjA6IGRlY29kaW5nIDMgcmFuZ2UgMHhkMDAwMC0weGQzZmZmCnBjaWIwOiBkZWNvZGlu ZyAzIHJhbmdlIDB4ZDQwMDAtMHhkN2ZmZgpwY2liMDogZGVjb2RpbmcgMyByYW5nZSAweGQ4 MDAwLTB4ZGJmZmYKcGNpYjA6IGRlY29kaW5nIDMgcmFuZ2UgMHhjMDAwMDAwMC0weGZlYmZm ZmZmCnBjaWIwOiBkZWNvZGluZyA0IHJhbmdlIDAtMHhjZjcKcGNpYjA6IGRlY29kaW5nIDQg cmFuZ2UgMHhkMDAtMHhmZWZmCnBjaTA6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIwCnBjaTA6 IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9MApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0w eDcxOTAsIHJldmlkPTB4MDEKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0wLCBmdW5jPTAKCWNs YXNzPTA2LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDYsIHN0 YXRyZWc9MHgwMjAwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBu cyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVu ZG9yPTB4ODA4NiwgZGV2PTB4NzE5MSwgcmV2aWQ9MHgwMQoJZG9tYWluPTAsIGJ1cz0wLCBz bG90PTEsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MAoJ Y21kcmVnPTB4MDExZiwgc3RhdHJlZz0weDAyMjAsIGNhY2hlbG5zej0wIChkd29yZHMpCgls YXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDQgKDEwMDAgbnMpLCBtYXhsYXQ9MHgw MCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHg3MTEwLCByZXZpZD0weDA4 Cglkb21haW49MCwgYnVzPTAsIHNsb3Q9NywgZnVuYz0wCgljbGFzcz0wNi0wMS0wMCwgaGRy dHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDI4MCwgY2Fj aGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAo MCBucyksIG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0w eDcxMTEsIHJldmlkPTB4MDEKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD03LCBmdW5jPTEKCWNs YXNzPTAxLTAxLThlLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDUsIHN0 YXRyZWc9MHgwMjgwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHg0MCAoMTky MCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCnBjaWIwOiBh bGxvY2F0ZWQgdHlwZSA0ICgweDFmMC0weDFmNykgZm9yIHJpZCAxMCBvZiBwY2kwOjA6Nzox CnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSA0ICgweDNmNi0weDNmNikgZm9yIHJpZCAxNCBvZiBw Y2kwOjA6NzoxCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDEw YzAsIHNpemUgIDQsIGVuYWJsZWQKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDQgKDB4MTBjMC0w eDEwY2YpIGZvciByaWQgMjAgb2YgcGNpMDowOjc6MQpmb3VuZC0+CXZlbmRvcj0weDgwODYs IGRldj0weDcxMTMsIHJldmlkPTB4MDgKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD03LCBmdW5j PTMKCWNsYXNzPTA2LTgwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAw MDEsIHN0YXRyZWc9MHgwMjgwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgw MCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCgltYXBb OTBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDEwNDAsIHNpemUgIDQsIGVu YWJsZWQKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDQgKDB4MTA0MC0weDEwNGYpIGZvciByaWQg OTAgb2YgcGNpMDowOjc6Mwpmb3VuZC0+CXZlbmRvcj0weDE1YWQsIGRldj0weDA3NDAsIHJl dmlkPTB4MTAKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD03LCBmdW5jPTcKCWNsYXNzPTA4LTgw LTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDMsIHN0YXRyZWc9MHgw MjkwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHg0MCAoMTkyMCBucyksIG1p bmdudD0weDA2ICgxNTAwIG5zKSwgbWF4bGF0PTB4ZmYgKDYzNzUwIG5zKQoJaW50cGluPWEs IGlycT05CglNU0kgc3VwcG9ydHMgMSBtZXNzYWdlLCA2NCBiaXQKCU1TSS1YIHN1cHBvcnRz IDIgbWVzc2FnZXMgaW4gbWFwIDB4MTQKCW1hcFsxMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdl IDMyLCBiYXNlIDB4MTA4MCwgc2l6ZSAgNiwgZW5hYmxlZApwY2liMDogYWxsb2NhdGVkIHR5 cGUgNCAoMHgxMDgwLTB4MTBiZikgZm9yIHJpZCAxMCBvZiBwY2kwOjA6Nzo3CgltYXBbMTRd OiB0eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhkNDAwMDAwMCwgc2l6ZSAxMywgZW5h YmxlZApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkNDAwMDAwMC0weGQ0MDAxZmZmKSBm b3IgcmlkIDE0IG9mIHBjaTA6MDo3OjcKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuNy5J TlRBCnBjaWIwOiBzbG90IDcgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE2CmZvdW5kLT4JdmVu ZG9yPTB4MTVhZCwgZGV2PTB4MDQwNSwgcmV2aWQ9MHgwMAoJZG9tYWluPTAsIGJ1cz0wLCBz bG90PTE1LCBmdW5jPTAKCWNsYXNzPTAzLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAK CWNtZHJlZz0weDAwMDMsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9OCAoZHdvcmRzKQoJ bGF0dGltZXI9MHg0MCAoMTkyMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4 MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTkKCW1hcFsxMF06IHR5cGUgSS9PIFBvcnQsIHJh bmdlIDMyLCBiYXNlIDB4MTBkMCwgc2l6ZSAgNCwgZW5hYmxlZApwY2liMDogYWxsb2NhdGVk IHR5cGUgNCAoMHgxMGQwLTB4MTBkZikgZm9yIHJpZCAxMCBvZiBwY2kwOjA6MTU6MAoJbWFw WzE0XTogdHlwZSBQcmVmZXRjaGFibGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGQ4MDAw MDAwLCBzaXplIDI2LCBlbmFibGVkCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGQ4MDAw MDAwLTB4ZGJmZmZmZmYpIGZvciByaWQgMTQgb2YgcGNpMDowOjE1OjAKCW1hcFsxOF06IHR5 cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGQ0ODAwMDAwLCBzaXplIDIzLCBlbmFibGVk CnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGQ0ODAwMDAwLTB4ZDRmZmZmZmYpIGZvciBy aWQgMTggb2YgcGNpMDowOjE1OjAKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMTUuSU5U QQpwY2liMDogc2xvdCAxNSBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMTYKZm91bmQtPgl2ZW5k b3I9MHgxNWFkLCBkZXY9MHgwNzkwLCByZXZpZD0weDAyCglkb21haW49MCwgYnVzPTAsIHNs b3Q9MTcsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDEsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MAoJ Y21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5zej04IChkd29yZHMpCgls YXR0aW1lcj0weDQwICgxOTIwIG5zKSwgbWluZ250PTB4MDQgKDEwMDAgbnMpLCBtYXhsYXQ9 MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHgxNWFkLCBkZXY9MHgwN2EwLCByZXZpZD0w eDAxCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjEsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAs IGhkcnR5cGU9MHgwMSwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAwMTAs IGNhY2hlbG5zej04IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4 MDQgKDEwMDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCXBvd2Vyc3BlYyAzICBzdXBwb3J0 cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSwgNjQgYml0LCB2 ZWN0b3IgbWFza3MKZm91bmQtPgl2ZW5kb3I9MHgxNWFkLCBkZXY9MHgwN2EwLCByZXZpZD0w eDAxCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjIsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAs IGhkcnR5cGU9MHgwMSwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAwMTAs IGNhY2hlbG5zej04IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4 MDQgKDEwMDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCXBvd2Vyc3BlYyAzICBzdXBwb3J0 cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSwgNjQgYml0LCB2 ZWN0b3IgbWFza3MKZm91bmQtPgl2ZW5kb3I9MHgxNWFkLCBkZXY9MHgwN2EwLCByZXZpZD0w eDAxCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjMsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAs IGhkcnR5cGU9MHgwMSwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAwMTAs IGNhY2hlbG5zej04IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4 MDQgKDEwMDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCXBvd2Vyc3BlYyAzICBzdXBwb3J0 cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSwgNjQgYml0LCB2 ZWN0b3IgbWFza3MKZm91bmQtPgl2ZW5kb3I9MHgxNWFkLCBkZXY9MHgwN2EwLCByZXZpZD0w eDAxCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjQsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAs IGhkcnR5cGU9MHgwMSwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAwMTAs IGNhY2hlbG5zej04IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4 MDQgKDEwMDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCXBvd2Vyc3BlYyAzICBzdXBwb3J0 cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSwgNjQgYml0LCB2 ZWN0b3IgbWFza3MKcGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMS4w IG9uIHBjaTAKcGNpYjE6ICAgZG9tYWluICAgICAgICAgICAgMApwY2liMTogICBzZWNvbmRh cnkgYnVzICAgICAxCnBjaWIxOiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDEKcGNpYjE6ICAgbm8g cHJlZmV0Y2hlZCBkZWNvZGUKcGNpYjE6IGNvdWxkIG5vdCBnZXQgUENJIGludGVycnVwdCBy b3V0aW5nIHRhYmxlIGZvciBcXF9TQl8uUENJMC5BR1BfIC0gQUVfTk9UX0ZPVU5ECnBjaTE6 IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIxCnBjaTE6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9 MQppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgNy4wIG9uIHBjaTAKaXNhMDog PElTQSBidXM+IG9uIGlzYWIwCmF0YXBjaTA6IDxJbnRlbCBQSUlYNCBVRE1BMzMgY29udHJv bGxlcj4gcG9ydCAweDFmMC0weDFmNywweDNmNiwweDEwYzAtMHgxMGNmIGF0IGRldmljZSA3 LjEgb24gcGNpMAphdGEwOiA8QVRBIGNoYW5uZWw+IGF0IGNoYW5uZWwgMCBvbiBhdGFwY2kw CmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE0IChJU0EgSVJRIDE0KSB0byBsYXBpYyAwIHZl Y3RvciA1MQphdGExOiA8QVRBIGNoYW5uZWw+IGF0IGNoYW5uZWwgMSBvbiBhdGFwY2kwCmRl dmljZV9hdHRhY2g6IGF0YTEgYXR0YWNoIHJldHVybmVkIDYKaW50c21iMDogPEludGVsIFBJ SVg0IFNNQlVTIEludGVyZmFjZT4gcG9ydCAweDEwNDAtMHgxMDRmIGF0IGRldmljZSA3LjMg b24gcGNpMAppbnRzbWIwOiBpbnRyIFNNSSBkaXNhYmxlZCByZXZpc2lvbiAwCnNtYnVzMDog PFN5c3RlbSBNYW5hZ2VtZW50IEJ1cz4gb24gaW50c21iMApwY2kwOiA8YmFzZSBwZXJpcGhl cmFsPiBhdCBkZXZpY2UgNy43IChubyBkcml2ZXIgYXR0YWNoZWQpCnZnYXBjaTA6IDxWR0Et Y29tcGF0aWJsZSBkaXNwbGF5PiBwb3J0IDB4MTBkMC0weDEwZGYgbWVtIDB4ZDgwMDAwMDAt MHhkYmZmZmZmZiwweGQ0ODAwMDAwLTB4ZDRmZmZmZmYgaXJxIDE2IGF0IGRldmljZSAxNS4w IG9uIHBjaTAKcGNpYjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMTcuMCBv biBwY2kwCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSA0ICgweDIwMDAtMHgzZmZmKSBmb3Igcmlk IDFjIG9mIHBjaWIyCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGQ1OTAwMDAwLTB4ZDYz ZmZmZmYpIGZvciByaWQgMjAgb2YgcGNpYjIKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4 ZGM0MDAwMDAtMHhkYzlmZmZmZikgZm9yIHJpZCAyNCBvZiBwY2liMgpwY2liMjogICBkb21h aW4gICAgICAgICAgICAwCnBjaWIyOiAgIHNlY29uZGFyeSBidXMgICAgIDIKcGNpYjI6ICAg c3Vib3JkaW5hdGUgYnVzICAgMgpwY2liMjogICBJL08gZGVjb2RlICAgICAgICAweDIwMDAt MHgzZmZmCnBjaWIyOiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4ZDU5MDAwMDAtMHhkNjNmZmZm ZgpwY2liMjogICBwcmVmZXRjaGVkIGRlY29kZSAweGRjNDAwMDAwLTB4ZGM5ZmZmZmYKcGNp YjI6ICAgU3VidHJhY3RpdmVseSBkZWNvZGVkIGJyaWRnZS4KcGNpYjI6IGNvdWxkIG5vdCBn ZXQgUENJIGludGVycnVwdCByb3V0aW5nIHRhYmxlIGZvciBcXF9TQl8uUENJMC5QMlAwIC0g QUVfTk9UX0ZPVU5ECnBjaTI6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIyCnBjaTI6IGRvbWFp bj0wLCBwaHlzaWNhbCBidXM9MgpwY2liMzogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRl dmljZSAyMS4wIG9uIHBjaTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDQgKDB4NDAwMC0weDRm ZmYpIGZvciByaWQgMWMgb2YgcGNpYjMKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDY0 MDAwMDAtMHhkNjRmZmZmZikgZm9yIHJpZCAyMCBvZiBwY2liMwpwY2liMDogYWxsb2NhdGVk IHR5cGUgMyAoMHhkY2EwMDAwMC0weGRjYWZmZmZmKSBmb3IgcmlkIDI0IG9mIHBjaWIzCnBj aWIzOiAgIGRvbWFpbiAgICAgICAgICAgIDAKcGNpYjM6ICAgc2Vjb25kYXJ5IGJ1cyAgICAg MwpwY2liMzogICBzdWJvcmRpbmF0ZSBidXMgICAzCnBjaWIzOiAgIEkvTyBkZWNvZGUgICAg ICAgIDB4NDAwMC0weDRmZmYKcGNpYjM6ICAgbWVtb3J5IGRlY29kZSAgICAgMHhkNjQwMDAw MC0weGQ2NGZmZmZmCnBjaWIzOiAgIHByZWZldGNoZWQgZGVjb2RlIDB4ZGNhMDAwMDAtMHhk Y2FmZmZmZgpwY2liMzogY291bGQgbm90IGdldCBQQ0kgaW50ZXJydXB0IHJvdXRpbmcgdGFi bGUgZm9yIFxcX1NCXy5QQ0kwLlBFNDAgLSBBRV9OT1RfRk9VTkQKcGNpMzogPEFDUEkgUENJ IGJ1cz4gb24gcGNpYjMKcGNpMzogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz0zCmZvdW5kLT4J dmVuZG9yPTB4MTAwMCwgZGV2PTB4MDA1NCwgcmV2aWQ9MHgwMQoJZG9tYWluPTAsIGJ1cz0z LCBzbG90PTAsIGZ1bmM9MAoJY2xhc3M9MDEtMDctMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9 MAoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0wIChkd29yZHMp CglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgw MCAoMCBucykKCWludHBpbj1hLCBpcnE9MTEKCXBvd2Vyc3BlYyAzICBzdXBwb3J0cyBEMCBE MyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSwgNjQgYml0LCB2ZWN0b3Ig bWFza3MKCW1hcFsxMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4NDAwMCwg c2l6ZSAgOCwgZW5hYmxlZApwY2liMzogYWxsb2NhdGVkIEkvTyBwb3J0IHJhbmdlICgweDQw MDAtMHg0MGZmKSBmb3IgcmlkIDEwIG9mIHBjaTA6MzowOjAKCW1hcFsxNF06IHR5cGUgTWVt b3J5LCByYW5nZSA2NCwgYmFzZSAweGQ2NDEwMDAwLCBzaXplIDE0LCBlbmFibGVkCnBjaWIz OiBhbGxvY2F0ZWQgbWVtb3J5IHJhbmdlICgweGQ2NDEwMDAwLTB4ZDY0MTNmZmYpIGZvciBy aWQgMTQgb2YgcGNpMDozOjA6MAoJbWFwWzFjXTogdHlwZSBNZW1vcnksIHJhbmdlIDY0LCBi YXNlIDB4ZDY0MDAwMDAsIHNpemUgMTYsIGVuYWJsZWQKcGNpYjM6IGFsbG9jYXRlZCBtZW1v cnkgcmFuZ2UgKDB4ZDY0MDAwMDAtMHhkNjQwZmZmZikgZm9yIHJpZCAxYyBvZiBwY2kwOjM6 MDowCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjIxLklOVEEKcGNpYjA6IHNsb3QgMjEg SU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE4CnBjaWIzOiBzbG90IDAgSU5UQSBpcyByb3V0ZWQg dG8gaXJxIDE4Cm1wdDA6IDxMU0lMb2dpYyBTQVMvU0FUQSBBZGFwdGVyPiBwb3J0IDB4NDAw MC0weDQwZmYgbWVtIDB4ZDY0MTAwMDAtMHhkNjQxM2ZmZiwweGQ2NDAwMDAwLTB4ZDY0MGZm ZmYgaXJxIDE4IGF0IGRldmljZSAwLjAgb24gcGNpMwptcHQwOiBhdHRlbXB0aW5nIHRvIGFs bG9jYXRlIDEgTVNJIHZlY3RvcnMgKDEgc3VwcG9ydGVkKQptc2k6IHJvdXRpbmcgTVNJIElS USAyNTYgdG8gbG9jYWwgQVBJQyAwIHZlY3RvciA1MgptcHQwOiB1c2luZyBJUlEgMjU2IGZv ciBNU0kKbXB0MDogTVBJIFZlcnNpb249MS41LjAuMAptcHQwOiBjaGFpbiBkZXB0aCBsaW1p dGVkIHRvIDM0IChmcm9tIDIwNDApCm1wdDA6IE1heGltdW0gU2VnbWVudCBDb3VudDogMzA2 LCBNYXhpbXVtIENBTSBTZWdtZW50IENvdW50OiAzMwptcHQwOiBNc2dMZW5ndGg9MjAgSU9D TnVtYmVyID0gMAptcHQwOiBJT0NGQUNUUzogR2xvYmFsQ3JlZGl0cz0xMjggQmxvY2tTaXpl PTggYnl0ZXMgUmVxdWVzdCBGcmFtZSBTaXplIDEyOCBieXRlcyBNYXggQ2hhaW4gRGVwdGgg MzQKbXB0MDogSU9DRkFDVFM6IE51bSBQb3J0cyAxLCBGV0ltYWdlU2l6ZSAwLCBGbGFncz0w Cm1wdDA6IE5vIEhhbmRsZXJzIEZvciBBbnkgRXZlbnQgTm90aWZ5IEZyYW1lcy4gRXZlbnQg MHhhIChBQ0sgbm90IHJlcXVpcmVkKS4KbXB0MDogTm8gSGFuZGxlcnMgRm9yIEFueSBFdmVu dCBOb3RpZnkgRnJhbWVzLiBFdmVudCAweGEgKEFDSyBub3QgcmVxdWlyZWQpLgptcHQwOiBO byBIYW5kbGVycyBGb3IgQW55IEV2ZW50IE5vdGlmeSBGcmFtZXMuIEV2ZW50IDB4YSAoQUNL IG5vdCByZXF1aXJlZCkuCnBjaWI0OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNl IDIyLjAgb24gcGNpMApwY2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHg1MDAwLTB4NWZmZikg Zm9yIHJpZCAxYyBvZiBwY2liNApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkNjUwMDAw MC0weGQ2NWZmZmZmKSBmb3IgcmlkIDIwIG9mIHBjaWI0CnBjaWIwOiBhbGxvY2F0ZWQgdHlw ZSAzICgweGRjYjAwMDAwLTB4ZGNiZmZmZmYpIGZvciByaWQgMjQgb2YgcGNpYjQKcGNpYjQ6 ICAgZG9tYWluICAgICAgICAgICAgMApwY2liNDogICBzZWNvbmRhcnkgYnVzICAgICA0CnBj aWI0OiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDQKcGNpYjQ6ICAgSS9PIGRlY29kZSAgICAgICAg MHg1MDAwLTB4NWZmZgpwY2liNDogICBtZW1vcnkgZGVjb2RlICAgICAweGQ2NTAwMDAwLTB4 ZDY1ZmZmZmYKcGNpYjQ6ICAgcHJlZmV0Y2hlZCBkZWNvZGUgMHhkY2IwMDAwMC0weGRjYmZm ZmZmCnBjaWI0OiBjb3VsZCBub3QgZ2V0IFBDSSBpbnRlcnJ1cHQgcm91dGluZyB0YWJsZSBm b3IgXFxfU0JfLlBDSTAuUEU1MCAtIEFFX05PVF9GT1VORApwY2k0OiA8QUNQSSBQQ0kgYnVz PiBvbiBwY2liNApwY2k0OiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTQKZm91bmQtPgl2ZW5k b3I9MHgxMDAwLCBkZXY9MHgwMDcyLCByZXZpZD0weDAzCglkb21haW49MCwgYnVzPTQsIHNs b3Q9MCwgZnVuYz0wCgljbGFzcz0wMS0wNy0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCglj bWRyZWc9MHgwMDAzLCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCgls YXR0aW1lcj0weDQwICgxOTIwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgw MCAoMCBucykKCWludHBpbj1hLCBpcnE9MTAKCXBvd2Vyc3BlYyAzICBzdXBwb3J0cyBEMCBE MSBEMiBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSwgNjQgYml0CglN U0ktWCBzdXBwb3J0cyAxNSBtZXNzYWdlcyBpbiBtYXAgMHgxNAoJbWFwWzEwXTogdHlwZSBJ L08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHg1MDAwLCBzaXplICA4LCBlbmFibGVkCnBjaWI0 OiBhbGxvY2F0ZWQgSS9PIHBvcnQgcmFuZ2UgKDB4NTAwMC0weDUwZmYpIGZvciByaWQgMTAg b2YgcGNpMDo0OjA6MAoJbWFwWzE0XTogdHlwZSBNZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4 ZDY1MDAwMDAsIHNpemUgMTQsIGVuYWJsZWQKcGNpYjQ6IGFsbG9jYXRlZCBtZW1vcnkgcmFu Z2UgKDB4ZDY1MDAwMDAtMHhkNjUwM2ZmZikgZm9yIHJpZCAxNCBvZiBwY2kwOjQ6MDowCglt YXBbMWNdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhkNjU0MDAwMCwgc2l6ZSAx OCwgZW5hYmxlZApwY2liNDogYWxsb2NhdGVkIG1lbW9yeSByYW5nZSAoMHhkNjU0MDAwMC0w eGQ2NTdmZmZmKSBmb3IgcmlkIDFjIG9mIHBjaTA6NDowOjAKcGNpYjA6IG1hdGNoZWQgZW50 cnkgZm9yIDAuMjIuSU5UQQpwY2liMDogc2xvdCAyMiBJTlRBIGhhcmR3aXJlZCB0byBJUlEg MTkKcGNpYjQ6IHNsb3QgMCBJTlRBIGlzIHJvdXRlZCB0byBpcnEgMTkKbXBzMDogPExTSSBT QVMyMDA4PiBwb3J0IDB4NTAwMC0weDUwZmYgbWVtIDB4ZDY1MDAwMDAtMHhkNjUwM2ZmZiww eGQ2NTQwMDAwLTB4ZDY1N2ZmZmYgaXJxIDE5IGF0IGRldmljZSAwLjAgb24gcGNpNAptcHMw OiBGaXJtd2FyZTogMTQuMDAuMDAuMDAsIERyaXZlcjogMTQuMDAuMDAuMDEtZmJzZAptcHMw OiBJT0NDYXBhYmlsaXRpZXM6IDEyODVjPFNjc2lUYXNrRnVsbCxEaWFnVHJhY2UsU25hcEJ1 ZixFRURQLFRyYW5zUmV0cnksRXZlbnRSZXBsYXksSG9zdERpc2M+Cm1wczA6IGF0dGVtcHRp bmcgdG8gYWxsb2NhdGUgMSBNU0kgdmVjdG9ycyAoMSBzdXBwb3J0ZWQpCm1zaTogcm91dGlu ZyBNU0kgSVJRIDI1NyB0byBsb2NhbCBBUElDIDAgdmVjdG9yIDUzCm1wczA6IHVzaW5nIElS USAyNTcgZm9yIE1TSQpwY2liNTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAy My4wIG9uIHBjaTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDQgKDB4NjAwMC0weDZmZmYpIGZv ciByaWQgMWMgb2YgcGNpYjUKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDY2MDAwMDAt MHhkNjZmZmZmZikgZm9yIHJpZCAyMCBvZiBwY2liNQpwY2liMDogYWxsb2NhdGVkIHR5cGUg MyAoMHhkY2MwMDAwMC0weGRjY2ZmZmZmKSBmb3IgcmlkIDI0IG9mIHBjaWI1CnBjaWI1OiAg IGRvbWFpbiAgICAgICAgICAgIDAKcGNpYjU6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgNQpwY2li NTogICBzdWJvcmRpbmF0ZSBidXMgICA1CnBjaWI1OiAgIEkvTyBkZWNvZGUgICAgICAgIDB4 NjAwMC0weDZmZmYKcGNpYjU6ICAgbWVtb3J5IGRlY29kZSAgICAgMHhkNjYwMDAwMC0weGQ2 NmZmZmZmCnBjaWI1OiAgIHByZWZldGNoZWQgZGVjb2RlIDB4ZGNjMDAwMDAtMHhkY2NmZmZm ZgpwY2liNTogY291bGQgbm90IGdldCBQQ0kgaW50ZXJydXB0IHJvdXRpbmcgdGFibGUgZm9y IFxcX1NCXy5QQ0kwLlBFNjAgLSBBRV9OT1RfRk9VTkQKcGNpNTogPEFDUEkgUENJIGJ1cz4g b24gcGNpYjUKcGNpNTogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz01CmZvdW5kLT4JdmVuZG9y PTB4ODA4NiwgZGV2PTB4MTBkMywgcmV2aWQ9MHgwMAoJZG9tYWluPTAsIGJ1cz01LCBzbG90 PTAsIGZ1bmM9MAoJY2xhc3M9MDItMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21k cmVnPTB4MDEwMywgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0 dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAg bnMpCglpbnRwaW49YSwgaXJxPTkKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3Vy cmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSwgNjQgYml0CglNU0ktWCBzdXBwb3J0 cyA1IG1lc3NhZ2VzIGluIG1hcCAweDFjCgltYXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2Ug MzIsIGJhc2UgMHhkNjY0MDAwMCwgc2l6ZSAxNywgZW5hYmxlZApwY2liNTogYWxsb2NhdGVk IG1lbW9yeSByYW5nZSAoMHhkNjY0MDAwMC0weGQ2NjVmZmZmKSBmb3IgcmlkIDEwIG9mIHBj aTA6NTowOjAKCW1hcFsxNF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGQ2NjIw MDAwLCBzaXplIDE3LCBlbmFibGVkCnBjaWI1OiBhbGxvY2F0ZWQgbWVtb3J5IHJhbmdlICgw eGQ2NjIwMDAwLTB4ZDY2M2ZmZmYpIGZvciByaWQgMTQgb2YgcGNpMDo1OjA6MAoJbWFwWzE4 XTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHg2MDAwLCBzaXplICA1LCBlbmFi bGVkCnBjaWI1OiBhbGxvY2F0ZWQgSS9PIHBvcnQgcmFuZ2UgKDB4NjAwMC0weDYwMWYpIGZv ciByaWQgMTggb2YgcGNpMDo1OjA6MAoJbWFwWzFjXTogdHlwZSBNZW1vcnksIHJhbmdlIDMy LCBiYXNlIDB4ZDY2MDAwMDAsIHNpemUgMTQsIGVuYWJsZWQKcGNpYjU6IGFsbG9jYXRlZCBt ZW1vcnkgcmFuZ2UgKDB4ZDY2MDAwMDAtMHhkNjYwM2ZmZikgZm9yIHJpZCAxYyBvZiBwY2kw OjU6MDowCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjIzLklOVEEKcGNpYjA6IHNsb3Qg MjMgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE2CnBjaWI1OiBzbG90IDAgSU5UQSBpcyByb3V0 ZWQgdG8gaXJxIDE2CmVtMDogPEludGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsgQ29ubmVjdGlv biA3LjMuMj4gcG9ydCAweDYwMDAtMHg2MDFmIG1lbSAweGQ2NjQwMDAwLTB4ZDY2NWZmZmYs MHhkNjYyMDAwMC0weGQ2NjNmZmZmLDB4ZDY2MDAwMDAtMHhkNjYwM2ZmZiBpcnEgMTYgYXQg ZGV2aWNlIDAuMCBvbiBwY2k1CmVtMDogTWVtb3J5IEFjY2VzcyBhbmQvb3IgQnVzIE1hc3Rl ciBiaXRzIHdlcmUgbm90IHNldCEKZW0wOiBhdHRlbXB0aW5nIHRvIGFsbG9jYXRlIDMgTVNJ LVggdmVjdG9ycyAoNSBzdXBwb3J0ZWQpCm1zaTogcm91dGluZyBNU0ktWCBJUlEgMjU4IHRv IGxvY2FsIEFQSUMgMCB2ZWN0b3IgNTQKbXNpOiByb3V0aW5nIE1TSS1YIElSUSAyNTkgdG8g bG9jYWwgQVBJQyAwIHZlY3RvciA1NQptc2k6IHJvdXRpbmcgTVNJLVggSVJRIDI2MCB0byBs b2NhbCBBUElDIDAgdmVjdG9yIDU2CmVtMDogdXNpbmcgSVJRcyAyNTgtMjYwIGZvciBNU0kt WAplbTA6IFVzaW5nIE1TSVggaW50ZXJydXB0cyB3aXRoIDMgdmVjdG9ycwplbTA6IGJwZiBh dHRhY2hlZAplbTA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjBjOjI5OjBhOjdjOjc2CnBjaWI2 OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDI0LjAgb24gcGNpMApwY2liMDog YWxsb2NhdGVkIHR5cGUgNCAoMHg3MDAwLTB4N2ZmZikgZm9yIHJpZCAxYyBvZiBwY2liNgpw Y2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkNjcwMDAwMC0weGQ2N2ZmZmZmKSBmb3Igcmlk IDIwIG9mIHBjaWI2CnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGRjZDAwMDAwLTB4ZGNk ZmZmZmYpIGZvciByaWQgMjQgb2YgcGNpYjYKcGNpYjY6ICAgZG9tYWluICAgICAgICAgICAg MApwY2liNjogICBzZWNvbmRhcnkgYnVzICAgICA2CnBjaWI2OiAgIHN1Ym9yZGluYXRlIGJ1 cyAgIDYKcGNpYjY6ICAgSS9PIGRlY29kZSAgICAgICAgMHg3MDAwLTB4N2ZmZgpwY2liNjog ICBtZW1vcnkgZGVjb2RlICAgICAweGQ2NzAwMDAwLTB4ZDY3ZmZmZmYKcGNpYjY6ICAgcHJl ZmV0Y2hlZCBkZWNvZGUgMHhkY2QwMDAwMC0weGRjZGZmZmZmCnBjaWI2OiBjb3VsZCBub3Qg Z2V0IFBDSSBpbnRlcnJ1cHQgcm91dGluZyB0YWJsZSBmb3IgXFxfU0JfLlBDSTAuUEU3MCAt IEFFX05PVF9GT1VORApwY2k2OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNgpwY2k2OiBkb21h aW49MCwgcGh5c2ljYWwgYnVzPTYKZm91bmQtPgl2ZW5kb3I9MHgxNWFkLCBkZXY9MHgwN2Iw LCByZXZpZD0weDAxCglkb21haW49MCwgYnVzPTYsIHNsb3Q9MCwgZnVuYz0wCgljbGFzcz0w Mi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDAzLCBzdGF0cmVn PTB4MDAxMCwgY2FjaGVsbnN6PTggKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBt aW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT03 Cglwb3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDAKCU1TSSBz dXBwb3J0cyAxIG1lc3NhZ2UsIDY0IGJpdAoJTVNJLVggc3VwcG9ydHMgMjUgbWVzc2FnZXMg aW4gbWFwIDB4MTgKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGQ2 NzA1MDAwLCBzaXplIDEyLCBlbmFibGVkCnBjaWI2OiBhbGxvY2F0ZWQgbWVtb3J5IHJhbmdl ICgweGQ2NzA1MDAwLTB4ZDY3MDVmZmYpIGZvciByaWQgMTAgb2YgcGNpMDo2OjA6MAoJbWFw WzE0XTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZDY3MDQwMDAsIHNpemUgMTIs IGVuYWJsZWQKcGNpYjY6IGFsbG9jYXRlZCBtZW1vcnkgcmFuZ2UgKDB4ZDY3MDQwMDAtMHhk NjcwNGZmZikgZm9yIHJpZCAxNCBvZiBwY2kwOjY6MDowCgltYXBbMThdOiB0eXBlIE1lbW9y eSwgcmFuZ2UgMzIsIGJhc2UgMHhkNjcwMjAwMCwgc2l6ZSAxMywgZW5hYmxlZApwY2liNjog YWxsb2NhdGVkIG1lbW9yeSByYW5nZSAoMHhkNjcwMjAwMC0weGQ2NzAzZmZmKSBmb3Igcmlk IDE4IG9mIHBjaTA6NjowOjAKCW1hcFsxY106IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBi YXNlIDB4NzAwMCwgc2l6ZSAgNCwgZW5hYmxlZApwY2liNjogYWxsb2NhdGVkIEkvTyBwb3J0 IHJhbmdlICgweDcwMDAtMHg3MDBmKSBmb3IgcmlkIDFjIG9mIHBjaTA6NjowOjAKcGNpYjA6 IG1hdGNoZWQgZW50cnkgZm9yIDAuMjQuSU5UQQpwY2liMDogc2xvdCAyNCBJTlRBIGhhcmR3 aXJlZCB0byBJUlEgMTcKcGNpYjY6IHNsb3QgMCBJTlRBIGlzIHJvdXRlZCB0byBpcnEgMTcK dm14M2YwOiA8Vk13YXJlIFZteG5ldDMgRXRoZXJuZXQgQ29udHJvbGxlcj4gcG9ydCAweDcw MDAtMHg3MDBmIG1lbSAweGQ2NzA1MDAwLTB4ZDY3MDVmZmYsMHhkNjcwNDAwMC0weGQ2NzA0 ZmZmLDB4ZDY3MDIwMDAtMHhkNjcwM2ZmZiBpcnEgMTcgYXQgZGV2aWNlIDAuMCBvbiBwY2k2 CnZteDNmMDogRHJpdmVyIHZlcnNpb24gOiAwLjEuMC4wLgp2bXgzZjA6IENhcGFiaWxpdGll cyA6IHNnIGpmIHZsYW4gY3N1bSB0c28Kdm14M2YwOiBhdHRlbXB0aW5nIHRvIGFsbG9jYXRl IDEgTVNJLVggdmVjdG9ycyAoMjUgc3VwcG9ydGVkKQptc2k6IHJvdXRpbmcgTVNJLVggSVJR IDI2MSB0byBsb2NhbCBBUElDIDAgdmVjdG9yIDU3CnZteDNmMDogdXNpbmcgSVJRIDI2MSBm b3IgTVNJLVgKdm14M2YwOiBicGYgYXR0YWNoZWQKdm14M2YwOiBFdGhlcm5ldCBhZGRyZXNz OiAwMDowYzoyOTowYTo3Yzo4MAphY3BpX2FjYWQwOiA8QUMgQWRhcHRlcj4gb24gYWNwaTAK YXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gcG9ydCAweDYwLDB4NjQg aXJxIDEgb24gYWNwaTAKYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzAK YXRrYmQ6IHRoZSBjdXJyZW50IGtiZCBjb250cm9sbGVyIGNvbW1hbmQgYnl0ZSAwMDQ3CmF0 a2JkOiBrZXlib2FyZCBJRCAweDQxYWIgKDIpCmtiZDAgYXQgYXRrYmQwCmtiZDA6IGF0a2Jk MCwgQVQgMTAxLzEwMiAoMiksIGNvbmZpZzoweDAsIGZsYWdzOjB4M2QwMDAwCmlvYXBpYzA6 IHJvdXRpbmcgaW50cGluIDEgKElTQSBJUlEgMSkgdG8gbGFwaWMgMCB2ZWN0b3IgNTgKYXRr YmQwOiBbR0lBTlQtTE9DS0VEXQpwc20wOiB1bmFibGUgdG8gYWxsb2NhdGUgSVJRCnBzbWNw bnAwOiA8UFMvMiBtb3VzZSBwb3J0PiBpcnEgMTIgb24gYWNwaTAKcHNtMDogY3VycmVudCBj b21tYW5kIGJ5dGU6MDA0Nwpwc20wOiA8UFMvMiBNb3VzZT4gaXJxIDEyIG9uIGF0a2JkYzAK aW9hcGljMDogcm91dGluZyBpbnRwaW4gMTIgKElTQSBJUlEgMTIpIHRvIGxhcGljIDAgdmVj dG9yIDU5CnBzbTA6IFtHSUFOVC1MT0NLRURdCnBzbTA6IG1vZGVsIEludGVsbGlNb3VzZSwg ZGV2aWNlIElEIDMtMDAsIDMgYnV0dG9ucwpwc20wOiBjb25maWc6MDAwMDAwMDAsIGZsYWdz OjAwMDAwMDA4LCBwYWNrZXQgc2l6ZTo0CnBzbTA6IHN5bmNtYXNrOjA4LCBzeW5jYml0czow MAp1YXJ0MDogPDE2NTUwIG9yIGNvbXBhdGlibGU+IHBvcnQgMHgzZjgtMHgzZmYgaXJxIDQg ZmxhZ3MgMHgxMCBvbiBhY3BpMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiA0IChJU0EgSVJR IDQpIHRvIGxhcGljIDAgdmVjdG9yIDYwCnVhcnQwOiBmYXN0IGludGVycnVwdAp1YXJ0MTog PDE2NTUwIG9yIGNvbXBhdGlibGU+IHBvcnQgMHgyZjgtMHgyZmYgaXJxIDMgb24gYWNwaTAK aW9hcGljMDogcm91dGluZyBpbnRwaW4gMyAoSVNBIElSUSAzKSB0byBsYXBpYyAwIHZlY3Rv ciA2MQp1YXJ0MTogZmFzdCBpbnRlcnJ1cHQKYWNwaTA6IHdha2V1cCBjb2RlIHZhIDB4ZmZm ZmZmODFmMDc2ZTAwMCBwYSAweDQwMDAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTAw MDAtMHhhMDdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMg KDB4YTA4MDAtMHhhMGZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0 eXBlIDMgKDB4YTEwMDAtMHhhMTdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9j YXRlZCB0eXBlIDMgKDB4YTE4MDAtMHhhMWZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6 IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTIwMDAtMHhhMjdmZikgZm9yIHJpZCAwIG9mIG9ybTAK cGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTI4MDAtMHhhMmZmZikgZm9yIHJpZCAwIG9m IG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTMwMDAtMHhhMzdmZikgZm9yIHJp ZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTM4MDAtMHhhM2ZmZikg Zm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTQwMDAtMHhh NDdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTQ4 MDAtMHhhNGZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMg KDB4YTUwMDAtMHhhNTdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0 eXBlIDMgKDB4YTU4MDAtMHhhNWZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9j YXRlZCB0eXBlIDMgKDB4YTYwMDAtMHhhNjdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6 IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTY4MDAtMHhhNmZmZikgZm9yIHJpZCAwIG9mIG9ybTAK cGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTcwMDAtMHhhNzdmZikgZm9yIHJpZCAwIG9m IG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTc4MDAtMHhhN2ZmZikgZm9yIHJp ZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTgwMDAtMHhhODdmZikg Zm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTg4MDAtMHhh OGZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTkw MDAtMHhhOTdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMg KDB4YTk4MDAtMHhhOWZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0 eXBlIDMgKDB4YWEwMDAtMHhhYTdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9j YXRlZCB0eXBlIDMgKDB4YWE4MDAtMHhhYWZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6 IGFsbG9jYXRlZCB0eXBlIDMgKDB4YWIwMDAtMHhhYjdmZikgZm9yIHJpZCAwIG9mIG9ybTAK cGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YWI4MDAtMHhhYmZmZikgZm9yIHJpZCAwIG9m IG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YWMwMDAtMHhhYzdmZikgZm9yIHJp ZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YWM4MDAtMHhhY2ZmZikg Zm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YWQwMDAtMHhh ZDdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YWQ4 MDAtMHhhZGZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMg KDB4YWUwMDAtMHhhZTdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0 eXBlIDMgKDB4YWU4MDAtMHhhZWZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9j YXRlZCB0eXBlIDMgKDB4YWYwMDAtMHhhZjdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6 IGFsbG9jYXRlZCB0eXBlIDMgKDB4YWY4MDAtMHhhZmZmZikgZm9yIHJpZCAwIG9mIG9ybTAK cGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjAwMDAtMHhiMDdmZikgZm9yIHJpZCAwIG9m IG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjA4MDAtMHhiMGZmZikgZm9yIHJp ZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjEwMDAtMHhiMTdmZikg Zm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjE4MDAtMHhi MWZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjIw MDAtMHhiMjdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMg KDB4YjI4MDAtMHhiMmZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0 eXBlIDMgKDB4YjMwMDAtMHhiMzdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9j YXRlZCB0eXBlIDMgKDB4YjM4MDAtMHhiM2ZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6 IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjQwMDAtMHhiNDdmZikgZm9yIHJpZCAwIG9mIG9ybTAK cGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjQ4MDAtMHhiNGZmZikgZm9yIHJpZCAwIG9m IG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjUwMDAtMHhiNTdmZikgZm9yIHJp ZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjU4MDAtMHhiNWZmZikg Zm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjYwMDAtMHhi NjdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjY4 MDAtMHhiNmZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMg KDB4YjcwMDAtMHhiNzdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0 eXBlIDMgKDB4Yjc4MDAtMHhiN2ZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9j YXRlZCB0eXBlIDMgKDB4YjgwMDAtMHhiODdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6 IGFsbG9jYXRlZCB0eXBlIDMgKDB4Yjg4MDAtMHhiOGZmZikgZm9yIHJpZCAwIG9mIG9ybTAK cGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjkwMDAtMHhiOTdmZikgZm9yIHJpZCAwIG9m IG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4Yjk4MDAtMHhiOWZmZikgZm9yIHJp ZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YmEwMDAtMHhiYTdmZikg Zm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YmE4MDAtMHhi YWZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YmIw MDAtMHhiYjdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMg KDB4YmI4MDAtMHhiYmZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0 eXBlIDMgKDB4YmMwMDAtMHhiYzdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9j YXRlZCB0eXBlIDMgKDB4YmM4MDAtMHhiY2ZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6 IGFsbG9jYXRlZCB0eXBlIDMgKDB4YmQwMDAtMHhiZDdmZikgZm9yIHJpZCAwIG9mIG9ybTAK cGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YmQ4MDAtMHhiZGZmZikgZm9yIHJpZCAwIG9m IG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YmUwMDAtMHhiZTdmZikgZm9yIHJp ZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YmU4MDAtMHhiZWZmZikg Zm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YmYwMDAtMHhi ZjdmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YmY4 MDAtMHhiZmZmZikgZm9yIHJpZCAwIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMg KDB4Y2MwMDAtMHhjYzdmZikgZm9yIHJpZCAzIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0 eXBlIDMgKDB4Y2M4MDAtMHhjY2ZmZikgZm9yIHJpZCAzIG9mIG9ybTAKcGNpYjA6IGFsbG9j YXRlZCB0eXBlIDMgKDB4Y2QwMDAtMHhjZDdmZikgZm9yIHJpZCAzIG9mIG9ybTAKcGNpYjA6 IGFsbG9jYXRlZCB0eXBlIDMgKDB4Y2Q4MDAtMHhjZGZmZikgZm9yIHJpZCAzIG9mIG9ybTAK cGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4Y2UwMDAtMHhjZTdmZikgZm9yIHJpZCAzIG9m IG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4Y2U4MDAtMHhjZWZmZikgZm9yIHJp ZCAzIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4Y2YwMDAtMHhjZjdmZikg Zm9yIHJpZCAzIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4Y2Y4MDAtMHhj ZmZmZikgZm9yIHJpZCAzIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDAw MDAtMHhkMDdmZikgZm9yIHJpZCAzIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMg KDB4ZDA4MDAtMHhkMGZmZikgZm9yIHJpZCAzIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0 eXBlIDMgKDB4ZDEwMDAtMHhkMTdmZikgZm9yIHJpZCAzIG9mIG9ybTAKcGNpYjA6IGFsbG9j YXRlZCB0eXBlIDMgKDB4ZDE4MDAtMHhkMWZmZikgZm9yIHJpZCAzIG9mIG9ybTAKcGNpYjA6 IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDIwMDAtMHhkMjdmZikgZm9yIHJpZCAzIG9mIG9ybTAK cGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDI4MDAtMHhkMmZmZikgZm9yIHJpZCAzIG9m IG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDMwMDAtMHhkMzdmZikgZm9yIHJp ZCAzIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDM4MDAtMHhkM2ZmZikg Zm9yIHJpZCAzIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDQwMDAtMHhk NDdmZikgZm9yIHJpZCAzIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDQ4 MDAtMHhkNGZmZikgZm9yIHJpZCAzIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMg KDB4ZDUwMDAtMHhkNTdmZikgZm9yIHJpZCAzIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0 eXBlIDMgKDB4ZDU4MDAtMHhkNWZmZikgZm9yIHJpZCAzIG9mIG9ybTAKcGNpYjA6IGFsbG9j YXRlZCB0eXBlIDMgKDB4ZDYwMDAtMHhkNjdmZikgZm9yIHJpZCAzIG9mIG9ybTAKcGNpYjA6 IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDY4MDAtMHhkNmZmZikgZm9yIHJpZCAzIG9mIG9ybTAK cGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDcwMDAtMHhkNzdmZikgZm9yIHJpZCAzIG9m IG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDc4MDAtMHhkN2ZmZikgZm9yIHJp ZCAzIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDgwMDAtMHhkODdmZikg Zm9yIHJpZCAzIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDg4MDAtMHhk OGZmZikgZm9yIHJpZCAzIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDkw MDAtMHhkOTdmZikgZm9yIHJpZCAzIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMg KDB4ZDk4MDAtMHhkOWZmZikgZm9yIHJpZCAzIG9mIG9ybTAKcGNpYjA6IGFsbG9jYXRlZCB0 eXBlIDMgKDB4ZGEwMDAtMHhkYTdmZikgZm9yIHJpZCAzIG9mIG9ybTAKcGNpYjA6IGFsbG9j YXRlZCB0eXBlIDMgKDB4ZGE4MDAtMHhkYWZmZikgZm9yIHJpZCAzIG9mIG9ybTAKcGNpYjA6 IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZGIwMDAtMHhkYjdmZikgZm9yIHJpZCAzIG9mIG9ybTAK cGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZGI4MDAtMHhkYmZmZikgZm9yIHJpZCAzIG9m IG9ybTAKaXNhX3Byb2JlX2NoaWxkcmVuOiBkaXNhYmxpbmcgUG5QIGRldmljZXMKYXRrYmRj OiBhdGtiZGMwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdAphdHJ0YzogYXRydGMwIGFs cmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdAphdHRpbWVyOiBhdHRpbWVyMCBhbHJlYWR5IGV4 aXN0czsgc2tpcHBpbmcgaXQKc2M6IHNjMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQK dWFydDogdWFydDAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CnVhcnQ6IHVhcnQxIGFs cmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdAppc2FfcHJvYmVfY2hpbGRyZW46IHByb2Jpbmcg bm9uLVBuUCBkZXZpY2VzCm9ybTA6IDxJU0EgT3B0aW9uIFJPTXM+IGF0IGlvbWVtIDB4YzAw MDAtMHhjN2ZmZiwweGNhMDAwLTB4Y2FmZmYsMHhjYjAwMC0weGNiZmZmLDB4ZGMwMDAtMHhk ZmZmZiwweGUwMDAwLTB4ZTdmZmYgb24gaXNhMApzYzA6IDxTeXN0ZW0gY29uc29sZT4gYXQg ZmxhZ3MgMHgxMDAgb24gaXNhMApzYzA6IFZHQSA8MTIgdmlydHVhbCBjb25zb2xlcywgZmxh Z3M9MHgzMDA+CnNjMDogZmIwLCBrYmQwLCB0ZXJtaW5hbCBlbXVsYXRvcjogc2N0ZWtlbiAo dGVrZW4gdGVybWluYWwpCnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAt MHgzZGYgaW9tZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTAKcGNpYjA6IGFsbG9jYXRlZCB0 eXBlIDQgKDB4M2MwLTB4M2RmKSBmb3IgcmlkIDAgb2YgdmdhMApwY2liMDogYWxsb2NhdGVk IHR5cGUgMyAoMHhhMDAwMC0weGJmZmZmKSBmb3IgcmlkIDAgb2YgdmdhMApmZGMwIGZhaWxl ZCB0byBwcm9iZSBhdCBwb3J0IDB4M2YwIGlycSA2IGRycSAyIG9uIGlzYTAKcHBjMCBmYWls ZWQgdG8gcHJvYmUgYXQgaXJxIDcgb24gaXNhMAp3YndkMCBmYWlsZWQgdG8gcHJvYmUgb24g aXNhMAppc2FfcHJvYmVfY2hpbGRyZW46IHByb2JpbmcgUG5QIGRldmljZXMKRGV2aWNlIGNv bmZpZ3VyYXRpb24gZmluaXNoZWQuCnByb2NmcyByZWdpc3RlcmVkClpGUyBmaWxlc3lzdGVt IHZlcnNpb246IDUKWkZTIHN0b3JhZ2UgcG9vbCB2ZXJzaW9uOiBmZWF0dXJlcyBzdXBwb3J0 ICg1MDAwKQpsYXBpYzogRGl2aXNvciAyLCBGcmVxdWVuY3kgMzMwMDAxMTQgSHoKVGltZWNv dW50ZXJzIHRpY2sgZXZlcnkgMTAuMDAwIG1zZWMKdmxhbjogaW5pdGlhbGl6ZWQsIHVzaW5n IGhhc2ggdGFibGVzIHdpdGggY2hhaW5pbmcKY3J5cHRvOiA8Y3J5cHRvIGRldmljZT4KSVBz ZWM6IEluaXRpYWxpemVkIFNlY3VyaXR5IEFzc29jaWF0aW9uIFByb2Nlc3NpbmcuCmxvMDog YnBmIGF0dGFjaGVkCmF0YTA6IHJlc2V0IHRwMSBtYXNrPTAzIG9zdGF0MD01MSBvc3RhdDE9 N2YKYXRhMDogc3RhdDA9MHgwMCBlcnI9MHgwMSBsc2I9MHgxNCBtc2I9MHhlYgphdGEwOiBz dGF0MT0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTA6IHN0YXQxPTB4N2Yg ZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhMDogc3RhdDE9MHg3ZiBlcnI9MHhmZiBs c2I9MHhmZiBtc2I9MHhmZgphdGEwOiBzdGF0MT0weDdmIGVycj0weGZmIGxzYj0weGZmIG1z Yj0weGZmCmF0YTA6IHN0YXQxPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRh MDogc3RhdDE9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGEwOiBzdGF0MT0w eDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTA6IHN0YXQxPTB4N2YgZXJyPTB4 ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhMDogc3RhdDE9MHg3ZiBlcnI9MHhmZiBsc2I9MHhm ZiBtc2I9MHhmZgphdGEwOiBzdGF0MT0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZm CmF0YTA6IHN0YXQxPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhMDogc3Rh dDE9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGEwOiBzdGF0MT0weDdmIGVy cj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTA6IHN0YXQxPTB4N2YgZXJyPTB4ZmYgbHNi PTB4ZmYgbXNiPTB4ZmYKYXRhMDogc3RhdDE9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9 MHhmZgphdGEwOiBzdGF0MT0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTA6 IHN0YXQxPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhMDogc3RhdDE9MHg3 ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGEwOiBzdGF0MT0weDdmIGVycj0weGZm IGxzYj0weGZmIG1zYj0weGZmCmF0YTA6IHN0YXQxPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYg bXNiPTB4ZmYKYXRhMDogc3RhdDE9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgph dGEwOiBzdGF0MT0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTA6IHJlc2V0 IHRwMiBzdGF0MD0wMCBzdGF0MT1mZiBkZXZpY2VzPTB4MTAwMDAKYWNwaV9hY2FkMDogYWNs aW5lIGluaXRpYWxpemF0aW9uIHN0YXJ0CmFjcGlfYWNhZDA6IE9uIExpbmUKYWNwaV9hY2Fk MDogYWNsaW5lIGluaXRpYWxpemF0aW9uIGRvbmUsIHRyaWVkIDEgdGltZXMKKHByb2JlMDpt cHQwOjA6MDowKTogRG93biByZXZpbmcgUHJvdG9jb2wgVmVyc2lvbiBmcm9tIDQgdG8gMj8K Y2QwIGF0IGF0YTAgYnVzIDAgc2NidXMwIHRhcmdldCAwIGx1biAwCmNkMDogPE5FQ1ZNV2Fy IFZNd2FyZSBJREUgQ0RSMDAgMS4wMD4gUmVtb3ZhYmxlIENELVJPTSBTQ1NJLTAgZGV2aWNl IApjZDA6IFNlcmlhbCBOdW1iZXIgMDAwMDAwMDAwMDAwMDAwMDAwMDEKY2QwOiAzMy4zMDBN Qi9zIHRyYW5zZmVycyAoVURNQTIsIEFUQVBJIDEyYnl0ZXMsIFBJTyA2NTUzNGJ5dGVzKQpj ZDA6IEF0dGVtcHQgdG8gcXVlcnkgZGV2aWNlIHNpemUgZmFpbGVkOiBOT1QgUkVBRFksIE1l ZGl1bSBub3QgcHJlc2VudApHRU9NOiBuZXcgZGlzayBjZDAKZGEwIGF0IG1wdDAgYnVzIDAg c2NidXMxIHRhcmdldCAwIGx1biAwCmRhMDogPFZNd2FyZSBWaXJ0dWFsIGRpc2sgMS4wPiBG aXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktMiBkZXZpY2UgCmRhMDogMzAwLjAwME1CL3MgdHJh bnNmZXJzCmRhMDogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmRhMDogNTEyME1CICgxMDQ4 NTc2MCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDY1MkMpCkdFT006IG5ldyBkaXNr IGRhMApwYXNzMCBhdCBhdGEwIGJ1cyAwIHNjYnVzMCB0YXJnZXQgMCBsdW4gMApwYXNzMDog PE5FQ1ZNV2FyIFZNd2FyZSBJREUgQ0RSMDAgMS4wMD4gUmVtb3ZhYmxlIENELVJPTSBTQ1NJ LTAgZGV2aWNlIApwYXNzMDogU2VyaWFsIE51bWJlciAwMDAwMDAwMDAwMDAwMDAwMDAwMQpw YXNzMDogMzMuMzAwTUIvcyB0cmFuc2ZlcnMgKFVETUEyLCBBVEFQSSAxMmJ5dGVzLCBQSU8g NjU1MzRieXRlcykKcGFzczEgYXQgbXB0MCBidXMgMCBzY2J1czEgdGFyZ2V0IDAgbHVuIDAK cGFzczE6IDxWTXdhcmUgVmlydHVhbCBkaXNrIDEuMD4gRml4ZWQgRGlyZWN0IEFjY2VzcyBT Q1NJLTIgZGV2aWNlIApwYXNzMTogMzAwLjAwME1CL3MgdHJhbnNmZXJzCnBhc3MxOiBDb21t YW5kIFF1ZXVlaW5nIGVuYWJsZWQKZGEyIGF0IG1wczAgYnVzIDAgc2NidXMyIHRhcmdldCAx IGx1biAwCmRhMjogPEFUQSBJTlRFTCBTU0RTQzJDVDI0IDMwMGk+IEZpeGVkIERpcmVjdCBB Y2Nlc3MgU0NTSS02IGRldmljZSAKZGEyOiBTZXJpYWwgTnVtYmVyIENWTVAyMzMyMDM4TjI0 MERHTiAgCmRhMjogNjAwLjAwME1CL3MgdHJhbnNmZXJzCmRhMjogQ29tbWFuZCBRdWV1ZWlu ZyBlbmFibGVkCmRhMjogMjI4OTM2TUIgKDQ2ODg2MjEyOCA1MTIgYnl0ZSBzZWN0b3JzOiAy NTVIIDYzUy9UIDI5MTg1QykKZGEzIGF0IG1wczAgYnVzIDAgc2NidXMyIHRhcmdldCAyIGx1 biAwCmRhMzogPEFUQSBJTlRFTCBTU0RTQzJDVDI0IDMwMGk+IEZpeGVkIERpcmVjdCBBY2Nl c3MgU0NTSS02IGRldmljZSAKZGEzOiBTZXJpYWwgTnVtYmVyIENWTVAyMzMyMDQxVzI0MERH TiAgCmRhMzogNjAwLjAwME1CL3MgdHJhbnNmZXJzCmRhMzogQ29tbWFuZCBRdWV1ZWluZyBl bmFibGVkCmRhMzogMjI4OTM2TUIgKDQ2ODg2MjEyOCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVI IDYzUy9UIDI5MTg1QykKZGExIGF0IG1wczAgYnVzIDAgc2NidXMyIHRhcmdldCAwIGx1biAw CmRhMTogPEFUQSBJTlRFTCBTU0RTQzJDVDI0IDMwMGk+IEZpeGVkIERpcmVjdCBBY2Nlc3Mg U0NTSS02IGRldmljZSAKZGExOiBTZXJpYWwgTnVtYmVyIENWTVAyMzMyMDMwRzI0MERHTiAg CmRhMTogNjAwLjAwME1CL3MgdHJhbnNmZXJzCmRhMTogQ29tbWFuZCBRdWV1ZWluZyBlbmFi bGVkCmRhMTogMjI4OTM2TUIgKDQ2ODg2MjEyOCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYz Uy9UIDI5MTg1QykKcGFzczIgYXQgbXBzMCBidXMgMCBzY2J1czIgdGFyZ2V0IDAgbHVuIDAK cGFzczI6IDxBVEEgSU5URUwgU1NEU0MyQ1QyNCAzMDBpPiBGaXhlZCBEaXJlY3QgQWNjZXNz IFNDU0ktNiBkZXZpY2UgCnBhc3MyOiBTZXJpYWwgTnVtYmVyIENWTVAyMzMyMDMwRzI0MERH TiAgCnBhc3MyOiA2MDAuMDAwTUIvcyB0cmFuc2ZlcnMKcGFzczI6IENvbW1hbmQgUXVldWVp bmcgZW5hYmxlZApwYXNzMyBhdCBtcHMwIGJ1cyAwIHNjYnVzMiB0YXJnZXQgMSBsdW4gMApw YXNzMzogPEFUQSBJTlRFTCBTU0RTQzJDVDI0IDMwMGk+IEZpeGVkIERpcmVjdCBBY2Nlc3Mg U0NTSS02IGRldmljZSAKcGFzczM6IFNlcmlhbCBOdW1iZXIgQ1ZNUDIzMzIwMzhOMjQwREdO ICAKcGFzczM6IDYwMC4wMDBNQi9zIHRyYW5zZmVycwpwYXNzMzogQ29tbWFuZCBRdWV1ZWlu ZyBlbmFibGVkCnBhc3M0IGF0IG1wczAgYnVzIDAgc2NidXMyIHRhcmdldCAyIGx1biAwCnBh c3M0OiA8QVRBIElOVEVMIFNTRFNDMkNUMjQgMzAwaT4gRml4ZWQgRGlyZWN0IEFjY2VzcyBT Q1NJLTYgZGV2aWNlIApwYXNzNDogU2VyaWFsIE51bWJlciBDVk1QMjMzMjA0MVcyNDBER04g IApwYXNzNDogNjAwLjAwME1CL3MgdHJhbnNmZXJzCnBhc3M0OiBDb21tYW5kIFF1ZXVlaW5n IGVuYWJsZWQKcGFzczUgYXQgbXBzMCBidXMgMCBzY2J1czIgdGFyZ2V0IDMgbHVuIDAKcGFz czU6IDxBVEEgSGl0YWNoaSBIRFM3MjMwMiBBNUMwPiBGaXhlZCBEaXJlY3QgQWNjZXNzIFND U0ktNiBkZXZpY2UgCnBhc3M1OiBTZXJpYWwgTnVtYmVyICAgICAgIE1OMTIyMEYzMjgxNEhE CkdFT006IG5ldyBkaXNrIGRhMQpHRU9NOiBuZXcgZGlzayBkYTIKR0VPTTogbmV3IGRpc2sg ZGEzCkdFT006IG5ldyBkaXNrIGRhNApHRU9NOiBuZXcgZGlzayBkYTUKcGFzczU6IDYwMC4w MDBNQi9zIHRyYW5zZmVycwpwYXNzNTogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCnBhc3M2 IGF0IG1wczAgYnVzIDAgc2NidXMyIHRhcmdldCA0IGx1biAwCnBhc3M2OiA8QVRBIEhpdGFj aGkgSERTNzIzMDIgQTVDMD4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTYgZGV2aWNlIApw YXNzNjogU2VyaWFsIE51bWJlciAgICAgICBNTjEyMjBGMzI4MzU0RApwYXNzNjogNjAwLjAw ME1CL3MgdHJhbnNmZXJzCnBhc3M2OiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQKU01QOiBB UCBDUFUgIzEgTGF1bmNoZWQhCmNwdTEgQVA6CiAgICAgSUQ6IDB4MDEwMDAwMDAgICBWRVI6 IDB4MDAwNTAwMTUgTERSOiAweDAwMDAwMDAwIERGUjogMHhmZmZmZmZmZgogIGxpbnQwOiAw eDAwMDEwNzAwIGxpbnQxOiAweDAwMDAwNDAwIFRQUjogMHgwMDAwMDAwMCBTVlI6IDB4MDAw MDAxZmYKICB0aW1lcjogMHgwMDAxMDBlZiB0aGVybTogMHgwMDAxMDAwMCBlcnI6IDB4MDAw MDAwZjAgcG1jOiAweDAwMDEwNDAwClNNUDogQVAgQ1BVICMyIExhdW5jaGVkIQpjcHUyIEFQ OgogICAgIElEOiAweDAyMDAwMDAwICAgVkVSOiAweDAwMDUwMDE1IExEUjogMHgwMDAwMDAw MCBERlI6IDB4ZmZmZmZmZmYKICBsaW50MDogMHgwMDAxMDcwMCBsaW50MTogMHgwMDAwMDQw MCBUUFI6IDB4MDAwMDAwMDAgU1ZSOiAweDAwMDAwMWZmCiAgdGltZXI6IDB4MDAwMTAwZWYg dGhlcm06IDB4MDAwMTAwMDAgZXJyOiAweDAwMDAwMGYwIHBtYzogMHgwMDAxMDQwMApTTVA6 IEFQIENQVSAjMyBMYXVuY2hlZCEKY3B1MyBBUDoKICAgICBJRDogMHgwMzAwMDAwMCAgIFZF UjogMHgwMDA1MDAxNSBMRFI6IDB4MDAwMDAwMDAgREZSOiAweGZmZmZmZmZmCiAgbGludDA6 IDB4MDAwMTA3MDAgbGludDE6IDB4MDAwMDA0MDAgVFBSOiAweDAwMDAwMDAwIFNWUjogMHgw MDAwMDFmZgogIHRpbWVyOiAweDAwMDEwMGVmIHRoZXJtOiAweDAwMDEwMDAwIGVycjogMHgw MDAwMDBmMCBwbWM6IDB4MDAwMTA0MDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMSAoSVNB IElSUSAxKSB0byBsYXBpYyAxIHZlY3RvciA0OAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAz IChJU0EgSVJRIDMpIHRvIGxhcGljIDIgdmVjdG9yIDQ4CmlvYXBpYzA6IHJvdXRpbmcgaW50 cGluIDQgKElTQSBJUlEgNCkgdG8gbGFwaWMgMyB2ZWN0b3IgNDgKaW9hcGljMDogcm91dGlu ZyBpbnRwaW4gMTIgKElTQSBJUlEgMTIpIHRvIGxhcGljIDEgdmVjdG9yIDQ5CmlvYXBpYzA6 IHJvdXRpbmcgaW50cGluIDE0IChJU0EgSVJRIDE0KSB0byBsYXBpYyAyIHZlY3RvciA0OQpt c2k6IEFzc2lnbmluZyBNU0kgSVJRIDI1NiB0byBsb2NhbCBBUElDIDMgdmVjdG9yIDQ5Cm1z aTogQXNzaWduaW5nIE1TSS1YIElSUSAyNTggdG8gbG9jYWwgQVBJQyAxIHZlY3RvciA1MApt c2k6IEFzc2lnbmluZyBNU0ktWCBJUlEgMjU5IHRvIGxvY2FsIEFQSUMgMiB2ZWN0b3IgNTAK bXNpOiBBc3NpZ25pbmcgTVNJLVggSVJRIDI2MCB0byBsb2NhbCBBUElDIDMgdmVjdG9yIDUw ClRpbWVjb3VudGVyICJUU0MiIGZyZXF1ZW5jeSAzNDkyMDY3MDAwIEh6IHF1YWxpdHkgLTEw MApkYTQgYXQgbXBzMCBidXMgMCBzY2J1czIgdGFyZ2V0IDMgbHVuIDAKZGE0OiA8QVRBIEhp dGFjaGkgSERTNzIzMDIgQTVDMD4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTYgZGV2aWNl IApkYTQ6IFNlcmlhbCBOdW1iZXIgICAgICAgTU4xMjIwRjMyODE0SEQKZGE0OiA2MDAuMDAw TUIvcyB0cmFuc2ZlcnMKZGE0OiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQKZGE0OiAxOTA3 NzI5TUIgKDM5MDcwMjkxNjggNTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2M1MvVCAyNDMyMDFD KQpkYTUgYXQgbXBzMCBidXMgMCBzY2J1czIgdGFyZ2V0IDQgbHVuIDAKZGE1OiA8QVRBIEhp dGFjaGkgSERTNzIzMDIgQTVDMD4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTYgZGV2aWNl IApkYTU6IFNlcmlhbCBOdW1iZXIgICAgICAgTU4xMjIwRjMyODM1NEQKZGE1OiA2MDAuMDAw TUIvcyB0cmFuc2ZlcnMKZGE1OiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQKZGE1OiAxOTA3 NzI5TUIgKDM5MDcwMjkxNjggNTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2M1MvVCAyNDMyMDFD KQpUcnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHVmczovZGV2L2dwdC9mbGludFJPT1QgW3Jv XS4uLgpzdGFydF9pbml0OiB0cnlpbmcgL3NiaW4vaW5pdAo= --------------020508020906000204040408-- --------------enig9E41760E4C813310F94CC698 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) iEYEARECAAYFAlB9J+gACgkQLDqVQ9VXb8jp1wCfXieRdXQr8YyXeYtmLYurAzfH rJQAnRO8OS68O/S1EqGGOaiV1SQMK5yU =LfqK -----END PGP SIGNATURE----- --------------enig9E41760E4C813310F94CC698-- From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 10:29:48 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ACAC0A61; Tue, 16 Oct 2012 10:29:48 +0000 (UTC) (envelope-from wkoszek@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by mx1.freebsd.org (Postfix) with ESMTP id 321578FC1B; Tue, 16 Oct 2012 10:29:47 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by freebsd.czest.pl (8.14.5/8.14.5) with ESMTP id q9GAJvKR007057; Tue, 16 Oct 2012 10:19:57 GMT (envelope-from wkoszek@freebsd.czest.pl) Received: (from wkoszek@localhost) by freebsd.czest.pl (8.14.5/8.14.5/Submit) id q9GAJv5B007056; Tue, 16 Oct 2012 10:19:57 GMT (envelope-from wkoszek) Date: Tue, 16 Oct 2012 10:19:57 +0000 From: "Wojciech A. Koszek" To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org Subject: FreeBSD in Google Code-In 2012? You can help too! Message-ID: <20121016101957.GB53800@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (freebsd.czest.pl [212.87.224.105]); Tue, 16 Oct 2012 10:19:58 +0000 (UTC) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 10:29:48 -0000 (cross-posted message; please keep discussion on freebsd-hackers@) Hello, Last year FreeBSD qualified for Google Code-In 2011 event--contest for youngest open-source hackers in 13-17yr age range: http://www.google-melange.com/gci/homepage/google/gci2012 It was successful. We gained one more FreeBSD developer thanks to that (Isabell Long) We're pondering participating in the contest this year as well. For now we only have 25 ideas. We need at least 100. I felt all members of the FreeBSD community should help, so please submit your own Google Code-In 2012 ideas here: http://www.emailmeform.com/builder/form/4aU93Obxo4NYdVAgb1 Examples of previously completed tasks: http://wiki.freebsd.org/GoogleCodeIn/2011Tasks Those of you who have Wiki access, please spent 2 more minutes and submit straight to Wiki: http://wiki.freebsd.org/GoogleCodeIn/2012Tasks I plan to send out next e-mail if there's any progress on this project. Help will be appreciated. Thanks, -- Wojciech A. Koszek wkoszek@FreeBSD.czest.pl http://FreeBSD.czest.pl/~wkoszek/ From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 17:00:43 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1D9E966E; Tue, 16 Oct 2012 17:00:43 +0000 (UTC) (envelope-from wkoszek@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by mx1.freebsd.org (Postfix) with ESMTP id 938848FC16; Tue, 16 Oct 2012 17:00:42 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by freebsd.czest.pl (8.14.5/8.14.5) with ESMTP id q9GGopOU009154; Tue, 16 Oct 2012 16:50:51 GMT (envelope-from wkoszek@freebsd.czest.pl) Received: (from wkoszek@localhost) by freebsd.czest.pl (8.14.5/8.14.5/Submit) id q9GGopps009153; Tue, 16 Oct 2012 16:50:51 GMT (envelope-from wkoszek) Date: Tue, 16 Oct 2012 16:50:51 +0000 From: "Wojciech A. Koszek" To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: FreeBSD in Google Code-In 2012? You can help too! Message-ID: <20121016165051.GC53800@FreeBSD.org> References: <20121016101957.GB53800@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <20121016101957.GB53800@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (freebsd.czest.pl [212.87.224.105]); Tue, 16 Oct 2012 16:50:52 +0000 (UTC) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 17:00:43 -0000 On Tue, Oct 16, 2012 at 10:19:57AM +0000, Wojciech A. Koszek wrote: > (cross-posted message; please keep discussion on freebsd-hackers@) > > Hello, > > Last year FreeBSD qualified for Google Code-In 2011 event--contest for > youngest open-source hackers in 13-17yr age range: > > http://www.google-melange.com/gci/homepage/google/gci2012 > > It was successful. We gained one more FreeBSD developer thanks to that > (Isabell Long) We're pondering participating in the contest this year as > well. > > For now we only have 25 ideas. We need at least 100. > > I felt all members of the FreeBSD community should help, so please submit > your own Google Code-In 2012 ideas here: > > http://www.emailmeform.com/builder/form/4aU93Obxo4NYdVAgb1 > > Examples of previously completed tasks: > > http://wiki.freebsd.org/GoogleCodeIn/2011Tasks > > Those of you who have Wiki access, please spent 2 more minutes and submit > straight to Wiki: > > http://wiki.freebsd.org/GoogleCodeIn/2012Tasks > > I plan to send out next e-mail if there's any progress on this project. > > Help will be appreciated. Hi, (cross-posted message; please keep discussion on freebsd-hackers@) I made a mistake -- the web form didn't have "Contributor's name", thus I don't know who of you guys contributed first 9 ideas; e-mail me which ideas are yours, so that your name can be mentioned on Wiki: http://wiki.freebsd.org/GoogleCodeIn/2012Tasks I made slight adjustments to the form to make some fields more precise: http://www.emailmeform.com/builder/form/4aU93Obxo4NYdVAgb1 Sorry and thanks, -- Wojciech A. Koszek wkoszek@FreeBSD.czest.pl http://FreeBSD.czest.pl/~wkoszek/ From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 13:58:44 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B6FC01B8; Wed, 17 Oct 2012 13:58:44 +0000 (UTC) (envelope-from guy.helmer@gmail.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id 585628FC1C; Wed, 17 Oct 2012 13:58:44 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id k10so15445297iea.13 for ; Wed, 17 Oct 2012 06:58:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=uBkU6J6yz2QtLFjXXnukFNjQ++pfiG7l0wHcQUIVeEU=; b=EqBfrGxUafgz1idFOfr+iqdSMibRQdUJBVRzPbz6bk5oTqbJXkfkIwSlTXadzFEH7J sRW4tWqoLJFOjJr2Pj447JWP0E6bAhd0rVEI+EQKrdvSLpW90vKVWimNvPyK3CC6XAu6 TUmaNWN1lGyhz0IaQku2ALThX1wnbjQP9dRudkcwbcvdfv+vauG102Ob7f+5IkaLtVUk 5FafdIvi3y/szeR8VrCv7vBzdrOgrFHqlX4c+C8HisiYPQt4wGDCSGFmZ4DNYusNl79Y 0Q5eZC2OGZfkUoO5xTGA0QkZX2cQskEIzs6bjujnKLUZDiedSp2Bq4xP5aobf68KPwSt GRQg== Received: by 10.50.190.232 with SMTP id gt8mr1578197igc.69.1350482321182; Wed, 17 Oct 2012 06:58:41 -0700 (PDT) Received: from guysmbp.dyn.palisadesys.com ([216.81.189.9]) by mx.google.com with ESMTPS id az4sm3015212igb.2.2012.10.17.06.58.39 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 17 Oct 2012 06:58:40 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: 8.3: kernel panic in bpf.c catchpacket() From: Guy Helmer In-Reply-To: <1EDA1615-2CDE-405A-A725-AF7CC7D3E273@gmail.com> Date: Wed, 17 Oct 2012 08:58:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <381E3EEC-7EDB-428B-A724-434443E51A53@gmail.com> References: <4B5399BF-4EE0-4182-8297-3BB97C4AA884@gmail.com> <59F9A36E-3DB2-4F6F-BB2A-A4C9DA76A70C@gmail.com> <5075C05E.9070800@FreeBSD.org> <1EDA1615-2CDE-405A-A725-AF7CC7D3E273@gmail.com> To: "Alexander V. Chernikov" X-Mailer: Apple Mail (2.1499) Cc: freebsd-net@freebsd.org, FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 13:58:44 -0000 On Oct 12, 2012, at 8:54 AM, Guy Helmer wrote: >=20 > On Oct 10, 2012, at 1:37 PM, Alexander V. Chernikov = wrote: >=20 >> On 10.10.2012 00:36, Guy Helmer wrote: >>>=20 >>> On Oct 8, 2012, at 8:09 AM, Guy Helmer wrote: >>>=20 >>>> I'm seeing a consistent new kernel panic in FreeBSD 8.3: >>>> I'm not seeing how bd_sbuf would be NULL here. Any ideas? >>>=20 >>> Since I've not had any replies, I hope nobody minds if I reply with = more information. >>>=20 >>> This panic seems to be occasionally triggered now that my user land = code is changing the packet filter a while after the bpd device has been = opened and an initial packet filter was set (previously, my code did not = change the filter after it was initially set). >>>=20 >>> I'm focusing on bpf_setf() since that seems to be the place that = could be tickling a problem, and I see that bpf_setf() calls reset_d(d) = to clear the hold buffer. I have manually verified that the BPFD lock is = held during the call to reset_d(), and the lock is held every other = place that the buffers are manipulated, so I haven't been able to find = any place that seems vulnerable to losing one of the bpf buffers. Still = searching, but any help would be appreciated. >>=20 >> Can you please check this code on -current? >> Locking has changed quite significantly some time ago, so there is = good chance that you can get rid of this panic (or discover different = one which is really "new") :). >=20 > I'm not ready to run this app on current, so I have merged revs = 229898, 233937, 233938, 233946, 235744, 235745, 235746, 235747, 236231, = 236251, 236261, 236262, 236559, and 236806 to my 8.3 checkout to get = code that should be virtually identical to current without the timestamp = changes. >=20 > Unfortunately, I have only been able to trigger the panic in my test = lab once -- so I'm not sure whether a lack of problems with the updated = code will be indicative of likely success in the field where this has = been trigged regularly at some sites=85 >=20 > Thanks, > Guy >=20 FWIW, I was able to trigger the panic with the original 8.3 code again = in my test lab. With these changes resulting from merging the revs = mentioned above, I have not seen any panics in my test lab setup in two = days of load testing, and AFAIK, packet capturing seems to be working = fine. I've included the diffs for reference for anyone encountering the issue. Thanks, Alexander! Guy Index: net/bpf.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- net/bpf.c (revision 239830) +++ net/bpf.c (working copy) @@ -43,6 +43,8 @@ =20 #include #include +#include +#include #include #include #include @@ -66,6 +68,7 @@ #include =20 #include +#define BPF_INTERNAL #include #include #ifdef BPF_JITTER @@ -139,6 +142,7 @@ =20 static void bpf_attachd(struct bpf_d *, struct bpf_if *); static void bpf_detachd(struct bpf_d *); +static void bpf_detachd_locked(struct bpf_d *); static void bpf_freed(struct bpf_d *); static int bpf_movein(struct uio *, int, struct ifnet *, struct = mbuf **, struct sockaddr *, int *, struct bpf_insn *); @@ -150,7 +154,7 @@ void (*)(struct bpf_d *, caddr_t, u_int, void *, = u_int), struct timeval *); static void reset_d(struct bpf_d *); -static int bpf_setf(struct bpf_d *, struct bpf_program *, u_long = cmd); +static int bpf_setf(struct bpf_d *, struct bpf_program *, u_long = cmd); static int bpf_getdltlist(struct bpf_d *, struct bpf_dltlist *); static int bpf_setdlt(struct bpf_d *, u_int); static void filt_bpfdetach(struct knote *); @@ -168,6 +172,12 @@ SYSCTL_NODE(_net_bpf, OID_AUTO, stats, CTLFLAG_MPSAFE | CTLFLAG_RW, bpf_stats_sysctl, "bpf statistics portal"); =20 +static VNET_DEFINE(int, bpf_optimize_writers) =3D 0; +#define V_bpf_optimize_writers VNET(bpf_optimize_writers) +SYSCTL_VNET_INT(_net_bpf, OID_AUTO, optimize_writers, + CTLFLAG_RW, &VNET_NAME(bpf_optimize_writers), 0, + "Do not send packets until BPF program is set"); + static d_open_t bpfopen; static d_read_t bpfread; static d_write_t bpfwrite; @@ -189,7 +199,38 @@ static struct filterops bpfread_filtops =3D { 1, NULL, filt_bpfdetach, filt_bpfread }; =20 +eventhandler_tag bpf_ifdetach_cookie =3D NULL; + /* + * LOCKING MODEL USED BY BPF: + * Locks: + * 1) global lock (BPF_LOCK). Mutex, used to protect interface = addition/removal, + * some global counters and every bpf_if reference. + * 2) Interface lock. Rwlock, used to protect list of BPF descriptors = and their filters. + * 3) Descriptor lock. Mutex, used to protect BPF buffers and various = structure fields + * used by bpf_mtap code. + * + * Lock order: + * + * Global lock, interface lock, descriptor lock + * + * We have to acquire interface lock before descriptor main lock due to = BPF_MTAP[2] + * working model. In many places (like bpf_detachd) we start with BPF = descriptor + * (and we need to at least rlock it to get reliable interface = pointer). This + * gives us potential LOR. As a result, we use global lock to protect = from bpf_if + * change in every such place. + * + * Changing d->bd_bif is protected by 1) global lock, 2) interface lock = and + * 3) descriptor main wlock. + * Reading bd_bif can be protected by any of these locks, typically = global lock. + * + * Changing read/write BPF filter is protected by the same three locks, + * the same applies for reading. + * + * Sleeping in global lock is not allowed due to bpfdetach() using it. + */ + +/* * Wrapper functions for various buffering methods. If the set of = buffer * modes expands, we will probably want to introduce a switch data = structure * similar to protosw, et. @@ -282,7 +323,6 @@ static int bpf_canwritebuf(struct bpf_d *d) { - BPFD_LOCK_ASSERT(d); =20 switch (d->bd_bufmode) { @@ -561,18 +601,93 @@ static void bpf_attachd(struct bpf_d *d, struct bpf_if *bp) { + int op_w; + + BPF_LOCK_ASSERT(); + /* - * Point d at bp, and add d to the interface's list of = listeners. - * Finally, point the driver's bpf cookie at the interface so - * it will divert packets to bpf. + * Save sysctl value to protect from sysctl change + * between reads */ - BPFIF_LOCK(bp); + op_w =3D V_bpf_optimize_writers; + + if (d->bd_bif !=3D NULL) + bpf_detachd_locked(d); + /* + * Point d at bp, and add d to the interface's list. + * Since there are many applicaiotns using BPF for + * sending raw packets only (dhcpd, cdpd are good examples) + * we can delay adding d to the list of active listeners until + * some filter is configured. + */ + + BPFIF_WLOCK(bp); + BPFD_LOCK(d); + d->bd_bif =3D bp; - LIST_INSERT_HEAD(&bp->bif_dlist, d, bd_next); =20 + if (op_w !=3D 0) { + /* Add to writers-only list */ + LIST_INSERT_HEAD(&bp->bif_wlist, d, bd_next); + /* + * We decrement bd_writer on every filter set operation. + * First BIOCSETF is done by pcap_open_live() to set up + * snap length. After that appliation usually sets its = own filter + */ + d->bd_writer =3D 2; + } else + LIST_INSERT_HEAD(&bp->bif_dlist, d, bd_next); + + BPFD_UNLOCK(d); + BPFIF_WUNLOCK(bp); + bpf_bpfd_cnt++; - BPFIF_UNLOCK(bp); =20 + CTR3(KTR_NET, "%s: bpf_attach called by pid %d, adding to %s = list", + __func__, d->bd_pid, d->bd_writer ? "writer" : "active"); + + if (op_w =3D=3D 0) + EVENTHANDLER_INVOKE(bpf_track, bp->bif_ifp, bp->bif_dlt, = 1); +} + +/* + * Add d to the list of active bp filters. + * Reuqires bpf_attachd() to be called before + */ +static void +bpf_upgraded(struct bpf_d *d) +{ + struct bpf_if *bp; + + BPF_LOCK_ASSERT(); + + bp =3D d->bd_bif; + + /* + * Filter can be set several times without specifying interface. + * Mark d as reader and exit. + */ + if (bp =3D=3D NULL) { + BPFD_LOCK(d); + d->bd_writer =3D 0; + BPFD_UNLOCK(d); + return; + } + + BPFIF_WLOCK(bp); + BPFD_LOCK(d); + + /* Remove from writers-only list */ + LIST_REMOVE(d, bd_next); + LIST_INSERT_HEAD(&bp->bif_dlist, d, bd_next); + /* Mark d as reader */ + d->bd_writer =3D 0; + + BPFD_UNLOCK(d); + BPFIF_WUNLOCK(bp); + + CTR2(KTR_NET, "%s: upgrade required by pid %d", __func__, = d->bd_pid); + EVENTHANDLER_INVOKE(bpf_track, bp->bif_ifp, bp->bif_dlt, 1); } =20 @@ -582,27 +697,48 @@ static void bpf_detachd(struct bpf_d *d) { + BPF_LOCK(); + bpf_detachd_locked(d); + BPF_UNLOCK(); +} + +static void +bpf_detachd_locked(struct bpf_d *d) +{ int error; struct bpf_if *bp; struct ifnet *ifp; =20 - bp =3D d->bd_bif; - BPFIF_LOCK(bp); + CTR2(KTR_NET, "%s: detach required by pid %d", __func__, = d->bd_pid); + + BPF_LOCK_ASSERT(); + + /* Check if descriptor is attached */ + if ((bp =3D d->bd_bif) =3D=3D NULL) + return; + + BPFIF_WLOCK(bp); BPFD_LOCK(d); - ifp =3D d->bd_bif->bif_ifp; =20 + /* Save bd_writer value */ + error =3D d->bd_writer; + /* * Remove d from the interface's descriptor list. */ LIST_REMOVE(d, bd_next); =20 - bpf_bpfd_cnt--; + ifp =3D bp->bif_ifp; d->bd_bif =3D NULL; BPFD_UNLOCK(d); - BPFIF_UNLOCK(bp); + BPFIF_WUNLOCK(bp); =20 - EVENTHANDLER_INVOKE(bpf_track, ifp, bp->bif_dlt, 0); + bpf_bpfd_cnt--; =20 + /* Call event handler iff d is attached */ + if (error =3D=3D 0) + EVENTHANDLER_INVOKE(bpf_track, ifp, bp->bif_dlt, 0); + /* * Check if this descriptor had requested promiscuous mode. * If so, turn it off. @@ -640,10 +776,7 @@ d->bd_state =3D BPF_IDLE; BPFD_UNLOCK(d); funsetown(&d->bd_sigio); - mtx_lock(&bpf_mtx); - if (d->bd_bif) - bpf_detachd(d); - mtx_unlock(&bpf_mtx); + bpf_detachd(d); #ifdef MAC mac_bpfdesc_destroy(d); #endif /* MAC */ @@ -663,7 +796,7 @@ bpfopen(struct cdev *dev, int flags, int fmt, struct thread *td) { struct bpf_d *d; - int error; + int error, size; =20 d =3D malloc(sizeof(*d), M_BPF, M_WAITOK | M_ZERO); error =3D devfs_set_cdevpriv(d, bpf_dtor); @@ -681,15 +814,19 @@ d->bd_bufmode =3D BPF_BUFMODE_BUFFER; d->bd_sig =3D SIGIO; d->bd_direction =3D BPF_D_INOUT; - d->bd_pid =3D td->td_proc->p_pid; + BPF_PID_REFRESH(d, td); #ifdef MAC mac_bpfdesc_init(d); mac_bpfdesc_create(td->td_ucred, d); #endif - mtx_init(&d->bd_mtx, devtoname(dev), "bpf cdev lock", MTX_DEF); - callout_init_mtx(&d->bd_callout, &d->bd_mtx, 0); - knlist_init_mtx(&d->bd_sel.si_note, &d->bd_mtx); + mtx_init(&d->bd_lock, devtoname(dev), "bpf cdev lock", MTX_DEF); + callout_init_mtx(&d->bd_callout, &d->bd_lock, 0); + knlist_init_mtx(&d->bd_sel.si_note, &d->bd_lock); =20 + /* Allocate default buffers */ + size =3D d->bd_bufsize; + bpf_buffer_ioctl_sblen(d, &size); + return (0); } =20 @@ -718,7 +855,7 @@ non_block =3D ((ioflag & O_NONBLOCK) !=3D 0); =20 BPFD_LOCK(d); - d->bd_pid =3D curthread->td_proc->p_pid; + BPF_PID_REFRESH_CUR(d); if (d->bd_bufmode !=3D BPF_BUFMODE_BUFFER) { BPFD_UNLOCK(d); return (EOPNOTSUPP); @@ -764,7 +901,7 @@ BPFD_UNLOCK(d); return (EWOULDBLOCK); } - error =3D msleep(d, &d->bd_mtx, PRINET|PCATCH, + error =3D msleep(d, &d->bd_lock, PRINET|PCATCH, "bpf", d->bd_rtout); if (error =3D=3D EINTR || error =3D=3D ERESTART) { BPFD_UNLOCK(d); @@ -881,8 +1018,9 @@ if (error !=3D 0) return (error); =20 - d->bd_pid =3D curthread->td_proc->p_pid; + BPF_PID_REFRESH_CUR(d); d->bd_wcount++; + /* XXX: locking required */ if (d->bd_bif =3D=3D NULL) { d->bd_wdcount++; return (ENXIO); @@ -903,6 +1041,7 @@ bzero(&dst, sizeof(dst)); m =3D NULL; hlen =3D 0; + /* XXX: bpf_movein() can sleep */ error =3D bpf_movein(uio, (int)d->bd_bif->bif_dlt, ifp, &m, &dst, &hlen, d->bd_wfilter); if (error) { @@ -962,7 +1101,7 @@ reset_d(struct bpf_d *d) { =20 - mtx_assert(&d->bd_mtx, MA_OWNED); + BPFD_LOCK_ASSERT(d); =20 if ((d->bd_hbuf !=3D NULL) && (d->bd_bufmode !=3D BPF_BUFMODE_ZBUF || bpf_canfreebuf(d))) = { @@ -1028,7 +1167,7 @@ * Refresh PID associated with this descriptor. */ BPFD_LOCK(d); - d->bd_pid =3D td->td_proc->p_pid; + BPF_PID_REFRESH(d, td); if (d->bd_state =3D=3D BPF_WAITING) callout_stop(&d->bd_callout); d->bd_state =3D BPF_IDLE; @@ -1079,7 +1218,9 @@ case BIOCGDLTLIST32: case BIOCGRTIMEOUT32: case BIOCSRTIMEOUT32: + BPFD_LOCK(d); d->bd_compat32 =3D 1; + BPFD_UNLOCK(d); } #endif =20 @@ -1124,7 +1265,9 @@ * Get buffer len [for read()]. */ case BIOCGBLEN: + BPFD_LOCK(d); *(u_int *)addr =3D d->bd_bufsize; + BPFD_UNLOCK(d); break; =20 /* @@ -1179,10 +1322,12 @@ * Get current data link type. */ case BIOCGDLT: + BPF_LOCK(); if (d->bd_bif =3D=3D NULL) error =3D EINVAL; else *(u_int *)addr =3D d->bd_bif->bif_dlt; + BPF_UNLOCK(); break; =20 /* @@ -1197,6 +1342,7 @@ list32 =3D (struct bpf_dltlist32 *)addr; dltlist.bfl_len =3D list32->bfl_len; dltlist.bfl_list =3D PTRIN(list32->bfl_list); + BPF_LOCK(); if (d->bd_bif =3D=3D NULL) error =3D EINVAL; else { @@ -1204,31 +1350,37 @@ if (error =3D=3D 0) list32->bfl_len =3D = dltlist.bfl_len; } + BPF_UNLOCK(); break; } #endif =20 case BIOCGDLTLIST: + BPF_LOCK(); if (d->bd_bif =3D=3D NULL) error =3D EINVAL; else error =3D bpf_getdltlist(d, (struct bpf_dltlist = *)addr); + BPF_UNLOCK(); break; =20 /* * Set data link type. */ case BIOCSDLT: + BPF_LOCK(); if (d->bd_bif =3D=3D NULL) error =3D EINVAL; else error =3D bpf_setdlt(d, *(u_int *)addr); + BPF_UNLOCK(); break; =20 /* * Get interface name. */ case BIOCGETIF: + BPF_LOCK(); if (d->bd_bif =3D=3D NULL) error =3D EINVAL; else { @@ -1238,13 +1390,16 @@ strlcpy(ifr->ifr_name, ifp->if_xname, sizeof(ifr->ifr_name)); } + BPF_UNLOCK(); break; =20 /* * Set interface. */ case BIOCSETIF: + BPF_LOCK(); error =3D bpf_setif(d, (struct ifreq *)addr); + BPF_UNLOCK(); break; =20 /* @@ -1327,7 +1482,9 @@ * Set immediate mode. */ case BIOCIMMEDIATE: + BPFD_LOCK(d); d->bd_immediate =3D *(u_int *)addr; + BPFD_UNLOCK(d); break; =20 case BIOCVERSION: @@ -1343,21 +1500,27 @@ * Get "header already complete" flag */ case BIOCGHDRCMPLT: + BPFD_LOCK(d); *(u_int *)addr =3D d->bd_hdrcmplt; + BPFD_UNLOCK(d); break; =20 /* * Set "header already complete" flag */ case BIOCSHDRCMPLT: + BPFD_LOCK(d); d->bd_hdrcmplt =3D *(u_int *)addr ? 1 : 0; + BPFD_UNLOCK(d); break; =20 /* * Get packet direction flag */ case BIOCGDIRECTION: + BPFD_LOCK(d); *(u_int *)addr =3D d->bd_direction; + BPFD_UNLOCK(d); break; =20 /* @@ -1372,7 +1535,9 @@ case BPF_D_IN: case BPF_D_INOUT: case BPF_D_OUT: + BPFD_LOCK(d); d->bd_direction =3D direction; + BPFD_UNLOCK(d); break; default: error =3D EINVAL; @@ -1381,26 +1546,38 @@ break; =20 case BIOCFEEDBACK: + BPFD_LOCK(d); d->bd_feedback =3D *(u_int *)addr; + BPFD_UNLOCK(d); break; =20 case BIOCLOCK: + BPFD_LOCK(d); d->bd_locked =3D 1; + BPFD_UNLOCK(d); break; =20 case FIONBIO: /* Non-blocking I/O */ break; =20 case FIOASYNC: /* Send signal on receive packets */ + BPFD_LOCK(d); d->bd_async =3D *(int *)addr; + BPFD_UNLOCK(d); break; =20 case FIOSETOWN: + /* + * XXX: Add some sort of locking here? + * fsetown() can sleep. + */ error =3D fsetown(*(int *)addr, &d->bd_sigio); break; =20 case FIOGETOWN: + BPFD_LOCK(d); *(int *)addr =3D fgetown(&d->bd_sigio); + BPFD_UNLOCK(d); break; =20 /* This is deprecated, FIOSETOWN should be used instead. */ @@ -1421,16 +1598,23 @@ =20 if (sig >=3D NSIG) error =3D EINVAL; - else + else { + BPFD_LOCK(d); d->bd_sig =3D sig; + BPFD_UNLOCK(d); + } break; } case BIOCGRSIG: + BPFD_LOCK(d); *(u_int *)addr =3D d->bd_sig; + BPFD_UNLOCK(d); break; =20 case BIOCGETBUFMODE: + BPFD_LOCK(d); *(u_int *)addr =3D d->bd_bufmode; + BPFD_UNLOCK(d); break; =20 case BIOCSETBUFMODE: @@ -1485,95 +1669,130 @@ /* * Set d's packet filter program to fp. If this file already has a = filter, * free it and replace it. Returns EINVAL for bogus requests. + * + * Note we need global lock here to serialize bpf_setf() and = bpf_setif() calls + * since reading d->bd_bif can't be protected by d or interface lock = due to + * lock order. + * + * Additionally, we have to acquire interface write lock due to = bpf_mtap() uses + * interface read lock to read all filers. + * */ static int bpf_setf(struct bpf_d *d, struct bpf_program *fp, u_long cmd) { +#ifdef COMPAT_FREEBSD32 + struct bpf_program fp_swab; + struct bpf_program32 *fp32; +#endif struct bpf_insn *fcode, *old; - u_int wfilter, flen, size; #ifdef BPF_JITTER - bpf_jit_filter *ofunc; + bpf_jit_filter *jfunc, *ofunc; #endif + size_t size; + u_int flen; + int need_upgrade; + #ifdef COMPAT_FREEBSD32 - struct bpf_program32 *fp32; - struct bpf_program fp_swab; - - if (cmd =3D=3D BIOCSETWF32 || cmd =3D=3D BIOCSETF32 || cmd =3D=3D = BIOCSETFNR32) { + switch (cmd) { + case BIOCSETF32: + case BIOCSETWF32: + case BIOCSETFNR32: fp32 =3D (struct bpf_program32 *)fp; fp_swab.bf_len =3D fp32->bf_len; fp_swab.bf_insns =3D (struct bpf_insn = *)(uintptr_t)fp32->bf_insns; fp =3D &fp_swab; - if (cmd =3D=3D BIOCSETWF32) + switch (cmd) { + case BIOCSETF32: + cmd =3D BIOCSETF; + break; + case BIOCSETWF32: cmd =3D BIOCSETWF; + break; + } + break; } #endif - if (cmd =3D=3D BIOCSETWF) { - old =3D d->bd_wfilter; - wfilter =3D 1; + + fcode =3D NULL; #ifdef BPF_JITTER - ofunc =3D NULL; + jfunc =3D ofunc =3D NULL; #endif - } else { - wfilter =3D 0; - old =3D d->bd_rfilter; -#ifdef BPF_JITTER - ofunc =3D d->bd_bfilter; -#endif - } - if (fp->bf_insns =3D=3D NULL) { - if (fp->bf_len !=3D 0) + need_upgrade =3D 0; + + /* + * Check new filter validness before acquiring any locks. + * Allocate memory for new filter, if needed. + */ + flen =3D fp->bf_len; + if (flen > bpf_maxinsns || (fp->bf_insns =3D=3D NULL && flen !=3D = 0)) + return (EINVAL); + size =3D flen * sizeof(*fp->bf_insns); + if (size > 0) { + /* We're setting up new filter. Copy and check actual = data. */ + fcode =3D malloc(size, M_BPF, M_WAITOK); + if (copyin(fp->bf_insns, fcode, size) !=3D 0 || + !bpf_validate(fcode, flen)) { + free(fcode, M_BPF); return (EINVAL); - BPFD_LOCK(d); - if (wfilter) - d->bd_wfilter =3D NULL; - else { - d->bd_rfilter =3D NULL; -#ifdef BPF_JITTER - d->bd_bfilter =3D NULL; -#endif - if (cmd =3D=3D BIOCSETF) - reset_d(d); } - BPFD_UNLOCK(d); - if (old !=3D NULL) - free((caddr_t)old, M_BPF); #ifdef BPF_JITTER - if (ofunc !=3D NULL) - bpf_destroy_jit_filter(ofunc); + /* Filter is copied inside fcode and is perfectly valid. = */ + jfunc =3D bpf_jitter(fcode, flen); #endif - return (0); } - flen =3D fp->bf_len; - if (flen > bpf_maxinsns) - return (EINVAL); =20 - size =3D flen * sizeof(*fp->bf_insns); - fcode =3D (struct bpf_insn *)malloc(size, M_BPF, M_WAITOK); - if (copyin((caddr_t)fp->bf_insns, (caddr_t)fcode, size) =3D=3D 0 = && - bpf_validate(fcode, (int)flen)) { - BPFD_LOCK(d); - if (wfilter) - d->bd_wfilter =3D fcode; - else { - d->bd_rfilter =3D fcode; + BPF_LOCK(); + + /* + * Set up new filter. + * Protect filter change by interface lock. + * Additionally, we are protected by global lock here. + */ + if (d->bd_bif !=3D NULL) + BPFIF_WLOCK(d->bd_bif); + BPFD_LOCK(d); + if (cmd =3D=3D BIOCSETWF) { + old =3D d->bd_wfilter; + d->bd_wfilter =3D fcode; + } else { + old =3D d->bd_rfilter; + d->bd_rfilter =3D fcode; #ifdef BPF_JITTER - d->bd_bfilter =3D bpf_jitter(fcode, flen); + ofunc =3D d->bd_bfilter; + d->bd_bfilter =3D jfunc; #endif - if (cmd =3D=3D BIOCSETF) - reset_d(d); + if (cmd =3D=3D BIOCSETF) + reset_d(d); + + if (fcode !=3D NULL) { + /* + * Do not require upgrade by first BIOCSETF + * (used to set snaplen) by pcap_open_live(). + */ + if (d->bd_writer !=3D 0 && --d->bd_writer =3D=3D = 0) + need_upgrade =3D 1; + CTR4(KTR_NET, "%s: filter function set by pid = %d, " + "bd_writer counter %d, need_upgrade %d", + __func__, d->bd_pid, d->bd_writer, = need_upgrade); } - BPFD_UNLOCK(d); - if (old !=3D NULL) - free((caddr_t)old, M_BPF); + } + BPFD_UNLOCK(d); + if (d->bd_bif !=3D NULL) + BPFIF_WUNLOCK(d->bd_bif); + if (old !=3D NULL) + free(old, M_BPF); #ifdef BPF_JITTER - if (ofunc !=3D NULL) - bpf_destroy_jit_filter(ofunc); + if (ofunc !=3D NULL) + bpf_destroy_jit_filter(ofunc); #endif =20 - return (0); - } - free((caddr_t)fcode, M_BPF); - return (EINVAL); + /* Move d to active readers list. */ + if (need_upgrade) + bpf_upgraded(d); + + BPF_UNLOCK(); + return (0); } =20 /* @@ -1587,28 +1806,30 @@ struct bpf_if *bp; struct ifnet *theywant; =20 + BPF_LOCK_ASSERT(); + theywant =3D ifunit(ifr->ifr_name); if (theywant =3D=3D NULL || theywant->if_bpf =3D=3D NULL) return (ENXIO); =20 bp =3D theywant->if_bpf; =20 + /* Check if interface is not being detached from BPF */ + BPFIF_RLOCK(bp); + if (bp->flags & BPFIF_FLAG_DYING) { + BPFIF_RUNLOCK(bp); + return (ENXIO); + } + BPFIF_RUNLOCK(bp); + /* * Behavior here depends on the buffering model. If we're using * kernel memory buffers, then we can allocate them here. If = we're * using zero-copy, then the user process must have registered * buffers by the time we get here. If not, return an error. - * - * XXXRW: There are locking issues here with multi-threaded use: = what - * if two threads try to set the interface at once? */ switch (d->bd_bufmode) { case BPF_BUFMODE_BUFFER: - if (d->bd_sbuf =3D=3D NULL) - bpf_buffer_alloc(d); - KASSERT(d->bd_sbuf !=3D NULL, ("bpf_setif: bd_sbuf = NULL")); - break; - case BPF_BUFMODE_ZBUF: if (d->bd_sbuf =3D=3D NULL) return (EINVAL); @@ -1617,15 +1838,8 @@ default: panic("bpf_setif: bufmode %d", d->bd_bufmode); } - if (bp !=3D d->bd_bif) { - if (d->bd_bif) - /* - * Detach if attached to something else. - */ - bpf_detachd(d); - + if (bp !=3D d->bd_bif) bpf_attachd(d, bp); - } BPFD_LOCK(d); reset_d(d); BPFD_UNLOCK(d); @@ -1653,7 +1867,7 @@ */ revents =3D events & (POLLOUT | POLLWRNORM); BPFD_LOCK(d); - d->bd_pid =3D td->td_proc->p_pid; + BPF_PID_REFRESH(d, td); if (events & (POLLIN | POLLRDNORM)) { if (bpf_ready(d)) revents |=3D events & (POLLIN | POLLRDNORM); @@ -1688,7 +1902,7 @@ * Refresh PID associated with this descriptor. */ BPFD_LOCK(d); - d->bd_pid =3D curthread->td_proc->p_pid; + BPF_PID_REFRESH_CUR(d); kn->kn_fop =3D &bpfread_filtops; kn->kn_hook =3D d; knlist_add(&d->bd_sel.si_note, kn, 1); @@ -1744,9 +1958,19 @@ struct timeval tv; =20 gottime =3D 0; - BPFIF_LOCK(bp); + + BPFIF_RLOCK(bp); + LIST_FOREACH(d, &bp->bif_dlist, bd_next) { - BPFD_LOCK(d); + /* + * We are not using any locks for d here because: + * 1) any filter change is protected by interface + * write lock + * 2) destroying/detaching d is protected by interface + * write lock, too + */ + + /* XXX: Do not protect counter for the sake of = performance. */ ++d->bd_rcount; /* * NB: We dont call BPF_CHECK_DIRECTION() here since = there is no @@ -1762,6 +1986,11 @@ #endif slen =3D bpf_filter(d->bd_rfilter, pkt, pktlen, pktlen); if (slen !=3D 0) { + /* + * Filter matches. Let's to acquire write lock. + */ + BPFD_LOCK(d); + d->bd_fcount++; if (!gottime) { microtime(&tv); @@ -1772,10 +2001,10 @@ #endif catchpacket(d, pkt, pktlen, slen, bpf_append_bytes, &tv); + BPFD_UNLOCK(d); } - BPFD_UNLOCK(d); } - BPFIF_UNLOCK(bp); + BPFIF_RUNLOCK(bp); } =20 #define BPF_CHECK_DIRECTION(d, r, i) = \ @@ -1784,6 +2013,7 @@ =20 /* * Incoming linkage from device drivers, when packet is in an mbuf = chain. + * Locking model is explained in bpf_tap(). */ void bpf_mtap(struct bpf_if *bp, struct mbuf *m) @@ -1806,11 +2036,11 @@ =20 pktlen =3D m_length(m, NULL); =20 - BPFIF_LOCK(bp); + BPFIF_RLOCK(bp); + LIST_FOREACH(d, &bp->bif_dlist, bd_next) { if (BPF_CHECK_DIRECTION(d, m->m_pkthdr.rcvif, = bp->bif_ifp)) continue; - BPFD_LOCK(d); ++d->bd_rcount; #ifdef BPF_JITTER bf =3D bpf_jitter_enable !=3D 0 ? d->bd_bfilter : NULL; @@ -1821,6 +2051,8 @@ #endif slen =3D bpf_filter(d->bd_rfilter, (u_char *)m, pktlen, = 0); if (slen !=3D 0) { + BPFD_LOCK(d); + d->bd_fcount++; if (!gottime) { microtime(&tv); @@ -1831,10 +2063,10 @@ #endif catchpacket(d, (u_char *)m, pktlen, = slen, bpf_append_mbuf, &tv); + BPFD_UNLOCK(d); } - BPFD_UNLOCK(d); } - BPFIF_UNLOCK(bp); + BPFIF_RUNLOCK(bp); } =20 /* @@ -1869,14 +2101,17 @@ mb.m_len =3D dlen; pktlen +=3D dlen; =20 - BPFIF_LOCK(bp); + + BPFIF_RLOCK(bp); + LIST_FOREACH(d, &bp->bif_dlist, bd_next) { if (BPF_CHECK_DIRECTION(d, m->m_pkthdr.rcvif, = bp->bif_ifp)) continue; - BPFD_LOCK(d); ++d->bd_rcount; slen =3D bpf_filter(d->bd_rfilter, (u_char *)&mb, = pktlen, 0); if (slen !=3D 0) { + BPFD_LOCK(d); + d->bd_fcount++; if (!gottime) { microtime(&tv); @@ -1887,10 +2122,10 @@ #endif catchpacket(d, (u_char *)&mb, pktlen, = slen, bpf_append_mbuf, &tv); + BPFD_UNLOCK(d); } - BPFD_UNLOCK(d); } - BPFIF_UNLOCK(bp); + BPFIF_RUNLOCK(bp); } =20 #undef BPF_CHECK_DIRECTION @@ -2040,7 +2275,7 @@ } if (d->bd_wfilter !=3D NULL) free((caddr_t)d->bd_wfilter, M_BPF); - mtx_destroy(&d->bd_mtx); + mtx_destroy(&d->bd_lock); } =20 /* @@ -2070,15 +2305,16 @@ panic("bpfattach"); =20 LIST_INIT(&bp->bif_dlist); + LIST_INIT(&bp->bif_wlist); bp->bif_ifp =3D ifp; bp->bif_dlt =3D dlt; - mtx_init(&bp->bif_mtx, "bpf interface lock", NULL, MTX_DEF); + rw_init(&bp->bif_lock, "bpf interface lock"); KASSERT(*driverp =3D=3D NULL, ("bpfattach2: driverp already = initialized")); *driverp =3D bp; =20 - mtx_lock(&bpf_mtx); + BPF_LOCK(); LIST_INSERT_HEAD(&bpf_iflist, bp, bif_next); - mtx_unlock(&bpf_mtx); + BPF_UNLOCK(); =20 /* * Compute the length of the bpf header. This is not = necessarily @@ -2093,10 +2329,9 @@ } =20 /* - * Detach bpf from an interface. This involves detaching each = descriptor - * associated with the interface, and leaving bd_bif NULL. Notify each - * descriptor as it's detached so that any sleepers wake up and get - * ENXIO. + * Detach bpf from an interface. This involves detaching each = descriptor + * associated with the interface. Notify each descriptor as it's = detached + * so that any sleepers wake up and get ENXIO. */ void bpfdetach(struct ifnet *ifp) @@ -2109,31 +2344,45 @@ ndetached =3D 0; #endif =20 + BPF_LOCK(); /* Find all bpf_if struct's which reference ifp and detach them. = */ do { - mtx_lock(&bpf_mtx); LIST_FOREACH(bp, &bpf_iflist, bif_next) { if (ifp =3D=3D bp->bif_ifp) break; } if (bp !=3D NULL) LIST_REMOVE(bp, bif_next); - mtx_unlock(&bpf_mtx); =20 if (bp !=3D NULL) { #ifdef INVARIANTS ndetached++; #endif while ((d =3D LIST_FIRST(&bp->bif_dlist)) !=3D = NULL) { - bpf_detachd(d); + bpf_detachd_locked(d); BPFD_LOCK(d); bpf_wakeup(d); BPFD_UNLOCK(d); } - mtx_destroy(&bp->bif_mtx); - free(bp, M_BPF); + /* Free writer-only descriptors */ + while ((d =3D LIST_FIRST(&bp->bif_wlist)) !=3D = NULL) { + bpf_detachd_locked(d); + BPFD_LOCK(d); + bpf_wakeup(d); + BPFD_UNLOCK(d); + } + + /* + * Delay freing bp till interface is detached + * and all routes through this interface are = removed. + * Mark bp as detached to restrict new = consumers. + */ + BPFIF_WLOCK(bp); + bp->flags |=3D BPFIF_FLAG_DYING; + BPFIF_WUNLOCK(bp); } } while (bp !=3D NULL); + BPF_UNLOCK(); =20 #ifdef INVARIANTS if (ndetached =3D=3D 0) @@ -2142,6 +2391,37 @@ } =20 /* + * Interface departure handler. + * Note departure event does not guarantee interface is going down. + */ +static void +bpf_ifdetach(void *arg __unused, struct ifnet *ifp) +{ + struct bpf_if *bp; + + BPF_LOCK(); + if ((bp =3D ifp->if_bpf) =3D=3D NULL) { + BPF_UNLOCK(); + return; + } + + /* Check if bpfdetach() was called previously */ + if ((bp->flags & BPFIF_FLAG_DYING) =3D=3D 0) { + BPF_UNLOCK(); + return; + } + + CTR3(KTR_NET, "%s: freing BPF instance %p for interface %p", + __func__, bp, ifp); + + ifp->if_bpf =3D NULL; + BPF_UNLOCK(); + + rw_destroy(&bp->bif_lock); + free(bp, M_BPF); +} + +/* * Get a list of available data link type of the interface. */ static int @@ -2151,24 +2431,22 @@ struct ifnet *ifp; struct bpf_if *bp; =20 + BPF_LOCK_ASSERT(); + ifp =3D d->bd_bif->bif_ifp; n =3D 0; error =3D 0; - mtx_lock(&bpf_mtx); LIST_FOREACH(bp, &bpf_iflist, bif_next) { if (bp->bif_ifp !=3D ifp) continue; if (bfl->bfl_list !=3D NULL) { - if (n >=3D bfl->bfl_len) { - mtx_unlock(&bpf_mtx); + if (n >=3D bfl->bfl_len) return (ENOMEM); - } error =3D copyout(&bp->bif_dlt, bfl->bfl_list + n, sizeof(u_int)); } n++; } - mtx_unlock(&bpf_mtx); bfl->bfl_len =3D n; return (error); } @@ -2183,18 +2461,19 @@ struct ifnet *ifp; struct bpf_if *bp; =20 + BPF_LOCK_ASSERT(); + if (d->bd_bif->bif_dlt =3D=3D dlt) return (0); ifp =3D d->bd_bif->bif_ifp; - mtx_lock(&bpf_mtx); + LIST_FOREACH(bp, &bpf_iflist, bif_next) { if (bp->bif_ifp =3D=3D ifp && bp->bif_dlt =3D=3D dlt) break; } - mtx_unlock(&bpf_mtx); + if (bp !=3D NULL) { opromisc =3D d->bd_promisc; - bpf_detachd(d); bpf_attachd(d, bp); BPFD_LOCK(d); reset_d(d); @@ -2223,6 +2502,11 @@ dev =3D make_dev(&bpf_cdevsw, 0, UID_ROOT, GID_WHEEL, 0600, = "bpf"); /* For compatibility */ make_dev_alias(dev, "bpf0"); + + /* Register interface departure handler */ + bpf_ifdetach_cookie =3D EVENTHANDLER_REGISTER( + ifnet_departure_event, bpf_ifdetach, NULL, + EVENTHANDLER_PRI_ANY); } =20 /* @@ -2236,9 +2520,9 @@ struct bpf_if *bp; struct bpf_d *bd; =20 - mtx_lock(&bpf_mtx); + BPF_LOCK(); LIST_FOREACH(bp, &bpf_iflist, bif_next) { - BPFIF_LOCK(bp); + BPFIF_RLOCK(bp); LIST_FOREACH(bd, &bp->bif_dlist, bd_next) { BPFD_LOCK(bd); bd->bd_rcount =3D 0; @@ -2249,11 +2533,14 @@ bd->bd_zcopy =3D 0; BPFD_UNLOCK(bd); } - BPFIF_UNLOCK(bp); + BPFIF_RUNLOCK(bp); } - mtx_unlock(&bpf_mtx); + BPF_UNLOCK(); } =20 +/* + * Fill filter statistics + */ static void bpfstats_fill_xbpf(struct xbpf_d *d, struct bpf_d *bd) { @@ -2261,6 +2548,7 @@ bzero(d, sizeof(*d)); BPFD_LOCK_ASSERT(bd); d->bd_structsize =3D sizeof(*d); + /* XXX: reading should be protected by global lock */ d->bd_immediate =3D bd->bd_immediate; d->bd_promisc =3D bd->bd_promisc; d->bd_hdrcmplt =3D bd->bd_hdrcmplt; @@ -2285,6 +2573,9 @@ d->bd_bufmode =3D bd->bd_bufmode; } =20 +/* + * Handle `netstat -B' stats request + */ static int bpf_stats_sysctl(SYSCTL_HANDLER_ARGS) { @@ -2322,24 +2613,31 @@ if (bpf_bpfd_cnt =3D=3D 0) return (SYSCTL_OUT(req, 0, 0)); xbdbuf =3D malloc(req->oldlen, M_BPF, M_WAITOK); - mtx_lock(&bpf_mtx); + BPF_LOCK(); if (req->oldlen < (bpf_bpfd_cnt * sizeof(*xbd))) { - mtx_unlock(&bpf_mtx); + BPF_UNLOCK(); free(xbdbuf, M_BPF); return (ENOMEM); } index =3D 0; LIST_FOREACH(bp, &bpf_iflist, bif_next) { - BPFIF_LOCK(bp); + BPFIF_RLOCK(bp); + /* Send writers-only first */ + LIST_FOREACH(bd, &bp->bif_wlist, bd_next) { + xbd =3D &xbdbuf[index++]; + BPFD_LOCK(bd); + bpfstats_fill_xbpf(xbd, bd); + BPFD_UNLOCK(bd); + } LIST_FOREACH(bd, &bp->bif_dlist, bd_next) { xbd =3D &xbdbuf[index++]; BPFD_LOCK(bd); bpfstats_fill_xbpf(xbd, bd); BPFD_UNLOCK(bd); } - BPFIF_UNLOCK(bp); + BPFIF_RUNLOCK(bp); } - mtx_unlock(&bpf_mtx); + BPF_UNLOCK(); error =3D SYSCTL_OUT(req, xbdbuf, index * sizeof(*xbd)); free(xbdbuf, M_BPF); return (error); Index: net/bpf.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- net/bpf.h (revision 239830) +++ net/bpf.h (working copy) @@ -917,14 +917,21 @@ =20 /* * Descriptor associated with each attached hardware interface. + * FIXME: this structure is exposed to external callers to speed up + * bpf_peers_present() call. However we cover all fields not needed by + * this function via BPF_INTERNAL define */ struct bpf_if { LIST_ENTRY(bpf_if) bif_next; /* list of all = interfaces */ LIST_HEAD(, bpf_d) bif_dlist; /* descriptor list */ +#ifdef BPF_INTERNAL u_int bif_dlt; /* link layer type */ u_int bif_hdrlen; /* length of header (with = padding) */ struct ifnet *bif_ifp; /* corresponding interface */ - struct mtx bif_mtx; /* mutex for interface */ + struct rwlock bif_lock; /* interface lock */ + LIST_HEAD(, bpf_d) bif_wlist; /* writer-only list */ + int flags; /* Interface flags */ +#endif }; =20 void bpf_bufheld(struct bpf_d *d); Index: net/bpf_buffer.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- net/bpf_buffer.c (revision 239830) +++ net/bpf_buffer.c (working copy) @@ -93,21 +93,6 @@ SYSCTL_INT(_net_bpf, OID_AUTO, maxbufsize, CTLFLAG_RW, &bpf_maxbufsize, 0, "Default capture buffer in bytes"); =20 -void -bpf_buffer_alloc(struct bpf_d *d) -{ - - KASSERT(d->bd_fbuf =3D=3D NULL, ("bpf_buffer_alloc: bd_fbuf !=3D = NULL")); - KASSERT(d->bd_sbuf =3D=3D NULL, ("bpf_buffer_alloc: bd_sbuf !=3D = NULL")); - KASSERT(d->bd_hbuf =3D=3D NULL, ("bpf_buffer_alloc: bd_hbuf !=3D = NULL")); - - d->bd_fbuf =3D (caddr_t)malloc(d->bd_bufsize, M_BPF, M_WAITOK); - d->bd_sbuf =3D (caddr_t)malloc(d->bd_bufsize, M_BPF, M_WAITOK); - d->bd_hbuf =3D NULL; - d->bd_slen =3D 0; - d->bd_hlen =3D 0; -} - /* * Simple data copy to the current kernel buffer. */ @@ -183,18 +168,42 @@ bpf_buffer_ioctl_sblen(struct bpf_d *d, u_int *i) { u_int size; + caddr_t fbuf, sbuf; =20 + size =3D *i; + if (size > bpf_maxbufsize) + *i =3D size =3D bpf_maxbufsize; + else if (size < BPF_MINBUFSIZE) + *i =3D size =3D BPF_MINBUFSIZE; + + /* Allocate buffers immediately */ + fbuf =3D (caddr_t)malloc(size, M_BPF, M_WAITOK); + sbuf =3D (caddr_t)malloc(size, M_BPF, M_WAITOK); + BPFD_LOCK(d); if (d->bd_bif !=3D NULL) { + /* Interface already attached, unable to change buffers = */ BPFD_UNLOCK(d); + free(fbuf, M_BPF); + free(sbuf, M_BPF); return (EINVAL); } - size =3D *i; - if (size > bpf_maxbufsize) - *i =3D size =3D bpf_maxbufsize; - else if (size < BPF_MINBUFSIZE) - *i =3D size =3D BPF_MINBUFSIZE; + + /* Free old buffers if set */ + if (d->bd_fbuf !=3D NULL) + free(d->bd_fbuf, M_BPF); + if (d->bd_sbuf !=3D NULL) + free(d->bd_sbuf, M_BPF); + + /* Fill in new data */ d->bd_bufsize =3D size; + d->bd_fbuf =3D fbuf; + d->bd_sbuf =3D sbuf; + + d->bd_hbuf =3D NULL; + d->bd_slen =3D 0; + d->bd_hlen =3D 0; + BPFD_UNLOCK(d); return (0); } Index: net/bpf_buffer.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- net/bpf_buffer.h (revision 239830) +++ net/bpf_buffer.h (working copy) @@ -36,7 +36,6 @@ #error "no user-serviceable parts inside" #endif =20 -void bpf_buffer_alloc(struct bpf_d *d); void bpf_buffer_append_bytes(struct bpf_d *d, caddr_t buf, u_int = offset, void *src, u_int len); void bpf_buffer_append_mbuf(struct bpf_d *d, caddr_t buf, u_int = offset, Index: net/bpfdesc.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- net/bpfdesc.h (revision 239830) +++ net/bpfdesc.h (working copy) @@ -79,6 +79,7 @@ u_char bd_promisc; /* true if listening = promiscuously */ u_char bd_state; /* idle, waiting, or timed out = */ u_char bd_immediate; /* true to return on packet = arrival */ + u_char bd_writer; /* non-zero if d is writer-only = */ int bd_hdrcmplt; /* false to fill in src lladdr = automatically */ int bd_direction; /* select packet direction */ int bd_feedback; /* true to feed back sent = packets */ @@ -86,7 +87,7 @@ int bd_sig; /* signal to send upon packet = reception */ struct sigio * bd_sigio; /* information for async I/O */ struct selinfo bd_sel; /* bsd select info */ - struct mtx bd_mtx; /* mutex for this descriptor */ + struct mtx bd_lock; /* per-descriptor lock */ struct callout bd_callout; /* for BPF timeouts with select = */ struct label *bd_label; /* MAC label for descriptor */ u_int64_t bd_fcount; /* number of packets which = matched filter */ @@ -105,10 +106,16 @@ #define BPF_WAITING 1 /* waiting for read timeout in = select */ #define BPF_TIMED_OUT 2 /* read timeout has expired in = select */ =20 -#define BPFD_LOCK(bd) mtx_lock(&(bd)->bd_mtx) -#define BPFD_UNLOCK(bd) mtx_unlock(&(bd)->bd_mtx) -#define BPFD_LOCK_ASSERT(bd) mtx_assert(&(bd)->bd_mtx, MA_OWNED) +#define BPFD_LOCK(bd) mtx_lock(&(bd)->bd_lock) +#define BPFD_UNLOCK(bd) mtx_unlock(&(bd)->bd_lock) +#define BPFD_LOCK_ASSERT(bd) mtx_assert(&(bd)->bd_lock, MA_OWNED) =20 +#define BPF_PID_REFRESH(bd, td) (bd)->bd_pid =3D = (td)->td_proc->p_pid +#define BPF_PID_REFRESH_CUR(bd) (bd)->bd_pid =3D = curthread->td_proc->p_pid + +#define BPF_LOCK() mtx_lock(&bpf_mtx) +#define BPF_UNLOCK() mtx_unlock(&bpf_mtx) +#define BPF_LOCK_ASSERT() mtx_assert(&bpf_mtx, MA_OWNED) /* * External representation of the bpf descriptor */ @@ -143,7 +150,11 @@ u_int64_t bd_spare[4]; }; =20 -#define BPFIF_LOCK(bif) mtx_lock(&(bif)->bif_mtx) -#define BPFIF_UNLOCK(bif) mtx_unlock(&(bif)->bif_mtx) +#define BPFIF_RLOCK(bif) rw_rlock(&(bif)->bif_lock) +#define BPFIF_RUNLOCK(bif) rw_runlock(&(bif)->bif_lock) +#define BPFIF_WLOCK(bif) rw_wlock(&(bif)->bif_lock) +#define BPFIF_WUNLOCK(bif) rw_wunlock(&(bif)->bif_lock) =20 +#define BPFIF_FLAG_DYING 1 /* Reject new bpf consumers */ + #endif From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 15:35:45 2012 Return-Path: Delivered-To: FreeBSD-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 422CCD4A for ; Wed, 17 Oct 2012 15:35:45 +0000 (UTC) (envelope-from wynnwilkes@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id C5BE08FC16 for ; Wed, 17 Oct 2012 15:35:44 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id hr7so693981wib.13 for ; Wed, 17 Oct 2012 08:35:43 -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=mkcGkTb9E4FcsXI6RrONhSLtDphnB4db+l4NUetkpo4=; b=XLWILVXTdjrYqGv/1xIRX/ry3Y+aJJTDVIsvIER+gTSwvydO9+Gw/BC7YPJIgsB9Nv V60P74AcIxKJHfx2dGusYeNtwbAugzvd09a6z6EioYUiSaX3W0FWNfaH/xSQcmJvgMxh RkqgDQUMUPYd9NxOm5hYJx+mm93AqLGmPxlJH3XztVD7TukfXOSI2aGDRXaSvKKgQdGA 72Yh/OUzjyFXuGWhhtEuWIk+7hgBjEfJgWW4kNL3TNSkRWiRVNnlTjKags3lU86vl3dz h8ZKZL6eYnLAeDBfLPwhYiUmqv05RJCXBoKLPZ+feIxknFdn5XpR85EA/BKATq/CsxBV Zvlw== MIME-Version: 1.0 Received: by 10.216.206.11 with SMTP id k11mr11077992weo.81.1350488143595; Wed, 17 Oct 2012 08:35:43 -0700 (PDT) Received: by 10.194.77.168 with HTTP; Wed, 17 Oct 2012 08:35:43 -0700 (PDT) Date: Wed, 17 Oct 2012 09:35:43 -0600 Message-ID: Subject: 9.1-RC2 ixgbe lagg problems From: Wynn Wilkes To: FreeBSD-stable@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 15:35:45 -0000 I'm testing out a networking configuration that creates a lagg1 interface that uses lacp with the ix0 and ix1 interfaces. The lagg1 interface I've set up always just reports: laggport: ix1 flags=18 laggport: ix0 flags=18 Missing the ACTIVE flag that working lagg interfaces report. The built in ixgbe driver is at version 2.4.8 in the 9.1-RC2 release I upgraded to. The problem is very similar to this blog post: http://christopher-technicalmusings.blogspot.com/2012/03/freebsd-90-and-intel-x520s-ixgbe-2311.html and this mailing list thread: http://comments.gmane.org/gmane.os.freebsd.stable/79650 I've tried the 2.4.4 driver from Intel's site, but it still has the same problems. Is a lagg using lacp with the ix interfaces working for anyone else? Thanks From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 18:46:12 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 45156C4 for ; Wed, 17 Oct 2012 18:46:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id F40788FC17 for ; Wed, 17 Oct 2012 18:46:11 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5857BB98E; Wed, 17 Oct 2012 14:46:11 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Subject: Re: mpt irq timeout problem after reboot - only if non-verbose booting !?! Date: Wed, 17 Oct 2012 13:19:32 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <507D27DC.5030104@omnilan.de> In-Reply-To: <507D27DC.5030104@omnilan.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201210171319.32815.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 17 Oct 2012 14:46:11 -0400 (EDT) Cc: Harald Schmalzbauer X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 18:46:12 -0000 On Tuesday, October 16, 2012 5:24:44 am Harald Schmalzbauer wrote: > Hello, >=20 > I have 9.1-RC2 running in an ESXi 5.1 guest. > I use 'lsisas' as virtual SCSI-Controller and mpt attaches and finds 1068= E. >=20 > Everything is working fine until the first 'shutdown -r now': > The second boot pauses for ~2 minutes after probing disks and continues > with this error: > mpt0: Timedout requests already complete. Interrupts may not be functioni= ng. To be clear, you only see this at the end of reboot, and the hardware is fi= ne once the machine is back up? > This problem was also obeserved with real 1068 hardware: > http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/063937.h= tml >=20 > When I power off the virtual machine instead of rebooting, the problem > doesn't occur. >=20 > Accidentally I found a workarround ;-) : > If I set 'verbose_boot' in loader.conf, the problem vanisehs!?!?!? >=20 > Any idea how =E2=80=9Everbose_boot=E2=80=9C affects the operation of the = mpt driver? Extra printfs affect the timing most likely. Are you using any RAID volumes? The only shutdown handler in mpt that looks like it might want interrupts to work is mpt_raid_shutdown(). It needs to = use polled I/O instead of disabling interrupts I think. Try this: Index: mpt_raid.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =2D-- mpt_raid.c (revision 241641) +++ mpt_raid.c (working copy) @@ -115,7 +115,7 @@ static timeout_t mpt_raid_timer; static void mpt_enable_vol(struct mpt_softc *mpt, struct mpt_raid_volume *mpt_vol, int enable); #endif =2Dstatic void mpt_verify_mwce(struct mpt_softc *, struct mpt_raid_volume *= ); +static void mpt_verify_mwce(struct mpt_softc *, struct mpt_raid_volume *, = int); static void mpt_adjust_queue_depth(struct mpt_softc *, struct mpt_raid_vol= ume *, struct cam_path *); #if __FreeBSD_version < 500000 @@ -135,7 +135,7 @@ static void mpt_disk_prt(struct mpt_softc *mpt, st static int mpt_issue_raid_req(struct mpt_softc *mpt, struct mpt_raid_volume *vol, struct mpt_raid_disk *disk, request_t *re= q, u_int Action, uint32_t ActionDataWord, bus_addr_t addr, bus_size_t len, =2D int write, int wait); + int write, int wait, int sleep_ok); =20 static int mpt_refresh_raid_data(struct mpt_softc *mpt); static void mpt_schedule_raid_refresh(struct mpt_softc *mpt); @@ -517,7 +517,7 @@ mpt_raid_shutdown(struct mpt_softc *mpt) =20 mpt->raid_mwce_setting =3D MPT_RAID_MWCE_OFF; RAID_VOL_FOREACH(mpt, mpt_vol) { =2D mpt_verify_mwce(mpt, mpt_vol); + mpt_verify_mwce(mpt, mpt_vol, FALSE); } } =20 @@ -592,7 +592,7 @@ static int mpt_issue_raid_req(struct mpt_softc *mpt, struct mpt_raid_volume *vol, struct mpt_raid_disk *disk, request_t *req, u_int Action, uint32_t ActionDataWord, bus_addr_t addr, bus_size_t len, =2D int write, int wait) + int write, int wait, int sleep_ok) { MSG_RAID_ACTION_REQUEST *rap; SGE_SIMPLE32 *se; @@ -623,7 +623,7 @@ mpt_issue_raid_req(struct mpt_softc *mpt, struct m =20 if (wait) { return (mpt_wait_req(mpt, req, REQ_STATE_DONE, REQ_STATE_DONE, =2D /*sleep_ok*/FALSE, /*time_ms*/2000)); + sleep_ok, /*time_ms*/2000)); } else { return (0); } @@ -763,7 +763,7 @@ mpt_raid_quiesce_disk(struct mpt_softc *mpt, struc MPI_RAID_ACTION_QUIESCE_PHYS_IO, /*ActionData*/0, /*addr*/0, /*len*/0, /*write*/FALSE, =2D /*wait*/FALSE); + /*wait*/FALSE, /*sleep_ok*/FALSE); if (rv !=3D 0) return (CAM_REQ_CMP_ERR); =20 @@ -882,7 +882,7 @@ mpt_enable_vol(struct mpt_softc *mpt, struct mpt_r enable ? MPI_RAID_ACTION_ENABLE_VOLUME : MPI_RAID_ACTION_DISABLE_VOLUME, /*data*/0, /*addr*/0, /*len*/0, =2D /*write*/FALSE, /*wait*/TRUE); + /*write*/FALSE, /*wait*/TRUE, /*sleep_ok*/TRUE); if (rv =3D=3D ETIMEDOUT) { mpt_vol_prt(mpt, mpt_vol, "mpt_enable_vol: " "%s Volume Timed-out\n", @@ -903,7 +903,8 @@ mpt_enable_vol(struct mpt_softc *mpt, struct mpt_r #endif =20 static void =2Dmpt_verify_mwce(struct mpt_softc *mpt, struct mpt_raid_volume *mpt_vol) +mpt_verify_mwce(struct mpt_softc *mpt, struct mpt_raid_volume *mpt_vol, + int sleep_ok) { request_t *req; struct mpt_raid_action_result *ar; @@ -950,7 +951,7 @@ static void return; } =20 =2D req =3D mpt_get_request(mpt, /*sleep_ok*/TRUE); + req =3D mpt_get_request(mpt, sleep_ok); if (req =3D=3D NULL) { mpt_vol_prt(mpt, mpt_vol, "mpt_verify_mwce: Get request failed!\n"); @@ -965,7 +966,7 @@ static void rv =3D mpt_issue_raid_req(mpt, mpt_vol, /*disk*/NULL, req, MPI_RAID_ACTION_CHANGE_VOLUME_SETTINGS, data, /*addr*/0, /*len*/0, =2D /*write*/FALSE, /*wait*/TRUE); + /*write*/FALSE, /*wait*/TRUE, sleep_ok); if (rv =3D=3D ETIMEDOUT) { mpt_vol_prt(mpt, mpt_vol, "mpt_verify_mwce: " "Write Cache Enable Timed-out\n"); @@ -1018,7 +1019,8 @@ mpt_verify_resync_rate(struct mpt_softc *mpt, stru rv =3D mpt_issue_raid_req(mpt, mpt_vol, /*disk*/NULL, req, MPI_RAID_ACTION_SET_RESYNC_RATE, mpt->raid_resync_rate, /*addr*/0, =2D /*len*/0, /*write*/FALSE, /*wait*/TRUE); + /*len*/0, /*write*/FALSE, /*wait*/TRUE, + /*sleep_ok*/TRUE); if (rv =3D=3D ETIMEDOUT) { mpt_vol_prt(mpt, mpt_vol, "mpt_refresh_raid_data: " "Resync Rate Setting Timed-out\n"); @@ -1054,7 +1056,8 @@ mpt_verify_resync_rate(struct mpt_softc *mpt, stru rv =3D mpt_issue_raid_req(mpt, mpt_vol, /*disk*/NULL, req, MPI_RAID_ACTION_CHANGE_VOLUME_SETTINGS, data, /*addr*/0, /*len*/0, =2D /*write*/FALSE, /*wait*/TRUE); + /*write*/FALSE, /*wait*/TRUE, + /*sleep_ok*/TRUE); if (rv =3D=3D ETIMEDOUT) { mpt_vol_prt(mpt, mpt_vol, "mpt_refresh_raid_data: " "Resync Rate Setting Timed-out\n"); @@ -1314,7 +1317,7 @@ mpt_refresh_raid_vol(struct mpt_softc *mpt, struct return; } rv =3D mpt_issue_raid_req(mpt, mpt_vol, NULL, req, =2D MPI_RAID_ACTION_INDICATOR_STRUCT, 0, 0, 0, FALSE, TRUE); + MPI_RAID_ACTION_INDICATOR_STRUCT, 0, 0, 0, FALSE, TRUE, TRUE); if (rv =3D=3D ETIMEDOUT) { mpt_vol_prt(mpt, mpt_vol, "mpt_refresh_raid_vol: Progress Indicator fetch timeout\n"); @@ -1474,7 +1477,7 @@ mpt_refresh_raid_data(struct mpt_softc *mpt) mpt_vol->flags |=3D MPT_RVF_UP2DATE; mpt_vol_prt(mpt, mpt_vol, "%s - %s\n", mpt_vol_type(mpt_vol), mpt_vol_state(mpt_vol)); =2D mpt_verify_mwce(mpt, mpt_vol); + mpt_verify_mwce(mpt, mpt_vol, TRUE); =20 if (vol_pg->VolumeStatus.Flags =3D=3D 0) { continue; @@ -1752,7 +1755,7 @@ mpt_raid_set_vol_mwce(struct mpt_softc *mpt, mpt_r mpt_vol_prt(mpt, mpt_vol, "WARNING - Unsafe shutdown " "detected. Suggest full resync.\n"); } =2D mpt_verify_mwce(mpt, mpt_vol); + mpt_verify_mwce(mpt, mpt_vol, TRUE); } mpt->raid_mwce_set =3D 1; MPT_UNLOCK(mpt); =2D-=20 John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 18:48:36 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 843586EA for ; Wed, 17 Oct 2012 18:48:36 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) by mx1.freebsd.org (Postfix) with ESMTP id 35BDB8FC0A for ; Wed, 17 Oct 2012 18:48:36 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.5/8.14.5) with ESMTP id q9HImZYm039944; Wed, 17 Oct 2012 14:48:35 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.5/8.14.4/Submit) id q9HImZBj039943; Wed, 17 Oct 2012 14:48:35 -0400 (EDT) (envelope-from wollman) Date: Wed, 17 Oct 2012 14:48:35 -0400 (EDT) From: Garrett Wollman Message-Id: <201210171848.q9HImZBj039943@hergotha.csail.mit.edu> To: wynnwilkes@gmail.com Subject: Re: 9.1-RC2 ixgbe lagg problems In-Reply-To: Organization: none X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (hergotha.csail.mit.edu [127.0.0.1]); Wed, 17 Oct 2012 14:48:35 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 18:48:36 -0000 In article , wynnwilkes@gmail.com writes: >I've tried the 2.4.4 driver from Intel's site, but it still has the >same problems. Is a lagg using lacp with the ix interfaces working for >anyone else? You bet. lagg0: flags=8943 metric 0 mtu 9120 options=401bb ether 04:7d:7b:a5:88:f0 inet 128.30.3.34 netmask 0xffffff00 broadcast 128.30.3.255 nd6 options=29 media: Ethernet autoselect status: active laggproto lacp lagghash l2,l3,l4 laggport: ix1 flags=1c laggport: ix0 flags=1c Configured with: cloned_interfaces="lagg0" ifconfig_ix0="mtu 9120 up" ifconfig_ix1="mtu 9120 up" ifconfig_lagg0="laggproto lacp laggport ix0 laggport ix1" ipv4_addrs_lagg0="128.30.x.x/24" -GAWollman From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 19:15:01 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1D6F02ED; Wed, 17 Oct 2012 19:15:01 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id A27F48FC12; Wed, 17 Oct 2012 19:14:59 +0000 (UTC) Received: from [172.21.97.229] ([172.21.97.229]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id q9HJG8D9001643 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 17 Oct 2012 21:16:09 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Subject: Re: mpt irq timeout problem after reboot - only if non-verbose booting !?! Date: Wed, 17 Oct 2012 21:14:52 +0200 From: "Harald Schmalzbauer (mobil)" To: jhb@freebsd.org MIME-Version: 1.0 X-Mailer: LCG ProfiMail 3.56 Message-ID: <7671651912.1034975692@omnilan.de> References: <507D27DC.5030104@omnilan.de> <201210171319.32815.jhb@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 19:15:01 -0000 -----Urspr=C3=BCngliche Nachricht----- > Von: John Baldwin > An: freebsd-stable@freebsd.org > Cc: h.schmalzbauer@omnilan.de > Gesendet: 17.10.'12, 20:46 > > On Tuesday, October 16, 2012 5:24:44 am Harald Schmalzbauer wrote: >> Hello, >> >> I have 9.1-RC2 running in an ESXi 5.1 guest. >> I use 'lsisas' as virtual SCSI-Controller and mpt attaches and finds = 1068E. >> >> Everything is working fine until the first 'shutdown -r now': >> The second boot pauses for ~2 minutes after probing disks and continues >> with this error: >> mpt0: Timedout requests already complete. Interrupts may not be = functioning. > > To be clear, you only see this at the end of reboot, and the hardware is = fine > once the machine is back up? . Thanks for your attention! The timeout occurs after the first 'shutdown -r' while device probing = during second boot process. Perhaps this is amd64 specific. Today I had a new i386 setup which doesn't = exhibit this timeout. But it's on different hardware and hv-host was 5.0 = inestead 5.1. So not really representative... > Extra printfs affect the timing most likely. > > Are you using any RAID volumes? The only shutdown handler in mpt that = looks The controller is 'virtual' SAS. But thers's been reports that also on real = HW (sasuc8i) the same problem occurs. I'll try your patch tomorrow morning; timezon shift... Thanks, -Harry= From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 20:16:14 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3B932CEE for ; Wed, 17 Oct 2012 20:16:14 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from chinatsu.takeda.tk (takeda-1-pt.tunnel.tserv15.lax1.ipv6.he.net [IPv6:2001:470:c:16b::2]) by mx1.freebsd.org (Postfix) with ESMTP id C051D8FC0A for ; Wed, 17 Oct 2012 20:16:13 +0000 (UTC) Received: from takeda-ws.lan (takeda-ws.lan [10.0.0.3]) (authenticated bits=0) by chinatsu.takeda.tk (8.14.5/8.14.5) with ESMTP id q9HKGBUu036064 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 17 Oct 2012 13:16:11 -0700 (PDT) (envelope-from takeda@takeda.tk) Date: Wed, 17 Oct 2012 13:15:43 -0700 From: Derek Kulinski X-Priority: 3 (Normal) Message-ID: <1286515493.20121017131543@takeda.tk> To: freebsd-stable@freebsd.org Subject: Problem reading vitals from Gigabyte H77-DH3H MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 20:16:14 -0000 Hello everyone, I'm unable to read temperature Gigabyte H77-DH3H motherboard. Is that motherboard supported or am I doing it incorrectly? When trying to access hw.acpi.thermal everything appears to be ok, but it is not, the system always returns 27,8C and 29,8C which fooled me initially - the values never change. Here is output: [chinatsu]:/root# sysctl hw.acpi.thermal hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 27,8C hw.acpi.thermal.tz0.active: 2 hw.acpi.thermal.tz0.passive_cooling: 0 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: -1 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 106,0C hw.acpi.thermal.tz0._ACx: 85,0C 55,0C 0,0C 0,0C 0,0C -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: -1 hw.acpi.thermal.tz0._TC2: -1 hw.acpi.thermal.tz0._TSP: -1 hw.acpi.thermal.tz1.temperature: 29,8C hw.acpi.thermal.tz1.active: -1 hw.acpi.thermal.tz1.passive_cooling: 1 hw.acpi.thermal.tz1.thermal_flags: 0 hw.acpi.thermal.tz1._PSV: 106,0C hw.acpi.thermal.tz1._HOT: -1 hw.acpi.thermal.tz1._CRT: 106,0C hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz1._TC1: 1 hw.acpi.thermal.tz1._TC2: 5 hw.acpi.thermal.tz1._TSP: 10 Since above method fails, I decided to try motherboard monitors in ports. It seems that almost all of them rely on /dev/smb device. After loading smb and ichsmb (seems like ichsmb is the only driver that causes /dev/smb0) any access to /dev/smb0 returns "Device not configured". For example: [chinatsu]:/root# lmmon IOCTL: Device not configured Similarly mbmon fails: [chinatsu]:/root# mbmon -V No VIA686 HWM available!! InitMBInfo: No error: 0 Exit 1 [chinatsu]:/root# mbmon -S No SMBus HWM available!! InitMBInfo: No error: 0 Exit 1 [chinatsu]:/root# mbmon -I No ISA-IO HWM available!! InitMBInfo: No error: 0 Exit 1 [chinatsu]:/root# mbmon -A InitMBInfo: No error: 0 This program needs "setuid root"!! Exit 1 Here's output of pciconf: [chinatsu]:/root# pciconf -lv hostb0@pci0:0:0:0: class=0x060000 card=0x50001458 chip=0x01508086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = 'Ivy Bridge DRAM Controller' class = bridge subclass = HOST-PCI vgapci0@pci0:0:2:0: class=0x030000 card=0xd0001458 chip=0x01528086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = 'Ivy Bridge Graphics Controller' class = display subclass = VGA xhci0@pci0:0:20:0: class=0x0c0330 card=0x50071458 chip=0x1e318086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = 'Panther Point USB xHCI Host Controller' class = serial bus subclass = USB none0@pci0:0:22:0: class=0x078000 card=0x1c3a1458 chip=0x1e3a8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = 'Panther Point MEI Controller' class = simple comms ehci0@pci0:0:26:0: class=0x0c0320 card=0x50061458 chip=0x1e2d8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = 'Panther Point USB Enhanced Host Controller' class = serial bus subclass = USB pcib1@pci0:0:28:0: class=0x060400 card=0x50011458 chip=0x1e108086 rev=0xc4 hdr=0x01 vendor = 'Intel Corporation' device = 'Panther Point PCI Express Root Port 1' class = bridge subclass = PCI-PCI pcib2@pci0:0:28:2: class=0x060400 card=0x50011458 chip=0x1e148086 rev=0xc4 hdr=0x01 vendor = 'Intel Corporation' device = 'Panther Point PCI Express Root Port 3' class = bridge subclass = PCI-PCI pcib3@pci0:0:28:3: class=0x060401 card=0x50011458 chip=0x244e8086 rev=0xc4 hdr=0x01 vendor = 'Intel Corporation' device = '82801 PCI Bridge' class = bridge subclass = PCI-PCI ehci1@pci0:0:29:0: class=0x0c0320 card=0x50061458 chip=0x1e268086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = 'Panther Point USB Enhanced Host Controller' class = serial bus subclass = USB isab0@pci0:0:31:0: class=0x060100 card=0x50011458 chip=0x1e4a8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = 'Panther Point LPC Controller' class = bridge subclass = PCI-ISA ahci0@pci0:0:31:2: class=0x010601 card=0xb0051458 chip=0x1e028086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = 'Panther Point 6 port SATA AHCI Controller' class = mass storage subclass = SATA ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x50011458 chip=0x1e228086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = 'Panther Point SMBus Controller' class = serial bus subclass = SMBus alc0@pci0:2:0:0: class=0x020000 card=0xe0001458 chip=0x10831969 rev=0xc0 hdr=0x00 vendor = 'Atheros Communications' device = 'AR8151 v2.0 Gigabit Ethernet' class = network subclass = ethernet pcib4@pci0:3:0:0: class=0x060401 card=0x88921458 chip=0x244e8086 rev=0x41 hdr=0x01 vendor = 'Intel Corporation' device = '82801 PCI Bridge' class = bridge subclass = PCI-PCI em0@pci0:4:1:0: class=0x020000 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = '82541PI Gigabit Ethernet Controller' class = network subclass = ethernet -- Best regards, Derek mailto:takeda@takeda.tk Never underestimate the bandwidth of a station wagon full of tapes hurling down the highway From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 20:39:05 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 76D27559 for ; Wed, 17 Oct 2012 20:39:05 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D0A858FC12 for ; Wed, 17 Oct 2012 20:39:04 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA09570; Wed, 17 Oct 2012 23:38:58 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TOaOI-0000Oz-K4; Wed, 17 Oct 2012 23:38:58 +0300 Message-ID: <507F1761.1010202@FreeBSD.org> Date: Wed, 17 Oct 2012 23:38:57 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121013 Thunderbird/16.0.1 MIME-Version: 1.0 To: Derek Kulinski Subject: Re: Problem reading vitals from Gigabyte H77-DH3H References: <1286515493.20121017131543@takeda.tk> In-Reply-To: <1286515493.20121017131543@takeda.tk> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 20:39:05 -0000 on 17/10/2012 23:15 Derek Kulinski said the following: > Hello everyone, > > I'm unable to read temperature Gigabyte H77-DH3H motherboard. Is that > motherboard supported or am I doing it incorrectly? > > When trying to access hw.acpi.thermal everything appears to be ok, but > it is not, the system always returns 27,8C and 29,8C which fooled me > initially - the values never change. I've found that on quite a few modern systems the ACPI platform advertises some useless thermal zones, which always return some hardcoded temperatures. E.g. I have Asus P8Z77-M PRO near me and it also reports two thermal zones. Looking at DSDT (acpidump -dt) I see that the temperatures are hardcoded. It seems that your motherboard has an ITE Super I/O with hardware monitoring function. I am not sure which model though... Your best bet would be it(4) driver, but it is not committed yet. If you are into some mild hacking (applying patches, building custom kernel), then I can point you to the patches. Although I can not give a firm guarantee that the driver supports your HWM chip, since I don't know the model. > Here is output: > [chinatsu]:/root# sysctl hw.acpi.thermal > hw.acpi.thermal.min_runtime: 0 > hw.acpi.thermal.polling_rate: 10 > hw.acpi.thermal.user_override: 0 > hw.acpi.thermal.tz0.temperature: 27,8C > hw.acpi.thermal.tz0.active: 2 > hw.acpi.thermal.tz0.passive_cooling: 0 > hw.acpi.thermal.tz0.thermal_flags: 0 > hw.acpi.thermal.tz0._PSV: -1 > hw.acpi.thermal.tz0._HOT: -1 > hw.acpi.thermal.tz0._CRT: 106,0C > hw.acpi.thermal.tz0._ACx: 85,0C 55,0C 0,0C 0,0C 0,0C -1 -1 -1 -1 -1 > hw.acpi.thermal.tz0._TC1: -1 > hw.acpi.thermal.tz0._TC2: -1 > hw.acpi.thermal.tz0._TSP: -1 > hw.acpi.thermal.tz1.temperature: 29,8C > hw.acpi.thermal.tz1.active: -1 > hw.acpi.thermal.tz1.passive_cooling: 1 > hw.acpi.thermal.tz1.thermal_flags: 0 > hw.acpi.thermal.tz1._PSV: 106,0C > hw.acpi.thermal.tz1._HOT: -1 > hw.acpi.thermal.tz1._CRT: 106,0C > hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > hw.acpi.thermal.tz1._TC1: 1 > hw.acpi.thermal.tz1._TC2: 5 > hw.acpi.thermal.tz1._TSP: 10 > > Since above method fails, I decided to try motherboard monitors in > ports. It seems that almost all of them rely on /dev/smb device. > > After loading smb and ichsmb (seems like ichsmb is the only driver > that causes /dev/smb0) any access to /dev/smb0 returns "Device > not configured". For example: > > [chinatsu]:/root# lmmon > IOCTL: Device not configured > > Similarly mbmon fails: > [chinatsu]:/root# mbmon -V > No VIA686 HWM available!! > InitMBInfo: No error: 0 > Exit 1 > [chinatsu]:/root# mbmon -S > No SMBus HWM available!! > InitMBInfo: No error: 0 > Exit 1 > [chinatsu]:/root# mbmon -I > No ISA-IO HWM available!! > InitMBInfo: No error: 0 > Exit 1 > [chinatsu]:/root# mbmon -A > InitMBInfo: No error: 0 > This program needs "setuid root"!! > Exit 1 > > Here's output of pciconf: These tools from ports are very outdated and thus do not support new hardware. > [chinatsu]:/root# pciconf -lv > hostb0@pci0:0:0:0: class=0x060000 card=0x50001458 chip=0x01508086 rev=0x09 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Ivy Bridge DRAM Controller' > class = bridge > subclass = HOST-PCI > vgapci0@pci0:0:2:0: class=0x030000 card=0xd0001458 chip=0x01528086 rev=0x09 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Ivy Bridge Graphics Controller' > class = display > subclass = VGA > xhci0@pci0:0:20:0: class=0x0c0330 card=0x50071458 chip=0x1e318086 rev=0x04 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Panther Point USB xHCI Host Controller' > class = serial bus > subclass = USB > none0@pci0:0:22:0: class=0x078000 card=0x1c3a1458 chip=0x1e3a8086 rev=0x04 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Panther Point MEI Controller' > class = simple comms > ehci0@pci0:0:26:0: class=0x0c0320 card=0x50061458 chip=0x1e2d8086 rev=0x04 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Panther Point USB Enhanced Host Controller' > class = serial bus > subclass = USB > pcib1@pci0:0:28:0: class=0x060400 card=0x50011458 chip=0x1e108086 rev=0xc4 hdr=0x01 > vendor = 'Intel Corporation' > device = 'Panther Point PCI Express Root Port 1' > class = bridge > subclass = PCI-PCI > pcib2@pci0:0:28:2: class=0x060400 card=0x50011458 chip=0x1e148086 rev=0xc4 hdr=0x01 > vendor = 'Intel Corporation' > device = 'Panther Point PCI Express Root Port 3' > class = bridge > subclass = PCI-PCI > pcib3@pci0:0:28:3: class=0x060401 card=0x50011458 chip=0x244e8086 rev=0xc4 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801 PCI Bridge' > class = bridge > subclass = PCI-PCI > ehci1@pci0:0:29:0: class=0x0c0320 card=0x50061458 chip=0x1e268086 rev=0x04 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Panther Point USB Enhanced Host Controller' > class = serial bus > subclass = USB > isab0@pci0:0:31:0: class=0x060100 card=0x50011458 chip=0x1e4a8086 rev=0x04 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Panther Point LPC Controller' > class = bridge > subclass = PCI-ISA > ahci0@pci0:0:31:2: class=0x010601 card=0xb0051458 chip=0x1e028086 rev=0x04 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Panther Point 6 port SATA AHCI Controller' > class = mass storage > subclass = SATA > ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x50011458 chip=0x1e228086 rev=0x04 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Panther Point SMBus Controller' > class = serial bus > subclass = SMBus > alc0@pci0:2:0:0: class=0x020000 card=0xe0001458 chip=0x10831969 rev=0xc0 hdr=0x00 > vendor = 'Atheros Communications' > device = 'AR8151 v2.0 Gigabit Ethernet' > class = network > subclass = ethernet > pcib4@pci0:3:0:0: class=0x060401 card=0x88921458 chip=0x244e8086 rev=0x41 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801 PCI Bridge' > class = bridge > subclass = PCI-PCI > em0@pci0:4:1:0: class=0x020000 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00 > vendor = 'Intel Corporation' > device = '82541PI Gigabit Ethernet Controller' > class = network > subclass = ethernet > > -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 20:51:51 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5503BA4D; Wed, 17 Oct 2012 20:51:51 +0000 (UTC) (envelope-from takeda@chinatsu.takeda.tk) Received: from chinatsu.takeda.tk (takeda-1-pt.tunnel.tserv15.lax1.ipv6.he.net [IPv6:2001:470:c:16b::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1CAC68FC12; Wed, 17 Oct 2012 20:51:50 +0000 (UTC) Received: from chinatsu.takeda.tk (localhost.takeda.tk [127.0.0.1]) by chinatsu.takeda.tk (8.14.5/8.14.5) with ESMTP id q9HKpoRa036548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Oct 2012 13:51:50 -0700 (PDT) (envelope-from takeda@chinatsu.takeda.tk) Received: (from takeda@localhost) by chinatsu.takeda.tk (8.14.5/8.14.5/Submit) id q9HKplqY036547; Wed, 17 Oct 2012 13:51:47 -0700 (PDT) (envelope-from takeda) Date: Wed, 17 Oct 2012 13:51:47 -0700 From: Derek Kulinski To: Andriy Gapon Subject: Re: Problem reading vitals from Gigabyte H77-DH3H Message-ID: <20121017205147.GB36106@chinatsu.takeda.tk> References: <1286515493.20121017131543@takeda.tk> <507F1761.1010202@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <507F1761.1010202@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 20:51:51 -0000 On Wed, Oct 17, 2012 at 11:38:57PM +0300, Andriy Gapon wrote: > I've found that on quite a few modern systems the ACPI platform advertises some > useless thermal zones, which always return some hardcoded temperatures. > E.g. I have Asus P8Z77-M PRO near me and it also reports two thermal zones. > Looking at DSDT (acpidump -dt) I see that the temperatures are hardcoded. > > It seems that your motherboard has an ITE Super I/O with hardware monitoring > function. I am not sure which model though... > Your best bet would be it(4) driver, but it is not committed yet. > If you are into some mild hacking (applying patches, building custom kernel), > then I can point you to the patches. > Although I can not give a firm guarantee that the driver supports your HWM chip, > since I don't know the model. I'm open to experimenting. It's kind of important to me, because I recently had heating issue (that I hopefully fixed) and I wasn't aware of problems until my system started freezing. I was fooled by those values thinking everything was ok. > [...] > > These tools from ports are very outdated and thus do not support new hardware. I never used them before since on my old box hw.acpi.thermal worked fine. Is there anything in ports that you would recommend? Thanks, Derek From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 20:56:46 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3EFE6C56 for ; Wed, 17 Oct 2012 20:56:46 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from mail.ultra-secure.de (mail.ultra-secure.de [78.47.114.122]) by mx1.freebsd.org (Postfix) with ESMTP id 7C03F8FC08 for ; Wed, 17 Oct 2012 20:56:44 +0000 (UTC) Received: (qmail 74968 invoked by uid 89); 17 Oct 2012 20:56:38 -0000 Received: by simscan 1.4.0 ppid: 74963, pid: 74965, t: 0.0516s scanners: attach: 1.4.0 clamav: 0.97.3/m:54/d:15472 Received: from unknown (HELO ?192.168.1.201?) (rainer@ultra-secure.de@217.71.83.52) by mail.ultra-secure.de with ESMTPA; 17 Oct 2012 20:56:37 -0000 From: Rainer Duffner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 9.1-RC2 - could it be that the installer does not write the MBR? Message-Id: Date: Wed, 17 Oct 2012 22:56:36 +0200 To: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 20:56:46 -0000 Hi, I tried to install 9.1-RC2 amd64 on two disks that previously had some = version of Solaris installed (with grub as boot-manager). The installation would always be successful, but it would just boot to = grub and then sit there. It's a rather old G1 BL460C blade, but 9.0 installs flawlessly. I didn't have time to really test it through because the server needed = to get installed and it had taken me some time to realize what had = happened. Maybe someone might want to look into this. From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 20:59:35 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 34EE2E35 for ; Wed, 17 Oct 2012 20:59:35 +0000 (UTC) (envelope-from allbery.b@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id D66278FC0C for ; Wed, 17 Oct 2012 20:59:34 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id l39so7952814qcs.13 for ; Wed, 17 Oct 2012 13:59:34 -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=+JmCXZFjmAV8NcIK+G+8nSKPARf+RJlOrsHUPraVqGg=; b=XxffhORgb0VqIB2Jqrt992JchIBJese1rPFclrpoKRPy9mMzJR6oeDAOU6Mejj5Ufm beDeEPzr0aka8eLDmrhZoApoi8UfqVbrbuUpFpWHUBZFcrtoasBifmRFNAt08oQVPL73 BYuzg0rHZzfOeJyC1LYpmO0ZT9s48FzEj8LE5k7oBDSt95GSe0c7cfHzMyiJxR2R7cBL 74abOEvVGCK3cNNt5gISHdBYUQKgMbIuuDowNupQBw5dXUOAZomHqyTEBIX2gn/FklGk h7glZTFJl/xw2/Rhf0djXViN3u8ioyeCN/yzli5uTULKA22Ca+20XMjWQzNq4tRhe4qI hztA== MIME-Version: 1.0 Received: by 10.229.178.153 with SMTP id bm25mr9339036qcb.131.1350507573981; Wed, 17 Oct 2012 13:59:33 -0700 (PDT) Received: by 10.49.61.233 with HTTP; Wed, 17 Oct 2012 13:59:33 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Oct 2012 16:59:33 -0400 Message-ID: Subject: Re: 9.1-RC2 - could it be that the installer does not write the MBR? From: Brandon Allbery To: Rainer Duffner Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 20:59:35 -0000 On Wed, Oct 17, 2012 at 4:56 PM, Rainer Duffner wrote: > I tried to install 9.1-RC2 amd64 on two disks that previously had some > version of Solaris installed (with grub as boot-manager). > The installation would always be successful, but it would just boot to > grub and then sit there. > RC1 wasn't very good at it either. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix/linux, openafs, kerberos, infrastructure http://sinenomine.net From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 21:55:40 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5EDD7532; Wed, 17 Oct 2012 21:55:40 +0000 (UTC) (envelope-from guy.helmer@gmail.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id EF2968FC0A; Wed, 17 Oct 2012 21:55:39 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id k10so16544767iea.13 for ; Wed, 17 Oct 2012 14:55:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=+VPzoL2TvdeKPfNnawln5jqNkmyBemf0SdUXnawLnFU=; b=dc9CcfcZkWorCHQz0jYbalZ/Abbkc1ThndzcXkgem+YVc4iCI2B87NSN0g2ncB9fBt t2zo45pXmpONFezcy73vn36oz5G1iqwehaRg6iH/9fAGSe8bmiZskZgCslLlBdaxVVp3 DWuZ23DVaTP1n4JU4Px3HpLAequHW3R5VUEb+pWAkw0rtswaIfpdlxykxuIqwh9ds68P hMYYp+C+zIy6SpReSmBf7YdJpPVQldTJ9s8L3O6Ax8YeL4jcs8nm2+Ew082UDTUzg6Fr l2PHgC+2tN3wbFpGAMjiJDs6eVGk4n8aR2s31172dKdeQyma4IwQIgNMaldmb9JGhcrO IqMg== Received: by 10.50.135.38 with SMTP id pp6mr3069810igb.36.1350510939583; Wed, 17 Oct 2012 14:55:39 -0700 (PDT) Received: from [192.168.221.99] ([216.81.189.9]) by mx.google.com with ESMTPS id yf6sm12681211igb.0.2012.10.17.14.55.37 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 17 Oct 2012 14:55:38 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: 8.3: kernel panic in bpf.c catchpacket() From: Guy Helmer In-Reply-To: <381E3EEC-7EDB-428B-A724-434443E51A53@gmail.com> Date: Wed, 17 Oct 2012 16:55:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B5399BF-4EE0-4182-8297-3BB97C4AA884@gmail.com> <59F9A36E-3DB2-4F6F-BB2A-A4C9DA76A70C@gmail.com> <5075C05E.9070800@FreeBSD.org> <1EDA1615-2CDE-405A-A725-AF7CC7D3E273@gmail.com> <381E3EEC-7EDB-428B-A724-434443E51A53@gmail.com> To: "Alexander V. Chernikov" X-Mailer: Apple Mail (2.1499) Cc: freebsd-net@freebsd.org, FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 21:55:40 -0000 On Oct 17, 2012, at 8:58 AM, Guy Helmer wrote: > On Oct 12, 2012, at 8:54 AM, Guy Helmer wrote: >=20 >>=20 >> On Oct 10, 2012, at 1:37 PM, Alexander V. Chernikov = wrote: >>=20 >>> On 10.10.2012 00:36, Guy Helmer wrote: >>>>=20 >>>> On Oct 8, 2012, at 8:09 AM, Guy Helmer = wrote: >>>>=20 >>>>> I'm seeing a consistent new kernel panic in FreeBSD 8.3: >>>>> I'm not seeing how bd_sbuf would be NULL here. Any ideas? >>>>=20 >>>> Since I've not had any replies, I hope nobody minds if I reply with = more information. >>>>=20 >>>> This panic seems to be occasionally triggered now that my user land = code is changing the packet filter a while after the bpd device has been = opened and an initial packet filter was set (previously, my code did not = change the filter after it was initially set). >>>>=20 >>>> I'm focusing on bpf_setf() since that seems to be the place that = could be tickling a problem, and I see that bpf_setf() calls reset_d(d) = to clear the hold buffer. I have manually verified that the BPFD lock is = held during the call to reset_d(), and the lock is held every other = place that the buffers are manipulated, so I haven't been able to find = any place that seems vulnerable to losing one of the bpf buffers. Still = searching, but any help would be appreciated. >>>=20 >>> Can you please check this code on -current? >>> Locking has changed quite significantly some time ago, so there is = good chance that you can get rid of this panic (or discover different = one which is really "new") :). >>=20 >> I'm not ready to run this app on current, so I have merged revs = 229898, 233937, 233938, 233946, 235744, 235745, 235746, 235747, 236231, = 236251, 236261, 236262, 236559, and 236806 to my 8.3 checkout to get = code that should be virtually identical to current without the timestamp = changes. >>=20 >> Unfortunately, I have only been able to trigger the panic in my test = lab once -- so I'm not sure whether a lack of problems with the updated = code will be indicative of likely success in the field where this has = been trigged regularly at some sites=85 >>=20 >> Thanks, >> Guy >>=20 >=20 >=20 > FWIW, I was able to trigger the panic with the original 8.3 code again = in my test lab. With these changes resulting from merging the revs = mentioned above, I have not seen any panics in my test lab setup in two = days of load testing, and AFAIK, packet capturing seems to be working = fine. Of course, the test system panic'ed with the same problem in = catchpacket() an hour after I wrote this. (kgdb) where #0 doadump () at pcpu.h:224 #1 0xffffffff804c8280 in boot (howto=3D260) at = ../../../kern/kern_shutdown.c:441 #2 0xffffffff804c8703 in panic (fmt=3D0x0) at = ../../../kern/kern_shutdown.c:614 #3 0xffffffff8069ffad in trap_fatal (frame=3D0xffffffff809edbc0, = eva=3DVariable "eva" is not available. ) at ../../../amd64/amd64/trap.c:825 #4 0xffffffff806a02e1 in trap_pfault (frame=3D0xffffff800014a8a0, = usermode=3D0) at ../../../amd64/amd64/trap.c:741 #5 0xffffffff806a06bf in trap (frame=3D0xffffff800014a8a0) at ../../../amd64/amd64/trap.c:478 #6 0xffffffff80687cd4 in calltrap () at = ../../../amd64/amd64/exception.S:228 #7 0xffffffff8069dc06 in bcopy () at ../../../amd64/amd64/support.S:124 #8 0xffffffff8056f69e in catchpacket (d=3D0xffffff005aaaf000,=20 pkt=3D0xffffff0001f46200 "", pktlen=3D522, snaplen=3DVariable = "snaplen" is not available. ) at ../../../net/bpf.c:2240 #9 0xffffffff8056fc66 in bpf_mtap (bp=3D0xffffff0001be8c80,=20 m=3D0xffffff0001f46200) at ../../../net/bpf.c:2064 #10 0xffffffff80579c15 in ether_input (ifp=3D0xffffff0001b73800,=20 m=3D0xffffff0001f46200) at ../../../net/if_ethersubr.c:635 #11 0xffffffff802b694a in em_rxeof (rxr=3D0xffffff0001bca200, count=3D99, = done=3D0x0) at ../../../dev/e1000/if_em.c:4404 #12 0xffffffff802b6db8 in em_handle_que (context=3DVariable "context" is = not available. ) at ../../../dev/e1000/if_em.c:1494 #13 0xffffffff80506d85 in taskqueue_run_locked = (queue=3D0xffffff0001be1580) at ../../../kern/subr_taskqueue.c:250 ---Type to continue, or q to quit---q=20 Quit (kgdb) frame 8 #8 0xffffffff8056f69e in catchpacket (d=3D0xffffff005aaaf000,=20 pkt=3D0xffffff0001f46200 "", pktlen=3D522, snaplen=3DVariable = "snaplen" is not available. ) at ../../../net/bpf.c:2240 warning: Source file is more recent than executable. 2240 bpf_append_bytes(d, d->bd_sbuf, curlen, &hdr, = sizeof(hdr)); (kgdb) print *d $1 =3D {bd_next =3D {le_next =3D 0xffffff0023fff400, le_prev =3D = 0xffffff0001be8c90},=20 bd_sbuf =3D 0x0, bd_hbuf =3D 0xffffff8000ffa000 "??~P", bd_fbuf =3D = 0x0,=20 bd_slen =3D 0, bd_hlen =3D 2068, bd_bufsize =3D 8388608,=20 bd_bif =3D 0xffffff0001be8c80, bd_rtout =3D 1, bd_rfilter =3D = 0xffffff0001e6f580,=20 bd_wfilter =3D 0x0, bd_bfilter =3D 0x0, bd_rcount =3D 7, bd_dcount =3D = 0,=20 bd_promisc =3D 1 '\001', bd_state =3D 0 '\0', bd_immediate =3D 1 = '\001',=20 bd_writer =3D 0 '\0', bd_hdrcmplt =3D 1, bd_direction =3D 1, = bd_feedback =3D 0,=20 bd_async =3D 0, bd_sig =3D 23, bd_sigio =3D 0x0, bd_sel =3D {si_tdlist = =3D { tqh_first =3D 0x0, tqh_last =3D 0x0}, si_note =3D {kl_list =3D { slh_first =3D 0x0}, kl_lock =3D 0xffffffff80497920 = ,=20 kl_unlock =3D 0xffffffff804978f0 ,=20 kl_assert_locked =3D 0xffffffff804945d0 = ,=20 kl_assert_unlocked =3D 0xffffffff804945e0 = ,=20 kl_lockarg =3D 0xffffff005aaaf0d8}, si_mtx =3D 0x0}, bd_lock =3D { lock_object =3D {lo_name =3D 0xffffff0001a5fce0 "bpf", lo_flags =3D = 16973824,=20 lo_data =3D 0, lo_witness =3D 0x0}, mtx_lock =3D = 18446742974226712768},=20 bd_callout =3D {c_links =3D {sle =3D {sle_next =3D 0x0}, tqe =3D = {tqe_next =3D 0x0,=20 tqe_prev =3D 0x0}}, c_time =3D 0, c_arg =3D 0x0, c_func =3D 0,=20= c_lock =3D 0xffffff005aaaf0d8, c_flags =3D 0, c_cpu =3D 0}, bd_label = =3D 0x0,=20 bd_fcount =3D 7, bd_pid =3D 89517, bd_locked =3D 0, bd_bufmode =3D 1, = bd_wcount =3D 0,=20 bd_wfcount =3D 0, bd_wdcount =3D 0, bd_zcopy =3D 0, bd_compat32 =3D 0 = '\0'} Now, I am thinking the malloc() of the sbuf is failing but not sure = how/why -- I thought malloc(size, M_BPF, M_WAITOK) should not fail? Guy= From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 06:31:35 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 62EE1844; Thu, 18 Oct 2012 06:31:35 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id C38448FC0C; Thu, 18 Oct 2012 06:31:34 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id q9I6Wm6R015763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Oct 2012 08:32:48 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <507FA243.6020207@omnilan.de> Date: Thu, 18 Oct 2012 08:31:31 +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: John Baldwin Subject: Re: mpt irq timeout problem after reboot - only if non-verbose booting !?! References: <507D27DC.5030104@omnilan.de> <201210171319.32815.jhb@freebsd.org> In-Reply-To: <201210171319.32815.jhb@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD8A57725472644A9F128EEE6" Cc: freebsd-stable@freebsd.org, freebsdlists@bsdunix.ch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 06:31:35 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD8A57725472644A9F128EEE6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable schrieb John Baldwin am 17.10.2012 19:19 (localtime): > Are you using any RAID volumes? The only shutdown handler in mpt that = looks > like it might want interrupts to work is mpt_raid_shutdown(). It needs= to use > polled I/O instead of disabling interrupts I think. Try this: > > Index: mpt_raid.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- mpt_raid.c (revision 241641) > +++ mpt_raid.c (working copy) > @@ -115,7 +115,7 @@ static timeout_t mpt_raid_timer; > static void mpt_enable_vol(struct mpt_softc *mpt, > struct mpt_raid_volume *mpt_vol, int enable); > #endif > -static void mpt_verify_mwce(struct mpt_softc *, struct mpt_raid_volume= *); > +static void mpt_verify_mwce(struct mpt_softc *, struct mpt_raid_volume= *, int); > static void mpt_adjust_queue_depth(struct mpt_softc *, struct mpt_raid= _volume *, > struct cam_path *); > #if __FreeBSD_version < 500000 > @@ -135,7 +135,7 @@ static void mpt_disk_prt(struct mpt_softc *mpt, st > static int mpt_issue_raid_req(struct mpt_softc *mpt, > struct mpt_raid_volume *vol, struct mpt_raid_disk *disk, request_t= *req, > u_int Action, uint32_t ActionDataWord, bus_addr_t addr, bus_size_t= len, > - int write, int wait); > + int write, int wait, int sleep_ok); > =20 > static int mpt_refresh_raid_data(struct mpt_softc *mpt); > static void mpt_schedule_raid_refresh(struct mpt_softc *mpt); > @@ -517,7 +517,7 @@ mpt_raid_shutdown(struct mpt_softc *mpt) > =20 > mpt->raid_mwce_setting =3D MPT_RAID_MWCE_OFF; > RAID_VOL_FOREACH(mpt, mpt_vol) { > - mpt_verify_mwce(mpt, mpt_vol); > + mpt_verify_mwce(mpt, mpt_vol, FALSE); > } > } > =20 > @@ -592,7 +592,7 @@ static int > mpt_issue_raid_req(struct mpt_softc *mpt, struct mpt_raid_volume *vol,= > struct mpt_raid_disk *disk, request_t *req, u_int Action, > uint32_t ActionDataWord, bus_addr_t addr, bus_size_t len, > - int write, int wait) > + int write, int wait, int sleep_ok) > { > MSG_RAID_ACTION_REQUEST *rap; > SGE_SIMPLE32 *se; > @@ -623,7 +623,7 @@ mpt_issue_raid_req(struct mpt_softc *mpt, struct m > =20 > if (wait) { > return (mpt_wait_req(mpt, req, REQ_STATE_DONE, REQ_STATE_DONE, > - /*sleep_ok*/FALSE, /*time_ms*/2000)); > + sleep_ok, /*time_ms*/2000)); > } else { > return (0); > } > @@ -763,7 +763,7 @@ mpt_raid_quiesce_disk(struct mpt_softc *mpt, struc > MPI_RAID_ACTION_QUIESCE_PHYS_IO, > /*ActionData*/0, /*addr*/0, > /*len*/0, /*write*/FALSE, > - /*wait*/FALSE); > + /*wait*/FALSE, /*sleep_ok*/FALSE); > if (rv !=3D 0) > return (CAM_REQ_CMP_ERR); > =20 > @@ -882,7 +882,7 @@ mpt_enable_vol(struct mpt_softc *mpt, struct mpt_r > enable ? MPI_RAID_ACTION_ENABLE_VOLUME > : MPI_RAID_ACTION_DISABLE_VOLUME, > /*data*/0, /*addr*/0, /*len*/0, > - /*write*/FALSE, /*wait*/TRUE); > + /*write*/FALSE, /*wait*/TRUE, /*sleep_ok*/TRUE); > if (rv =3D=3D ETIMEDOUT) { > mpt_vol_prt(mpt, mpt_vol, "mpt_enable_vol: " > "%s Volume Timed-out\n", > @@ -903,7 +903,8 @@ mpt_enable_vol(struct mpt_softc *mpt, struct mpt_r > #endif > =20 > static void > -mpt_verify_mwce(struct mpt_softc *mpt, struct mpt_raid_volume *mpt_vol= ) > +mpt_verify_mwce(struct mpt_softc *mpt, struct mpt_raid_volume *mpt_vol= , > + int sleep_ok) > { > request_t *req; > struct mpt_raid_action_result *ar; > @@ -950,7 +951,7 @@ static void > return; > } > =20 > - req =3D mpt_get_request(mpt, /*sleep_ok*/TRUE); > + req =3D mpt_get_request(mpt, sleep_ok); > if (req =3D=3D NULL) { > mpt_vol_prt(mpt, mpt_vol, > "mpt_verify_mwce: Get request failed!\n"); > @@ -965,7 +966,7 @@ static void > rv =3D mpt_issue_raid_req(mpt, mpt_vol, /*disk*/NULL, req, > MPI_RAID_ACTION_CHANGE_VOLUME_SETTINGS, > data, /*addr*/0, /*len*/0, > - /*write*/FALSE, /*wait*/TRUE); > + /*write*/FALSE, /*wait*/TRUE, sleep_ok); > if (rv =3D=3D ETIMEDOUT) { > mpt_vol_prt(mpt, mpt_vol, "mpt_verify_mwce: " > "Write Cache Enable Timed-out\n"); > @@ -1018,7 +1019,8 @@ mpt_verify_resync_rate(struct mpt_softc *mpt, str= u > rv =3D mpt_issue_raid_req(mpt, mpt_vol, /*disk*/NULL, req, > MPI_RAID_ACTION_SET_RESYNC_RATE, > mpt->raid_resync_rate, /*addr*/0, > - /*len*/0, /*write*/FALSE, /*wait*/TRUE); > + /*len*/0, /*write*/FALSE, /*wait*/TRUE, > + /*sleep_ok*/TRUE); > if (rv =3D=3D ETIMEDOUT) { > mpt_vol_prt(mpt, mpt_vol, "mpt_refresh_raid_data: " > "Resync Rate Setting Timed-out\n"); > @@ -1054,7 +1056,8 @@ mpt_verify_resync_rate(struct mpt_softc *mpt, str= u > rv =3D mpt_issue_raid_req(mpt, mpt_vol, /*disk*/NULL, req, > MPI_RAID_ACTION_CHANGE_VOLUME_SETTINGS, > data, /*addr*/0, /*len*/0, > - /*write*/FALSE, /*wait*/TRUE); > + /*write*/FALSE, /*wait*/TRUE, > + /*sleep_ok*/TRUE); > if (rv =3D=3D ETIMEDOUT) { > mpt_vol_prt(mpt, mpt_vol, "mpt_refresh_raid_data: " > "Resync Rate Setting Timed-out\n"); > @@ -1314,7 +1317,7 @@ mpt_refresh_raid_vol(struct mpt_softc *mpt, struc= t > return; > } > rv =3D mpt_issue_raid_req(mpt, mpt_vol, NULL, req, > - MPI_RAID_ACTION_INDICATOR_STRUCT, 0, 0, 0, FALSE, TRUE); > + MPI_RAID_ACTION_INDICATOR_STRUCT, 0, 0, 0, FALSE, TRUE, TRUE); > if (rv =3D=3D ETIMEDOUT) { > mpt_vol_prt(mpt, mpt_vol, > "mpt_refresh_raid_vol: Progress Indicator fetch timeout\n"); > @@ -1474,7 +1477,7 @@ mpt_refresh_raid_data(struct mpt_softc *mpt) > mpt_vol->flags |=3D MPT_RVF_UP2DATE; > mpt_vol_prt(mpt, mpt_vol, "%s - %s\n", > mpt_vol_type(mpt_vol), mpt_vol_state(mpt_vol)); > - mpt_verify_mwce(mpt, mpt_vol); > + mpt_verify_mwce(mpt, mpt_vol, TRUE); > =20 > if (vol_pg->VolumeStatus.Flags =3D=3D 0) { > continue; > @@ -1752,7 +1755,7 @@ mpt_raid_set_vol_mwce(struct mpt_softc *mpt, mpt_= r > mpt_vol_prt(mpt, mpt_vol, "WARNING - Unsafe shutdown " > "detected. Suggest full resync.\n"); > } > - mpt_verify_mwce(mpt, mpt_vol); > + mpt_verify_mwce(mpt, mpt_vol, TRUE); > } > mpt->raid_mwce_set =3D 1; > MPT_UNLOCK(mpt); > Hmm, unfortunately I can't reproduce it anymore. After applying your patch, rebooting worked without verbose_boot, but to be sure I wanted to falsify, booted with the old kernel and couldn't reproduce it anymore. In the meantime I modified some PCI-bridge settings in the virtual hardware, because more devices were added and my modification to assign every device it's own (virtual hard wired irq) slot wasn't applicable anymore. But I removed the additional hardware and tried to restore the config like it was when I hit the problem; no luck though :-( Sorry for wasting your time. If I ever see it again, I'll test the patch and let you know. Mabye Thomas Vogt still has his hardware setup handy where he saw the same timeout message a year ago, CCing him. Thanks, -Harry --------------enigD8A57725472644A9F128EEE6 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) iEYEARECAAYFAlB/okMACgkQLDqVQ9VXb8jfDgCgx9MgYLM/NtgXI13/ISvxaphH +SwAn0XjA0hFQfzLVcA0szZdV1BqBmKt =Qu73 -----END PGP SIGNATURE----- --------------enigD8A57725472644A9F128EEE6-- From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 07:57:52 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 32032A42 for ; Thu, 18 Oct 2012 07:57:52 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id 8DF428FC08 for ; Thu, 18 Oct 2012 07:57:51 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1TOkjg-0000hg-1C; Thu, 18 Oct 2012 09:41:45 +0200 Received: from [81.21.138.17] (helo=ronaldradial.versatec.local) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TOkje-0001eU-PP; Thu, 18 Oct 2012 09:41:42 +0200 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes References: <20120925013438.4BC4213256@sjakie.klop.ws> <20121003220149.00007b0c@unknown> Subject: Re: daily run output misses zpool errors To: freebsd-stable@freebsd.org, "Alexander Leidinger" Date: Thu, 18 Oct 2012 09:41:41 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <20121003220149.00007b0c@unknown> User-Agent: Opera Mail/12.02 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: 0.0 X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=disabled version=3.2.5 X-Scan-Signature: 1629bd954af37e9bd463cbe85bf61e19 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 07:57:52 -0000 On Wed, 03 Oct 2012 22:01:49 +0200, Alexander Leidinger wrote: > On Tue, 25 Sep 2012 14:56:49 +0200 "Ronald Klop" wrote: > >> Hi, >> >> Below my daily report. And here my zpool status -x. It would be nice >> to see this error in my daily info. I am running with >> daily_show_info="NO", but this looks more severe than info. > > Just to make sure: you verified that you have > daily_status_zfs_enable=YES in periodic.conf? > > In the daily mail you provided I've seen several headings without > content, but I haven't seen the "Checking status of zfs pools:" part > which is supposed to show up when the zfs stats script is run. > > Bye, > Alexander. > Yes. My point is that as long as the pool is healthy the daily e-mail tells me that and when the pool is unhealthy it does not show me any info. I setup a test to reproduce this. I broke a mirror by dd-ing /dev/random over one of the md backing files. $ cat /etc/periodic.conf daily_show_info="NO" weekly_show_info="NO" monthly_show_info="NO" daily_status_zfs_enable="YES" daily_scrub_zfs_enable="YES" daily_status_smart_devices="AUTO" daily_clean_hoststat_enable="NO" daily_status_mail_rejects_enable="NO" daily_status_include_submit_mailq="NO" daily_submit_queuerun="NO" $ zpool status test pool: test state: ONLINE status: One or more devices could not be used because the label is missing or invalid. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Replace the device using 'zpool replace'. see: http://illumos.org/msg/ZFS-8000-4J scan: scrub repaired 0 in 0h0m with 0 errors on Wed Oct 17 14:26:43 2012 config: NAME STATE READ WRITE CKSUM test ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 md0 ONLINE 0 0 0 18290078248358455968 UNAVAIL 0 0 0 was /dev/md1 errors: No known data errors The daily mail before I broke the pool: --------------------------------------------------------------------- Removing stale files from /var/preserve: Cleaning out old system announcements: Removing stale files from /var/rwho: Backup passwd and group files: Verifying group file syntax: /etc/group is fine Backing up package db directory: Rotating accounting logs and gathering statistics: Checking status of zfs pools: NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT extern 298G 161G 137G 54% 1.00x ONLINE - tank 292G 215G 77.2G 73% 1.00x ONLINE - test 95.5M 5.32M 90.2M 5% 1.00x ONLINE - all pools are healthy Network interface status: Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop em0 1500 00:21:70:46:6c:da 427203 0 0 321583 0 0 0 em0 1500 192.168.1.0 sjakie.home 368631 - - 322492 - - - em0 1500 192.168.1.36/ 192.168.1.36 64146 - - 0 - - - usbus 0 0 0 0 0 0 0 0 usbus 0 0 0 0 0 0 0 0 usbus 0 0 0 0 0 0 0 0 usbus 0 0 0 0 0 0 0 0 usbus 0 0 0 0 0 0 0 0 usbus 0 0 0 0 0 0 0 0 usbus 0 0 0 0 0 0 0 0 usbus 0 0 0 0 0 0 0 0 lo0 16384 20857 0 0 20857 0 0 0 lo0 16384 localhost ::1 0 - - 0 - - - lo0 16384 fe80::1%lo0 fe80::1 0 - - 0 - - - lo0 16384 your-net localhost 34 - - 20857 - - - ipfw0 65536 0 0 0 0 0 0 0 Security check: (output mailed separately) Checking for denied zone transfers (AXFR and IXFR): Scrubbing of zfs pools: skipping scrubbing of pool 'extern': last scrubbing is 20 days ago, threshold is set to 35 days skipping scrubbing of pool 'tank': last scrubbing is 4 days ago, threshold is set to 35 days skipping scrubbing of pool 'test': last scrubbing is 0 days ago, threshold is set to 35 days -- End of daily output -- The daily mail after I broke the pool: --------------------------------------------------------------------- Removing stale files from /var/preserve: Cleaning out old system announcements: Removing stale files from /var/rwho: Backup passwd and group files: Verifying group file syntax: /etc/group is fine Backing up package db directory: Rotating accounting logs and gathering statistics: Network interface status: Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop em0 1500 00:21:70:46:6c:da 586075 0 0 443833 0 0 0 em0 1500 192.168.1.0 sjakie.home 493306 - - 445997 - - - em0 1500 192.168.1.36/ 192.168.1.36 98748 - - 0 - - - usbus 0 0 0 0 0 0 0 0 usbus 0 0 0 0 0 0 0 0 usbus 0 0 0 0 0 0 0 0 usbus 0 0 0 0 0 0 0 0 usbus 0 0 0 0 0 0 0 0 usbus 0 0 0 0 0 0 0 0 usbus 0 0 0 0 0 0 0 0 usbus 0 0 0 0 0 0 0 0 lo0 16384 27243 0 0 27243 0 0 0 lo0 16384 localhost ::1 0 - - 0 - - - lo0 16384 fe80::1%lo0 fe80::1 0 - - 0 - - - lo0 16384 your-net localhost 34 - - 27243 - - - ipfw0 65536 0 0 0 0 0 0 0 Security check: (output mailed separately) Checking for denied zone transfers (AXFR and IXFR): Scrubbing of zfs pools: skipping scrubbing of pool 'extern': last scrubbing is 21 days ago, threshold is set to 35 days skipping scrubbing of pool 'tank': last scrubbing is 5 days ago, threshold is set to 35 days skipping scrubbing of pool 'test': last scrubbing is 0 days ago, threshold is set to 35 days -- End of daily output -- From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 08:06:08 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3525FD10 for ; Thu, 18 Oct 2012 08:06:08 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 1974D8FC08 for ; Thu, 18 Oct 2012 08:06:06 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TOl7F-0002g0-44 for freebsd-stable@freebsd.org; Thu, 18 Oct 2012 10:06:05 +0200 Received: from 79-139-19-75.prenet.pl ([79.139.19.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 18 Oct 2012 10:06:05 +0200 Received: from jb.1234abcd by 79-139-19-75.prenet.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 18 Oct 2012 10:06:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: jb Subject: Re: 9.1-RC2 - could it be that the installer does not write the MBR? Date: Thu, 18 Oct 2012 08:05:47 +0000 (UTC) Lines: 22 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 79.139.19.75 (Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20100101 Firefox/16.0) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 08:06:08 -0000 Brandon Allbery gmail.com> writes: > > On Wed, Oct 17, 2012 at 4:56 PM, Rainer Duffner ultra-secure.de>wrote: > > > I tried to install 9.1-RC2 amd64 on two disks that previously had some > > version of Solaris installed (with grub as boot-manager). > > The installation would always be successful, but it would just boot to > > grub and then sit there. > > > > RC1 wasn't very good at it either. > I installed RC2 yesterday and noticed that there was no question asked where to install boot loader (MBR or FB root slice/partition). That's something needing a fix. jb From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 09:31:58 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 889AD697 for ; Thu, 18 Oct 2012 09:31:58 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2DF118FC14 for ; Thu, 18 Oct 2012 09:31:58 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fw7so11804164vcb.13 for ; Thu, 18 Oct 2012 02:31:57 -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=ffxSsxGX6ZPk8QQXD51+/SPC0fqo+hW+7BClg+rdXXU=; b=nV6bXbPfPpuCxn5QDoOlwQhlS3eTLsa9n9Z3mcpSa2PvbJSYU30hs6F2J9PoSEZ461 p/FP1D4fgf9iZCPCloWUkGgQDEvy7U5/h1OLnF1TbChwSKxKikCg0dxPsnWi26o4pAUO b59u8Z9Rim1pxlmqnbSnMfAJT9PzG5Bx8mEIGJJ4aXE9WkB3jjxhH0/RtqXY567oNwvC uYfvL8oNB60m+djcW+VhtS9ZzBBKvwCm6uGO/Gt9qY+AJkuHnCEW8X9CWRP8Q2W+njzj FC+wTx2FztvbobsJ31f/CeBKQdSLcpsuSwsoP838aw0fHasY3e6Nb/+Yu4cFieWZ1C/0 yidw== MIME-Version: 1.0 Received: by 10.220.155.203 with SMTP id t11mr4338210vcw.36.1350552717512; Thu, 18 Oct 2012 02:31:57 -0700 (PDT) Received: by 10.58.209.163 with HTTP; Thu, 18 Oct 2012 02:31:56 -0700 (PDT) In-Reply-To: References: Date: Thu, 18 Oct 2012 12:31:56 +0300 Message-ID: Subject: Re: 9.1-RC2 - could it be that the installer does not write the MBR? From: Kimmo Paasiala To: jb Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 09:31:58 -0000 On Thu, Oct 18, 2012 at 11:05 AM, jb wrote: > Brandon Allbery gmail.com> writes: > >> >> On Wed, Oct 17, 2012 at 4:56 PM, Rainer Duffner > ultra-secure.de>wrote: >> >> > I tried to install 9.1-RC2 amd64 on two disks that previously had some >> > version of Solaris installed (with grub as boot-manager). >> > The installation would always be successful, but it would just boot to >> > grub and then sit there. >> > >> >> RC1 wasn't very good at it either. >> > > I installed RC2 yesterday and noticed that there was no question asked where > to install boot loader (MBR or FB root slice/partition). > That's something needing a fix. > jb > > > > Such question does not make sense if the disk is GPT partitioned which is the default now. The boot loader is installed on a separate freebsd-boot partition and the MBR of the disk contains a special "protective MBR". From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 09:45:08 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D6D67A5E for ; Thu, 18 Oct 2012 09:45:08 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from mail-chaos.rambler.ru (mail-chaos.rambler.ru [81.19.68.130]) by mx1.freebsd.org (Postfix) with ESMTP id 84FFB8FC0C for ; Thu, 18 Oct 2012 09:45:07 +0000 (UTC) Received: from citrin.office.vega.ru (office-nat.spylog.net [193.169.234.6]) (Authenticated sender: citrin@citrin.ru) by mail-chaos.rambler.ru (Postfix) with ESMTPSA id 72C0017026 for ; Thu, 18 Oct 2012 13:44:59 +0400 (MSD) Message-ID: <507FCF9B.9080104@citrin.ru> Date: Thu, 18 Oct 2012 13:44:59 +0400 From: Anton Yuzhaninov User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:6.0.2) Gecko/20110922 Thunderbird/6.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Problem with IPMI KCS driver References: <503DE2AB.6030702@citrin.ru> <201208290825.44198.jhb@freebsd.org> <506573DD.2030808@citrin.ru> <201209280848.35380.jhb@freebsd.org> In-Reply-To: <201209280848.35380.jhb@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 09:45:08 -0000 On 28.09.2012 16:48, John Baldwin wrote: >> kcs_wait_for_obf() at kcs_wait_for_obf+0xb6 point to >> > /usr/src/sys/dev/ipmi/ipmi_kcs.c:94 >> > >> > 91 while (ticks - start< MAX_TIMEOUT&& >> > 92 !(status& KCS_STATUS_OBF)) { >> > 93 DELAY(100); >> > 94 status = INB(sc, KCS_CTL_STS); >> > 95 } > Hummm. I'm a bit out of ideas then. Even the volatile change is a bug that > could have been confirmed (to see if volatile was preventing the compiler > from caching the value of 'ticks') by examining the assembly. > > Well, maybe this. This just avoids using 'ticks' altogether and depends on > DELAY(100) doing what it says: New patch also don't solve my problem. My guess was wrong. Loop in kcs_wait_for_obf() is not endless, at least with last patch. Whole function called in some loop, but because loop in kcs_wait_for_obf() takes much CPU time, backtrace always point to loop kcs_wait_for_obf(). This problem need further investigation. -- Anton Yuzhaninov From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 09:52:25 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E3BCD9A for ; Thu, 18 Oct 2012 09:52:25 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5ACE38FC0A for ; Thu, 18 Oct 2012 09:52:24 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so11184922oag.13 for ; Thu, 18 Oct 2012 02:52:24 -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=UgGh0bXVIpdLAJ5KStIit6IzUT+c/Cb+QA/VXYz+irQ=; b=XPataG3iuYPNyFGJmF6s1LSoYygQpVlVQOarvEWezS9D2TQdFCFSuUV1MRTV5aKDAr +VSb43Ehe9baiPHTpo0H83UNdl6yPe5g2rWzlIm3Jg5orjjuWBQA2FFtZTXU3I3JclzI IuqCNWMsCdI4X2Zoitpxg04QWIx9Sw91du04cq6PL7oaj5Alij5qWeeNjNcYrY8jSUnw /7l8ErLcPPg9iDBr6MgF4qXCvMkzRSzhHujQro5EpShWNL87eEa+paIfv+CPARzGEmYH KlhWvCzJhyq1puMbKyIeTb94pF4dnWS8wUFclcHmVWlrisaNWa3soK6nSmrO/HUUlj2L RDYA== MIME-Version: 1.0 Received: by 10.60.169.241 with SMTP id ah17mr17857341oec.37.1350553944338; Thu, 18 Oct 2012 02:52:24 -0700 (PDT) Received: by 10.182.133.40 with HTTP; Thu, 18 Oct 2012 02:52:24 -0700 (PDT) In-Reply-To: <201210171848.q9HImZBj039943@hergotha.csail.mit.edu> References: <201210171848.q9HImZBj039943@hergotha.csail.mit.edu> Date: Thu, 18 Oct 2012 11:52:24 +0200 Message-ID: Subject: Re: 9.1-RC2 ixgbe lagg problems From: Sami Halabi To: Garrett Wollman Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: stable@freebsd.org, wynnwilkes@gmail.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 09:52:25 -0000 Hi, what fbsd version... what uname -a shows, what driver version do you have? Sami On Wed, Oct 17, 2012 at 8:48 PM, Garrett Wollman < wollman@hergotha.csail.mit.edu> wrote: > In article > , > wynnwilkes@gmail.com writes: > > >I've tried the 2.4.4 driver from Intel's site, but it still has the > >same problems. Is a lagg using lacp with the ix interfaces working for > >anyone else? > > You bet. > > lagg0: flags=8943 > metric 0 mtu 9120 > > options=401bb > ether 04:7d:7b:a5:88:f0 > inet 128.30.3.34 netmask 0xffffff00 broadcast 128.30.3.255 > nd6 options=29 > media: Ethernet autoselect > status: active > laggproto lacp lagghash l2,l3,l4 > laggport: ix1 flags=1c > laggport: ix0 flags=1c > > Configured with: > > cloned_interfaces="lagg0" > ifconfig_ix0="mtu 9120 up" > ifconfig_ix1="mtu 9120 up" > ifconfig_lagg0="laggproto lacp laggport ix0 laggport ix1" > ipv4_addrs_lagg0="128.30.x.x/24" > > -GAWollman > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 13:47:34 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A300F7B0 for ; Thu, 18 Oct 2012 13:47:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 73E3B8FC12 for ; Thu, 18 Oct 2012 13:47:34 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CC2DAB963; Thu, 18 Oct 2012 09:47:33 -0400 (EDT) From: John Baldwin To: "Harald Schmalzbauer (mobil)" Subject: Re: mpt irq timeout problem after reboot - only if non-verbose booting !?! Date: Thu, 18 Oct 2012 08:46:12 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <507D27DC.5030104@omnilan.de> <201210171319.32815.jhb@freebsd.org> <7671651912.1034975692@omnilan.de> In-Reply-To: <7671651912.1034975692@omnilan.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201210180846.12630.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 18 Oct 2012 09:47:33 -0400 (EDT) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 13:47:34 -0000 On Wednesday, October 17, 2012 3:14:52 pm Harald Schmalzbauer (mobil) wrote: > -----Urspr=C3=BCngliche Nachricht----- > > Von: John Baldwin > > An: freebsd-stable@freebsd.org > > Cc: h.schmalzbauer@omnilan.de > > Gesendet: 17.10.'12, 20:46 > >=20 > > On Tuesday, October 16, 2012 5:24:44 am Harald Schmalzbauer wrote: > >> Hello, > >>=20 > >> I have 9.1-RC2 running in an ESXi 5.1 guest. > >> I use 'lsisas' as virtual SCSI-Controller and mpt attaches and finds 1= 068E. > >>=20 > >> Everything is working fine until the first 'shutdown -r now': > >> The second boot pauses for ~2 minutes after probing disks and continues > >> with this error: > >> mpt0: Timedout requests already complete. Interrupts may not be functi= oning. > >=20 > > To be clear, you only see this at the end of reboot, and the hardware i= s fine > > once the machine is back up? > . >=20 > Thanks for your attention! > The timeout occurs after the first 'shutdown -r' while device probing dur= ing > second boot process. Perhaps this is amd64 specific. Today I had a new i= 386 > setup which doesn't exhibit this timeout. But it's on different hardware = and > hv-host was 5.0 inestead 5.1. So not really representative... Hmmm, ok. In that case my patch is not relevant. It would only fix that message occuring during the shutdown. =2D-=20 John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 16:05:32 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2B607426 for ; Thu, 18 Oct 2012 16:05:32 +0000 (UTC) (envelope-from allbery.b@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id C68D58FC16 for ; Thu, 18 Oct 2012 16:05:31 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id l39so8643173qcs.13 for ; Thu, 18 Oct 2012 09:05:31 -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=YY54FMM6ExGEMYishseY1Z8kiRbxZbAbzCS7Xk+/4R0=; b=odmbOuCVPPR4NvI+v9/JiE3r5YBp5cJ20i2BfpoKTEP5C8Y3NndmdcNFerBvv52f/Y ebnW3yaH8I3695/IpxD14JNZAHeogMy4n1+F1Dc41zBpOOigVeS6no0q0V+e2/j6bkn+ rt5cGHi4LZ6hU06WWzdWFFoekF7dzRAVB1n38h+IIoZCmT5lknoCqVx88Il3VyJx0Jkj io7ATfaZ2G9T8FY8lWmwnoMKlhPqROQVEankIM7j5qHtPGAH3MyWxlrMB7Ci1EUqOSK/ stM69IbTC1N/6R0N81pKExQRs5PtsPYAzA0+WHHfIjAyAMwiuu0/AckTYCyVj/VhXy9r eXQw== MIME-Version: 1.0 Received: by 10.49.127.115 with SMTP id nf19mr46209371qeb.36.1350576331200; Thu, 18 Oct 2012 09:05:31 -0700 (PDT) Received: by 10.49.61.233 with HTTP; Thu, 18 Oct 2012 09:05:31 -0700 (PDT) In-Reply-To: References: Date: Thu, 18 Oct 2012 12:05:31 -0400 Message-ID: Subject: Re: 9.1-RC2 - could it be that the installer does not write the MBR? From: Brandon Allbery To: Kimmo Paasiala Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-stable@freebsd.org, jb X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 16:05:32 -0000 On Thu, Oct 18, 2012 at 5:31 AM, Kimmo Paasiala wrote: > Such question does not make sense if the disk is GPT partitioned which > is the default now. The boot loader is installed on a separate > freebsd-boot partition and the MBR of the disk contains a special > "protective MBR". And what is supposed to happen if the disk has an existing MBR and existing partitions? -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix/linux, openafs, kerberos, infrastructure http://sinenomine.net From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 16:32:01 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5F839BEC for ; Thu, 18 Oct 2012 16:32:01 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1BA978FC14 for ; Thu, 18 Oct 2012 16:32:01 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id k10so18407183iea.13 for ; Thu, 18 Oct 2012 09:32:00 -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:references :in-reply-to:content-type:content-transfer-encoding; bh=rktHdYlOY+V/oYobb8ZDJm3VdB657t3GXsmr01HfaTw=; b=sd0AEv4wxWsje3CLGwax/efsjdT8OZAT5iJcpOZPWjTbgx3xd/vWvxUd7EN12k1EJW n4SQxKMLbgUc5IArIew6X7cF8wTdBSQ0TgY6VLdbG8dH32GcdU8EaHNcBxhnlK8typBj qp+shwy1IkN4rJDw4v7dCK4oOafp6EK7cHRM3oErKfnO60OKiUpwzC74COPzzbfGvSi2 F/9zwcLla+hdQlubGnmNjaB3H6EHEdgUQ6ntT8rp09KBG+mU0hIqUC00Pybh7lkx08E9 AkoFi0i/eoIg4Vcm0CLAI+dpXAGr4Wlnf2n2vc3bfr4sJQbBoirDCeabenmPCrXQ8Yaa TsWw== Received: by 10.50.5.205 with SMTP id u13mr5569451igu.37.1350577920648; Thu, 18 Oct 2012 09:32:00 -0700 (PDT) Received: from [192.168.0.198] ([173.156.64.64]) by mx.google.com with ESMTPS id s20sm6253252igs.10.2012.10.18.09.31.59 (version=SSLv3 cipher=OTHER); Thu, 18 Oct 2012 09:32:00 -0700 (PDT) Message-ID: <50802EFC.2010101@gmail.com> Date: Thu, 18 Oct 2012 11:31:56 -0500 From: Chuck Burns User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: 9.1-RC2 - could it be that the installer does not write the MBR? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 16:32:01 -0000 On 10/18/2012 11:05 AM, Brandon Allbery wrote: > On Thu, Oct 18, 2012 at 5:31 AM, Kimmo Paasiala wrote: > >> Such question does not make sense if the disk is GPT partitioned which >> is the default now. The boot loader is installed on a separate >> freebsd-boot partition and the MBR of the disk contains a special >> "protective MBR". > > > And what is supposed to happen if the disk has an existing MBR and existing > partitions? > Besides which.. Do you want FreeBSD to overwrite the MBR? Thus erasing grub when someone is attempting to install FreeBSD alongside Linux? If you do not want GRUB, you must remove GRUB and revert to a proper MBR. -- Chuck Burns From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 16:33:00 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 01F28E18 for ; Thu, 18 Oct 2012 16:33:00 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-ia0-f182.google.com (mail-ia0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id B55AC8FC16 for ; Thu, 18 Oct 2012 16:32:59 +0000 (UTC) Received: by mail-ia0-f182.google.com with SMTP id k10so8495320iag.13 for ; Thu, 18 Oct 2012 09:32:59 -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:references :in-reply-to:x-forwarded-message-id:content-type :content-transfer-encoding; bh=yphGteL1iAtj8tLOslT+8zPs5qFzRm1TRmXFXgQHbrw=; b=RAsm7LSbYBSQH30RgGt3+4kD3Vku+ximh8SL6lZPNWTuEfr3V5HF9akPFcBd4DOHoR lYn6dTlKUUpPA367R7OWOxGFXAFUihHgXeeDjeKF61gVn63fp92bYm5u83yQws4YR7kl oJjlUMDR3BzcWvaf41AHfjeGmnKdZEqG5rvp2Worn0m1JVyIV8IuVaNm8na+HzqsvU3A d01ykKBdZHVY4thV6VRhJgWJ6rTd60CN2kk1C4oB2qlJ9ngnmefEC5JvSfuIJcS4gwmY Q3RO+d2dadeCVVqIMstfP7xwDQVcdGM8qGszbu4Dn59QH4+hrTH/rCRrwVpcx9eMRi3G dumg== Received: by 10.50.5.239 with SMTP id v15mr5553444igv.41.1350577979030; Thu, 18 Oct 2012 09:32:59 -0700 (PDT) Received: from [192.168.0.198] ([173.156.64.64]) by mx.google.com with ESMTPS id yf6sm14633183igb.0.2012.10.18.09.32.57 (version=SSLv3 cipher=OTHER); Thu, 18 Oct 2012 09:32:58 -0700 (PDT) Message-ID: <50802F36.7020102@gmail.com> Date: Thu, 18 Oct 2012 11:32:54 -0500 From: Chuck Burns User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Fwd: Re: 9.1-RC2 - could it be that the installer does not write the MBR? References: <50802EA6.2080305@gmail.com> In-Reply-To: <50802EA6.2080305@gmail.com> X-Forwarded-Message-Id: <50802EA6.2080305@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 16:33:00 -0000 On 10/18/2012 11:05 AM, Brandon Allbery wrote: > On Thu, Oct 18, 2012 at 5:31 AM, Kimmo Paasiala wrote: > >> Such question does not make sense if the disk is GPT partitioned which >> is the default now. The boot loader is installed on a separate >> freebsd-boot partition and the MBR of the disk contains a special >> "protective MBR". > > > And what is supposed to happen if the disk has an existing MBR and existing > partitions? > With a -proper- existing MBR, it doesn't matter, since it will still pass boot off to the proper partition. But when you install an MBR partition manager that overrides the standard MBR code, you must also then uninstall it when you want to revert back to an OS that knows how to boot with a normal MBR. -- Chuck Burns -- Chuck Burns From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 16:44:31 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C169F571 for ; Thu, 18 Oct 2012 16:44:31 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from mail.ultra-secure.de (mail.ultra-secure.de [78.47.114.122]) by mx1.freebsd.org (Postfix) with ESMTP id 03BE58FC0C for ; Thu, 18 Oct 2012 16:44:30 +0000 (UTC) Received: (qmail 5265 invoked by uid 89); 18 Oct 2012 16:44:26 -0000 Received: by simscan 1.4.0 ppid: 5260, pid: 5262, t: 0.0364s scanners: attach: 1.4.0 clamav: 0.97.3/m:54/d:15475 Received: from unknown (HELO suse3) (rainer@ultra-secure.de@212.71.117.1) by mail.ultra-secure.de with ESMTPA; 18 Oct 2012 16:44:26 -0000 Date: Thu, 18 Oct 2012 18:44:26 +0200 From: Rainer Duffner To: Chuck Burns Subject: Re: 9.1-RC2 - could it be that the installer does not write the MBR? Message-ID: <20121018184426.63c59601@suse3> In-Reply-To: <50802EFC.2010101@gmail.com> References: <50802EFC.2010101@gmail.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-suse-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 16:44:31 -0000 Am Thu, 18 Oct 2012 11:31:56 -0500 schrieb Chuck Burns : > On 10/18/2012 11:05 AM, Brandon Allbery wrote: > > On Thu, Oct 18, 2012 at 5:31 AM, Kimmo Paasiala > > wrote: > > > >> Such question does not make sense if the disk is GPT partitioned > >> which is the default now. The boot loader is installed on a > >> separate freebsd-boot partition and the MBR of the disk contains a > >> special "protective MBR". > > > > > > And what is supposed to happen if the disk has an existing MBR and > > existing partitions? > > > > Besides which.. Do you want FreeBSD to overwrite the MBR? Yes. I've long since given up on FreeBSD for workstations - I simply don't have the time to get everything right. > Thus > erasing grub when someone is attempting to install FreeBSD alongside > Linux? How many people actually do that, now that there are so many virtualization-options? > If you do not want GRUB, you must remove GRUB and revert to a proper > MBR. And how do you remove GRUB? The original OS did no longer boot in my case.... Do I need to file a PR for this? From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 17:05:09 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 38195B34 for ; Thu, 18 Oct 2012 17:05:09 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id E00BC8FC14 for ; Thu, 18 Oct 2012 17:05:08 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TOtWt-0006dU-OR for freebsd-stable@freebsd.org; Thu, 18 Oct 2012 19:05:09 +0200 Received: from 79-139-19-75.prenet.pl ([79.139.19.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 18 Oct 2012 19:05:07 +0200 Received: from jb.1234abcd by 79-139-19-75.prenet.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 18 Oct 2012 19:05:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: jb Subject: Re: 9.1-RC2 - could it be that the installer does not write the MBR? Date: Thu, 18 Oct 2012 17:04:50 +0000 (UTC) Lines: 13 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 79.139.19.75 (Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20100101 Firefox/16.0) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 17:05:09 -0000 jb gmail.com> writes: > ... > I installed RC2 yesterday and noticed that there was no question asked where > to install boot loader (MBR or FB root slice/partition). > That's something needing a fix. > jb I filed a PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/172847 jb From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 17:22:21 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2FBCA53D for ; Thu, 18 Oct 2012 17:22:21 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id DE5428FC08 for ; Thu, 18 Oct 2012 17:22:20 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id k10so18519570iea.13 for ; Thu, 18 Oct 2012 10:22:20 -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=U9gxP4Pi0/Sp2hGl/cpjwyshcIS3I8nSm33NiDzDmoM=; b=00uhKuIeUWJ52wQaQSsuhz9zYw50fOiO4wXebxeEI94SuivSymiBmvgkYm12VjGnjn wweS3wy+1eSeN4INx9kfEwvmhzX3m+PD0+ImrS/7IOyp0EHpqPEQKTDaaetIWOUrybbu XnpiTFk9mSFfJD0n4voT/40mmmaXDHoR3iCQ/4FtTo7b4iesM2+6uRjq5wn9ChmmfOyf /yfY0m9x2JTNG03CHJNCTHiVnkBMoSn52gOlmY1X7fn+Tc5pT04l/isifp1C0RRPGu5+ BphADjuVom56JGppKvZOHUht8wCJ9hyPyjJuRfwSBXqHx4GUK5kdfzMB65lTbA/O5CqP cdZQ== Received: by 10.50.179.97 with SMTP id df1mr5693771igc.2.1350580940227; Thu, 18 Oct 2012 10:22:20 -0700 (PDT) Received: from blackbeast.local (173-17-34-224.client.mchsi.com. [173.17.34.224]) by mx.google.com with ESMTPS id az6sm13794344igb.11.2012.10.18.10.22.19 (version=SSLv3 cipher=OTHER); Thu, 18 Oct 2012 10:22:19 -0700 (PDT) Message-ID: <50803B22.7000706@gmail.com> Date: Thu, 18 Oct 2012 12:23:46 -0500 From: Chuck Burns User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120929 Thunderbird/15.0.1 MIME-Version: 1.0 To: Rainer Duffner Subject: Re: 9.1-RC2 - could it be that the installer does not write the MBR? References: <50802EFC.2010101@gmail.com> <20121018184426.63c59601@suse3> In-Reply-To: <20121018184426.63c59601@suse3> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 17:22:21 -0000 On 10/18/12 11:44, Rainer Duffner wrote: > Am Thu, 18 Oct 2012 11:31:56 -0500 > schrieb Chuck Burns : > >> On 10/18/2012 11:05 AM, Brandon Allbery wrote: >>> On Thu, Oct 18, 2012 at 5:31 AM, Kimmo Paasiala >>> wrote: >>> >>>> Such question does not make sense if the disk is GPT partitioned >>>> which is the default now. The boot loader is installed on a >>>> separate freebsd-boot partition and the MBR of the disk contains a >>>> special "protective MBR". >>> >>> >>> And what is supposed to happen if the disk has an existing MBR and >>> existing partitions? >>> >> >> Besides which.. Do you want FreeBSD to overwrite the MBR? > > Yes. > I've long since given up on FreeBSD for workstations - I simply don't > have the time to get everything right. > >> Thus >> erasing grub when someone is attempting to install FreeBSD alongside >> Linux? > > > How many people actually do that, now that there are so many > virtualization-options? > > >> If you do not want GRUB, you must remove GRUB and revert to a proper >> MBR. > > And how do you remove GRUB? > The original OS did no longer boot in my case.... > > Do I need to file a PR for this? > > Simply zero out first few MB of the drive, when you create a new partition map, a new MBR is created. Chuck From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 19:35:20 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CD80FAAF; Thu, 18 Oct 2012 19:35:20 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) by mx1.freebsd.org (Postfix) with ESMTP id 7AE538FC0A; Thu, 18 Oct 2012 19:35:20 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id C600B6A6001; Thu, 18 Oct 2012 21:35:18 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.5/8.14.5) with ESMTP id q9IJZI4m031695; Thu, 18 Oct 2012 21:35:18 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.5/8.14.5/Submit) id q9IJZI7s030827; Thu, 18 Oct 2012 21:35:18 +0200 (CEST) (envelope-from lars) Date: Thu, 18 Oct 2012 21:35:18 +0200 From: Lars Engels To: Andriy Gapon Subject: Re: Thinkpad X61s cannot boot 9.1-BETA1 Message-ID: <20121018193518.GL21091@e-new.0x20.net> References: <5050C6BC.8000307@FreeBSD.org> <20120912174649.GV20762@e-new.0x20.net> <5050DB57.90903@FreeBSD.org> <20120912195821.GW20762@e-new.0x20.net> <5050EBB9.7040202@FreeBSD.org> <20120913074437.GX20762@e-new.0x20.net> <505210A3.8000105@FreeBSD.org> <20120914081751.GA11773@e-new.0x20.net> <50531FC8.4090307@FreeBSD.org> <20120915114802.GL11773@e-new.0x20.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UUBKWyapWpFAak7q" Content-Disposition: inline In-Reply-To: <20120915114802.GL11773@e-new.0x20.net> X-Editor: VIM - Vi IMproved 7.3 X-Operation-System: FreeBSD 8.3-RELEASE-p4 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Alexander Motin , freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 19:35:20 -0000 --UUBKWyapWpFAak7q Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 15, 2012 at 01:48:02PM +0200, Lars Engels wrote: > On Fri, Sep 14, 2012 at 03:15:04PM +0300, Andriy Gapon wrote: > > on 14/09/2012 11:17 Lars Engels said the following: > > > Here's are some more dmesgs: > > >=20 > > > http://bsd-geek.de/FreeBSD/T61_dmesg.boot.9.works # PCBSD 9.1-RC1 s= uccessuful boot on AC power > > > http://bsd-geek.de/FreeBSD/T61_dmesg.boot.10.works # FreeBSD 10-CURR= ENT successful boot on battery > > > http://bsd-geek.de/FreeBSD/T61_dmesg.boot.9_10.diff # Their diff > > >=20 > >=20 > > Is it possible to produce two verbose dmesgs for 10 - one on AC power a= nd one on > > battery? > > I think that now you can complete booting in both cases. >=20 > Yes, they're here: >=20 > http://bsd-geek.de/FreeBSD/T61_dmesg.boot.10.works > http://bsd-geek.de/FreeBSD/T61_dmesg.boot.10_i8254.works > http://bsd-geek.de/FreeBSD/T61_dmesg.boot.10_eventtimer.diff >=20 > It shows also that with i8254 I'm having USB problems. Any news here? There's another one who has this issue on a different notebook: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D171193 --UUBKWyapWpFAak7q Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCAWfYACgkQKc512sD3afjFUgCgwHzNaEQ5jj+Z3SePEPPE3aqe j2AAn1PoE7dYBgVZ60Zt6T2PBmWX2i3Q =AykW -----END PGP SIGNATURE----- --UUBKWyapWpFAak7q-- From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 21:08:42 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 119277B8 for ; Thu, 18 Oct 2012 21:08:42 +0000 (UTC) (envelope-from a.dejoode@leaseweb.com) Received: from mailhq.ocom.com (mailhq.ocom.com [85.17.130.16]) by mx1.freebsd.org (Postfix) with ESMTP id 64FD68FC0A for ; Thu, 18 Oct 2012 21:08:40 +0000 (UTC) Received: from NLHLMEXDB03.ocom.lan ([fe80::645b:6bc9:19b9:a360]) by NLHLMEXHUB02.ocom.lan ([fe80::313e:ce9a:268c:c74%11]) with mapi id 14.02.0318.004; Thu, 18 Oct 2012 23:07:26 +0200 From: Alex de Joode To: "freebsd-stable@freebsd.org" Subject: Re: FreeBSD 9.1-RC2 Available... Thread-Topic: Re: FreeBSD 9.1-RC2 Available... Thread-Index: Ac2tdAF9eFQ/jVhhQ2Cn5A5HDMdepA== Date: Thu, 18 Oct 2012 21:07:25 +0000 Message-ID: <17ECE3EA4CEBE34A910A8B067A4DABA71B771C@nlhlmexdb03.ocom.lan> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [2001:1af8:4100:1103::7] Content-Type: multipart/mixed; boundary="_004_17ECE3EA4CEBE34A910A8B067A4DABA71B771Cnlhlmexdb03ocomla_" MIME-Version: 1.0 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 21:08:42 -0000 --_004_17ECE3EA4CEBE34A910A8B067A4DABA71B771Cnlhlmexdb03ocomla_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Updated two 9.1-RC1 machines (both R210, dual GEOM MIRRORED disk) 1 went OK; 1 went belly up (see attachment) (after the 1st reboot) - Invalid format - BTX halted. Any ideas why ? (need to upgrade more machines without KVM access ....) -AJ- --_004_17ECE3EA4CEBE34A910A8B067A4DABA71B771Cnlhlmexdb03ocomla_-- From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 21:44:11 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 90E44FE9 for ; Thu, 18 Oct 2012 21:44:11 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id 691EA8FC08 for ; Thu, 18 Oct 2012 21:44:11 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 18 Oct 2012 14:44:18 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id q9ILh2AN010854; Thu, 18 Oct 2012 14:43:02 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id q9ILh2Bh010846; Thu, 18 Oct 2012 14:43:02 -0700 (PDT) (envelope-from ambrisko) Date: Thu, 18 Oct 2012 14:43:02 -0700 From: Doug Ambrisko To: Anton Yuzhaninov Subject: Re: Problem with IPMI KCS driver Message-ID: <20121018214302.GA8009@ambrisko.com> References: <503DE2AB.6030702@citrin.ru> <201208290825.44198.jhb@freebsd.org> <506573DD.2030808@citrin.ru> <201209280848.35380.jhb@freebsd.org> <507FCF9B.9080104@citrin.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <507FCF9B.9080104@citrin.ru> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 21:44:11 -0000 On Thu, Oct 18, 2012 at 01:44:59PM +0400, Anton Yuzhaninov wrote: | On 28.09.2012 16:48, John Baldwin wrote: | >>kcs_wait_for_obf() at kcs_wait_for_obf+0xb6 point to | >>> /usr/src/sys/dev/ipmi/ipmi_kcs.c:94 | >>> | >>> 91 while (ticks - start< MAX_TIMEOUT&& | >>> 92 !(status& KCS_STATUS_OBF)) { | >>> 93 DELAY(100); | >>> 94 status = INB(sc, KCS_CTL_STS); | >>> 95 } | >Hummm. I'm a bit out of ideas then. Even the volatile change is a bug | >that | >could have been confirmed (to see if volatile was preventing the compiler | >from caching the value of 'ticks') by examining the assembly. | > | >Well, maybe this. This just avoids using 'ticks' altogether and depends on | >DELAY(100) doing what it says: | | New patch also don't solve my problem. | | My guess was wrong. Loop in kcs_wait_for_obf() is not endless, at least | with last patch. | Whole function called in some loop, but because loop in kcs_wait_for_obf() | takes much CPU time, backtrace always point to loop kcs_wait_for_obf(). Yep, the IPMI local interfaces are polled so they use a lot of CPU so it pretty much always going to be checking "are you done yet" once a command is submitted. We have local patches here that changes the DELAY into a tsleep when the system is running. It has the bad feature of making it a lot slower but uses far less CPU. So for us it is a good trade off. One reason to put it into a loop is so things happen in order and are not interrupted. I guess a different approach might be to do a "big" lock around the entire submit and get response code fargment. Then it would be expensed against the application thread running in the kernel. We also have local changes to all it to run in polled mode without the kernel thread when we are dumping a kernel backtrace into the IPMI system event log. That's nice when the kernel core hasn't worked on a remote machine but we see the back trace in SEL. | This problem need further investigation. It might be good to instrument the code in ipmi.c in which it sending a command and then getting status. If that is actually looking okay then maybe some application is doing something bad. Doug A. From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 23:20:21 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 487A2E7F for ; Thu, 18 Oct 2012 23:20:21 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from mail4.riverwillow.net.au (mail4.riverwillow.net.au [202.125.45.59]) by mx1.freebsd.org (Postfix) with ESMTP id DD1718FC08 for ; Thu, 18 Oct 2012 23:20:20 +0000 (UTC) Received: from [172.25.24.201] (CPE-60-225-19-68.home33.cht.bigpond.net.au [60.225.19.68]) (authenticated bits=0) by mail4.riverwillow.net.au (8.14.5/8.14.5) with ESMTP id q9INK7vS028761 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 19 Oct 2012 09:20:11 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=m4001; t=1350602411; bh=ql5uXnkYnE7aXztMPny385rz6GPjJuRRGSc2FNMJkXc=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=aH48OsfJK4vs5TWL4wG/kjJsVYhR5b4QcoiczFF7tIwgEGtmpyVdGGH8NMHHJuJfz PuNURS+aYITbIiibVgdUYXDvGxDfS9VvQE6HXqgctwOZH+bdjXT6tlVhb7UNyI9IJ/ Ql4vfgByZQ6VGoT9641RbsXZBiJnMZVE6Orwbkq8= Message-ID: <50808E9D.4010601@riverwillow.com.au> Date: Fri, 19 Oct 2012 10:19:57 +1100 From: John Marshall Organization: Riverwillow Pty Ltd User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20121016 Thunderbird/16.0.1 MIME-Version: 1.0 To: George Mamalakis Subject: Re: mod_auth_kerb2 broken in 8-STABLE? Or is it heimdal to blame? References: <4D9C86E8.3090402@eng.auth.gr> <4D9D9B22.2020701@eng.auth.gr> <5069BFE4.9040500@eng.auth.gr> In-Reply-To: <5069BFE4.9040500@eng.auth.gr> X-Enigmail-Version: 1.4.5 OpenPGP: id=A29A84A2; url=http://pki.riverwillow.com.au/pgp/johnmarshall.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB8FFB965534062729F2267BC" Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 23:20:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB8FFB965534062729F2267BC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 02/10/2012 02:08, George Mamalakis wrote: > On 04/07/11 14:08, George Mamalakis wrote: >> On 06/04/2011 18:29, George Mamalakis wrote: >>> Dear all, >>> >>> I installed mod_auth_kerb2 on my FreeBSD 8-STABLE machine and tried >>> to use it. After the installation (which was successful(?!?)), the >>> server refused to start giving the error: >>> >>> # /usr/local/etc/rc.d/apache22 start >>> Performing sanity check on apache22 configuration: >>> httpd: Syntax error on line 103 of >>> /usr/local/etc/apache22/httpd.conf: Cannot load >>> /usr/local/libexec/apache22/mod_auth_kerb.so into server: >>> /usr/local/libexec/apache22/mod_auth_kerb.so: Undefined symbol >>> "gsskrb5_register_acceptor_identity" >>> Starting apache22. >>> httpd: Syntax error on line 103 of >>> /usr/local/etc/apache22/httpd.conf: Cannot load >>> /usr/local/libexec/apache22/mod_auth_kerb.so into server: >>> /usr/local/libexec/apache22/mod_auth_kerb.so: Undefined symbol >>> "gsskrb5_register_acceptor_identity" >>> /usr/local/etc/rc.d/apache22: WARNING: failed to start apache22 >>> >>> but ldd showed: >>> >>> # ldd /usr/local/libexec/apache22/mod_auth_kerb.so >>> /usr/local/libexec/apache22/mod_auth_kerb.so: >>> libgssapi.so.10 =3D> /usr/lib/libgssapi.so.10 (0x800c00000) >>> libheimntlm.so.10 =3D> /usr/lib/libheimntlm.so.10 (0x800d0a000) >>> libkrb5.so.10 =3D> /usr/lib/libkrb5.so.10 (0x800e0f000) >>> libhx509.so.10 =3D> /usr/lib/libhx509.so.10 (0x800f7e000) >>> libcom_err.so.5 =3D> /usr/lib/libcom_err.so.5 (0x8010be000) >>> libcrypto.so.6 =3D> /lib/libcrypto.so.6 (0x8011c0000) >>> libasn1.so.10 =3D> /usr/lib/libasn1.so.10 (0x801461000) >>> libroken.so.10 =3D> /usr/lib/libroken.so.10 (0x8015e3000) >>> libcrypt.so.5 =3D> /lib/libcrypt.so.5 (0x8016f5000) >>> libc.so.7 =3D> /lib/libc.so.7 (0x800647000) >>> >>> which showed that everything should have been fine. I googled it a >>> bit and found this thread regarding my error message: >>> http://forum.nginx.org/read.php?23,88476 , which started on May 2010,= >>> and pointed to this PR: >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D147454 , which started o= n >>> June 2010. What is stated, is that heimdal-1.1 was broken in FreeBSD,= >>> and that it should be fixed at some moment in the future. (I tested >>> mod_auth_kerb2 on another machine running heimdal from ports (1.4_1) >>> and I had exactly the same problem). >>> >>> I searched to find where this notorious function >>> (gsskrb5_register_acceptor_identity) was located, and I found its >>> declaration in: /usr/include/gssapi/gssapi_krb5.h, and its definition= >>> in: /usr/lib/libgssapi_krb5.so. >>> >>> So, I added -lgssapi_krb5 in KRB5_LDFLAGS variable of >>> /usr/ports/www/mod_auth_kerb2/work/mod_auth_kerb-5.4/Makefile , since= >>> this where the location of gsskrb5_register_acceptor_identity >>> originally seemed to be, and reinstalled the port using gmake this >>> time (inside the port's work directory). After that, the module works= >>> just fine. The initial content of this line was: >>> >>> KRB5_LDFLAGS =3D -L/usr/lib -lgssapi -lheimntlm -lkrb5 -lhx509 >>> -lcom_err -lcrypto -lasn1 -lroken -lcrypt >>> >>> I've sent an analogous email to the port maintainer, but I am not >>> sure if it is their "fault". Hence, I decided to send this email to >>> the stable list for two reasons: First, someone else may be having a >>> similar problem and wants to find a rough solution. Secondly, there >>> are people reading this list that know heimdal's code, so somebody >>> may know another (much more elegant) way to fix this bug. >>> >>> Thank you all for your time in advance, >>> >>> Regards, >>> >>> mamalos. >>> >> >> OK, >> >> I spoke with the maintainer who confirmed the problem. He also >> suggested to change line 96 of /usb/bin/krb5-config to include >> gssapi_krb5 among its libraries. He also gave me the relevant patch, >> and asked me to send a PR to FreeBSD. The patch is as follows: >> >> --- /usr/bin/krb5-config.orig 2011-02-17 03:18:57.000000000 +0100 >> +++ /usr/bin/krb5-config 2011-04-06 23:41:31.000000000 +0200 >> @@ -93,7 +93,7 @@ >> lib_flags=3D"-L${libdir}" >> case $library in >> gssapi) >> - lib_flags=3D"$lib_flags -lgssapi -lheimntlm" >> + lib_flags=3D"$lib_flags -lgssapi -lgssapi_krb5 -lheimntlm" >> ;; >> kadm-client) >> lib_flags=3D"$lib_flags -lkadm5clnt" >> >> >> >> And the relevant PR is: >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D156245 >> >> Thank you all for your time, >> >> mamalos >> > Hi all, >=20 > I am bringing this matter back again because the same things hold for m= y > current system too (/usr/bin/krb5-config does not seem to link > gssapi-things properly): >=20 > # uname -a > FreeBSD example.com 9.0-STABLE FreeBSD 9.0-STABLE #0: Mon Jun 18 > 21:04:14 EEST 2012 root@example.com:/usr/obj/usr/src/sys/FILESRV amd64= > # pkg_info -Ix apache kerb > ap22-mod_auth_kerb-5.4_3 An Apache module for authenticating users with= > Kerberos v5 > apache22-2.2.22_8 Version 2.2.x of Apache web server with prefork MPM= =2E >=20 > Should I send a PR or is there something that I've done wrong? I've seen the same thing on 8.3-RELEASE, 9.1-RC1 and 9.1-RC2. In all cases, applying your patch (thank you!) to /usr/bin/krb5-config resolved the issue. I did not need to patch krb5-config for other GSSAPI servers to work (dovecot and sendmail) but they are obviously satisified with -lgssapi and don't need routines supplied via -lgssapi_krb5. Thus far, www/mod_auth_kerb2 is the only port I've used which appears to need gssapi_krb5. I think this is purely a FreeBSD Heimdal config issue. --=20 John Marshall --------------enigB8FFB965534062729F2267BC 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.19 (FreeBSD) iEYEARECAAYFAlCAjqcACgkQw/tAaKKahKL0fACgmSOlKpZ4FXgi9xiWzJzQOvrO t3AAoJT/Csh3GKh/GMIL/ARHlVqXwT6Z =A+sF -----END PGP SIGNATURE----- --------------enigB8FFB965534062729F2267BC-- From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 08:39:05 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AE338E99 for ; Fri, 19 Oct 2012 08:39:05 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from vergina.eng.auth.gr (vergina.eng.auth.gr [155.207.18.1]) by mx1.freebsd.org (Postfix) with ESMTP id 13C6A8FC08 for ; Fri, 19 Oct 2012 08:39:04 +0000 (UTC) Received: from mamalacation.ee.auth.gr (mamalacation.ee.auth.gr [155.207.33.29]) (authenticated bits=0) by vergina.eng.auth.gr (8.14.4/8.14.3) with ESMTP id q9J8d0GR032993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Oct 2012 11:39:03 +0300 (EEST) (envelope-from mamalos@eng.auth.gr) Message-ID: <5081119A.9080107@eng.auth.gr> Date: Fri, 19 Oct 2012 11:38:50 +0300 From: George Mamalakis User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121012 Thunderbird/16.0.1 MIME-Version: 1.0 To: John Marshall Subject: Re: mod_auth_kerb2 broken in 8-STABLE? Or is it heimdal to blame? References: <4D9C86E8.3090402@eng.auth.gr> <4D9D9B22.2020701@eng.auth.gr> <5069BFE4.9040500@eng.auth.gr> <50808E9D.4010601@riverwillow.com.au> In-Reply-To: <50808E9D.4010601@riverwillow.com.au> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (vergina.eng.auth.gr [192.168.18.7]); Fri, 19 Oct 2012 11:39:03 +0300 (EEST) Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 08:39:05 -0000 On 19/10/2012 02:19 πμ, John Marshall wrote: > On 02/10/2012 02:08, George Mamalakis wrote: >> On 04/07/11 14:08, George Mamalakis wrote: >>> On 06/04/2011 18:29, George Mamalakis wrote: >>>> Dear all, >>>> >>>> I installed mod_auth_kerb2 on my FreeBSD 8-STABLE machine and tried >>>> to use it. After the installation (which was successful(?!?)), the >>>> server refused to start giving the error: >>>> >>>> # /usr/local/etc/rc.d/apache22 start >>>> Performing sanity check on apache22 configuration: >>>> httpd: Syntax error on line 103 of >>>> /usr/local/etc/apache22/httpd.conf: Cannot load >>>> /usr/local/libexec/apache22/mod_auth_kerb.so into server: >>>> /usr/local/libexec/apache22/mod_auth_kerb.so: Undefined symbol >>>> "gsskrb5_register_acceptor_identity" >>>> Starting apache22. >>>> httpd: Syntax error on line 103 of >>>> /usr/local/etc/apache22/httpd.conf: Cannot load >>>> /usr/local/libexec/apache22/mod_auth_kerb.so into server: >>>> /usr/local/libexec/apache22/mod_auth_kerb.so: Undefined symbol >>>> "gsskrb5_register_acceptor_identity" >>>> /usr/local/etc/rc.d/apache22: WARNING: failed to start apache22 >>>> >>>> but ldd showed: >>>> >>>> # ldd /usr/local/libexec/apache22/mod_auth_kerb.so >>>> /usr/local/libexec/apache22/mod_auth_kerb.so: >>>> libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x800c00000) >>>> libheimntlm.so.10 => /usr/lib/libheimntlm.so.10 (0x800d0a000) >>>> libkrb5.so.10 => /usr/lib/libkrb5.so.10 (0x800e0f000) >>>> libhx509.so.10 => /usr/lib/libhx509.so.10 (0x800f7e000) >>>> libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x8010be000) >>>> libcrypto.so.6 => /lib/libcrypto.so.6 (0x8011c0000) >>>> libasn1.so.10 => /usr/lib/libasn1.so.10 (0x801461000) >>>> libroken.so.10 => /usr/lib/libroken.so.10 (0x8015e3000) >>>> libcrypt.so.5 => /lib/libcrypt.so.5 (0x8016f5000) >>>> libc.so.7 => /lib/libc.so.7 (0x800647000) >>>> >>>> which showed that everything should have been fine. I googled it a >>>> bit and found this thread regarding my error message: >>>> http://forum.nginx.org/read.php?23,88476 , which started on May 2010, >>>> and pointed to this PR: >>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=147454 , which started on >>>> June 2010. What is stated, is that heimdal-1.1 was broken in FreeBSD, >>>> and that it should be fixed at some moment in the future. (I tested >>>> mod_auth_kerb2 on another machine running heimdal from ports (1.4_1) >>>> and I had exactly the same problem). >>>> >>>> I searched to find where this notorious function >>>> (gsskrb5_register_acceptor_identity) was located, and I found its >>>> declaration in: /usr/include/gssapi/gssapi_krb5.h, and its definition >>>> in: /usr/lib/libgssapi_krb5.so. >>>> >>>> So, I added -lgssapi_krb5 in KRB5_LDFLAGS variable of >>>> /usr/ports/www/mod_auth_kerb2/work/mod_auth_kerb-5.4/Makefile , since >>>> this where the location of gsskrb5_register_acceptor_identity >>>> originally seemed to be, and reinstalled the port using gmake this >>>> time (inside the port's work directory). After that, the module works >>>> just fine. The initial content of this line was: >>>> >>>> KRB5_LDFLAGS = -L/usr/lib -lgssapi -lheimntlm -lkrb5 -lhx509 >>>> -lcom_err -lcrypto -lasn1 -lroken -lcrypt >>>> >>>> I've sent an analogous email to the port maintainer, but I am not >>>> sure if it is their "fault". Hence, I decided to send this email to >>>> the stable list for two reasons: First, someone else may be having a >>>> similar problem and wants to find a rough solution. Secondly, there >>>> are people reading this list that know heimdal's code, so somebody >>>> may know another (much more elegant) way to fix this bug. >>>> >>>> Thank you all for your time in advance, >>>> >>>> Regards, >>>> >>>> mamalos. >>>> >>> OK, >>> >>> I spoke with the maintainer who confirmed the problem. He also >>> suggested to change line 96 of /usb/bin/krb5-config to include >>> gssapi_krb5 among its libraries. He also gave me the relevant patch, >>> and asked me to send a PR to FreeBSD. The patch is as follows: >>> >>> --- /usr/bin/krb5-config.orig 2011-02-17 03:18:57.000000000 +0100 >>> +++ /usr/bin/krb5-config 2011-04-06 23:41:31.000000000 +0200 >>> @@ -93,7 +93,7 @@ >>> lib_flags="-L${libdir}" >>> case $library in >>> gssapi) >>> - lib_flags="$lib_flags -lgssapi -lheimntlm" >>> + lib_flags="$lib_flags -lgssapi -lgssapi_krb5 -lheimntlm" >>> ;; >>> kadm-client) >>> lib_flags="$lib_flags -lkadm5clnt" >>> >>> >>> >>> And the relevant PR is: >>> >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=156245 >>> >>> Thank you all for your time, >>> >>> mamalos >>> >> Hi all, >> >> I am bringing this matter back again because the same things hold for my >> current system too (/usr/bin/krb5-config does not seem to link >> gssapi-things properly): >> >> # uname -a >> FreeBSD example.com 9.0-STABLE FreeBSD 9.0-STABLE #0: Mon Jun 18 >> 21:04:14 EEST 2012 root@example.com:/usr/obj/usr/src/sys/FILESRV amd64 >> # pkg_info -Ix apache kerb >> ap22-mod_auth_kerb-5.4_3 An Apache module for authenticating users with >> Kerberos v5 >> apache22-2.2.22_8 Version 2.2.x of Apache web server with prefork MPM. >> >> Should I send a PR or is there something that I've done wrong? > I've seen the same thing on 8.3-RELEASE, 9.1-RC1 and 9.1-RC2. In all > cases, applying your patch (thank you!) to /usr/bin/krb5-config resolved > the issue. I did not need to patch krb5-config for other GSSAPI servers > to work (dovecot and sendmail) but they are obviously satisified with > -lgssapi and don't need routines supplied via -lgssapi_krb5. Thus far, > www/mod_auth_kerb2 is the only port I've used which appears to need > gssapi_krb5. > > I think this is purely a FreeBSD Heimdal config issue. > John, thank you for your confirmation on this. I really don't understand why FreeBSD hasn't resolved this issue since 7 Apr 2011 when I first filed this PR. Hope they'll do it this time (I sent a follow-up to my previous PR). George. From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 13:27:18 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C2CD662E for ; Fri, 19 Oct 2012 13:27:18 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1AC1B8FC18 for ; Fri, 19 Oct 2012 13:27:17 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA29779; Fri, 19 Oct 2012 16:27:12 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <5081552F.2050303@FreeBSD.org> Date: Fri, 19 Oct 2012 16:27:11 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121014 Thunderbird/16.0.1 MIME-Version: 1.0 To: Derek Kulinski Subject: Re: Problem reading vitals from Gigabyte H77-DH3H References: <1286515493.20121017131543@takeda.tk> <507F1761.1010202@FreeBSD.org> <20121017205147.GB36106@chinatsu.takeda.tk> In-Reply-To: <20121017205147.GB36106@chinatsu.takeda.tk> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 13:27:18 -0000 on 17/10/2012 23:51 Derek Kulinski said the following: > On Wed, Oct 17, 2012 at 11:38:57PM +0300, Andriy Gapon wrote: >> I've found that on quite a few modern systems the ACPI platform advertises some >> useless thermal zones, which always return some hardcoded temperatures. >> E.g. I have Asus P8Z77-M PRO near me and it also reports two thermal zones. >> Looking at DSDT (acpidump -dt) I see that the temperatures are hardcoded. >> >> It seems that your motherboard has an ITE Super I/O with hardware monitoring >> function. I am not sure which model though... >> Your best bet would be it(4) driver, but it is not committed yet. >> If you are into some mild hacking (applying patches, building custom kernel), >> then I can point you to the patches. >> Although I can not give a firm guarantee that the driver supports your HWM chip, >> since I don't know the model. > > I'm open to experimenting. It's kind of important to me, because I recently had heating issue (that I hopefully fixed) and I wasn't aware of problems until my system started freezing. I was fooled by those values thinking everything was ok. Here is a (quite large) patch: http://people.freebsd.org/~avg/sensors.diff Please note that if affects both kernel and userland code. Read it(4) manual page after upgrading. Note that you will need to add some entries to /boot/device.hints (unless your upgrade procedure would automatically merge the file). >> [...] >> >> These tools from ports are very outdated and thus do not support new hardware. > > I never used them before since on my old box hw.acpi.thermal worked fine. > Is there anything in ports that you would recommend? No. I do not know of any good userland tool for recent hardware. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 13:28:34 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9853F740 for ; Fri, 19 Oct 2012 13:28:34 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DDE838FC12 for ; Fri, 19 Oct 2012 13:28:33 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA29786; Fri, 19 Oct 2012 16:28:28 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <5081557C.7000504@FreeBSD.org> Date: Fri, 19 Oct 2012 16:28:28 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121014 Thunderbird/16.0.1 MIME-Version: 1.0 To: Derek Kulinski Subject: Re: Problem reading vitals from Gigabyte H77-DH3H References: <1286515493.20121017131543@takeda.tk> <507F1761.1010202@FreeBSD.org> <20121017205147.GB36106@chinatsu.takeda.tk> <5081552F.2050303@FreeBSD.org> In-Reply-To: <5081552F.2050303@FreeBSD.org> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 13:28:34 -0000 on 19/10/2012 16:27 Andriy Gapon said the following: > on 17/10/2012 23:51 Derek Kulinski said the following: [snip] >> I'm open to experimenting. It's kind of important to me, because I recently had heating issue (that I hopefully fixed) and I wasn't aware of problems until my system started freezing. I was fooled by those values thinking everything was ok. > > Here is a (quite large) patch: http://people.freebsd.org/~avg/sensors.diff Forgot to mention - the patch is against recent-ish head. > Please note that if affects both kernel and userland code. > Read it(4) manual page after upgrading. Note that you will need to add some > entries to /boot/device.hints (unless your upgrade procedure would automatically > merge the file). -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 13:30:16 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 63A7D89E for ; Fri, 19 Oct 2012 13:30:16 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 997E88FC0A for ; Fri, 19 Oct 2012 13:30:15 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA29810; Fri, 19 Oct 2012 16:30:12 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <508155E4.3040602@FreeBSD.org> Date: Fri, 19 Oct 2012 16:30:12 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121014 Thunderbird/16.0.1 MIME-Version: 1.0 To: Alex de Joode Subject: Re: FreeBSD 9.1-RC2 Available... References: <17ECE3EA4CEBE34A910A8B067A4DABA71B771C@nlhlmexdb03.ocom.lan> In-Reply-To: <17ECE3EA4CEBE34A910A8B067A4DABA71B771C@nlhlmexdb03.ocom.lan> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 13:30:16 -0000 on 19/10/2012 00:07 Alex de Joode said the following: > Updated two 9.1-RC1 machines (both R210, dual GEOM MIRRORED disk) > > > 1 went OK; > 1 went belly up (see attachment) (after the 1st reboot) There is no spoon^Wattachment. Consider sending a link. > - Invalid format > > - BTX halted. > > > Any ideas why ? (need to upgrade more machines without KVM access ....) -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 18:26:48 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6F06ACBF; Fri, 19 Oct 2012 18:26:48 +0000 (UTC) (envelope-from a.dejoode@leaseweb.com) Received: from mailhq.ocom.com (mailhq.ocom.com [85.17.130.16]) by mx1.freebsd.org (Postfix) with ESMTP id EC0508FC18; Fri, 19 Oct 2012 18:26:47 +0000 (UTC) Received: from NLHLMEXDB03.ocom.lan ([fe80::645b:6bc9:19b9:a360]) by NLHLMEXHUB02.ocom.lan ([fe80::313e:ce9a:268c:c74%11]) with mapi id 14.02.0318.004; Fri, 19 Oct 2012 20:26:46 +0200 From: Alex de Joode To: Andriy Gapon Subject: RE: FreeBSD 9.1-RC2 Available... Thread-Topic: FreeBSD 9.1-RC2 Available... Thread-Index: AQHNrf74uXwfn96I1UmOvqWWbmczWJfA8hJw Date: Fri, 19 Oct 2012 18:26:45 +0000 Message-ID: <17ECE3EA4CEBE34A910A8B067A4DABA71B9B3C@nlhlmexdb03.ocom.lan> References: <17ECE3EA4CEBE34A910A8B067A4DABA71B771C@nlhlmexdb03.ocom.lan> <508155E4.3040602@FreeBSD.org> In-Reply-To: <508155E4.3040602@FreeBSD.org> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:1af8:4100:1103::7] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 18:26:48 -0000 https://sabotage.org/FBSD/FBSD-9.1RC2.jpg Screen shot. Basicly the only diff between the two r210 are the disks,=20 one has 2x2TB (works) and the one that has 2x1Tb fails with the above error= . Both are sw/ mirrored. No hw/ raid and ACHI sata settings. : -----Original Message----- : From: Andriy Gapon [mailto:avg@FreeBSD.org] : Sent: Friday, October 19, 2012 3:30 PM : To: Alex de Joode : Cc: freebsd-stable@freebsd.org : Subject: Re: FreeBSD 9.1-RC2 Available... :=20 : on 19/10/2012 00:07 Alex de Joode said the following: : > Updated two 9.1-RC1 machines (both R210, dual GEOM MIRRORED disk) : > : > : > 1 went OK; : > 1 went belly up (see attachment) (after the 1st reboot) :=20 : There is no spoon^Wattachment. : Consider sending a link. :=20 : > - Invalid format : > : > - BTX halted. : > : > : > Any ideas why ? (need to upgrade more machines without KVM access ....) :=20 :=20 : -- : Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 18:32:55 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B27DCF7B for ; Fri, 19 Oct 2012 18:32:55 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7C9538FC14 for ; Fri, 19 Oct 2012 18:32:55 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so607028pad.13 for ; Fri, 19 Oct 2012 11:32:49 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=P3NdpSOp4tO4jvGhwQU4I3RcW6QxobcUWrmqACiglFE=; b=Ls75jC5Zvk1g06UN8I8/0CUj5s+MiAuuPjoa3fbSSAt3HBJO0qz4Pevk2SLI8m2Gaw iMJzeCMIeF2s4egItsQMC19T+il6NsPLg7pEXr9hQ3ru0c3w2pO63i9Gb29oMXLFrYXa VP541EyrXrem5qxGWF7BHinxG1hSUSKj/WoK6peH1R4yFRmBwHHzF+sboyuzn7iMMFfH qXKmevuvyI+JOwYt0kXvENTLGERTeCrueT9L9WtBLXx8kpjbHXNZPPwZX5tnwSXzLH4c 72i2ZlwPcw/mMdyozNfiLvKu/ZI3/rouZyAzGJVtfZvVyr+FGmYqqzT9uz0VzXzLc4gc nuZQ== MIME-Version: 1.0 Received: by 10.68.197.9 with SMTP id iq9mr8142967pbc.130.1350671569633; Fri, 19 Oct 2012 11:32:49 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.146.233 with HTTP; Fri, 19 Oct 2012 11:32:49 -0700 (PDT) In-Reply-To: <50803B22.7000706@gmail.com> References: <50802EFC.2010101@gmail.com> <20121018184426.63c59601@suse3> <50803B22.7000706@gmail.com> Date: Fri, 19 Oct 2012 11:32:49 -0700 X-Google-Sender-Auth: mxhXey_4H0Dj_GHwOJSJ8Du0J0A Message-ID: Subject: Re: 9.1-RC2 - could it be that the installer does not write the MBR? From: Adrian Chadd To: Chuck Burns Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org, Rainer Duffner X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 18:32:55 -0000 Guys/girls/etc, I do suggest that someone actually spends some time coming up with a table of "what the current state is", "what we could do", "what would happen if we did that." Right now there's a lot of possibilities (new drive, drive with windows, drive with linux, drive with linux/windows, drive with legacy freebsd MBR, etc) and as an outsider trying to figure out what is actually the "right" sounding behaviour, it's difficult for me to sit down and digest all these emails that chip away at a bit of the problem at a time. So if you'd like to see this fixed, I really do suggest that one of you dumps some time into coming up with a basic table like I said above, work with others who can correct/flesh out the various options to take into account, and then we can come up with a real solution. Then 9.1 can go out the door. Adrian From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 20:20:46 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 43021CE2; Fri, 19 Oct 2012 20:20:46 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-ia0-f182.google.com (mail-ia0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id DA1608FC08; Fri, 19 Oct 2012 20:20:45 +0000 (UTC) Received: by mail-ia0-f182.google.com with SMTP id k10so812348iag.13 for ; Fri, 19 Oct 2012 13:20:45 -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=QUrs4TBUNFF3LsYxVgBf5pNAvrYD9fhvnp2skMdKzek=; b=DyEXUyu5ied7UwvXVdeJQA5t2x838BApbnSqPvKg0qUXbPrSSrr9aX4q6gCJjhiHM3 QYCXS4/UcEzsr44wxpisaD0+slU7ESs4JD2P+koNpk/gpcS9uALum+Yb1ocL+Mpm6mRO Vwbfk9MyEZFtjC74/WraTgAnHsB3b4bySKoyXfHSEP19cvNZPiGJBKBW+MoYy5GrzCeM htXZEHWaNWRiq/RTKo4/fnw0KE/XH2jnYFZJgTFyl4pPsBFw6F4x7sscgEaDAa/aeSLU wuxmwXXAcf8yPkjwOhwMU/9i8JxHmkNWRQck2nLlN3vAkuEVFgEc+JMHB8chIdVK+DSc WrtA== Received: by 10.50.169.35 with SMTP id ab3mr2717533igc.8.1350678045031; Fri, 19 Oct 2012 13:20:45 -0700 (PDT) Received: from [192.168.0.198] ([108.119.194.69]) by mx.google.com with ESMTPS id x5sm7336681igc.14.2012.10.19.13.20.41 (version=SSLv3 cipher=OTHER); Fri, 19 Oct 2012 13:20:43 -0700 (PDT) Message-ID: <5081B614.7060308@gmail.com> Date: Fri, 19 Oct 2012 15:20:36 -0500 From: Chuck Burns User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: 9.1-RC2 - could it be that the installer does not write the MBR? References: <50802EFC.2010101@gmail.com> <20121018184426.63c59601@suse3> <50803B22.7000706@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Rainer Duffner X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 20:20:46 -0000 On 10/19/2012 1:32 PM, Adrian Chadd wrote: > Guys/girls/etc, > > I do suggest that someone actually spends some time coming up with a > table of "what the current state is", "what we could do", "what would > happen if we did that." > > Right now there's a lot of possibilities (new drive, drive with > windows, drive with linux, drive with linux/windows, drive with legacy > freebsd MBR, etc) and as an outsider trying to figure out what is > actually the "right" sounding behaviour, it's difficult for me to sit > down and digest all these emails that chip away at a bit of the > problem at a time. > > So if you'd like to see this fixed, I really do suggest that one of > you dumps some time into coming up with a basic table like I said > above, work with others who can correct/flesh out the various options > to take into account, and then we can come up with a real solution. > Then 9.1 can go out the door. > > > > Adrian > In my opinion, I think that the installer should be able to determine whether or not there is an existing partition table, either MBR or GPT, and at that point, ask the user about replacing MBR. But if there is no existing partition map on the drive, then there is no need for prompting about MBR over-writing. Basically: detect if map exists, if not, proceed as usual, if part-table/map is detected, prompt user "Existing partitions detected, Should we replace any existing MBR boot code? Only advanced users who know what they're doing should say "No" here, as this could leave you with an unbootable system: Yes/No (Recommended: Yes)" -- Chuck Burns From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 20:38:55 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CA3E03D3 for ; Fri, 19 Oct 2012 20:38:55 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from mail.ultra-secure.de (mail.ultra-secure.de [78.47.114.122]) by mx1.freebsd.org (Postfix) with ESMTP id 22B838FC0A for ; Fri, 19 Oct 2012 20:38:54 +0000 (UTC) Received: (qmail 46995 invoked by uid 89); 19 Oct 2012 20:38:47 -0000 Received: by simscan 1.4.0 ppid: 46990, pid: 46992, t: 0.0904s scanners: attach: 1.4.0 clamav: 0.97.3/m:54/d:15480 Received: from unknown (HELO linux-wb36.example.org) (rainer@ultra-secure.de@217.71.83.52) by mail.ultra-secure.de with ESMTPA; 19 Oct 2012 20:38:47 -0000 Date: Fri, 19 Oct 2012 22:38:41 +0200 From: Rainer Duffner To: Adrian Chadd Subject: Re: 9.1-RC2 - could it be that the installer does not write the MBR? Message-ID: <20121019223841.09866aac@linux-wb36.example.org> In-Reply-To: References: <50802EFC.2010101@gmail.com> <20121018184426.63c59601@suse3> <50803B22.7000706@gmail.com> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.7; i586-suse-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Chuck Burns X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 20:38:55 -0000 Am Fri, 19 Oct 2012 11:32:49 -0700 schrieb Adrian Chadd : > Guys/girls/etc, > > I do suggest that someone actually spends some time coming up with a > table of "what the current state is", "what we could do", "what would > happen if we did that." > > Right now there's a lot of possibilities (new drive, drive with > windows, drive with linux, drive with linux/windows, drive with legacy > freebsd MBR, etc) and as an outsider trying to figure out what is > actually the "right" sounding behaviour, it's difficult for me to sit > down and digest all these emails that chip away at a bit of the > problem at a time. > > So if you'd like to see this fixed, I really do suggest that one of > you dumps some time into coming up with a basic table like I said > above, work with others who can correct/flesh out the various options > to take into account, and then we can come up with a real solution. > Then 9.1 can go out the door. > If I select the "entire disk" for FreeBSD, I think it's a reasonable assumption that the MBR should replaced, too. Please don't make people install FreeBSD 9.0 first on disks with non-FreeBSD MRRs and then upgrade to 9.1. From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 21:11:34 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2FE38891; Fri, 19 Oct 2012 21:11:34 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id F07FA8FC08; Fri, 19 Oct 2012 21:11:33 +0000 (UTC) Received: from glenbarber.us (nucleus.glenbarber.us [IPv6:2001:470:8:1205:2:2:0:100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 8549C23F645; Fri, 19 Oct 2012 17:11:32 -0400 (EDT) Date: Fri, 19 Oct 2012 17:11:30 -0400 From: Glen Barber To: Rainer Duffner Subject: Re: 9.1-RC2 - could it be that the installer does not write the MBR? Message-ID: <20121019211130.GM1393@glenbarber.us> References: <50802EFC.2010101@gmail.com> <20121018184426.63c59601@suse3> <50803B22.7000706@gmail.com> <20121019223841.09866aac@linux-wb36.example.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tbBCmy51UvWhYeBI" Content-Disposition: inline In-Reply-To: <20121019223841.09866aac@linux-wb36.example.org> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Adrian Chadd , freebsd-stable@freebsd.org, Chuck Burns X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 21:11:34 -0000 --tbBCmy51UvWhYeBI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 19, 2012 at 10:38:41PM +0200, Rainer Duffner wrote: > Am Fri, 19 Oct 2012 11:32:49 -0700 > schrieb Adrian Chadd : >=20 > > Guys/girls/etc, > >=20 > > I do suggest that someone actually spends some time coming up with a > > table of "what the current state is", "what we could do", "what would > > happen if we did that." > >=20 > > Right now there's a lot of possibilities (new drive, drive with > > windows, drive with linux, drive with linux/windows, drive with legacy > > freebsd MBR, etc) and as an outsider trying to figure out what is > > actually the "right" sounding behaviour, it's difficult for me to sit > > down and digest all these emails that chip away at a bit of the > > problem at a time. > >=20 > > So if you'd like to see this fixed, I really do suggest that one of > > you dumps some time into coming up with a basic table like I said > > above, work with others who can correct/flesh out the various options > > to take into account, and then we can come up with a real solution. > > Then 9.1 can go out the door. > >=20 >=20 >=20 > If I select the "entire disk" for FreeBSD, I think it's a reasonable > assumption that the MBR should replaced, too. > Please don't make people install FreeBSD 9.0 first on disks with > non-FreeBSD MRRs and then upgrade to 9.1. >=20 Can you outline for me in detail what you did when you partitioned your drive during the installation? I have seen your specific issue exactly once, and reliably reproducing the problem has not been successful so far. BTW, what was on the drive before you did the install, if anything? Glen --tbBCmy51UvWhYeBI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQgcICAAoJEFJPDDeguUaj948IAJWyrnKbBioaPAZdqwbU1kuc uizNeP1UWBGZ7X8o1JblUv0b0kEcnyuifpfb35DUzs2jey4NCO58PYGV6SuDEXer YG5r8Hb7cGxJm3BpMnj5NPyIYyJlyXNILHrVG+jfaupFrSVCnnQz+Uue/2GCRQiu juXMIooKnxVdkgvBZP1pxJT+n+NR5WzHGz4xvtrJ9MRHMjveg8xASjM74frMnM0q CxvfJhKbmUhe4SOtq9afp4nQ8+3lt831pWctSHrI386hXb/hu6XOTc+W/22+JfaN R7u1ULdhqBkZqh+Ud6euihXoLW8CLYd1X7t3mo+7THD70dhqZ0PEYFuOyebOk3s= =NR/o -----END PGP SIGNATURE----- --tbBCmy51UvWhYeBI-- From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 21:31:43 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D391CCE9; Fri, 19 Oct 2012 21:31:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id A67D18FC16; Fri, 19 Oct 2012 21:31:43 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 018E6B97C; Fri, 19 Oct 2012 17:31:43 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Subject: Re: FreeBSD 9.1-RC2 Available... Date: Fri, 19 Oct 2012 17:31:22 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <17ECE3EA4CEBE34A910A8B067A4DABA71B771C@nlhlmexdb03.ocom.lan> <508155E4.3040602@FreeBSD.org> <17ECE3EA4CEBE34A910A8B067A4DABA71B9B3C@nlhlmexdb03.ocom.lan> In-Reply-To: <17ECE3EA4CEBE34A910A8B067A4DABA71B9B3C@nlhlmexdb03.ocom.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201210191731.22668.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 19 Oct 2012 17:31:43 -0400 (EDT) Cc: Alex de Joode , Andriy Gapon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 21:31:43 -0000 On Friday, October 19, 2012 2:26:45 pm Alex de Joode wrote: > https://sabotage.org/FBSD/FBSD-9.1RC2.jpg > > Screen shot. Basicly the only diff between the two r210 are the disks, > one has 2x2TB (works) and the one that has 2x1Tb fails with the above error. > > Both are sw/ mirrored. No hw/ raid and ACHI sata settings. Hummm, somehow we are executing data, not code: 00000000 8c 39 00 00 01 82 44 45 4c 4c 20 20 50 45 5f 53 |.9....DELL PE_S| That isn't a valid instruction. :( Also, your eip value is not anything that would be normal. Actually, your eip value looks like a pointer into the BIOS (0xf000:bf6a). I bet something in your BIOS had a buffer overrun and trashed the stack or some such. Or it overran an I/O buffer which trashed the return stack of the userland process somehow. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 21:42:00 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4AB4511B; Fri, 19 Oct 2012 21:42:00 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id BC9588FC0C; Fri, 19 Oct 2012 21:41:59 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TPKK8-0002IH-L7; Fri, 19 Oct 2012 17:41:44 -0400 Date: Fri, 19 Oct 2012 17:41:44 -0400 From: Gary Palmer To: Rainer Duffner Subject: Re: 9.1-RC2 - could it be that the installer does not write the MBR? Message-ID: <20121019214144.GC40357@in-addr.com> References: <50802EFC.2010101@gmail.com> <20121018184426.63c59601@suse3> <50803B22.7000706@gmail.com> <20121019223841.09866aac@linux-wb36.example.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121019223841.09866aac@linux-wb36.example.org> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: Adrian Chadd , freebsd-stable@freebsd.org, Chuck Burns X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 21:42:00 -0000 On Fri, Oct 19, 2012 at 10:38:41PM +0200, Rainer Duffner wrote: > Am Fri, 19 Oct 2012 11:32:49 -0700 > schrieb Adrian Chadd : > > > Guys/girls/etc, > > > > I do suggest that someone actually spends some time coming up with a > > table of "what the current state is", "what we could do", "what would > > happen if we did that." > > > > Right now there's a lot of possibilities (new drive, drive with > > windows, drive with linux, drive with linux/windows, drive with legacy > > freebsd MBR, etc) and as an outsider trying to figure out what is > > actually the "right" sounding behaviour, it's difficult for me to sit > > down and digest all these emails that chip away at a bit of the > > problem at a time. > > > > So if you'd like to see this fixed, I really do suggest that one of > > you dumps some time into coming up with a basic table like I said > > above, work with others who can correct/flesh out the various options > > to take into account, and then we can come up with a real solution. > > Then 9.1 can go out the door. > > > > > If I select the "entire disk" for FreeBSD, I think it's a reasonable > assumption that the MBR should replaced, too. I think it should still prompt clearly for permission to splat the boot record. There could be an OS (or multiple OSs) on other disks which the boot loader can reference. Just because you have complete ownership of *one* disk is not indicative of being able to take over the entire boot record. There are probably too many edge cases here to make a reliable automated decision, hence the necessity of a question. > Please don't make people install FreeBSD 9.0 first on disks with > non-FreeBSD MRRs and then upgrade to 9.1. Gary From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 00:06:08 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 067D2462 for ; Sat, 20 Oct 2012 00:06:08 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from mail.ultra-secure.de (mail.ultra-secure.de [78.47.114.122]) by mx1.freebsd.org (Postfix) with ESMTP id 4A88B8FC12 for ; Sat, 20 Oct 2012 00:06:06 +0000 (UTC) Received: (qmail 51112 invoked by uid 89); 20 Oct 2012 00:06:05 -0000 Received: by simscan 1.4.0 ppid: 51107, pid: 51109, t: 0.0937s scanners: attach: 1.4.0 clamav: 0.97.3/m:54/d:15480 Received: from unknown (HELO linux-wb36.example.org) (rainer@ultra-secure.de@212.71.117.93) by mail.ultra-secure.de with ESMTPA; 20 Oct 2012 00:06:05 -0000 Date: Sat, 20 Oct 2012 02:06:03 +0200 From: Rainer Duffner To: Glen Barber Subject: Re: 9.1-RC2 - could it be that the installer does not write the MBR? Message-ID: <20121020020603.628125c8@linux-wb36.example.org> In-Reply-To: <20121019211130.GM1393@glenbarber.us> References: <50802EFC.2010101@gmail.com> <20121018184426.63c59601@suse3> <50803B22.7000706@gmail.com> <20121019223841.09866aac@linux-wb36.example.org> <20121019211130.GM1393@glenbarber.us> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.7; i586-suse-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , freebsd-stable@freebsd.org, Chuck Burns X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 00:06:08 -0000 Am Fri, 19 Oct 2012 17:11:30 -0400 schrieb Glen Barber : > On Fri, Oct 19, 2012 at 10:38:41PM +0200, Rainer Duffner wrote: > > If I select the "entire disk" for FreeBSD, I think it's a reasonable > > assumption that the MBR should replaced, too. > > Please don't make people install FreeBSD 9.0 first on disks with > > non-FreeBSD MRRs and then upgrade to 9.1. > > > > Can you outline for me in detail what you did when you partitioned > your drive during the installation? I chose "entire disk", then deleted all partitions-suggestions except the first one and created my own partitioning scheme. (/, swap, var, usr, maybe /var/log and /home, too) > I have seen your specific issue exactly once, and reliably reproducing > the problem has not been successful so far. > > BTW, what was on the drive before you did the install, if anything? It had a version of Solaris. Maybe Opensolaris. I don't know exactly. And I don't know if it had zfsroot or not. I created a HW-RAID1 with the HP P400 controller on it. The drives were previously used in another server. I tried to install 9.1RC2 twice on these disks and it always went back to the grub-prompt after reboot. Then I installed 9.0 and it's running now. From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 00:14:05 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 726F1765; Sat, 20 Oct 2012 00:14:05 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id 330D98FC0C; Sat, 20 Oct 2012 00:14:05 +0000 (UTC) Received: from glenbarber.us (nucleus.glenbarber.us [IPv6:2001:470:8:1205:2:2:0:100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 827C423F645; Fri, 19 Oct 2012 20:14:03 -0400 (EDT) Date: Fri, 19 Oct 2012 20:14:01 -0400 From: Glen Barber To: Rainer Duffner Subject: Re: 9.1-RC2 - could it be that the installer does not write the MBR? Message-ID: <20121020001401.GQ1393@glenbarber.us> References: <50802EFC.2010101@gmail.com> <20121018184426.63c59601@suse3> <50803B22.7000706@gmail.com> <20121019223841.09866aac@linux-wb36.example.org> <20121019211130.GM1393@glenbarber.us> <20121020020603.628125c8@linux-wb36.example.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="367OTzzFqQya5wJv" Content-Disposition: inline In-Reply-To: <20121020020603.628125c8@linux-wb36.example.org> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Adrian Chadd , freebsd-stable@freebsd.org, Chuck Burns X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 00:14:05 -0000 --367OTzzFqQya5wJv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 20, 2012 at 02:06:03AM +0200, Rainer Duffner wrote: > Am Fri, 19 Oct 2012 17:11:30 -0400 > schrieb Glen Barber : >=20 > > On Fri, Oct 19, 2012 at 10:38:41PM +0200, Rainer Duffner wrote: > > > If I select the "entire disk" for FreeBSD, I think it's a reasonable > > > assumption that the MBR should replaced, too. > > > Please don't make people install FreeBSD 9.0 first on disks with > > > non-FreeBSD MRRs and then upgrade to 9.1. > > >=20 > >=20 > > Can you outline for me in detail what you did when you partitioned > > your drive during the installation? >=20 > I chose "entire disk", then deleted all partitions-suggestions except > the first one and created my own partitioning scheme. > (/, swap, var, usr, maybe /var/log and /home, too) > =20 Ok, this is similar to my case. > > I have seen your specific issue exactly once, and reliably reproducing > > the problem has not been successful so far. > >=20 > > BTW, what was on the drive before you did the install, if anything? >=20 > It had a version of Solaris. Maybe Opensolaris. I don't know exactly. > And I don't know if it had zfsroot or not. I created a HW-RAID1 with > the HP P400 controller on it. > The drives were previously used in another server. >=20 Ok, as long as they were not new drives. Thank you. > I tried to install 9.1RC2 twice on these disks and it always went back > to the grub-prompt after reboot. > Then I installed 9.0 and it's running now. >=20 The grub prompt for (Open)Solaris? Or do you use grub on FreeBSD? I _think_ at this point, you've hit the same problem I hit, the only difference is that in my case, 9.1-PRERELEASE was installed twice, because the paritions were not ideal. So, my guess is if you were to boot the install cd and select 'Live CD' or 'Shell' from the first menu option, and wrote the GPT bootcode to da0p1 (assuming da0 is the drive) and reboot, it would have booted fine. In my case, the disk originally had an older FreeBSD install, so had an existing MBR. The odd thing though is that the system was bootable before the second installation. Glen --367OTzzFqQya5wJv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQgezJAAoJEFJPDDeguUajbhkH+wTFOVDz6bCBtq5k55sOHLdP JMtJa2n9/+NeH0hxmhF65/7d/M0zViq7NdDwC4rP0JIA00RorT2do1nUgf4EdK6T uHzTlrYc6GFpKfQf3o7qDh50Kv5bi4ctXV1MqkwVtlG9BAW9yd8UPi26Cce01VwV YJMbv5AJ2lH5LrfbFvtqZeTLcEHIkPnBhHt5inHbClaLYn3u61BMKi+AGso/tYfJ KQe1oYCXYIlGnRUXaKExL2WGLHbN8gGwe3KmA+hmGXJrXu4d2SJYyrRDy/rZGSOU tBKnxk1k8QhrQ9fOyUwhTHe/qySPL9TJH8livP6/p7KVWUk6NarrfMqB/hZDkxA= =9B/B -----END PGP SIGNATURE----- --367OTzzFqQya5wJv-- From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 01:07:26 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 96846F5C for ; Sat, 20 Oct 2012 01:07:26 +0000 (UTC) (envelope-from mailer-daemon@vniz.net) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 111698FC12 for ; Sat, 20 Oct 2012 01:07:25 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id b5so874427lbd.13 for ; Fri, 19 Oct 2012 18:07:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:subject:openpgp:content-type :content-transfer-encoding:x-gm-message-state; bh=5fnO4wL4kN0d3psYrTeBkAwwiK6xPkbakihbCHlKdgs=; b=hPJLvlHJoqsC0xbe1muD1hOyzwnjBqr2KhrZqCJe+DKTNg4vKKUtATDeS1Tf/n2+Mv BiwEM2PdmxX5yLZTHpEaHHHlj1NjgPmD/giB94qizZBibOBMZ/g74x2oR5uIoIyBGSo5 YeMTl8Ih2JatsifhqrK4cP9VPGsAxilay/LDsMg7hztgQXkxRIrZcT3Y4Y/4MMIs9T7L E98J09jKy2cVT5+gXeXW4HbdItqFsuDL0bTTmXlPqH6wHiw/z7/hOf5CjsJapARGVhnw QFUVL5wqaSi7rXmGKhCSWk2ofcuXiN371BwtX+ZSlRMMDnXQRb5wlrY9kIF/Xx9Xf7Mr KJlg== Received: by 10.112.38.234 with SMTP id j10mr1152555lbk.80.1350695244255; Fri, 19 Oct 2012 18:07:24 -0700 (PDT) Received: from [192.168.1.2] ([89.169.140.97]) by mx.google.com with ESMTPS id fe5sm1023286lbb.6.2012.10.19.18.07.22 (version=SSLv3 cipher=OTHER); Fri, 19 Oct 2012 18:07:23 -0700 (PDT) Message-ID: <5081F92F.8040004@freebsd.org> Date: Sat, 20 Oct 2012 05:06:55 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: stable@freebsd.org, jhb@freebsd.org Subject: ${CTFCONVERT_CMD} expands to empty string OpenPGP: id=964474DD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkwt5jvumR/c/JjGWXFF6uJhWHBl4l9FaK7ZOQSrQbKvac7V/MlbLNrMusOhgAK5pHDztqQ X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 01:07:26 -0000 On recent -stable I got a lots of (see subj) now due to CTF changes in *.mk files. I have WITHOUT_CDDL=yes in my /etc/src.conf and WITHOUT_CDDL have wider scope than WITHOUT_CTF suggested, but WITHOUT_CDDL is not checked in recent CTF changes. Please fix this thing. From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 01:28:57 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 659145DA for ; Sat, 20 Oct 2012 01:28:57 +0000 (UTC) (envelope-from mailer-daemon@vniz.net) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id D32F28FC0C for ; Sat, 20 Oct 2012 01:28:56 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id e12so821484lag.13 for ; Fri, 19 Oct 2012 18:28:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:subject:references:in-reply-to:openpgp:content-type :content-transfer-encoding:x-gm-message-state; bh=Hq6GpDxlQBAilSwzOgsPpWkHk2oIkYQLBa/kFilCCjU=; b=SRxfYDKjced1t8LyqJvkqSFILhc6LdNXf/OB81YxT7V9GYDsj6e0kiFKmYDpx5taYK UIu4EyL0TL5QqtmqG0e4KeSnw4Z5RhZRbuHUhAz4Mcv1NEWDW7O5JfwRhjw7Bfolej3W KKX6G5ISCY1sacwYBhJdiT0cNztIGQsJlUGTSvbcAFEM7JkmI03YmwReN+mJbqBEPYYl PNP/gmHoEeObqsxsj8/gSZWHRK7r3xgIzyHBQvUI5yOzrstNKVUBm/Ue4wkTbiig5GBN K3J5c0/Vnw1WzIeUoX8OuSGVYfB2dTKM9lIpxvz5Lq87l44p2o7cV9E+pAv96gB1hECL 18mA== Received: by 10.112.47.226 with SMTP id g2mr1217529lbn.32.1350696535225; Fri, 19 Oct 2012 18:28:55 -0700 (PDT) Received: from [192.168.1.2] ([89.169.140.97]) by mx.google.com with ESMTPS id sj3sm956209lab.2.2012.10.19.18.28.54 (version=SSLv3 cipher=OTHER); Fri, 19 Oct 2012 18:28:54 -0700 (PDT) Message-ID: <5081FE56.5070204@freebsd.org> Date: Sat, 20 Oct 2012 05:28:54 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: stable@freebsd.org, jhb@freebsd.org Subject: Re: ${CTFCONVERT_CMD} expands to empty string References: <5081F92F.8040004@freebsd.org> In-Reply-To: <5081F92F.8040004@freebsd.org> OpenPGP: id=964474DD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQma0WmMWWAYk6rd3geMPpdvcEp609XCokQV+fDP5K2GKQariIUlxqjd8wR4pLXCAPZIDM0s X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 01:28:57 -0000 On 20.10.2012 5:06, Andrey Chernov wrote: > On recent -stable I got a lots of (see subj) now due to CTF changes in > *.mk files. > I have > WITHOUT_CDDL=yes > in my /etc/src.conf and WITHOUT_CDDL have wider scope than WITHOUT_CTF > suggested, but WITHOUT_CDDL is not checked in recent CTF changes. > Please fix this thing. > BTW, I got that ${CTFCONVERT_CMD} expands to empty string even placing WITHOUT_CTF=yes into /etc/src.conf From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 04:06:53 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C2E2123D; Sat, 20 Oct 2012 04:06:53 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from chinatsu.takeda.tk (mail.takeda.tk [74.0.89.210]) by mx1.freebsd.org (Postfix) with ESMTP id 952AE8FC08; Sat, 20 Oct 2012 04:06:53 +0000 (UTC) Received: from takeda-ws.lan (takeda-ws.lan [10.0.0.3]) (authenticated bits=0) by chinatsu.takeda.tk (8.14.5/8.14.5) with ESMTP id q9K3p2ps002014 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 19 Oct 2012 20:51:02 -0700 (PDT) (envelope-from takeda@takeda.tk) Date: Fri, 19 Oct 2012 20:50:10 -0700 From: Derek Kulinski X-Priority: 3 (Normal) Message-ID: <771658188.20121019205010@takeda.tk> To: Andriy Gapon Subject: Re: Problem reading vitals from Gigabyte H77-DH3H In-Reply-To: <5081552F.2050303@FreeBSD.org> References: <1286515493.20121017131543@takeda.tk> <507F1761.1010202@FreeBSD.org> <20121017205147.GB36106@chinatsu.takeda.tk> <5081552F.2050303@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 04:06:54 -0000 Hello Andriy, Friday, October 19, 2012, 6:27:11 AM, you wrote: > Here is a (quite large) patch: > http://people.freebsd.org/~avg/sensors.diff > Please note that if affects both kernel and userland code. > Read it(4) manual page after upgrading. Note that you will need to add some > entries to /boot/device.hints (unless your upgrade procedure would automatically > merge the file). I applied it to RELENG_9 as of today, recompiled the userland and kernel (I did not see any errors). The it device loaded successfully, unfortunately I don't see any effect; the hw.acpi.thermal does not change (though I guess it not supposed to), sysctl hw.sensors and hw._sensors do not return anything (not even a complaint that it does not exist). sensord returns: sensorsd: no sensors found -- Best regards, Derek mailto:takeda@takeda.tk "unzip; strip; touch; finger; mount; fsck; more; yes; unmount; sleep" - my daily unix command list From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 04:18:59 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 993555E8 for ; Sat, 20 Oct 2012 04:18:59 +0000 (UTC) (envelope-from zkolic@sbb.rs) Received: from smtp3.sbb.rs (smtp3.sbb.rs [89.216.2.35]) by mx1.freebsd.org (Postfix) with ESMTP id F20AF8FC08 for ; Sat, 20 Oct 2012 04:18:58 +0000 (UTC) Received: from mycenae (cable-178-148-96-92.dynamic.sbb.rs [178.148.96.92]) by smtp3.sbb.rs (8.14.0/8.14.0) with ESMTP id q9K4DEbM003808 for ; Sat, 20 Oct 2012 06:13:19 +0200 Received: by mycenae (Postfix, from userid 1001) id DC2055C2F; Sat, 20 Oct 2012 06:14:08 +0200 (CEST) Date: Sat, 20 Oct 2012 06:14:08 +0200 From: Zoran Kolic To: freebsd-stable@freebsd.org Subject: 9.1 and intel graphics Message-ID: <20121020041408.GA1218@mycenae.sbb.rs> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-SMTP-Vilter-Version: 1.3.2 X-SBB-Virus-Status: clean X-SBB-Spam-Score: -1.8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 04:18:59 -0000 Yesterday I have gotten lenovo e320 laptop, with core i3 2350 and HD3000 integrated. Gonna wait few days till 9.1 release. I never used anything aside "intel" on my old laptop. Kostik Belousov made a port of kms and I found patches from june and jule on the net. What should I do after 9.1 install in this case? I assume kms is in xorg. Do I have to find and install some driver from intel? Do I need to change xorg.conf after configure flag, that will make conf file? Finally, what happens when I leave x and want to go back to console mode? I tried out live RC2 from usb stick. Few acpi errors, intel 1000 wifi found. After some time "sysctl hw.acpi" gave me the cpu temperature of 50C. Fan was on. Probably temp gonna go down when I add powerd and cx_lowest to rc.conf on hdd. Is it normal temp for this cpu? Best regards all Zoran From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 04:22:02 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 106BA754; Sat, 20 Oct 2012 04:22:02 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 988428FC08; Sat, 20 Oct 2012 04:22:01 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q9K4Ltw7058526; Fri, 19 Oct 2012 22:21:55 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q9K4LsZk058523; Fri, 19 Oct 2012 22:21:54 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Fri, 19 Oct 2012 22:21:54 -0600 (MDT) From: Warren Block To: Rainer Duffner Subject: Re: 9.1-RC2 - could it be that the installer does not write the MBR? In-Reply-To: <20121020020603.628125c8@linux-wb36.example.org> Message-ID: References: <50802EFC.2010101@gmail.com> <20121018184426.63c59601@suse3> <50803B22.7000706@gmail.com> <20121019223841.09866aac@linux-wb36.example.org> <20121019211130.GM1393@glenbarber.us> <20121020020603.628125c8@linux-wb36.example.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Fri, 19 Oct 2012 22:21:55 -0600 (MDT) Cc: Glen Barber , Adrian Chadd , freebsd-stable@freebsd.org, Chuck Burns X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 04:22:02 -0000 On Sat, 20 Oct 2012, Rainer Duffner wrote: > Am Fri, 19 Oct 2012 17:11:30 -0400 > schrieb Glen Barber : > >> On Fri, Oct 19, 2012 at 10:38:41PM +0200, Rainer Duffner wrote: >>> If I select the "entire disk" for FreeBSD, I think it's a reasonable >>> assumption that the MBR should replaced, too. >>> Please don't make people install FreeBSD 9.0 first on disks with >>> non-FreeBSD MRRs and then upgrade to 9.1. >>> >> >> Can you outline for me in detail what you did when you partitioned >> your drive during the installation? > > I chose "entire disk", then deleted all partitions-suggestions except > the first one and created my own partitioning scheme. > (/, swap, var, usr, maybe /var/log and /home, too) > >> I have seen your specific issue exactly once, and reliably reproducing >> the problem has not been successful so far. >> >> BTW, what was on the drive before you did the install, if anything? > > It had a version of Solaris. Maybe Opensolaris. I don't know exactly. > And I don't know if it had zfsroot or not. I created a HW-RAID1 with > the HP P400 controller on it. > The drives were previously used in another server. > > I tried to install 9.1RC2 twice on these disks and it always went back > to the grub-prompt after reboot. > Then I installed 9.0 and it's running now. I don't know if this is the problem, but it is worth pointing out that graid(8) is now included in GENERIC. Leftover hardware RAID metadata could make for unexpected results. For example, http://forums.freebsd.org/showthread.php?t=35168 From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 04:23:05 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 929EB857; Sat, 20 Oct 2012 04:23:05 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id 5E8218FC1A; Sat, 20 Oct 2012 04:23:05 +0000 (UTC) Received: from glenbarber.us (nucleus.glenbarber.us [IPv6:2001:470:8:1205:2:2:0:100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 650AD23F645; Sat, 20 Oct 2012 00:23:02 -0400 (EDT) Date: Sat, 20 Oct 2012 00:22:59 -0400 From: Glen Barber To: Zoran Kolic Subject: Re: 9.1 and intel graphics Message-ID: <20121020042259.GU1393@glenbarber.us> References: <20121020041408.GA1218@mycenae.sbb.rs> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Wiqv+dddIdXsNRUi" Content-Disposition: inline In-Reply-To: <20121020041408.GA1218@mycenae.sbb.rs> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 04:23:05 -0000 --Wiqv+dddIdXsNRUi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Oct 20, 2012 at 06:14:08AM +0200, Zoran Kolic wrote: > Yesterday I have gotten lenovo e320 laptop, with core i3 2350 > and HD3000 integrated. Gonna wait few days till 9.1 release. > I never used anything aside "intel" on my old laptop. Kostik > Belousov made a port of kms and I found patches from june and > jule on the net. What should I do after 9.1 install in this > case? I assume kms is in xorg. Do I have to find and install > some driver from intel? Do I need to change xorg.conf after > configure flag, that will make conf file? The i915kms driver is in the 9-STABLE branch, I am not 100% certain if it is what will be 9.1-RELEASE. > Finally, what happens when I leave x and want to go back to > console mode? Currently, you cannot go back to console once i915kms is loaded. > I tried out live RC2 from usb stick. Few acpi errors, intel > 1000 wifi found. After some time "sysctl hw.acpi" gave me the > cpu temperature of 50C. Fan was on. Probably temp gonna go > down when I add powerd and cx_lowest to rc.conf on hdd. Is > it normal temp for this cpu? Yes. Glen --Wiqv+dddIdXsNRUi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQgicjAAoJEFJPDDeguUajWU4IAKrp2L7dUqcntFQVmQ90Y0l3 z3Ek8Xy5V05BX+WmUL8BuHidaX7+utO6ymBT4Gp0BQtr/wdRboIVBGYIAKNr9KlD gvE42b/vg914yqd/FzLuW4J/zl6G0dDPszUBSlsDCv4cDPYbIAM1AbZmeV/16fcH uBMKCIJLuNFZv4bFdS8fmUyqDOLvk1L415sx1gYo1KFiRddqNmNo9ggLGVsAsD18 2R6DTPgYY5w95zmzje6mclLS/Gq+kUxmQXYCDSr6aLZWa3T5L0tOa1ww36rmcBR8 HbOP/oqRZFCiD6pEMIX3CAUrrBX4Xd6NxGQwbVs4ImB4ODUxdkc+rYDlVnHrsO8= =ssYw -----END PGP SIGNATURE----- --Wiqv+dddIdXsNRUi-- From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 06:29:30 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2FE73C79 for ; Sat, 20 Oct 2012 06:29:30 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id B48228FC0A for ; Sat, 20 Oct 2012 06:29:29 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id x43so749241wey.13 for ; Fri, 19 Oct 2012 23:29:28 -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=nQLTPob9yjqZKdrZX7XzevjsnFG0rwtwMo9VXf+dMGQ=; b=F6mucVT74HXaBLy8iMnhDzPCphkSILvr6KUJ2FE8XvtETKGpUxUZuiidUEXk1w+P4B a49Y8YaRgi3lLbOsVCzatftTvyJhLEv30ECw3Iz3xyYrHzuLd6kOY5y9Rv/HgLhza+CF WVW12sfmcoL5Nh1EG4LfbMvxv6HF+0Hza5UbQIluFAphWqYitKUDiAI5HxqsFNPl+6mh 33hXkVUs/VuNGtylPiXGieYN7DJLzsmW0V9wxpharRWXDZW0oXvTysv+fK54Erk9Bbv3 kacbooojFG7uogtok1gtLSIx6nqnm5p/l5SQvzlDyqLRz+z0VuXmQLAFW8UC5/TgGES0 dAlQ== MIME-Version: 1.0 Received: by 10.216.197.104 with SMTP id s82mr1935914wen.62.1350714568508; Fri, 19 Oct 2012 23:29:28 -0700 (PDT) Received: by 10.223.66.194 with HTTP; Fri, 19 Oct 2012 23:29:28 -0700 (PDT) In-Reply-To: <20121020041408.GA1218@mycenae.sbb.rs> References: <20121020041408.GA1218@mycenae.sbb.rs> Date: Fri, 19 Oct 2012 23:29:28 -0700 Message-ID: Subject: Re: 9.1 and intel graphics From: Kevin Oberman To: Zoran Kolic Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 06:29:30 -0000 On Fri, Oct 19, 2012 at 9:14 PM, Zoran Kolic wrote: > Yesterday I have gotten lenovo e320 laptop, with core i3 2350 > and HD3000 integrated. Gonna wait few days till 9.1 release. > I never used anything aside "intel" on my old laptop. Kostik > Belousov made a port of kms and I found patches from june and > jule on the net. What should I do after 9.1 install in this > case? I assume kms is in xorg. Do I have to find and install > some driver from intel? Do I need to change xorg.conf after > configure flag, that will make conf file? Full support for the HD3000 is in 9-stable and 9.1-Beta and all RCs. To use it you need to build X drivers and drm and the kernel with: WITH_NEW_XORG=YES WITH_KMS=YES in /etc/make.conf. Specifically, the kernel and a few ports. graphics/drm and your org-drivers: xf86-video-intel, xf86-input-synaptics, xf86-input-mouse, and xf86-input-keyboard. Then just start X. Don't try loading the kernel module. It will be loaded by the startx. > Finally, what happens when I leave x and want to go back to > console mode? You don't If you try, your system will lock up. You need to shutdown from a window in X. Hopefully someone will implement switching back to console mode some day, but it has not happened, yet. > I tried out live RC2 from usb stick. Few acpi errors, intel > 1000 wifi found. After some time "sysctl hw.acpi" gave me the > cpu temperature of 50C. Fan was on. Probably temp gonna go > down when I add powerd and cx_lowest to rc.conf on hdd. Is > it normal temp for this cpu? Pretty reasonable. Be sure to set both cx_lowest to "Cmax". It is new to 9.1 and fixes some serious issues with C-states on many newer platforms. Specifically that some platforms skip some C-states and FreeBSD never used the ones saving more power than hte one skipped. I always remind folks to blow out the heat sink on laptops about one a year. Dust is a great insulator and laptops often collect a lot more dust than office systems, though my office system started dying during buildworld last week and blowing out the CPU heat sink fixed it up, but it had been sitting around for almost three years collecting dust. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 06:47:36 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 132B3F65 for ; Sat, 20 Oct 2012 06:47:36 +0000 (UTC) (envelope-from erich@alogreentechnologies.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id A17058FC0A for ; Sat, 20 Oct 2012 06:47:35 +0000 (UTC) Received: from X220.ovitrap.com ([122.129.201.29]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q9K6lVXx028797; Sat, 20 Oct 2012 00:47:33 -0600 Date: Sat, 20 Oct 2012 13:47:29 +0700 From: Erich Dollansky To: Kevin Oberman Subject: Re: 9.1 and intel graphics Message-ID: <20121020134729.0282689a@X220.ovitrap.com> In-Reply-To: References: <20121020041408.GA1218@mycenae.sbb.rs> Organization: ALO Green Technologies X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Zoran Kolic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 06:47:36 -0000 Hi, On Fri, 19 Oct 2012 23:29:28 -0700 Kevin Oberman wrote: > On Fri, Oct 19, 2012 at 9:14 PM, Zoran Kolic wrote: > > I always remind folks to blow out the heat sink on laptops about one a > year. Dust is a great insulator and laptops often collect a lot more I never did this on a laptop as all of mine where build in a way that dust could not collect. So, it depends very much on the model. > dust than office systems, though my office system started dying during > buildworld last week and blowing out the CPU heat sink fixed it up, > but it had been sitting around for almost three years collecting dust. I do this every year on my desktop. The temperature drops then by 10K. You can use the CPU temperature as an indicator when a cleaning is needed. But blowing does not work on my machine. I really have to take screw driver and tweezers to get the work finally done. Erich From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 07:00:14 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 37B87259 for ; Sat, 20 Oct 2012 07:00:14 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id A78748FC12 for ; Sat, 20 Oct 2012 07:00:13 +0000 (UTC) Received: from X220.ovitrap.com ([122.129.201.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q9K6hEOm027889; Sat, 20 Oct 2012 00:43:16 -0600 Date: Sat, 20 Oct 2012 13:43:10 +0700 From: Erich Dollansky To: Zoran Kolic Subject: Re: 9.1 and intel graphics Message-ID: <20121020134310.0bc512dc@X220.ovitrap.com> In-Reply-To: <20121020041408.GA1218@mycenae.sbb.rs> References: <20121020041408.GA1218@mycenae.sbb.rs> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 07:00:14 -0000 Hi, On Sat, 20 Oct 2012 06:14:08 +0200 Zoran Kolic wrote: > Yesterday I have gotten lenovo e320 laptop, with core i3 2350 > and HD3000 integrated. Gonna wait few days till 9.1 release. there shouldn't be many changes between RC2 and the final release version. You can always update later. > I never used anything aside "intel" on my old laptop. Kostik > Belousov made a port of kms and I found patches from june and > jule on the net. What should I do after 9.1 install in this > case? I assume kms is in xorg. Do I have to find and install You should not need the patches anymore for 9.x and 10.x. > some driver from intel? Do I need to change xorg.conf after > configure flag, that will make conf file? I have had to do but this is some time ago. > Finally, what happens when I leave x and want to go back to > console mode? It might crashes your system. You are not able to go back to X and you only see a black screen. This is not an error but a feature. Fun aside, this function was not implemented yet. > I tried out live RC2 from usb stick. Few acpi errors, intel The ACPI errors might depend on your BIOS. I get an endless number of ACPI errors during running X but they do not show any effect on my machine. > 1000 wifi found. After some time "sysctl hw.acpi" gave me the > cpu temperature of 50C. Fan was on. Probably temp gonna go > down when I add powerd and cx_lowest to rc.conf on hdd. Is > it normal temp for this cpu? 50 degrees? Seems pretty low. My i7 goes up to 96 under full load. As the CPU is made for 100 and I am in the tropics, I do not care much. This should be true for your CPU too. Erich From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 07:37:31 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C916AD07 for ; Sat, 20 Oct 2012 07:37:31 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 181818FC12 for ; Sat, 20 Oct 2012 07:37:30 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA07221; Sat, 20 Oct 2012 10:37:22 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TPTcY-000AfN-Bx; Sat, 20 Oct 2012 10:37:22 +0300 Message-ID: <508254AF.7040709@FreeBSD.org> Date: Sat, 20 Oct 2012 10:37:19 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121013 Thunderbird/16.0.1 MIME-Version: 1.0 To: Derek Kulinski Subject: Re: Problem reading vitals from Gigabyte H77-DH3H References: <1286515493.20121017131543@takeda.tk> <507F1761.1010202@FreeBSD.org> <20121017205147.GB36106@chinatsu.takeda.tk> <5081552F.2050303@FreeBSD.org> <771658188.20121019205010@takeda.tk> In-Reply-To: <771658188.20121019205010@takeda.tk> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 07:37:32 -0000 on 20/10/2012 06:50 Derek Kulinski said the following: > Hello Andriy, > > Friday, October 19, 2012, 6:27:11 AM, you wrote: > >> Here is a (quite large) patch: >> http://people.freebsd.org/~avg/sensors.diff >> Please note that if affects both kernel and userland code. >> Read it(4) manual page after upgrading. Note that you will need to add some >> entries to /boot/device.hints (unless your upgrade procedure would automatically >> merge the file). > > I applied it to RELENG_9 as of today, recompiled the userland and > kernel (I did not see any errors). > > The it device loaded successfully, unfortunately I don't see any > effect; the hw.acpi.thermal does not change (though I guess it not > supposed to), sysctl hw.sensors and hw._sensors do not return anything > (not even a complaint that it does not exist). > > sensord returns: > sensorsd: no sensors found Does your device.hints file has hints for it(4)? What are they? Could you please also fetch sysutils/superiotool port from here https://redports.org/browser/avg/sysutils/superiotool, replace what you have under /usr/ports, install the port and then run 'superiotool -d' command? -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 08:08:21 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B585FA97; Sat, 20 Oct 2012 08:08:21 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from chinatsu.takeda.tk (mail.takeda.tk [74.0.89.210]) by mx1.freebsd.org (Postfix) with ESMTP id 8619F8FC0A; Sat, 20 Oct 2012 08:08:21 +0000 (UTC) Received: from takeda-ws.lan (takeda-ws.lan [10.0.0.3]) (authenticated bits=0) by chinatsu.takeda.tk (8.14.5/8.14.5) with ESMTP id q9K88JMD083879 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 20 Oct 2012 01:08:19 -0700 (PDT) (envelope-from takeda@takeda.tk) Date: Sat, 20 Oct 2012 01:08:09 -0700 From: Derek Kulinski X-Priority: 3 (Normal) Message-ID: <994545137.20121020010809@takeda.tk> To: Andriy Gapon Subject: Re: Problem reading vitals from Gigabyte H77-DH3H In-Reply-To: <508254AF.7040709@FreeBSD.org> References: <1286515493.20121017131543@takeda.tk> <507F1761.1010202@FreeBSD.org> <20121017205147.GB36106@chinatsu.takeda.tk> <5081552F.2050303@FreeBSD.org> <771658188.20121019205010@takeda.tk> <508254AF.7040709@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 08:08:21 -0000 Hello Andriy, Saturday, October 20, 2012, 12:37:19 AM, you wrote: > Does your device.hints file has hints for it(4)? Yes, I did a full install with mergemaster etc. > What are they? hint.it.0.at="isa" hint.it.0.port="0x290" hint.it.1.at="isa" hint.it.1.port="0xc00" hint.it.2.at="isa" hint.it.2.port="0xd00" > Could you please also fetch sysutils/superiotool port from here > https://redports.org/browser/avg/sysutils/superiotool, replace what you have > under /usr/ports, install the port and then run 'superiotool -d' command? No luck: [chinatsu]:/tank/junk/ports/sysutils/superiotool# superiotool -d superiotool r4.0-2827-g1a00cf0 No Super I/O found -- Best regards, Derek mailto:takeda@takeda.tk Hard work pays off in the future. Laziness pays off now. From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 08:26:48 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1DDB1F3C for ; Sat, 20 Oct 2012 08:26:48 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 628818FC0C for ; Sat, 20 Oct 2012 08:26:47 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA07573; Sat, 20 Oct 2012 11:26:41 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TPUOH-000Aj1-Ce; Sat, 20 Oct 2012 11:26:41 +0300 Message-ID: <50826040.6010106@FreeBSD.org> Date: Sat, 20 Oct 2012 11:26:40 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121013 Thunderbird/16.0.1 MIME-Version: 1.0 To: Derek Kulinski Subject: Re: Problem reading vitals from Gigabyte H77-DH3H References: <1286515493.20121017131543@takeda.tk> <507F1761.1010202@FreeBSD.org> <20121017205147.GB36106@chinatsu.takeda.tk> <5081552F.2050303@FreeBSD.org> <771658188.20121019205010@takeda.tk> <508254AF.7040709@FreeBSD.org> <994545137.20121020010809@takeda.tk> In-Reply-To: <994545137.20121020010809@takeda.tk> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 08:26:48 -0000 on 20/10/2012 11:08 Derek Kulinski said the following: > Hello Andriy, > > Saturday, October 20, 2012, 12:37:19 AM, you wrote: [snip] >> Could you please also fetch sysutils/superiotool port from here >> https://redports.org/browser/avg/sysutils/superiotool, replace what you have >> under /usr/ports, install the port and then run 'superiotool -d' command? > > No luck: > [chinatsu]:/tank/junk/ports/sysutils/superiotool# superiotool -d > superiotool r4.0-2827-g1a00cf0 > No Super I/O found Hmm, it would be a pity if all of this was a waste of time... I based some of my assumptions on googling, in particular this post http://thread.gmane.org/gmane.linux.bios.flashrom/1163 mentioned: Found ITE Super I/O, ID 0x8728 on port 0x2e BTW, I suppose "DH3H" in the subject line is a typo? Or is it a different model? Oh, hmm, looks like even the latest superiotool may not have support for this newer chip. Could you please run superiotool -V | fgrep Failed | fgrep -v ff ? If this command returns id=0x8728, then you could hack superiotool source code between running 'make patch' and 'make'. You could edit ite.c file, search for 0x8726 and either change it to 0x8728 or duplicate the whole section and make the change there. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 08:50:27 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E0F9C4A3; Sat, 20 Oct 2012 08:50:27 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from chinatsu.takeda.tk (mail.takeda.tk [74.0.89.210]) by mx1.freebsd.org (Postfix) with ESMTP id 877EB8FC08; Sat, 20 Oct 2012 08:50:27 +0000 (UTC) Received: from [10.169.96.204] (101.sub-70-197-139.myvzw.com [70.197.139.101]) (authenticated bits=0) by chinatsu.takeda.tk (8.14.5/8.14.5) with ESMTP id q9K8oQ5l020431 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 20 Oct 2012 01:50:26 -0700 (PDT) (envelope-from takeda@takeda.tk) User-Agent: K-9 Mail for Android In-Reply-To: <50826040.6010106@FreeBSD.org> References: <1286515493.20121017131543@takeda.tk> <507F1761.1010202@FreeBSD.org> <20121017205147.GB36106@chinatsu.takeda.tk> <5081552F.2050303@FreeBSD.org> <771658188.20121019205010@takeda.tk> <508254AF.7040709@FreeBSD.org> <994545137.20121020010809@takeda.tk> <50826040.6010106@FreeBSD.org> MIME-Version: 1.0 Subject: Re: Problem reading vitals from Gigabyte H77-DH3H From: Derek Kulinski Date: Sat, 20 Oct 2012 01:50:18 -0700 To: Andriy Gapon Message-ID: X-Bogosity: No, tests=bogofilter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 08:50:27 -0000 It's really late where I live, will do what you mentioned in the morning. I think it is a typo. I believe it is DS3H, but I will confirm that tomorrow. Thank you for helping me with this. -- Sent from my phone. Please excuse my brevity. Andriy Gapon wrote: >on 20/10/2012 11:08 Derek Kulinski said the following: >> Hello Andriy, >> >> Saturday, October 20, 2012, 12:37:19 AM, you wrote: >[snip] >>> Could you please also fetch sysutils/superiotool port from here >>> https://redports.org/browser/avg/sysutils/superiotool, replace what >you have >>> under /usr/ports, install the port and then run 'superiotool -d' >command? >> >> No luck: >> [chinatsu]:/tank/junk/ports/sysutils/superiotool# superiotool -d >> superiotool r4.0-2827-g1a00cf0 >> No Super I/O found > >Hmm, it would be a pity if all of this was a waste of time... >I based some of my assumptions on googling, in particular this post >http://thread.gmane.org/gmane.linux.bios.flashrom/1163 mentioned: >Found ITE Super I/O, ID 0x8728 on port 0x2e >BTW, I suppose "DH3H" in the subject line is a typo? Or is it a >different model? > >Oh, hmm, looks like even the latest superiotool may not have support >for this >newer chip. >Could you please run superiotool -V | fgrep Failed | fgrep -v ff ? >If this command returns id=0x8728, then you could hack superiotool >source code >between running 'make patch' and 'make'. You could edit ite.c file, >search for >0x8726 and either change it to 0x8728 or duplicate the whole section >and make >the change there. > >-- >Andriy Gapon >_______________________________________________ >freebsd-stable@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-stable >To unsubscribe, send any mail to >"freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 09:12:47 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D3712BF6 for ; Sat, 20 Oct 2012 09:12:47 +0000 (UTC) (envelope-from mueller23@insightbb.com) Received: from mail.insightbb.com (smtp2.insight.synacor.com [208.47.185.24]) by mx1.freebsd.org (Postfix) with ESMTP id 8E7648FC0C for ; Sat, 20 Oct 2012 09:12:46 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.0 cv=f43K9ZOM c=1 sm=0 a=Dm9TOXL4taQ+Gy1KovpL+A==:17 a=jLN7EqiLvroA:10 a=9YQ-1ebCAAAA:8 a=Hz0Dtrm5_sgA:10 a=kZoMnW_TYPRoPPfwawEA:9 a=Dm9TOXL4taQ+Gy1KovpL+A==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp01.insight.synacor.com smtp.mail=mueller23@insightbb.com; spf=softfail; sender-id=softfail Authentication-Results: smtp01.insight.synacor.com header.from=mueller23@insightbb.com; sender-id=softfail Received-SPF: softfail (smtp01.insight.synacor.com: transitional domain insightbb.com does not designate 74.130.198.7 as permitted sender) Received: from [74.130.198.7] ([74.130.198.7:34826] helo=localhost) by mail.insightbb.com (envelope-from ) (ecelerity 2.2.3.49 r(42060/42061)) with ESMTP id 05/12-17144-D0B62805; Sat, 20 Oct 2012 05:12:45 -0400 Date: Sat, 20 Oct 2012 05:12:45 -0400 Message-ID: <05.12.17144.D0B62805@smtp01.insight.synacor.com> From: "Thomas Mueller" To: freebsd-stable@freebsd.org Subject: Re: 9.1 and intel graphics X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 09:12:48 -0000 > Full support for the HD3000 is in 9-stable and 9.1-Beta and all RCs. > To use it you need to build X drivers and drm and the kernel with: > WITH_NEW_XORG=YES > WITH_KMS=YES > in /etc/make.conf. > Specifically, the kernel and a few ports. graphics/drm and your > org-drivers: xf86-video-intel, xf86-input-synaptics, xf86-input-mouse, > and xf86-input-keyboard. Then just start X. Don't try loading the > kernel module. It will be loaded by the startx. > > Finally, what happens when I leave x and want to go back to > > console mode? > You don't If you try, your system will lock up. You need to shutdown > from a window in X. Hopefully someone will implement switching back to > console mode some day, but it has not happened, yet. How do you shutdown from a window in X if you're nonroot? Can you have both root and nonroot windows simultaneously in X? Tom From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 09:24:34 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C0CDFE3 for ; Sat, 20 Oct 2012 09:24:34 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id 691B88FC17 for ; Sat, 20 Oct 2012 09:24:34 +0000 (UTC) Received: from X220.ovitrap.com ([122.129.201.55]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q9K9OQLB026415; Sat, 20 Oct 2012 03:24:28 -0600 Date: Sat, 20 Oct 2012 16:24:25 +0700 From: Erich Dollansky To: "Thomas Mueller" Subject: Re: 9.1 and intel graphics Message-ID: <20121020162425.4f1d8598@X220.ovitrap.com> In-Reply-To: <05.12.17144.D0B62805@smtp01.insight.synacor.com> References: <05.12.17144.D0B62805@smtp01.insight.synacor.com> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 09:24:34 -0000 Hi, On Sat, 20 Oct 2012 05:12:45 -0400 "Thomas Mueller" wrote: > > Full support for the HD3000 is in 9-stable and 9.1-Beta and all RCs. > > To use it you need to build X drivers and drm and the kernel with: > > WITH_NEW_XORG=YES > > WITH_KMS=YES > > in /etc/make.conf. > > > Specifically, the kernel and a few ports. graphics/drm and your > > org-drivers: xf86-video-intel, xf86-input-synaptics, > > xf86-input-mouse, and xf86-input-keyboard. Then just start X. Don't > > try loading the kernel module. It will be loaded by the startx. > > > > Finally, what happens when I leave x and want to go back to > > > console mode? > > > You don't If you try, your system will lock up. You need to shutdown > > from a window in X. Hopefully someone will implement switching back > > to console mode some day, but it has not happened, yet. > > How do you shutdown from a window in X if you're nonroot? Can you > have both root and nonroot windows simultaneously in X? I have all the while. You can also open a normal xterm and enter su to become root or start a xterm as root. It booth works. You are also able to start any other program as root. Erich From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 09:30:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6471E750 for ; Sat, 20 Oct 2012 09:30:49 +0000 (UTC) (envelope-from alonsoschaich@fastmail.fm) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 21F388FC08 for ; Sat, 20 Oct 2012 09:30:47 +0000 (UTC) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 511082081B for ; Sat, 20 Oct 2012 05:23:20 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute1.internal (MEProxy); Sat, 20 Oct 2012 05:23:20 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= from:to:subject:date:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; s=mesmtp; bh=6DBu1V8H5JrCLLwU+zUZeexH+zc=; b=RMhWnMKJ7eFBpj76bF41JWw4TU0u rZoD4grR3cT361vGR+RoCH2JR7r+Puv1U14Qi3Xt3xtnMsJl0DkZv4CKXcSOlVPW Y9oIlLt7dnZ2rdNn9Nk0TIuOMFRTYRYVsOwvN0RDVtA/VnEvkPKRtiOjTh38avuN fRfM6O5deggc0E0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=from:to:subject:date:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; s=smtpout; bh=6DBu1V8H5JrCLLwU+zUZeexH+zc=; b=LUQR4 yhdGrlHCkFTgfOwA39rd73GCJfphgfW+Gr6qbWgKZbKkRrSSk4rWBPmBVzXgcHjK kxSHSB0G7TNiPMiq/MFQDmqLCDzLxoO/JmsQK7eDRKW09wrfgUVJ3/lwcSbZqNuT 3f3BR750tAMwoZ5KYu9oGn2K4ftr5MrowDVt8A= X-Sasl-enc: zLhAqbiCeZdd+KDDpgDidks96ItZeRoTzsmjEK6DNIW3 1350725000 Received: from harmony.localnet.edu (unknown [141.87.213.55]) by mail.messagingengine.com (Postfix) with ESMTPA id 003A5482507 for ; Sat, 20 Oct 2012 05:23:19 -0400 (EDT) From: Schaich Alonso To: freebsd-stable@freebsd.org Subject: Re: 9.1 and intel graphics Date: Sat, 20 Oct 2012 11:22:06 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <05.12.17144.D0B62805@smtp01.insight.synacor.com> In-Reply-To: <05.12.17144.D0B62805@smtp01.insight.synacor.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201210201122.06467.alonsoschaich@fastmail.fm> X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 09:30:49 -0000 On 2012-10-20 (Saturday) 11:12:45 Thomas Mueller wrote: > > Full support for the HD3000 is in 9-stable and 9.1-Beta and all RCs. > > To use it you need to build X drivers and drm and the kernel with: > > WITH_NEW_XORG=YES > > WITH_KMS=YES > > in /etc/make.conf. > > > > Specifically, the kernel and a few ports. graphics/drm and your > > org-drivers: xf86-video-intel, xf86-input-synaptics, xf86-input-mouse, > > and xf86-input-keyboard. Then just start X. Don't try loading the > > kernel module. It will be loaded by the startx. > > > > > Finally, what happens when I leave x and want to go back to > > > console mode? > > > > You don't If you try, your system will lock up. You need to shutdown > > from a window in X. Hopefully someone will implement switching back to > > console mode some day, but it has not happened, yet. > > How do you shutdown from a window in X if you're nonroot? Can you have > both root and nonroot windows simultaneously in X? > > Tom > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" Hello, While you are not able to see anything on the screen, the system is still operational after X11 shutdown (or tty switch). Therefore you can still type input to the (invisible) command line or connect to that system via telnet/ssh/rlogin ... By default the system shuts down gracefully if you hit it's power button. If you're using GDM/KDM you can also use their shutdown options. Eventually it might crash during shutdown though (at least over here). Alonso From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 11:00:59 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E326B7F2 for ; Sat, 20 Oct 2012 11:00:59 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 83D518FC08 for ; Sat, 20 Oct 2012 11:00:59 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q9KB0psU061476; Sat, 20 Oct 2012 05:00:51 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q9KB0obb061473; Sat, 20 Oct 2012 05:00:51 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sat, 20 Oct 2012 05:00:50 -0600 (MDT) From: Warren Block To: Thomas Mueller Subject: Re: 9.1 and intel graphics In-Reply-To: <05.12.17144.D0B62805@smtp01.insight.synacor.com> Message-ID: References: <05.12.17144.D0B62805@smtp01.insight.synacor.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Sat, 20 Oct 2012 05:00:51 -0600 (MDT) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 11:01:00 -0000 On Sat, 20 Oct 2012, Thomas Mueller wrote: > How do you shutdown from a window in X if you're nonroot? Users that are a member of the operator group can run shutdown -p or -r. > Can you have both root and nonroot windows simultaneously in X? Sure. From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 11:24:31 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CF6ACB8D for ; Sat, 20 Oct 2012 11:24:31 +0000 (UTC) (envelope-from lbc@bnrlabs.com) Received: from mail.bnrlabs.com (did75-5-82-224-61-5.fbx.proxad.net [82.224.61.5]) by mx1.freebsd.org (Postfix) with ESMTP id 7C8468FC16 for ; Sat, 20 Oct 2012 11:24:30 +0000 (UTC) Received: from [127.0.0.1] (unknown [172.20.96.112]) by mail.bnrlabs.com (Postfix) with ESMTP id 40B0C46078 for ; Sat, 20 Oct 2012 13:19:15 +0200 (CEST) Message-ID: <508288B4.6010307@bnrlabs.com> Date: Sat, 20 Oct 2012 13:19:16 +0200 From: "Lucas B. Cohen" MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: 9.1-RC2 - could it be that the installer does not write the MBR? References: <50802EFC.2010101@gmail.com> <20121018184426.63c59601@suse3> In-Reply-To: <20121018184426.63c59601@suse3> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 11:24:32 -0000 On 2012.10.18 18:44, Rainer Duffner wrote: >> Thus >> > erasing grub when someone is attempting to install FreeBSD alongside >> > Linux? > > How many people actually do that, now that there are so many > virtualization-options? At least I do. As invaluable and paradigm-shifting as virtualization is, I still like to run different OSen on bare hardware. For example right now I'm working on a prototype FreeBSD NAS, troubleshooting problematic disc controllers, and being able to run a Linux kernel is very useful to compare how both systems see and use the hardware, or access some programs I'm more familiar with. I'm not saying I expect bsdinstaller to hold my hand ; I'm comfortable using gpart, fdisk, grub and dd to get what I want, but it would be nice if things were clear on what is going to happen (through user dialog or even simply in the FreeBSD Handbook). From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 12:53:04 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 94A0CEAD; Sat, 20 Oct 2012 12:53:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6AFDF8FC16; Sat, 20 Oct 2012 12:53:04 +0000 (UTC) Received: from ralph.baldwin.cx (c-68-39-198-164.hsd1.de.comcast.net [68.39.198.164]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D13DBB948; Sat, 20 Oct 2012 08:53:03 -0400 (EDT) From: John Baldwin To: Andrey Chernov Subject: Re: ${CTFCONVERT_CMD} expands to empty string Date: Sat, 20 Oct 2012 08:38:18 -0400 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <5081F92F.8040004@freebsd.org> In-Reply-To: <5081F92F.8040004@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201210200838.18297.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Sat, 20 Oct 2012 08:53:03 -0400 (EDT) Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 12:53:04 -0000 On Friday, October 19, 2012 09:06:55 PM Andrey Chernov wrote: > On recent -stable I got a lots of (see subj) now due to CTF changes in > *.mk files. > I have > WITHOUT_CDDL=yes > in my /etc/src.conf and WITHOUT_CDDL have wider scope than WITHOUT_CTF > suggested, but WITHOUT_CDDL is not checked in recent CTF changes. > Please fix this thing. Which stable? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 13:33:15 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D0FF3FA; Sat, 20 Oct 2012 13:33:15 +0000 (UTC) (envelope-from universite@ukr.net) Received: from ffe8.ukr.net (ffe8.ukr.net [195.214.192.88]) by mx1.freebsd.org (Postfix) with ESMTP id 7B15B8FC0A; Sat, 20 Oct 2012 13:33:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Date:Message-Id:From:To:Subject:Cc:Content-Type:Content-Transfer-Encoding:MIME-Version; bh=rsTOUDU4+QbKOqXhdcei32i5k5cLLojecptQU5HOAXs=; b=JhUm4k56UhhBzSlkOU41CBz/d58dJPwielARqRqyG0mvyzqBLVU5BKyAX9KDf/lbyYfR+aAuqS76CyYfayd4Xl40W4Mmb+8B59kLlp+8ZW3565MGTZlgcMTdtvZLW85WSYaABU7URF+G0/gMucA3BVjglfQ/DMOmzERCY2krlFg=; Received: from mail by ffe8.ukr.net with local ID 1TPYpw-000MeG-J9 ; Sat, 20 Oct 2012 16:11:32 +0300 MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: binary Content-Type: text/plain; charset="windows-1251" Subject: [ZFS] Server periodically become unavailable To: freebsd-current@freebsd.org From: "Vladislav Prodan" X-Mailer: freemail.ukr.net 4.0 Message-Id: <86879.1350738692.82582785788739584@ffe8.ukr.net> X-Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0.1 Date: Sat, 20 Oct 2012 16:11:32 +0300 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 13:33:16 -0000 >FreeBSD 9.1-PRERELEASE #0: Wed Jul 25 01:40:56 EEST 2012 I have the server: 8 cores AMD, 16GB RAM, 4x3TB HDD in RAID10 for ZFS. Sometime wheels fall off the server and the network. Can this clean-up memory for ZFS cache? I enclose a picture with the monitoring system at the time lags. http://imageshack.us/a/img341/9643/memoryusage.png http://imageshack.us/a/img22/6935/nginxclientstat.png http://imageshack.us/a/img19/8817/realmemory.png #cat /etc/sysctl.conf kern.ipc.somaxconn=65535 kern.ipc.maxsockets=204800 net.inet.ip.portrange.first=1024 net.inet.ip.portrange.last=65535 kern.ipc.shmmax=67108864 kern.ipc.shmall=67108864 net.inet.tcp.rfc3465=0 net.graph.maxdgram=8388608 net.graph.recvspace=8388608 net.route.netisr_maxqlen=4096 kern.ipc.nmbclusters=400000 kern.ipc.maxsockbuf=83886080 net.inet.tcp.recvbuf_inc=524288 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.sendbuf_inc=524288 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.sendspace=65536 net.inet.tcp.keepidle=300000 net.inet.tcp.keepintvl=60000 net.inet.ip.fw.dyn_max=65535 net.inet.ip.fw.dyn_buckets=65536 net.inet.ip.fw.dyn_ack_lifetime=120 net.inet.ip.fw.dyn_syn_lifetime=10 net.inet.tcp.nolocaltimewait=1 security.bsd.hardlink_check_uid=1 security.bsd.hardlink_check_gid=1 security.bsd.see_other_uids=0 security.bsd.see_other_gids=0 -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 14:10:26 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8DC27A0E for ; Sat, 20 Oct 2012 14:10:26 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 4941F8FC16 for ; Sat, 20 Oct 2012 14:10:26 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id q9KEAJ7g032894 for ; Sat, 20 Oct 2012 07:10:19 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id q9KEAJWx032893 for stable@freebsd.org; Sat, 20 Oct 2012 07:10:19 -0700 (PDT) (envelope-from david) Date: Sat, 20 Oct 2012 07:10:19 -0700 From: David Wolfskill To: stable@freebsd.org Subject: stable/9 @r241776 panic: REDZONE: Buffer underflow detected... Message-ID: <20121020141019.GW1817@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="K9yN6gtjNHvbaj05" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 14:10:26 -0000 --K9yN6gtjNHvbaj05 Content-Type: multipart/mixed; boundary="uqlJfHshKOiOfK6d" Content-Disposition: inline --uqlJfHshKOiOfK6d Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable This seems ... fairly weird to me. Yesterday, I built & booted: FreeBSD g1-227.catwhisker.org 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #274 24= 1726M: Fri Oct 19 05:40:05 PDT 2012 root@g1-227.catwhisker.org:/usr/obj= /usr/src/sys/CANARY i386 and used the machine all day; nothing unusual (including various reboots (e.g. when I disembarked the train for the final leg of my commute home, so I powered the laptop off). This morning, I built: FreeBSD g1-227.catwhisker.org 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #275 24= 1776M: Sat Oct 20 04:34:45 PDT 2012 root@g1-227.catwhisker.org:/usr/obj= /usr/src/sys/CANARY i386 and on first reboot, I got a panic. After a bit of experimentation, it appears that I get a panic @r241776 if I attempt a normal boot into multi-user mode, but if I first boot to single-user mode, then exit single-user mode, it comes up without a problem. I don't have a serial console, so I started to write down some of the panic information, but my patience ran a bit short. Here's whet I recorded (warning: hand-transcripted -- twice!): =2E.. Starting devd. REDZONE: Buffer underflow detected. 1 byte corrupted before 0xced40080 (42= 94966796 bytes allocated). Allocation backtrace: #0 0xc0ceac8f at redzone_setup+0xcf #1 0xc0a5d5c9 at malloc+0x1d9 =2E..[about 20 more such lines I didn't record]... > bt Tracing pid 901 tid 100106 td 0xd2b99000 kdb_enter(...) panic(...) free(...) devread(ce8c2d00,f7274c0c,0,c0b1e4f0,d279e380,...) at devread+0x1a6 giant_read(...) at giant_read+0x87 devfs_read(...) at devfs_read+0xc6 dofileread(...) at dofileread+0x99 sys_read(...) at sys_read+0x98 syscall(f7274d08) at syscall+0x387 Within the bounds described above, this appears to be quite reproducible -- on my laptop. My build machine (updated in parallel, at the same GRNs) does not exhibit the panic. I was unable to get a crash dump; I have dumpdev=3D"AUTO" in /etc/rc.conf, and the panic was occurring well after swap was enabled. (Yes, I know I have swap over-allocated. I plan to do something about it at some point.) I've attached a copy of dmesg.boot. Anyone else seeing this? Any ideas how to diagnose it? Thanks! Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --uqlJfHshKOiOfK6d Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.boot.9.1-PRERELEASE" Content-Transfer-Encoding: quoted-printable Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.1-PRERELEASE #275 241776M: Sat Oct 20 04:34:45 PDT 2012 root@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 WARNING: DIAGNOSTIC option enabled, expect reduced performance. MEMGUARD DEBUGGING ALLOCATOR INITIALIZED: MEMGUARD map base: 0xc8000000 MEMGUARD map limit: 0xce681000 MEMGUARD map size: 104964 KBytes CPU: Intel(R) Core(TM)2 Duo CPU T9600 @ 2.80GHz (2793.06-MHz 686-class= CPU) Origin =3D "GenuineIntel" Id =3D 0x10676 Family =3D 0x6 Model =3D 0x17= Stepping =3D 6 Features=3D0xbfebfbff Features2=3D0x8e3fd AMD Features=3D0x20100000 AMD Features2=3D0x1 TSC: P-state invariant, performance statistics real memory =3D 4294967296 (4096 MB) avail memory =3D 3643670528 (3474 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 acpi0: reservation of 0, 9f000 (3) failed acpi0: reservation of 100000, df351c00 (3) failed cpu0: on acpi0 cpu1: on acpi0 atrtc0: port 0x70-0x71,0x72-0x77 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 2 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 acpi_ec0: port 0x930,0x934 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xdf00-0xdf7f mem 0xf5000000-0xf5fff= fff,0xe0000000-0xefffffff,0xf2000000-0xf3ffffff irq 16 at device 0.0 on pci1 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io pci0: at device 3.0 (no driver attached) atapci0: port 0xef78-0xef7f,0xef70-0xef73,0xef80-0xe= f87,0xef74-0xef77,0xef90-0xef9f irq 18 at device 3.2 on pci0 ata2: at channel 0 on atapci0 ata3: at channel 1 on atapci0 pci0: at device 3.3 (no driver attached) em0: port 0xefe0-0xefff mem 0x= f6fe0000-0xf6ffffff,0xf6fdb000-0xf6fdbfff irq 22 at device 25.0 on pci0 em0: Using an MSI interrupt em0: Ethernet address: 00:24:e8:9c:11:0f uhci0: port 0x6f60-0x6f7f irq 20 at de= vice 26.0 on pci0 uhci0: LegSup =3D 0x2f00 usbus0 on uhci0 uhci1: port 0x6f80-0x6f9f irq 21 at de= vice 26.1 on pci0 uhci1: LegSup =3D 0x2f00 usbus1 on uhci1 uhci2: port 0x6fa0-0x6fbf irq 22 at de= vice 26.2 on pci0 uhci2: LegSup =3D 0x2f00 usbus2 on uhci2 ehci0: mem 0xfed1c400-0xfed1c7ff i= rq 22 at device 26.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 hdac0: mem 0xf6fdc000-0xf6fdffff irq 21 at de= vice 27.0 on pci0 pcib2: at device 28.0 on pci0 pci11: on pcib2 pcib3: at device 28.1 on pci0 pci12: on pcib3 iwn0: mem 0xf1ffe000-0xf1ffffff irq 17 at= device 0.0 on pci12 pcib4: at device 28.2 on pci0 pci13: on pcib4 pcib5: at device 28.3 on pci0 pci14: on pcib5 uhci3: port 0x6f00-0x6f1f irq 20 at de= vice 29.0 on pci0 uhci3: LegSup =3D 0x2f00 usbus4 on uhci3 uhci4: port 0x6f20-0x6f3f irq 21 at de= vice 29.1 on pci0 uhci4: LegSup =3D 0x2f00 usbus5 on uhci4 uhci5: port 0x6f40-0x6f5f irq 22 at de= vice 29.2 on pci0 uhci5: LegSup =3D 0x2f00 usbus6 on uhci5 ehci1: mem 0xfed1c000-0xfed1c3ff i= rq 20 at device 29.7 on pci0 usbus7: EHCI version 1.0 usbus7 on ehci1 pcib6: at device 30.0 on pci0 pci3: on pcib6 cbb0: irq 19 at device 1.0 on pci3 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 fwohci0: <1394 Open Host Controller Interface> mem 0xf1bff800-0xf1bfffff ir= q 17 at device 1.1 on pci3 fwohci0: OHCI version 1.10 (ROM=3D0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 4a:4f:c0:00:10:37:06:01 fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 4a:4f:c0:37:06:01 fwe0: Ethernet address: 4a:4f:c0:37:06:01 fwip0: on firewire0 fwip0: Firewire address: 4a:4f:c0:00:10:37:06:01 @ 0xfffe00000000, S400, ma= xrec 2048 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x20e8000 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=3D0x00000000, SelfID Count=3D1, CYCLEMAS= TER mode sdhci0: mem 0xf1bff600-0xf1bff6ff irq 18 at device 1.2 on= pci3 sdhci0: 1 slot(s) allocated pci3: at device 1.3 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0x6e70-0x6e77,0x6e78-0x6e7b,= 0x6e80-0x6e87,0x6e88-0x6e8b,0x6ea0-0x6ebf mem 0xfed1c800-0xfed1cfff irq 19 = at device 31.2 on pci0 ahci0: AHCI v1.20 with 4 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 ichsmb0: port 0x1100-0x111f mem 0xf6= fd9f00-0xf6fd9fff irq 19 at device 31.3 on pci0 smbus0: on ichsmb0 smb0: on smbus0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 battery1: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64,0x62,0x66 irq 1 on ac= pi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model GlidePoint, device ID 0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xce7ff,0xce800-0xcffff pnpid ORM0= 000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ata0: at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata1: at port 0x170-0x177,0x376 irq 15 on isa0 ppc0: parallel port not found. ctl: CAM Target Layer loaded coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <=3D 0 cable IRM irm(0) (me)=20 firewire0: bus manager 0=20 ipfw2 (+ipv6) initialized, divert enabled, nat loadable, rule-based forward= ing enabled, default to deny, logging disabled DUMMYNET 0 with IPv6 initialized (100409) load_dn_sched dn_sched FIFO loaded load_dn_sched dn_sched PRIO loaded load_dn_sched dn_sched QFQ loaded load_dn_sched dn_sched RR loaded load_dn_sched dn_sched WF2Q+ loaded hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 13,10 and 11,14 on hdaa0 pcm1: at nid 15 and 24 on hdaa0 pcm2: at nid 30 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 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 Expensive timeout(9) function: 0xc0ab2680(0xcefa12f0) 0.002124711 s ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered Expensive timeout(9) function: 0xc055ae80(0xcf307e80) 0.365924998 s uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered ada0 at ahcich0 bus 0 scbus2 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad8 cd0 at ahcich1 bus 0 scbus3 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device=20 cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - t= ray closed SMP: AP CPU #1 Launched! WARNING: DIAGNOSTIC option enabled, expect reduced performance. GEOM: ada0s1: geometry does not match label (255h,63s !=3D 16h,63s). GEOM: ada0s2: geometry does not match label (255h,63s !=3D 16h,63s). GEOM: ada0s3: geometry does not match label (255h,63s !=3D 16h,63s). GEOM: ada0s4: geometry does not match label (255h,63s !=3D 16h,63s). Trying to mount root from ufs:/dev/ada0s1a [rw]... WARNING: / was not properly dismounted warning: total configured swap (5242880 pages) exceeds maximum recommended = amount (2097312 pages). warning: increase kern.maxswzone or reduce amount of swap. wlan0: Ethernet address: 00:21:6a:26:34:c0 --uqlJfHshKOiOfK6d-- --K9yN6gtjNHvbaj05 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCCsMsACgkQmprOCmdXAD389QCcDaRnI643aWBu+fe8vOJWdn5s GaYAnj9PESToWuBdlrbdkkr4I0W4M4u5 =m9Qu -----END PGP SIGNATURE----- --K9yN6gtjNHvbaj05-- From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 17:04:11 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 74A65519 for ; Sat, 20 Oct 2012 17:04:11 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from mail.ultra-secure.de (mail.ultra-secure.de [78.47.114.122]) by mx1.freebsd.org (Postfix) with ESMTP id A3B4C8FC08 for ; Sat, 20 Oct 2012 17:04:09 +0000 (UTC) Received: (qmail 73805 invoked by uid 89); 20 Oct 2012 17:04:03 -0000 Received: by simscan 1.4.0 ppid: 73800, pid: 73802, t: 0.0470s scanners: attach: 1.4.0 clamav: 0.97.3/m:54/d:15481 Received: from unknown (HELO suse3) (rainer@ultra-secure.de@212.71.117.1) by mail.ultra-secure.de with ESMTPA; 20 Oct 2012 17:04:03 -0000 Date: Sat, 20 Oct 2012 19:04:02 +0200 From: Rainer Duffner To: Glen Barber Subject: Re: 9.1-RC2 - could it be that the installer does not write the MBR? Message-ID: <20121020190402.253eb553@suse3> In-Reply-To: <20121020001401.GQ1393@glenbarber.us> References: <50802EFC.2010101@gmail.com> <20121018184426.63c59601@suse3> <50803B22.7000706@gmail.com> <20121019223841.09866aac@linux-wb36.example.org> <20121019211130.GM1393@glenbarber.us> <20121020020603.628125c8@linux-wb36.example.org> <20121020001401.GQ1393@glenbarber.us> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-suse-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , freebsd-stable@freebsd.org, Chuck Burns X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 17:04:11 -0000 Am Fri, 19 Oct 2012 20:14:01 -0400 schrieb Glen Barber : > The grub prompt for (Open)Solaris? Or do you use grub on FreeBSD? I thought it was a linux grub (the Firmware-Update DVD is linux-based and I thought it had gone postal. But I came to realize that it was the Solaris grub. We only use FreeBSD on servers and it's always the only OS on the disks. > I _think_ at this point, you've hit the same problem I hit, the only > difference is that in my case, 9.1-PRERELEASE was installed twice, > because the paritions were not ideal. > > So, my guess is if you were to boot the install cd and select 'Live > CD' or 'Shell' from the first menu option, and wrote the GPT bootcode > to da0p1 (assuming da0 is the drive) and reboot, it would have booted > fine. I don't think this is what a user is expecting from an OS installation routine.... It's a bug. Rainer From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 17:13:54 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DF275767; Sat, 20 Oct 2012 17:13:54 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id A15C78FC0C; Sat, 20 Oct 2012 17:13:54 +0000 (UTC) Received: from glenbarber.us (nucleus.glenbarber.us [IPv6:2001:470:8:1205:2:2:0:100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 2B5DB23F645; Sat, 20 Oct 2012 13:13:53 -0400 (EDT) Date: Sat, 20 Oct 2012 13:13:50 -0400 From: Glen Barber To: Rainer Duffner Subject: Re: 9.1-RC2 - could it be that the installer does not write the MBR? Message-ID: <20121020171350.GX1393@glenbarber.us> References: <50802EFC.2010101@gmail.com> <20121018184426.63c59601@suse3> <50803B22.7000706@gmail.com> <20121019223841.09866aac@linux-wb36.example.org> <20121019211130.GM1393@glenbarber.us> <20121020020603.628125c8@linux-wb36.example.org> <20121020001401.GQ1393@glenbarber.us> <20121020190402.253eb553@suse3> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5aNh9si8bffKePh3" Content-Disposition: inline In-Reply-To: <20121020190402.253eb553@suse3> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Adrian Chadd , freebsd-stable@freebsd.org, Chuck Burns X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 17:13:54 -0000 --5aNh9si8bffKePh3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 20, 2012 at 07:04:02PM +0200, Rainer Duffner wrote: > Am Fri, 19 Oct 2012 20:14:01 -0400 > schrieb Glen Barber : >=20 >=20 > > The grub prompt for (Open)Solaris? Or do you use grub on FreeBSD? >=20 > I thought it was a linux grub (the Firmware-Update DVD is linux-based > and I thought it had gone postal. > But I came to realize that it was the Solaris grub. > We only use FreeBSD on servers and it's always the only OS on the disks. > =20 Ok, thank you. I did not want to assume anything here. > > I _think_ at this point, you've hit the same problem I hit, the only > > difference is that in my case, 9.1-PRERELEASE was installed twice, > > because the paritions were not ideal. > >=20 > > So, my guess is if you were to boot the install cd and select 'Live > > CD' or 'Shell' from the first menu option, and wrote the GPT bootcode > > to da0p1 (assuming da0 is the drive) and reboot, it would have booted > > fine. >=20 >=20 > I don't think this is what a user is expecting from an OS installation > routine.... > It's a bug. >=20 Oh, I agree. For what it is worth, when I ran into this, I just merely thought I did something wrong during the install, so writing the gptboot code to the drive was my quick fix. I originally didn't bother reproducing it, until about an hour later when I saw this thread start. The frustrating part now is I have had zero luck reproducing the problem... Glen --5aNh9si8bffKePh3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQgtvOAAoJEFJPDDeguUajHJAIAIUngIC5UIuEQC/uVcm0K9zM vbgj/TClargbFGaWkYFHwVXMR1Of4++3i2RsrTsEfKIMsv2pu5DS0BW0B4lX7RvR VWZB9i34w4AWkFpzta4FyYukro/qPHjpzpMMM/iFPazHO3kuYrvcDwyhdgvMYvAE jUlaAQozTMeT6aF678EUfi3Hfu2irw/rzENXJeuyQGckdWjAk+oKGd9VAtDNQb9x SC8V9Yv043r1jmgiB0L5yzRSWzWGZPPISms0hdOHaEvMdtA0Jk7z8LLIJcqs6IqS dGQ19nuh+CEwmvcMOojJQxY2AdB2SoHxyl5UhbX7pkNkV4EYS05XaIj7o4VcIIA= =c7oZ -----END PGP SIGNATURE----- --5aNh9si8bffKePh3-- From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 17:38:06 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A0F27262; Sat, 20 Oct 2012 17:38:06 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from chinatsu.takeda.tk (mail.takeda.tk [74.0.89.210]) by mx1.freebsd.org (Postfix) with ESMTP id 66CE48FC0A; Sat, 20 Oct 2012 17:38:05 +0000 (UTC) Received: from takeda-ws.lan (takeda-ws.lan [10.0.0.3]) (authenticated bits=0) by chinatsu.takeda.tk (8.14.5/8.14.5) with ESMTP id q9KHc4AT064570 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 20 Oct 2012 10:38:05 -0700 (PDT) (envelope-from takeda@takeda.tk) Date: Sat, 20 Oct 2012 10:37:32 -0700 From: Derek Kulinski X-Priority: 3 (Normal) Message-ID: <55342693.20121020103732@takeda.tk> To: Andriy Gapon Subject: Re: Problem reading vitals from Gigabyte H77-DH3H In-Reply-To: <50826040.6010106@FreeBSD.org> References: <1286515493.20121017131543@takeda.tk> <507F1761.1010202@FreeBSD.org> <20121017205147.GB36106@chinatsu.takeda.tk> <5081552F.2050303@FreeBSD.org> <771658188.20121019205010@takeda.tk> <508254AF.7040709@FreeBSD.org> <994545137.20121020010809@takeda.tk> <50826040.6010106@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 17:38:06 -0000 Hello Andriy, Saturday, October 20, 2012, 1:26:40 AM, you wrote: > Hmm, it would be a pity if all of this was a waste of time... > I based some of my assumptions on googling, in particular this post > http://thread.gmane.org/gmane.linux.bios.flashrom/1163 mentioned: > Found ITE Super I/O, ID 0x8728 on port 0x2e > BTW, I suppose "DH3H" in the subject line is a typo? Or is it a different model? Actually it is a typo, the model is H77-DS3H, sorry for the mistake. > Oh, hmm, looks like even the latest superiotool may not have support for this > newer chip. > Could you please run superiotool -V | fgrep Failed | fgrep -v ff ? # superiotool -V | fgrep Failed | fgrep -v ff Failed. Returned data: id=0x8728, rev=0x1 > If this command returns id=0x8728, then you could hack superiotool source code > between running 'make patch' and 'make'. You could edit ite.c file, search for > 0x8726 and either change it to 0x8728 or duplicate the whole section and make > the change there. After the change I run superiotool with -d, here is the output: superiotool r4.0-2827-g1a00cf0 Found ITE IT8726F (id=0x8728, rev=0x1) at 0x2e Register dump: idx 20 21 22 23 24 2b val 87 28 01 00 00 40 def 87 26 01 00 MM 00 LDN 0x00 (Floppy) idx 30 60 61 70 74 f0 f1 val 00 03 f0 06 02 00 00 def 00 03 f0 06 02 00 00 LDN 0x01 (COM1) idx 30 60 61 70 f0 f1 f2 f3 val 01 03 f8 04 00 50 50 50 def 00 03 f8 04 00 50 00 7f LDN 0x02 (COM2) idx 30 60 61 70 f0 f1 f2 f3 val 00 02 f8 03 00 50 50 50 def 00 02 f8 03 00 50 00 7f LDN 0x03 (Parallel port) idx 30 60 61 62 63 70 74 f0 val 00 03 78 07 78 07 04 0b def 00 03 78 07 78 07 03 03 LDN 0x04 (Environment controller) idx 30 60 61 62 63 70 f0 f1 f2 f3 f4 f5 f6 val 01 0a 30 0a 20 09 00 40 00 00 20 00 f0 def 00 02 90 02 30 09 00 00 00 00 00 MM MM LDN 0x05 (Keyboard) idx 30 60 61 62 63 70 71 f0 val 01 00 60 00 64 01 02 08 def 01 00 60 00 64 01 02 08 LDN 0x06 (Mouse) idx 30 70 71 f0 val 01 0c 02 00 def 00 0c 02 00 LDN 0x07 (GPIO) idx 25 26 27 28 29 2a 2c 60 61 62 63 64 65 70 71 72 73 74 b0 b1 b2 b3 b4 b5 b8 b9 ba bb bc bd c0 c1 c2 c3 c4 c8 c9 ca cb cc e0 e1 e2 e3 e4 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd val 00 f3 10 00 00 00 80 00 00 0a 00 00 00 00 00 20 00 00 00 00 00 00 00 00 20 00 00 00 00 00 01 00 00 40 00 01 00 00 00 00 00 00 00 00 00 10 42 00 00 00 00 1c 00 00 00 00 00 80 00 def 01 00 00 40 00 00 1f 00 00 00 00 00 00 00 00 MM 38 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 40 00 01 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 MM 00 LDN 0x08 (MIDI port) idx 30 60 61 70 f0 val 00 00 00 00 00 def 00 03 00 0a 00 LDN 0x09 (Game port) idx 30 60 61 val 00 00 00 def 00 02 01 LDN 0x0a (Consumer IR) idx 30 60 61 70 f0 val 00 03 10 0b 06 def 00 03 10 0b 00 -- Best regards, Derek mailto:takeda@takeda.tk There are two ways to write error-free programs; only the third one works. -- Alan J. Perlis From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 17:40:16 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CD488475; Sat, 20 Oct 2012 17:40:16 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id 9A4298FC14; Sat, 20 Oct 2012 17:40:16 +0000 (UTC) Received: from glenbarber.us (nucleus.glenbarber.us [IPv6:2001:470:8:1205:2:2:0:100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 4EAC423F645; Sat, 20 Oct 2012 13:40:15 -0400 (EDT) Date: Sat, 20 Oct 2012 13:40:12 -0400 From: Glen Barber To: Warren Block Subject: Re: 9.1-RC2 - could it be that the installer does not write the MBR? Message-ID: <20121020174012.GZ1393@glenbarber.us> References: <50802EFC.2010101@gmail.com> <20121018184426.63c59601@suse3> <50803B22.7000706@gmail.com> <20121019223841.09866aac@linux-wb36.example.org> <20121019211130.GM1393@glenbarber.us> <20121020020603.628125c8@linux-wb36.example.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nuo3pj+LxAUL1L82" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Adrian Chadd , freebsd-stable@freebsd.org, Chuck Burns , Rainer Duffner X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 17:40:16 -0000 --nuo3pj+LxAUL1L82 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 19, 2012 at 10:21:54PM -0600, Warren Block wrote: > I don't know if this is the problem, but it is worth pointing out that=20 > graid(8) is now included in GENERIC. Leftover hardware RAID metadata=20 > could make for unexpected results. For example, > http://forums.freebsd.org/showthread.php?t=3D35168 Definitely worth noting. GEOM_MIRROR can do this too, iirc. In my case, however, the target installation disk was not previously part of any RAID configuration, software or otherwise. Glen --nuo3pj+LxAUL1L82 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQguH8AAoJEFJPDDeguUajIkoIAJAWy9lppijL+GJu5YBowSU9 cPf+oWb/RXnfjr5xfUbgi9bIvjckl0dOnPqeidqLxyWv7PhL/b7R1qBulvDAhncE jFxBTsI8i5NT5vA7Jzd7xN1T6b97nM7BwkWFEo3p6JMiJAZb+z463zQtHhofw/9W mxwbhexq3n2qBy4j9P0ZqBXBrW9jAxS7+gJlurmkPrE9LODjTTs1N1Yx9yZg7BWG PKmhcN95j/KC5LFQvjZ4H2ffsVJuJrDCM/wnR/Ag0p2CccHzJbV3ga8kw2wO5Bqv 9s3hcHLPiebw/7ihtwrIlKBMZdtQbngG32ruZGRDO7wK2zyER4nsT9jMNVge1bs= =8gSc -----END PGP SIGNATURE----- --nuo3pj+LxAUL1L82-- From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 18:34:55 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 907E4462 for ; Sat, 20 Oct 2012 18:34:55 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D523C8FC08 for ; Sat, 20 Oct 2012 18:34:54 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA11420; Sat, 20 Oct 2012 21:34:49 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TPdsm-000Bag-Ot; Sat, 20 Oct 2012 21:34:48 +0300 Message-ID: <5082EEC8.2080307@FreeBSD.org> Date: Sat, 20 Oct 2012 21:34:48 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121013 Thunderbird/16.0.1 MIME-Version: 1.0 To: Derek Kulinski Subject: Re: Problem reading vitals from Gigabyte H77-DH3H References: <1286515493.20121017131543@takeda.tk> <507F1761.1010202@FreeBSD.org> <20121017205147.GB36106@chinatsu.takeda.tk> <5081552F.2050303@FreeBSD.org> <771658188.20121019205010@takeda.tk> <508254AF.7040709@FreeBSD.org> <994545137.20121020010809@takeda.tk> <50826040.6010106@FreeBSD.org> <55342693.20121020103732@takeda.tk> In-Reply-To: <55342693.20121020103732@takeda.tk> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 18:34:55 -0000 on 20/10/2012 20:37 Derek Kulinski said the following: > Hello Andriy, > > Saturday, October 20, 2012, 1:26:40 AM, you wrote: > >> Hmm, it would be a pity if all of this was a waste of time... >> I based some of my assumptions on googling, in particular this post >> http://thread.gmane.org/gmane.linux.bios.flashrom/1163 mentioned: >> Found ITE Super I/O, ID 0x8728 on port 0x2e >> BTW, I suppose "DH3H" in the subject line is a typo? Or is it a different model? > > Actually it is a typo, the model is H77-DS3H, sorry for the mistake. > >> Oh, hmm, looks like even the latest superiotool may not have support for this >> newer chip. >> Could you please run superiotool -V | fgrep Failed | fgrep -v ff ? > > # superiotool -V | fgrep Failed | fgrep -v ff > Failed. Returned data: id=0x8728, rev=0x1 > >> If this command returns id=0x8728, then you could hack superiotool source code >> between running 'make patch' and 'make'. You could edit ite.c file, search for >> 0x8726 and either change it to 0x8728 or duplicate the whole section and make >> the change there. > > After the change I run superiotool with -d, here is the output: > > superiotool r4.0-2827-g1a00cf0 > Found ITE IT8726F (id=0x8728, rev=0x1) at 0x2e > Register dump: > idx 20 21 22 23 24 2b > val 87 28 01 00 00 40 > def 87 26 01 00 MM 00 > LDN 0x00 (Floppy) > idx 30 60 61 70 74 f0 f1 > val 00 03 f0 06 02 00 00 > def 00 03 f0 06 02 00 00 > LDN 0x01 (COM1) > idx 30 60 61 70 f0 f1 f2 f3 > val 01 03 f8 04 00 50 50 50 > def 00 03 f8 04 00 50 00 7f > LDN 0x02 (COM2) > idx 30 60 61 70 f0 f1 f2 f3 > val 00 02 f8 03 00 50 50 50 > def 00 02 f8 03 00 50 00 7f > LDN 0x03 (Parallel port) > idx 30 60 61 62 63 70 74 f0 > val 00 03 78 07 78 07 04 0b > def 00 03 78 07 78 07 03 03 > LDN 0x04 (Environment controller) > idx 30 60 61 62 63 70 f0 f1 f2 f3 f4 f5 f6 > val 01 0a 30 0a 20 09 00 40 00 00 20 00 f0 > def 00 02 90 02 30 09 00 00 00 00 00 MM MM If this information is to be trusted (i.e. 8728 is sufficiently compatible with 8726), then please try to set port number in the hints to 0xa30 (e.g. where you have 0x290 now). > LDN 0x05 (Keyboard) > idx 30 60 61 62 63 70 71 f0 > val 01 00 60 00 64 01 02 08 > def 01 00 60 00 64 01 02 08 > LDN 0x06 (Mouse) > idx 30 70 71 f0 > val 01 0c 02 00 > def 00 0c 02 00 > LDN 0x07 (GPIO) > idx 25 26 27 28 29 2a 2c 60 61 62 63 64 65 70 71 72 73 74 b0 b1 b2 b3 b4 b5 b8 b9 ba bb bc bd c0 c1 c2 c3 c4 c8 c9 ca cb cc e0 e1 e2 e3 e4 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd > val 00 f3 10 00 00 00 80 00 00 0a 00 00 00 00 00 20 00 00 00 00 00 00 00 00 20 00 00 00 00 00 01 00 00 40 00 01 00 00 00 00 00 00 00 00 00 10 42 00 00 00 00 1c 00 00 00 00 00 80 00 > def 01 00 00 40 00 00 1f 00 00 00 00 00 00 00 00 MM 38 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 40 00 01 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 MM 00 > LDN 0x08 (MIDI port) > idx 30 60 61 70 f0 > val 00 00 00 00 00 > def 00 03 00 0a 00 > LDN 0x09 (Game port) > idx 30 60 61 > val 00 00 00 > def 00 02 01 > LDN 0x0a (Consumer IR) > idx 30 60 61 70 f0 > val 00 03 10 0b 06 > def 00 03 10 0b 00 > -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 19:20:44 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C830C566; Sat, 20 Oct 2012 19:20:44 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from chinatsu.takeda.tk (mail.takeda.tk [74.0.89.210]) by mx1.freebsd.org (Postfix) with ESMTP id 7A20C8FC14; Sat, 20 Oct 2012 19:20:44 +0000 (UTC) Received: from takeda-ws.lan (takeda-ws.lan [10.0.0.3]) (authenticated bits=0) by chinatsu.takeda.tk (8.14.5/8.14.5) with ESMTP id q9KJKh4t002089 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 20 Oct 2012 12:20:43 -0700 (PDT) (envelope-from takeda@takeda.tk) Date: Sat, 20 Oct 2012 12:20:34 -0700 From: Derek Kulinski X-Priority: 3 (Normal) Message-ID: <198684285.20121020122034@takeda.tk> To: Andriy Gapon Subject: Re: Problem reading vitals from Gigabyte H77-DH3H In-Reply-To: <5082EEC8.2080307@FreeBSD.org> References: <1286515493.20121017131543@takeda.tk> <507F1761.1010202@FreeBSD.org> <20121017205147.GB36106@chinatsu.takeda.tk> <5081552F.2050303@FreeBSD.org> <771658188.20121019205010@takeda.tk> <508254AF.7040709@FreeBSD.org> <994545137.20121020010809@takeda.tk> <50826040.6010106@FreeBSD.org> <55342693.20121020103732@takeda.tk> <5082EEC8.2080307@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 19:20:44 -0000 Hello Andriy, Saturday, October 20, 2012, 11:34:48 AM, you wrote: > If this information is to be trusted (i.e. 8728 is sufficiently compatible with > 8726), then please try to set port number in the hints to 0xa30 (e.g. where you > have 0x290 now). It appears to work fine: hw.sensors.it0.fan0: 997 RPM hw.sensors.it0.fan1: invalid hw.sensors.it0.fan2: 1305 RPM hw.sensors.it0.volt0: 1,42 VDC (VCORE_A) hw.sensors.it0.volt1: 2,72 VDC (VCORE_B) hw.sensors.it0.volt2: 2,70 VDC (+3.3V) hw.sensors.it0.volt3: 4,60 VDC (+5V) hw.sensors.it0.volt4: 0,06 VDC (+12V) hw.sensors.it0.volt5: -5,23 VDC (Unused) hw.sensors.it0.volt6: -6,53 VDC (-12V) hw.sensors.it0.volt7: 3,74 VDC (+5VSB) hw.sensors.it0.volt8: 2,14 VDC (VBAT) hw.sensors.it0.temp0: 30,00 degC hw.sensors.it0.temp1: 25,00 degC hw.sensors.it0.temp2: 25,00 degC I have three questions though: 1. The motherboard has 4 fan sockets (as far as I can tell), CPU_FAN, and SYS_FAN[1-3]. SYS_FAN1 currently is not connected. Seems like: fan0 -> CPU_FAN (did not try to disconnect it to check :) fan1 -> SYS_FAN1 fan2 -> SYS_FAN2 There is no entry for SYS_FAN3. I disconnected it temporarily but it did not seem to affect the output. Is it possible to get that information from the motherboard? 2. Is there a way for me to figure out which temperature is which? Or at least which one would correspond to H77's temperature? Is it possible that the temperature is not listed? Right now as I check it the component is hot enough to make it hard for me to touch the heat sink. I would think it would be higher than 30C. 3. When will the it module be included with the FreeBSD? Anyway thank you so much for your help so far. At least have meaningful values now that appear to be real (i.e. they change). Can't verify whether the voltages are correct due to my limited knowledge. -- Best regards, Derek mailto:takeda@takeda.tk If brute force doesn't solve your problems, then you aren't using enough. From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 19:42:41 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 601C3F76 for ; Sat, 20 Oct 2012 19:42:41 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A00D98FC08 for ; Sat, 20 Oct 2012 19:42:40 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA11733; Sat, 20 Oct 2012 22:42:34 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TPewL-000Bh5-Ut; Sat, 20 Oct 2012 22:42:34 +0300 Message-ID: <5082FEA8.3050600@FreeBSD.org> Date: Sat, 20 Oct 2012 22:42:32 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121013 Thunderbird/16.0.1 MIME-Version: 1.0 To: Derek Kulinski Subject: Re: Problem reading vitals from Gigabyte H77-DH3H References: <1286515493.20121017131543@takeda.tk> <507F1761.1010202@FreeBSD.org> <20121017205147.GB36106@chinatsu.takeda.tk> <5081552F.2050303@FreeBSD.org> <771658188.20121019205010@takeda.tk> <508254AF.7040709@FreeBSD.org> <994545137.20121020010809@takeda.tk> <50826040.6010106@FreeBSD.org> <55342693.20121020103732@takeda.tk> <5082EEC8.2080307@FreeBSD.org> <198684285.20121020122034@takeda.tk> In-Reply-To: <198684285.20121020122034@takeda.tk> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 19:42:41 -0000 on 20/10/2012 22:20 Derek Kulinski said the following: > Hello Andriy, > > Saturday, October 20, 2012, 11:34:48 AM, you wrote: > >> If this information is to be trusted (i.e. 8728 is sufficiently compatible with >> 8726), then please try to set port number in the hints to 0xa30 (e.g. where you >> have 0x290 now). > > It appears to work fine: > hw.sensors.it0.fan0: 997 RPM > hw.sensors.it0.fan1: invalid > hw.sensors.it0.fan2: 1305 RPM > hw.sensors.it0.volt0: 1,42 VDC (VCORE_A) > hw.sensors.it0.volt1: 2,72 VDC (VCORE_B) > hw.sensors.it0.volt2: 2,70 VDC (+3.3V) > hw.sensors.it0.volt3: 4,60 VDC (+5V) > hw.sensors.it0.volt4: 0,06 VDC (+12V) > hw.sensors.it0.volt5: -5,23 VDC (Unused) > hw.sensors.it0.volt6: -6,53 VDC (-12V) > hw.sensors.it0.volt7: 3,74 VDC (+5VSB) > hw.sensors.it0.volt8: 2,14 VDC (VBAT) > hw.sensors.it0.temp0: 30,00 degC > hw.sensors.it0.temp1: 25,00 degC > hw.sensors.it0.temp2: 25,00 degC Great! I a dreaming about a special Super I/O driver which would provide services for devices on the chip. Super I/O bases addresses are far more stable (hardwired to a few choices) than base addresses of their devices (freely programmable). > I have three questions though: > 1. The motherboard has 4 fan sockets (as far as I can tell), CPU_FAN, > and SYS_FAN[1-3]. SYS_FAN1 currently is not connected. > Seems like: > fan0 -> CPU_FAN (did not try to disconnect it to check :) > fan1 -> SYS_FAN1 > fan2 -> SYS_FAN2 > There is no entry for SYS_FAN3. I disconnected it temporarily but > it did not seem to affect the output. Is it possible to get that > information from the motherboard? The driver would have to be updated for that. Unfortunately ITE does not provide public datasheets. We could pick up some new bits from the Linux driver though. http://lxr.linux.no/#linux+v3.6.2/drivers/hwmon/it87.c > 2. Is there a way for me to figure out which temperature is which? Or > at least which one would correspond to H77's temperature? Is it > possible that the temperature is not listed? Right now as I check > it the component is hot enough to make it hard for me to touch the > heat sink. I would think it would be higher than 30C. Again, this would require more knowledge about the chip. Plus some additional knowledge about the motherboard. BTW, you could try to use some Linux live CD and see what gets reported there. Maybe they've already figured out the correct mapping. > 3. When will the it module be included with the FreeBSD? Soon, I hope. I am working towards that, just need some time. > Anyway thank you so much for your help so far. At least have > meaningful values now that appear to be real (i.e. they change). Can't > verify whether the voltages are correct due to my limited knowledge. Voltages are the most tricky ones as for many of them there are resistor dividers. There are some recommendations on what resistors to use, but only a motherboard vendor knows for sure what's there (or maybe some guesses could be made by studying the motherboard with a magnifying glass). Thank you very much for bearing with me and doing all the hard work! BTW, in the driver code there is a place with the following comment: /* XXX perhaps >= ? */ Could you please try to use >= instead of == there? -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 20:09:18 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7A0FA476 for ; Sat, 20 Oct 2012 20:09:18 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C02098FC0A for ; Sat, 20 Oct 2012 20:09:17 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA11854; Sat, 20 Oct 2012 23:09:12 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TPfM8-000BjG-G4; Sat, 20 Oct 2012 23:09:12 +0300 Message-ID: <508304E6.6020202@FreeBSD.org> Date: Sat, 20 Oct 2012 23:09:10 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121013 Thunderbird/16.0.1 MIME-Version: 1.0 To: Derek Kulinski Subject: Re: Problem reading vitals from Gigabyte H77-DH3H References: <1286515493.20121017131543@takeda.tk> <507F1761.1010202@FreeBSD.org> <20121017205147.GB36106@chinatsu.takeda.tk> <5081552F.2050303@FreeBSD.org> <771658188.20121019205010@takeda.tk> <508254AF.7040709@FreeBSD.org> <994545137.20121020010809@takeda.tk> <50826040.6010106@FreeBSD.org> <55342693.20121020103732@takeda.tk> <5082EEC8.2080307@FreeBSD.org> <198684285.20121020122034@takeda.tk> <5082FEA8.3050600@FreeBSD.org> In-Reply-To: <5082FEA8.3050600@FreeBSD.org> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 20:09:18 -0000 on 20/10/2012 22:42 Andriy Gapon said the following: > on 20/10/2012 22:20 Derek Kulinski said the following: >> I have three questions though: >> 1. The motherboard has 4 fan sockets (as far as I can tell), CPU_FAN, >> and SYS_FAN[1-3]. SYS_FAN1 currently is not connected. >> Seems like: >> fan0 -> CPU_FAN (did not try to disconnect it to check :) >> fan1 -> SYS_FAN1 >> fan2 -> SYS_FAN2 >> There is no entry for SYS_FAN3. I disconnected it temporarily but >> it did not seem to affect the output. Is it possible to get that >> information from the motherboard? > > The driver would have to be updated for that. > Unfortunately ITE does not provide public datasheets. > We could pick up some new bits from the Linux driver though. > http://lxr.linux.no/#linux+v3.6.2/drivers/hwmon/it87.c In fact, here is a completely untested patch: http://people.freebsd.org/~avg/it-fans-0x80.diff P.S. Just to satisfy my curiosity - could you please add a printf in it_attach that would print the value read from ITD_COREID? -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 21:17:03 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A812B12F; Sat, 20 Oct 2012 21:17:03 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from chinatsu.takeda.tk (mail.takeda.tk [74.0.89.210]) by mx1.freebsd.org (Postfix) with ESMTP id 553578FC0A; Sat, 20 Oct 2012 21:17:03 +0000 (UTC) Received: from takeda-ws.lan (takeda-ws.lan [10.0.0.3]) (authenticated bits=0) by chinatsu.takeda.tk (8.14.5/8.14.5) with ESMTP id q9KLH2eU065911 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 20 Oct 2012 14:17:02 -0700 (PDT) (envelope-from takeda@takeda.tk) Date: Sat, 20 Oct 2012 14:17:00 -0700 From: Derek Kulinski X-Priority: 3 (Normal) Message-ID: <1183222788.20121020141700@takeda.tk> To: Andriy Gapon Subject: Re: Problem reading vitals from Gigabyte H77-DH3H In-Reply-To: <508304E6.6020202@FreeBSD.org> References: <1286515493.20121017131543@takeda.tk> <507F1761.1010202@FreeBSD.org> <20121017205147.GB36106@chinatsu.takeda.tk> <5081552F.2050303@FreeBSD.org> <771658188.20121019205010@takeda.tk> <508254AF.7040709@FreeBSD.org> <994545137.20121020010809@takeda.tk> <50826040.6010106@FreeBSD.org> <55342693.20121020103732@takeda.tk> <5082EEC8.2080307@FreeBSD.org> <198684285.20121020122034@takeda.tk> <5082FEA8.3050600@FreeBSD.org> <508304E6.6020202@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 21:17:03 -0000 Hello Andriy, Saturday, October 20, 2012, 1:09:10 PM, you wrote: > on 20/10/2012 22:42 Andriy Gapon said the following: >> on 20/10/2012 22:20 Derek Kulinski said the following: >>> I have three questions though: >>> 1. The motherboard has 4 fan sockets (as far as I can tell), CPU_FAN, >>> and SYS_FAN[1-3]. SYS_FAN1 currently is not connected. >>> Seems like: >>> fan0 -> CPU_FAN (did not try to disconnect it to check :) >>> fan1 -> SYS_FAN1 >>> fan2 -> SYS_FAN2 >>> There is no entry for SYS_FAN3. I disconnected it temporarily but >>> it did not seem to affect the output. Is it possible to get that >>> information from the motherboard? >> >> The driver would have to be updated for that. >> Unfortunately ITE does not provide public datasheets. >> We could pick up some new bits from the Linux driver though. >> http://lxr.linux.no/#linux+v3.6.2/drivers/hwmon/it87.c > In fact, here is a completely untested patch: > http://people.freebsd.org/~avg/it-fans-0x80.diff hw.sensors.it0.fan0: 997 RPM hw.sensors.it0.fan1: invalid hw.sensors.it0.fan2: 1352 RPM hw.sensors.it0.fan3: 1222 RPM hw.sensors.it0.fan4: invalid hw.sensors.it0.volt0: 2,70 VDC (VCORE_A) hw.sensors.it0.volt1: 4,60 VDC (VCORE_B) hw.sensors.it0.volt2: 0,06 VDC (+3.3V) hw.sensors.it0.volt3: -5,08 VDC (+5V) hw.sensors.it0.volt4: -6,53 VDC (+12V) hw.sensors.it0.volt5: 3,74 VDC (Unused) hw.sensors.it0.volt6: 2,14 VDC (-12V) hw.sensors.it0.volt7: 301,15 VDC (+5VSB) hw.sensors.it0.volt8: 298,15 VDC (VBAT) hw.sensors.it0.temp0: 22,00 degC hw.sensors.it0.temp1: -273,15 degC hw.sensors.it0.temp2: -273,15 degC Looks like the 3rd fan is visible. BTW: The value invalid shows when it is unplugged, wouldn't value "0 RPM" make more sense in that case? At least that's what BIOS reports for unplugged fans. Looks like the the temperatures are messed up. Looks like 2 last voltage values is the temperature. > P.S. Just to satisfy my curiosity - could you please add a printf in it_attach > that would print the value read from ITD_COREID? Here it is the output (as decimal): Oct 20 14:08:04 chinatsu kernel: it0 at port 0xa30-0xa37 on isa0 Oct 20 14:08:04 chinatsu kernel: it0: ITD_COREID = 18 As for using Linux CD I can't do it immediatelly, the box does not have cdrom, besides I don't have any image lying around. Any recommendation for something that I could boot from USB and would be able to provide everything you need? -- Best regards, Derek mailto:takeda@takeda.tk The meta-Turing test counts a thing as intelligent if it seeks to apply Turing tests to objects of its own creation. From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 21:29:14 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 141953ED for ; Sat, 20 Oct 2012 21:29:14 +0000 (UTC) (envelope-from mailer-daemon@vniz.net) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 829868FC08 for ; Sat, 20 Oct 2012 21:29:13 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id b5so1265165lbd.13 for ; Sat, 20 Oct 2012 14:29:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:openpgp :content-type:content-transfer-encoding:x-gm-message-state; bh=WYc4jOGVow5JPnAwWewxxqMlP9SJ1rj+vKPJu2wRkE0=; b=P4ih8BtSkUbkW1sftnBdaxZr8bWmioUWOLtFVqf2+0F/MBt+bNnplHcXGCWKTjtLtE pd/JCLbqF1piYfiUOsdjJ+AXHq+/QYQX3jJkRvyGUf5f7EJ0fe3HIGf8TNIetPjViJom XqN/avgDdRLNVVB1986N0G+Q+epZ/pj8R8TusgPAivarMFHzNbPdbms0LvSEiLYt1Jza GIdFrxDhR/CHywTRZhZmYmn3g9zMOltMEEN54BrIy97SEh8b+d46lBJ7f6zk31KBiSDq Q8ICTqpg2YmJcRToQdzLc4p4Xe9+acU6urRG0AoIWId1ulsrgRXGtvXp9SpMAif92TC4 Gg6Q== Received: by 10.152.103.243 with SMTP id fz19mr4372938lab.27.1350768551919; Sat, 20 Oct 2012 14:29:11 -0700 (PDT) Received: from [192.168.1.2] ([89.169.140.97]) by mx.google.com with ESMTPS id m6sm1708690lbh.10.2012.10.20.14.29.11 (version=SSLv3 cipher=OTHER); Sat, 20 Oct 2012 14:29:11 -0700 (PDT) Message-ID: <508317A4.2060800@freebsd.org> Date: Sun, 21 Oct 2012 01:29:08 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: John Baldwin Subject: Re: ${CTFCONVERT_CMD} expands to empty string References: <5081F92F.8040004@freebsd.org> <201210200838.18297.jhb@freebsd.org> In-Reply-To: <201210200838.18297.jhb@freebsd.org> OpenPGP: id=964474DD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlEBg8tODQi2Me84gCljXJneM0fVoimjYsMsVigUuQ83SDEId0dI0apamDezjkjiZs7nWB6 Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 21:29:14 -0000 On 20.10.2012 16:38, John Baldwin wrote: > On Friday, October 19, 2012 09:06:55 PM Andrey Chernov wrote: >> On recent -stable I got a lots of (see subj) now due to CTF changes in >> *.mk files. >> I have >> WITHOUT_CDDL=yes >> in my /etc/src.conf and WITHOUT_CDDL have wider scope than WITHOUT_CTF >> suggested, but WITHOUT_CDDL is not checked in recent CTF changes. >> Please fix this thing. > > Which stable? stable-9 From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 21:39:30 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 295C8660 for ; Sat, 20 Oct 2012 21:39:30 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 95ABE8FC0A for ; Sat, 20 Oct 2012 21:39:28 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 51FC3EAB237; Sat, 20 Oct 2012 23:39:21 +0200 (CEST) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 11.3548] X-CRM114-CacheID: sfid-20121020_23392_885364C2 X-CRM114-Status: Good ( pR: 11.3548 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Sat Oct 20 23:39:21 2012 X-DSPAM-Confidence: 0.9937 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50831a09251761733311295 X-DSPAM-Factors: 27, From*Attila Nagy , 0.00010, boot, 0.00402, boot, 0.00402, 01+00, 0.00417, To*FreeBSD.org, 0.00422, dump, 0.00452, I+get, 0.00508, the+machine, 0.00542, the+machine, 0.00542, 02+00, 0.00542, 1+20, 0.00602, driver, 0.00650, root, 0.00656, SCSI, 0.00676, SCSI, 0.00676, ZFS, 0.00676, ZFS, 0.00676, command, 0.00706, command, 0.00706, 0), 0.00757, 0), 0.00757, Sun, 0.00782, 20+0, 0.00900, IO, 0.00900, IO, 0.00900, verbose, 0.00900, X-Spambayes-Classification: ham; 0.00 Received: from [192.168.3.2] (japan.t-online.co.hu [195.228.243.99]) by people.fsn.hu (Postfix) with ESMTPSA id 73661EAB22C for ; Sat, 20 Oct 2012 23:39:20 +0200 (CEST) Message-ID: <50831A07.20803@fsn.hu> Date: Sat, 20 Oct 2012 23:39:19 +0200 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org Subject: mpt doesn't propagate read errors and dies on a single sector? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 21:39:30 -0000 Hi, I have a Sun X4540 with LSI C1068E based SAS controllers (FW version: 1.27.02.00-IT). My problem is if one drive starts to fail with read errors, the machine becomes completely unusable (running stable/9 with ZFS), because -it seems- ZFS can't see that there are read errors on a device, the mpt driver (controller, kernel?) wants to re-issue the operation endlessly. Here is a verbose (dev.mpt.0.debug=7 level) dump: mpt0: Address Reply: SCSI IO Request Reply @ 0xffffff87ffcfdc00 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x09 MsgFlags 0x00 MsgContext 0x000200eb Bus: 0 TargetID 3 CDBLength 10 SCSI Status: Check Condition SCSI State: (0x00000001)AutoSense_Valid TransferCnt 0x20000 SenseCnt 0x0012 ResponseInfo 0x00000000 (da3:mpt0:0:3:0): READ(10). CDB: 28 0 3a 38 5d e 0 1 0 0 (da3:mpt0:0:3:0): CAM status: SCSI Status Error (da3:mpt0:0:3:0): SCSI status: Check Condition (da3:mpt0:0:3:0): SCSI sense: MEDIUM ERROR asc:11,0 (Unrecovered read error) (da3:mpt0:0:3:0): Info: 0x3a385d1a (da3:mpt0:0:3:0): Error 5, Unretryable error SCSI IO Request @ 0xffffff80003046f0 Chain Offset 0x00 MsgFlags 0x00 MsgContext 0x000200ea Bus: 0 TargetID 3 SenseBufferLength 32 LUN: 0x0 Control 0x02000000 READ SIMPLEQ DataLength 0x00020000 SenseBufAddr 0x0c65d5e0 CDB[0:10] 28 00 3a 38 5e 0e 00 01 00 00 SE64 0xffffff87ffd1c430: Addr=0x000000010e858000 FlagsLength=0xd3020000 64_BIT_ADDRESSING LAST_ELEMENT END_OF_BUFFER END_OF_LIST mpt0: Address Reply: SCSI IO Request Reply @ 0xffffff87ffcfdd00 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x09 MsgFlags 0x00 MsgContext 0x000200ea Bus: 0 TargetID 3 CDBLength 10 SCSI Status: Check Condition SCSI State: (0x00000001)AutoSense_Valid TransferCnt 0x20000 SenseCnt 0x0012 ResponseInfo 0x00000000 And I get these check condition SCSI errors endlessly. If ZFS is enabled at boot, the machine can't even start because of this (zpool import never finishes), if I boot without ZFS, and try to import, the zpool command stucks in the vdev_g state: 1163 root 1 20 0 35440K 5200K vdev_g 6 0:01 0.10% zpool procstat -k 1163 PID TID COMM TDNAME KSTACK 1163 100116 zpool - mi_switch sleepq_timedwait _sleep biowait vdev_geom_read_guid vdev_geom_open vdev_open vdev_open_children vdev_raidz_open vdev_open vdev_open_children vdev_root_open vdev_open spa_load spa_tryimport zfs_ioc_pool_tryimport zfsdev_ioctl devfs_ioctl_f Could it be that GEOM/ZFS doesn't receive this read error and waits indefinitely for the command to complete? From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 22:09:36 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A1D32C2C for ; Sat, 20 Oct 2012 22:09:36 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id CAF2F8FC08 for ; Sat, 20 Oct 2012 22:09:35 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id BAA12412; Sun, 21 Oct 2012 01:09:24 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TPhES-000Br5-Jv; Sun, 21 Oct 2012 01:09:24 +0300 Message-ID: <50832112.7050604@FreeBSD.org> Date: Sun, 21 Oct 2012 01:09:22 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121013 Thunderbird/16.0.1 MIME-Version: 1.0 To: Derek Kulinski Subject: Re: Problem reading vitals from Gigabyte H77-DH3H References: <1286515493.20121017131543@takeda.tk> <507F1761.1010202@FreeBSD.org> <20121017205147.GB36106@chinatsu.takeda.tk> <5081552F.2050303@FreeBSD.org> <771658188.20121019205010@takeda.tk> <508254AF.7040709@FreeBSD.org> <994545137.20121020010809@takeda.tk> <50826040.6010106@FreeBSD.org> <55342693.20121020103732@takeda.tk> <5082EEC8.2080307@FreeBSD.org> <198684285.20121020122034@takeda.tk> <5082FEA8.3050600@FreeBSD.org> <508304E6.6020202@FreeBSD.org> <1183222788.20121020141700@takeda.tk> In-Reply-To: <1183222788.20121020141700@takeda.tk> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 22:09:36 -0000 on 21/10/2012 00:17 Derek Kulinski said the following: > Hello Andriy, > > Saturday, October 20, 2012, 1:09:10 PM, you wrote: > >> on 20/10/2012 22:42 Andriy Gapon said the following: >>> on 20/10/2012 22:20 Derek Kulinski said the following: >>>> I have three questions though: >>>> 1. The motherboard has 4 fan sockets (as far as I can tell), CPU_FAN, >>>> and SYS_FAN[1-3]. SYS_FAN1 currently is not connected. >>>> Seems like: >>>> fan0 -> CPU_FAN (did not try to disconnect it to check :) >>>> fan1 -> SYS_FAN1 >>>> fan2 -> SYS_FAN2 >>>> There is no entry for SYS_FAN3. I disconnected it temporarily but >>>> it did not seem to affect the output. Is it possible to get that >>>> information from the motherboard? >>> >>> The driver would have to be updated for that. >>> Unfortunately ITE does not provide public datasheets. >>> We could pick up some new bits from the Linux driver though. >>> http://lxr.linux.no/#linux+v3.6.2/drivers/hwmon/it87.c > >> In fact, here is a completely untested patch: >> http://people.freebsd.org/~avg/it-fans-0x80.diff > > hw.sensors.it0.fan0: 997 RPM > hw.sensors.it0.fan1: invalid > hw.sensors.it0.fan2: 1352 RPM > hw.sensors.it0.fan3: 1222 RPM > hw.sensors.it0.fan4: invalid > hw.sensors.it0.volt0: 2,70 VDC (VCORE_A) > hw.sensors.it0.volt1: 4,60 VDC (VCORE_B) > hw.sensors.it0.volt2: 0,06 VDC (+3.3V) > hw.sensors.it0.volt3: -5,08 VDC (+5V) > hw.sensors.it0.volt4: -6,53 VDC (+12V) > hw.sensors.it0.volt5: 3,74 VDC (Unused) > hw.sensors.it0.volt6: 2,14 VDC (-12V) > hw.sensors.it0.volt7: 301,15 VDC (+5VSB) > hw.sensors.it0.volt8: 298,15 VDC (VBAT) > hw.sensors.it0.temp0: 22,00 degC > hw.sensors.it0.temp1: -273,15 degC > hw.sensors.it0.temp2: -273,15 degC > > Looks like the 3rd fan is visible. BTW: The value invalid shows when > it is unplugged, wouldn't value "0 RPM" make more sense in that case? > At least that's what BIOS reports for unplugged fans. The sensors code has its own conventions. > Looks like the the temperatures are messed up. Looks like 2 last > voltage values is the temperature. Oops, right. I've updated the patch at the same URL. >> P.S. Just to satisfy my curiosity - could you please add a printf in it_attach >> that would print the value read from ITD_COREID? > > Here it is the output (as decimal): > Oct 20 14:08:04 chinatsu kernel: it0 at port 0xa30-0xa37 on isa0 > Oct 20 14:08:04 chinatsu kernel: it0: ITD_COREID = 18 Thank you! > As for using Linux CD I can't do it immediatelly, the box does not > have cdrom, besides I don't have any image lying around. Any > recommendation for something that I could boot from USB and would be > able to provide everything you need? Unfortunately, I don't have familiarity with Linux distros either... -- Andriy Gapon