From owner-freebsd-stable@FreeBSD.ORG Sun May 6 03:32:47 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id E60401065674 for ; Sun, 6 May 2012 03:32:47 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 5FE0E16009F; Sun, 6 May 2012 03:32:20 +0000 (UTC) Date: Sat, 5 May 2012 20:32:19 -0700 (PDT) From: Doug Barton To: Freddie Cash In-Reply-To: Message-ID: References: <4FA3FF18.4000309@shatow.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-message-flag: Outlook -- Not just for spreading viruses anymore! OpenPGP: id=1A1ABC84 Organization: http://SupersetSolutions.com/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Stable , Bryan Drewery Subject: Re: Make filesystem type configurable for periodic(8)? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 03:32:48 -0000 On Fri, 4 May 2012, Freddie Cash wrote: > daily_status_security_neggrpperm_fs_ignore="" Please don't add new examples of variables that are empty by default. It's ok to include that line in /etc/defaults/periodic.conf, just put a comment before it. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-stable@FreeBSD.ORG Sun May 6 08:20:53 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A00201065686 for ; Sun, 6 May 2012 08:20:53 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 1E5158FC1B for ; Sun, 6 May 2012 08:20:52 +0000 (UTC) Received: from digsys226-136.pip.digsys.bg (digsys226-136.pip.digsys.bg [193.68.136.226]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.5/8.14.5) with ESMTP id q468Kg9D071960 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 6 May 2012 11:20:43 +0300 (EEST) (envelope-from daniel@digsys.bg) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1251 From: Daniel Kalchev In-Reply-To: Date: Sun, 6 May 2012 11:20:42 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <995A1779-9983-4AB9-8618-9227C1B491E5@digsys.bg> References: To: Freddie Cash X-Mailer: Apple Mail (2.1257) Cc: FreeBSD Stable Subject: Re: Make filesystem type configurable for periodic(8)? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 08:20:53 -0000 On May 4, 2012, at 7:05 PM, Freddie Cash wrote: > A few of the periodic(8) scripts in FreeBSD have constructs similar to > the following to get which filesystems to scan for various things: > MP=3D`mount -t ufs,zfs | awk '$0 !~ /no(suid|exec)/ { print $3 }'` >=20 > For systems with large ZFS pools, and many ZFS filesystems, these > periodic scripts can grind it to its knees, and then some. For > backups servers where we don't really care about the > ownership/permissions of files from the FreeBSD perspective, we really > don't want the ZFS filesytems to be scanned;=20 [=85] The script already accommodates this scenario. Just mount your storage = filesystems with 'nosuidexec' and they won't be scanned.=20 Daniel= From owner-freebsd-stable@FreeBSD.ORG Sun May 6 17:04:29 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4615106566C for ; Sun, 6 May 2012 17:04:29 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 526548FC08 for ; Sun, 6 May 2012 17:04:29 +0000 (UTC) Received: by obcni5 with SMTP id ni5so9398978obc.13 for ; Sun, 06 May 2012 10:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=Px82Q0RYop4gkXCKeDAjAXbAXHkrf8KzsIVK6XkjRA8=; b=ATjRbMClRAuAd4CstrThRTQhGrUWChvpiisCEelcUZGj1wJECsHoTyWEm/nYSJSB+L VNMQltA5XoLozVDKgQQdTP6RUPk7Yw+Cx4/W3TirXRYQTNDnvn5ipEGMNnv3Il2KFxfv uqS8SWCkAmSZmzSY8csmewvy5qa6HIURSFRnY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-gm-message-state; bh=Px82Q0RYop4gkXCKeDAjAXbAXHkrf8KzsIVK6XkjRA8=; b=dOl2hx2HHkQYt3n8new64TKTWJy64SmhIXJEK2CykzZpXUmkl1DFosjvXBiuMPimkD 6n8e3jxxDZnNvXadZwhhZz4EpnV58uN8ACQff1uucVSyEu9ezLDWTHat+dcbQmf1rSuc Y4Es+0diXdz+vHw1oXOTNttgvh2i3moYnSMGYWfOSK8BJHj79XFJTEkPRabNIU2y6xhT hwNG5T/8i6gyCOcKhP1FTGvTSLO5QjuLJU3p51DRDAtCRx0nxD7mFYjruF9q47F8Pzck SNSMeU6tJ/64nUVq6MuO8eMpBej2Wl0nlkG3eb1BijDzPCAbZP5LGwXGWIlixsBAQyQk O2Rg== Received: by 10.50.135.4 with SMTP id po4mr6796217igb.60.1336323868594; Sun, 06 May 2012 10:04:28 -0700 (PDT) Received: from DataIX.net (24-247-238-117.dhcp.aldl.mi.charter.com. [24.247.238.117]) by mx.google.com with ESMTPS id ww4sm7508387igb.9.2012.05.06.10.04.27 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 06 May 2012 10:04:28 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q46H4Q3O035802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 May 2012 13:04:26 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jhellenthal@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q46H4P0r035144; Sun, 6 May 2012 13:04:25 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Sun, 6 May 2012 13:04:25 -0400 From: Jason Hellenthal To: Daniel Kalchev Message-ID: <20120506170425.GA24117@DataIX.net> References: <995A1779-9983-4AB9-8618-9227C1B491E5@digsys.bg> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline In-Reply-To: <995A1779-9983-4AB9-8618-9227C1B491E5@digsys.bg> X-Gm-Message-State: ALoCoQkSIElR9hN7BBnt/UnAvuuBLWrwtRAfhAyBfgqG9IBECMmkyi0oPwig8+PM0d47KSaXcjKL Cc: FreeBSD Stable Subject: Re: Make filesystem type configurable for periodic(8)? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 17:04:29 -0000 --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 06, 2012 at 11:20:42AM +0300, Daniel Kalchev wrote: >=20 > On May 4, 2012, at 7:05 PM, Freddie Cash wrote: >=20 > > A few of the periodic(8) scripts in FreeBSD have constructs similar to > > the following to get which filesystems to scan for various things: > > MP=3D`mount -t ufs,zfs | awk '$0 !~ /no(suid|exec)/ { print $3 }'` > >=20 > > For systems with large ZFS pools, and many ZFS filesystems, these > > periodic scripts can grind it to its knees, and then some. For > > backups servers where we don't really care about the > > ownership/permissions of files from the FreeBSD perspective, we really > > don't want the ZFS filesytems to be scanned;=20 > [=E2=80=A6] >=20 > The script already accommodates this scenario. Just mount your storage fi= lesystems with 'nosuidexec' and they won't be scanned.=20 >=20 You all may be interested in this [1] but I have not touched it in a while and backed it out of a working source tree about a month ago so I am no longer tracking it. But last I used it, it was working cleanly. Configuration was like so... daily_status_security_chknoid_enable=3D"YES" daily_status_security_chknoid_dirs=3D"/ /home /tmp /var /usr/local" The same thing should also be done for anything that traverses multiple filesystems by default configuration and reporting output should remain consistent. The current reporting format of these scripts is nearly rediculous in its current use of diff(1). 1). http://code.google.com/p/jhell/source/browse/340.noid.patch?repo=3Dpatches --=20 - (2^(N-1)) --XsQoSWH+UP9D9v3l Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJPpq8YAAoJEBSh2Dr1DU7WALQH/3mrT2vAs6r+W03Hary8QOhl 84NnaTHiThfzY8UogJm+uCouCStUN3WDrdbMeG4NN1warL35M+TWZwJ9x1J66Kpq c0LxZvT+AKTbTwsv6Z3XzzlqB6dEF1tu0Zb+oOCCo95tHnzJhdHyiWkZbNmp1e+T LE39fq/xP2XAx++iW8+9mhpj628DfDOiKzpzYwQ6c/V8xCKteVhXhNJTqAVV+KmE 391WpDwo+rWlQeAGhCCR1ij2RYzO1q63LTWDjJ62AIgheQ8ScgmdXrruJlUVKpkl 3qGUkh8M23L1UimpAoUL+rCABaB1h4Lvi3Db+r37KrnXlAqlfgAVkdRtlM+cMX8= =neRG -----END PGP SIGNATURE----- --XsQoSWH+UP9D9v3l-- From owner-freebsd-stable@FreeBSD.ORG Sun May 6 18:12:31 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 444C3106564A; Sun, 6 May 2012 18:12:31 +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 CA05A8FC14; Sun, 6 May 2012 18:12:30 +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 q46ICUpi001915; Sun, 6 May 2012 18:12:30 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q46ICTM5001720; Sun, 6 May 2012 18:12:29 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 6 May 2012 18:12:29 GMT Message-Id: <201205061812.q46ICTM5001720@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 , , Precedence: bulk Cc: Subject: [releng_7 tinderbox] failure on i386/pc98 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 18:12:31 -0000 TB --- 2012-05-06 17:30:00 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-05-06 17:30: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-05-06 17:30:00 - starting RELENG_7 tinderbox run for i386/pc98 TB --- 2012-05-06 17:30:00 - cleaning the object tree TB --- 2012-05-06 17:30:00 - cvsupping the source tree TB --- 2012-05-06 17:30:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_7/i386/pc98/supfile TB --- 2012-05-06 17:30:49 - building world TB --- 2012-05-06 17:30:49 - CROSS_BUILD_TESTING=YES TB --- 2012-05-06 17:30:49 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-06 17:30:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-06 17:30:49 - SRCCONF=/dev/null TB --- 2012-05-06 17:30:49 - TARGET=pc98 TB --- 2012-05-06 17:30:49 - TARGET_ARCH=i386 TB --- 2012-05-06 17:30:49 - TZ=UTC TB --- 2012-05-06 17:30:49 - __MAKE_CONF=/dev/null TB --- 2012-05-06 17:30:49 - cd /src TB --- 2012-05-06 17:30:49 - /usr/bin/make -B buildworld >>> World build started on Sun May 6 17:30:49 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun May 6 18:10:28 UTC 2012 TB --- 2012-05-06 18:10:28 - generating LINT kernel config TB --- 2012-05-06 18:10:28 - cd /src/sys/pc98/conf TB --- 2012-05-06 18:10:28 - /usr/bin/make -B LINT TB --- 2012-05-06 18:10:28 - cd /src/sys/pc98/conf TB --- 2012-05-06 18:10:28 - /usr/sbin/config -m LINT TB --- 2012-05-06 18:10:28 - building LINT kernel TB --- 2012-05-06 18:10:28 - CROSS_BUILD_TESTING=YES TB --- 2012-05-06 18:10:28 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-06 18:10:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-06 18:10:28 - SRCCONF=/dev/null TB --- 2012-05-06 18:10:28 - TARGET=pc98 TB --- 2012-05-06 18:10:28 - TARGET_ARCH=i386 TB --- 2012-05-06 18:10:28 - TZ=UTC TB --- 2012-05-06 18:10:28 - __MAKE_CONF=/dev/null TB --- 2012-05-06 18:10:28 - cd /src TB --- 2012-05-06 18:10:28 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun May 6 18:10:29 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue /src/sys/cam/cam_queue.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue /src/sys/cam/cam_sim.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue /src/sys/cam/cam_xpt.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue /src/sys/cam/scsi/scsi_all.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue /src/sys/cam/scsi/scsi_cd.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue /src/sys/cam/scsi/scsi_ch.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue /src/sys/cam/scsi/scsi_da.c /src/sys/cam/scsi/scsi_da.c:558: error: expected '}' before '{' token *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-05-06 18:12:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-05-06 18:12:29 - ERROR: failed to build LINT kernel TB --- 2012-05-06 18:12:29 - 1955.59 user 390.97 system 2549.01 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Sun May 6 18:13:06 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 8D12A106564A; Sun, 6 May 2012 18:13:06 +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 48AE88FC18; Sun, 6 May 2012 18:13:06 +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 q46ICxuh016028; Sun, 6 May 2012 18:12:59 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q46ICxuA016026; Sun, 6 May 2012 18:12:59 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 6 May 2012 18:12:59 GMT Message-Id: <201205061812.q46ICxuA016026@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 , , Precedence: bulk Cc: Subject: [releng_7 tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 18:13:06 -0000 TB --- 2012-05-06 17:30:00 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-05-06 17:30: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-05-06 17:30:00 - starting RELENG_7 tinderbox run for powerpc/powerpc TB --- 2012-05-06 17:30:00 - cleaning the object tree TB --- 2012-05-06 17:30:00 - cvsupping the source tree TB --- 2012-05-06 17:30:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_7/powerpc/powerpc/supfile TB --- 2012-05-06 17:30:49 - building world TB --- 2012-05-06 17:30:49 - CROSS_BUILD_TESTING=YES TB --- 2012-05-06 17:30:49 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-06 17:30:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-06 17:30:49 - SRCCONF=/dev/null TB --- 2012-05-06 17:30:49 - TARGET=powerpc TB --- 2012-05-06 17:30:49 - TARGET_ARCH=powerpc TB --- 2012-05-06 17:30:49 - TZ=UTC TB --- 2012-05-06 17:30:49 - __MAKE_CONF=/dev/null TB --- 2012-05-06 17:30:49 - cd /src TB --- 2012-05-06 17:30:49 - /usr/bin/make -B buildworld >>> World build started on Sun May 6 17:30:49 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun May 6 18:11:38 UTC 2012 TB --- 2012-05-06 18:11:38 - generating LINT kernel config TB --- 2012-05-06 18:11:38 - cd /src/sys/powerpc/conf TB --- 2012-05-06 18:11:38 - /usr/bin/make -B LINT TB --- 2012-05-06 18:11:38 - cd /src/sys/powerpc/conf TB --- 2012-05-06 18:11:38 - /usr/sbin/config -m LINT TB --- 2012-05-06 18:11:38 - building LINT kernel TB --- 2012-05-06 18:11:38 - CROSS_BUILD_TESTING=YES TB --- 2012-05-06 18:11:38 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-06 18:11:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-06 18:11:38 - SRCCONF=/dev/null TB --- 2012-05-06 18:11:38 - TARGET=powerpc TB --- 2012-05-06 18:11:38 - TARGET_ARCH=powerpc TB --- 2012-05-06 18:11:38 - TZ=UTC TB --- 2012-05-06 18:11:38 - __MAKE_CONF=/dev/null TB --- 2012-05-06 18:11:38 - cd /src TB --- 2012-05-06 18:11:38 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun May 6 18:11:38 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -Werror /src/sys/cam/cam_queue.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -Werror /src/sys/cam/cam_sim.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -Werror /src/sys/cam/cam_xpt.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -Werror /src/sys/cam/scsi/scsi_all.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -Werror /src/sys/cam/scsi/scsi_cd.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -Werror /src/sys/cam/scsi/scsi_ch.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -Werror /src/sys/cam/scsi/scsi_da.c /src/sys/cam/scsi/scsi_da.c:558: error: expected '}' before '{' token *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-05-06 18:12:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-05-06 18:12:59 - ERROR: failed to build LINT kernel TB --- 2012-05-06 18:12:59 - 2009.12 user 376.30 system 2579.08 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Sun May 6 18:13:16 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 B5FF310656D3; Sun, 6 May 2012 18:13:16 +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 341FC8FC14; Sun, 6 May 2012 18:13:15 +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 q46IDFWK018980; Sun, 6 May 2012 18:13:15 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q46IDFej018979; Sun, 6 May 2012 18:13:15 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 6 May 2012 18:13:15 GMT Message-Id: <201205061813.q46IDFej018979@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 , , Precedence: bulk Cc: Subject: [releng_7 tinderbox] failure on i386/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 18:13:16 -0000 TB --- 2012-05-06 17:30:00 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-05-06 17:30: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-05-06 17:30:00 - starting RELENG_7 tinderbox run for i386/i386 TB --- 2012-05-06 17:30:00 - cleaning the object tree TB --- 2012-05-06 17:30:00 - cvsupping the source tree TB --- 2012-05-06 17:30:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_7/i386/i386/supfile TB --- 2012-05-06 17:30:49 - building world TB --- 2012-05-06 17:30:49 - CROSS_BUILD_TESTING=YES TB --- 2012-05-06 17:30:49 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-06 17:30:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-06 17:30:49 - SRCCONF=/dev/null TB --- 2012-05-06 17:30:49 - TARGET=i386 TB --- 2012-05-06 17:30:49 - TARGET_ARCH=i386 TB --- 2012-05-06 17:30:49 - TZ=UTC TB --- 2012-05-06 17:30:49 - __MAKE_CONF=/dev/null TB --- 2012-05-06 17:30:49 - cd /src TB --- 2012-05-06 17:30:49 - /usr/bin/make -B buildworld >>> World build started on Sun May 6 17:30:49 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun May 6 18:10:59 UTC 2012 TB --- 2012-05-06 18:10:59 - generating LINT kernel config TB --- 2012-05-06 18:10:59 - cd /src/sys/i386/conf TB --- 2012-05-06 18:10:59 - /usr/bin/make -B LINT TB --- 2012-05-06 18:10:59 - cd /src/sys/i386/conf TB --- 2012-05-06 18:10:59 - /usr/sbin/config -m LINT TB --- 2012-05-06 18:10:59 - building LINT kernel TB --- 2012-05-06 18:10:59 - CROSS_BUILD_TESTING=YES TB --- 2012-05-06 18:10:59 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-06 18:10:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-06 18:10:59 - SRCCONF=/dev/null TB --- 2012-05-06 18:10:59 - TARGET=i386 TB --- 2012-05-06 18:10:59 - TARGET_ARCH=i386 TB --- 2012-05-06 18:10:59 - TZ=UTC TB --- 2012-05-06 18:10:59 - __MAKE_CONF=/dev/null TB --- 2012-05-06 18:10:59 - cd /src TB --- 2012-05-06 18:10:59 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun May 6 18:10:59 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/cam/cam_queue.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/cam/cam_sim.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/cam/cam_xpt.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/cam/scsi/scsi_all.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/cam/scsi/scsi_cd.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/cam/scsi/scsi_ch.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/cam/scsi/scsi_da.c /src/sys/cam/scsi/scsi_da.c:558: error: expected '}' before '{' token *** Error code 1 Stop in /obj/i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-05-06 18:13:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-05-06 18:13:15 - ERROR: failed to build LINT kernel TB --- 2012-05-06 18:13:15 - 1991.77 user 389.95 system 2594.49 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Sun May 6 18:15:58 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 5F96C106566B; Sun, 6 May 2012 18:15:58 +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 1F27E8FC15; Sun, 6 May 2012 18:15:58 +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 q46IFvgv047413; Sun, 6 May 2012 18:15:57 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q46IFvDI047411; Sun, 6 May 2012 18:15:57 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 6 May 2012 18:15:57 GMT Message-Id: <201205061815.q46IFvDI047411@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 , , Precedence: bulk Cc: Subject: [releng_7 tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 18:15:58 -0000 TB --- 2012-05-06 17:30:00 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-05-06 17:30: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-05-06 17:30:00 - starting RELENG_7 tinderbox run for sparc64/sparc64 TB --- 2012-05-06 17:30:00 - cleaning the object tree TB --- 2012-05-06 17:30:00 - cvsupping the source tree TB --- 2012-05-06 17:30:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_7/sparc64/sparc64/supfile TB --- 2012-05-06 17:35:30 - building world TB --- 2012-05-06 17:35:30 - CROSS_BUILD_TESTING=YES TB --- 2012-05-06 17:35:30 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-06 17:35:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-06 17:35:30 - SRCCONF=/dev/null TB --- 2012-05-06 17:35:30 - TARGET=sparc64 TB --- 2012-05-06 17:35:30 - TARGET_ARCH=sparc64 TB --- 2012-05-06 17:35:30 - TZ=UTC TB --- 2012-05-06 17:35:30 - __MAKE_CONF=/dev/null TB --- 2012-05-06 17:35:30 - cd /src TB --- 2012-05-06 17:35:30 - /usr/bin/make -B buildworld >>> World build started on Sun May 6 17:35:30 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun May 6 18:14:47 UTC 2012 TB --- 2012-05-06 18:14:47 - generating LINT kernel config TB --- 2012-05-06 18:14:47 - cd /src/sys/sparc64/conf TB --- 2012-05-06 18:14:47 - /usr/bin/make -B LINT TB --- 2012-05-06 18:14:47 - cd /src/sys/sparc64/conf TB --- 2012-05-06 18:14:47 - /usr/sbin/config -m LINT TB --- 2012-05-06 18:14:47 - building LINT kernel TB --- 2012-05-06 18:14:47 - CROSS_BUILD_TESTING=YES TB --- 2012-05-06 18:14:47 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-06 18:14:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-06 18:14:47 - SRCCONF=/dev/null TB --- 2012-05-06 18:14:47 - TARGET=sparc64 TB --- 2012-05-06 18:14:47 - TARGET_ARCH=sparc64 TB --- 2012-05-06 18:14:47 - TZ=UTC TB --- 2012-05-06 18:14:47 - __MAKE_CONF=/dev/null TB --- 2012-05-06 18:14:47 - cd /src TB --- 2012-05-06 18:14:47 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun May 6 18:14:47 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/cam/cam_queue.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/cam/cam_sim.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/cam/cam_xpt.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/cam/scsi/scsi_all.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/cam/scsi/scsi_cd.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/cam/scsi/scsi_ch.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/cam/scsi/scsi_da.c /src/sys/cam/scsi/scsi_da.c:558: error: expected '}' before '{' token *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-05-06 18:15:57 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-05-06 18:15:57 - ERROR: failed to build LINT kernel TB --- 2012-05-06 18:15:57 - 1905.41 user 366.82 system 2757.05 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Sun May 6 18:27:41 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 4F7061065672; Sun, 6 May 2012 18:27:41 +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 0D80B8FC18; Sun, 6 May 2012 18:27:40 +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 q46IReXJ022802; Sun, 6 May 2012 18:27:40 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q46IReCF022801; Sun, 6 May 2012 18:27:40 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 6 May 2012 18:27:40 GMT Message-Id: <201205061827.q46IReCF022801@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 , , Precedence: bulk Cc: Subject: [releng_7 tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 18:27:41 -0000 TB --- 2012-05-06 17:30:00 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-05-06 17:30: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-05-06 17:30:00 - starting RELENG_7 tinderbox run for ia64/ia64 TB --- 2012-05-06 17:30:00 - cleaning the object tree TB --- 2012-05-06 17:30:00 - cvsupping the source tree TB --- 2012-05-06 17:30:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_7/ia64/ia64/supfile TB --- 2012-05-06 17:35:30 - building world TB --- 2012-05-06 17:35:30 - CROSS_BUILD_TESTING=YES TB --- 2012-05-06 17:35:30 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-06 17:35:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-06 17:35:30 - SRCCONF=/dev/null TB --- 2012-05-06 17:35:30 - TARGET=ia64 TB --- 2012-05-06 17:35:30 - TARGET_ARCH=ia64 TB --- 2012-05-06 17:35:30 - TZ=UTC TB --- 2012-05-06 17:35:30 - __MAKE_CONF=/dev/null TB --- 2012-05-06 17:35:30 - cd /src TB --- 2012-05-06 17:35:30 - /usr/bin/make -B buildworld >>> World build started on Sun May 6 17:35:31 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun May 6 18:26:27 UTC 2012 TB --- 2012-05-06 18:26:27 - generating LINT kernel config TB --- 2012-05-06 18:26:27 - cd /src/sys/ia64/conf TB --- 2012-05-06 18:26:27 - /usr/bin/make -B LINT TB --- 2012-05-06 18:26:27 - cd /src/sys/ia64/conf TB --- 2012-05-06 18:26:27 - /usr/sbin/config -m LINT TB --- 2012-05-06 18:26:27 - building LINT kernel TB --- 2012-05-06 18:26:27 - CROSS_BUILD_TESTING=YES TB --- 2012-05-06 18:26:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-06 18:26:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-06 18:26:27 - SRCCONF=/dev/null TB --- 2012-05-06 18:26:27 - TARGET=ia64 TB --- 2012-05-06 18:26:27 - TARGET_ARCH=ia64 TB --- 2012-05-06 18:26:27 - TZ=UTC TB --- 2012-05-06 18:26:27 - __MAKE_CONF=/dev/null TB --- 2012-05-06 18:26:27 - cd /src TB --- 2012-05-06 18:26:27 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun May 6 18:26:27 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/cam/cam_queue.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/cam/cam_sim.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/cam/cam_xpt.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/cam/scsi/scsi_all.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/cam/scsi/scsi_cd.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/cam/scsi/scsi_ch.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/cam/scsi/scsi_da.c /src/sys/cam/scsi/scsi_da.c:558: error: expected '}' before '{' token *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-05-06 18:27:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-05-06 18:27:40 - ERROR: failed to build LINT kernel TB --- 2012-05-06 18:27:40 - 2629.66 user 392.58 system 3459.94 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Sun May 6 18:30:40 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A5EE106564A; Sun, 6 May 2012 18:30:40 +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 B21258FC1C; Sun, 6 May 2012 18:30:39 +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 q46IUdfe045554; Sun, 6 May 2012 18:30:39 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q46IUdU4045553; Sun, 6 May 2012 18:30:39 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 6 May 2012 18:30:39 GMT Message-Id: <201205061830.q46IUdU4045553@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 , , Precedence: bulk Cc: Subject: [releng_7 tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 18:30:40 -0000 TB --- 2012-05-06 17:30:00 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-05-06 17:30: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-05-06 17:30:00 - starting RELENG_7 tinderbox run for amd64/amd64 TB --- 2012-05-06 17:30:00 - cleaning the object tree TB --- 2012-05-06 17:30:00 - cvsupping the source tree TB --- 2012-05-06 17:30:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_7/amd64/amd64/supfile TB --- 2012-05-06 17:35:30 - building world TB --- 2012-05-06 17:35:30 - CROSS_BUILD_TESTING=YES TB --- 2012-05-06 17:35:30 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-06 17:35:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-06 17:35:30 - SRCCONF=/dev/null TB --- 2012-05-06 17:35:30 - TARGET=amd64 TB --- 2012-05-06 17:35:30 - TARGET_ARCH=amd64 TB --- 2012-05-06 17:35:30 - TZ=UTC TB --- 2012-05-06 17:35:30 - __MAKE_CONF=/dev/null TB --- 2012-05-06 17:35:30 - cd /src TB --- 2012-05-06 17:35:30 - /usr/bin/make -B buildworld >>> World build started on Sun May 6 17:35:30 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sun May 6 18:29:13 UTC 2012 TB --- 2012-05-06 18:29:13 - generating LINT kernel config TB --- 2012-05-06 18:29:13 - cd /src/sys/amd64/conf TB --- 2012-05-06 18:29:13 - /usr/bin/make -B LINT TB --- 2012-05-06 18:29:13 - cd /src/sys/amd64/conf TB --- 2012-05-06 18:29:13 - /usr/sbin/config -m LINT TB --- 2012-05-06 18:29:13 - building LINT kernel TB --- 2012-05-06 18:29:13 - CROSS_BUILD_TESTING=YES TB --- 2012-05-06 18:29:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-06 18:29:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-06 18:29:13 - SRCCONF=/dev/null TB --- 2012-05-06 18:29:13 - TARGET=amd64 TB --- 2012-05-06 18:29:13 - TARGET_ARCH=amd64 TB --- 2012-05-06 18:29:13 - TZ=UTC TB --- 2012-05-06 18:29:13 - __MAKE_CONF=/dev/null TB --- 2012-05-06 18:29:13 - cd /src TB --- 2012-05-06 18:29:13 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun May 6 18:29:13 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/cam/cam_queue.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/cam/cam_sim.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/cam/cam_xpt.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/cam/scsi/scsi_all.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/cam/scsi/scsi_cd.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/cam/scsi/scsi_ch.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/cam/scsi/scsi_da.c /src/sys/cam/scsi/scsi_da.c:558: error: expected '}' before '{' token *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-05-06 18:30:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-05-06 18:30:39 - ERROR: failed to build LINT kernel TB --- 2012-05-06 18:30:39 - 2665.08 user 510.23 system 3638.63 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Mon May 7 03:54:43 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 4777C106564A for ; Mon, 7 May 2012 03:54:43 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (r2b9.nsu.ru [212.192.164.39]) by mx1.freebsd.org (Postfix) with ESMTP id D821B8FC08 for ; Mon, 7 May 2012 03:54:42 +0000 (UTC) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.69) (envelope-from ) id 1SRF0u-0001dH-W5 for stable@freebsd.org; Mon, 07 May 2012 10:53:33 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id q473sVnH049207 for ; Mon, 7 May 2012 10:54:32 +0700 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id q473s6fH049145 for stable@freebsd.org; Mon, 7 May 2012 10:54:06 +0700 (NOVT) (envelope-from danfe) Date: Mon, 7 May 2012 10:54:05 +0700 From: Alexey Dokuchaev To: stable@freebsd.org Message-ID: <20120507035405.GA47351@regency.nsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: panic with if_iwi(4) upon "netif restart" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 03:54:43 -0000 Folks, Weird panic occurs to me here with iwi(4) based laptop when trying to hook up to WPA-protected network with "service netif restart". Kernel and userland are not strictly in sync, with the latter lagging behind couple of months, but presumably this fact should not matter on stable branch. I was only able to get online by manually running wpa_supplicant(8) and dhclient(8). if_iwi(4) loaded after system fully boots (i.e. manually after login). # kgdb /boot/kernel/kernel /var/crash/vmcore.0 ... (kgdb) bt #0 doadump () at pcpu.h:231 #1 0xc045cc37 in db_fncall (dummy1=1, dummy2=0, dummy3=-1065923936, dummy4=0xe787e8a4 "") at /home/danfe/fbsd/src/8/sys/ddb/db_command.c:548 #2 0xc045d014 in db_command (last_cmdp=0xc071a0fc, cmd_table=0x0, dopager=1) at /home/danfe/fbsd/src/8/sys/ddb/db_command.c:445 #3 0xc045d152 in db_command_loop () at /home/danfe/fbsd/src/8/sys/ddb/db_command.c:498 #4 0xc045ef0e in db_trap (type=12, code=0) at /home/danfe/fbsd/src/8/sys/ddb/db_main.c:229 #5 0xc051009e in kdb_trap (type=12, code=0, tf=0xe787eb1c) at /home/danfe/fbsd/src/8/sys/kern/subr_kdb.c:548 #6 0xc06789ef in trap_fatal (frame=0xe787eb1c, eva=3319362005) at /home/danfe/fbsd/src/8/sys/i386/i386/trap.c:972 #7 0xc0678d56 in trap_pfault (frame=0xe787eb1c, usermode=0, eva=3319362005) at /home/danfe/fbsd/src/8/sys/i386/i386/trap.c:894 #8 0xc0679bba in trap (frame=0xe787eb1c) at /home/danfe/fbsd/src/8/sys/i386/i386/trap.c:562 #9 0xc06643cc in calltrap () at /home/danfe/fbsd/src/8/sys/i386/i386/exception.s:168 #10 0xc5cf0b48 in iwi_auth_and_assoc (sc=0xc521e800, vap=0xc5bf9000) at /home/danfe/fbsd/src/8/sys/modules/iwi/../../dev/iwi/if_iwi.c:2888 #11 0xc5cf125c in iwi_newstate (vap=0xc5bf9000, nstate=IEEE80211_S_AUTH, arg=192) at /home/danfe/fbsd/src/8/sys/modules/iwi/../../dev/iwi/if_iwi.c:1005 #12 0xc5d15848 in ieee80211_newstate_cb (xvap=0xc5bf9000, npending=1) at /home/danfe/fbsd/src/8/sys/modules/wlan/../../net80211/ieee80211_proto.c:1652 #13 0xc051abfe in taskqueue_run_locked (queue=0xc5c432c0) at /home/danfe/fbsd/src/8/sys/kern/subr_taskqueue.c:250 #14 0xc051b222 in taskqueue_thread_loop (arg=0xc54e2074) at /home/danfe/fbsd/src/8/sys/kern/subr_taskqueue.c:387 #15 0xc04b6eb9 in fork_exit (callout=0xc051b1a0 , arg=0xc54e2074, frame=0xe787ed28) at /home/danfe/fbsd/src/8/sys/kern/kern_fork.c:876 #16 0xc0664474 in fork_trampoline () at /home/danfe/fbsd/src/8/sys/i386/i386/exception.s:275 (kgdb) f 11 #11 0xc5cf125c in iwi_newstate (vap=0xc5bf9000, nstate=IEEE80211_S_AUTH, arg=192) at /home/danfe/fbsd/src/8/sys/modules/iwi/../../dev/iwi/if_iwi.c:1005 1005 iwi_auth_and_assoc(sc, vap); (kgdb) l 1000 * for the ASSOC status to come back from the firmware. 1001 * Otherwise we need to issue the association request. 1002 */ 1003 if (vap->iv_state == IEEE80211_S_AUTH) 1004 break; 1005 iwi_auth_and_assoc(sc, vap); 1006 break; 1007 default: 1008 break; 1009 } (kgdb) f 10 #10 0xc5cf0b48 in iwi_auth_and_assoc (sc=0xc521e800, vap=0xc5bf9000) at /home/danfe/fbsd/src/8/sys/modules/iwi/../../dev/iwi/if_iwi.c:2888 2888 rs.nrates = ni->ni_rates.rs_nrates; (kgdb) l 2883 2884 /* the rate set has already been "negotiated" */ 2885 memset(&rs, 0, sizeof rs); 2886 rs.mode = mode; 2887 rs.type = IWI_RATESET_TYPE_NEGOTIATED; 2888 rs.nrates = ni->ni_rates.rs_nrates; 2889 if (rs.nrates > IWI_RATESET_SIZE) { 2890 DPRINTF(("Truncating negotiated rate set from %u\n", 2891 rs.nrates)); 2892 rs.nrates = IWI_RATESET_SIZE; Feel free to ask for more information. ./danfe From owner-freebsd-stable@FreeBSD.ORG Mon May 7 18:28:52 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 5EFD1106566B for ; Mon, 7 May 2012 18:28:52 +0000 (UTC) (envelope-from bschmidt@techwires.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 CA41B8FC08 for ; Mon, 7 May 2012 18:28:51 +0000 (UTC) Received: by lbon10 with SMTP id n10so5013424lbo.13 for ; Mon, 07 May 2012 11:28:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=LUPnYpN7vRqLM7nIuVxMECrygKpLxaQUchjREZNhyww=; b=AG5VgmZS8YYZDSXY4CzMMsvDfjrsxwbWfjB8SBjUFPmMnJR3u2u2cxHlw6YZDs/+y8 8tV1VOl1k4sP0g9/uSLnEcrTnWWZsUMQVpwwuFhJAX45IdaAmSrHk5EG12N+AYZ1ybPR z0BnBD5yW7rsore3RQZnT8r+sXC3FRmx3tdlKEvaIPZFbyeZNXRv3oLeJEJgRhBMFYS3 7wnC/AUWe9NHn0yim8Y9+4ErOEh/qU7MjhwErG29Q4qFbi6w6jDzGBzzouAv8H2of1Kz aQAP7+dJXtt7z/XpwLXq8XiJtfsO9zNtGgoanqPmiWkFVOX1ftSO7Wv4dv5Il1uSbp9w No0A== MIME-Version: 1.0 Received: by 10.152.147.33 with SMTP id th1mr7329779lab.9.1336415330509; Mon, 07 May 2012 11:28:50 -0700 (PDT) Sender: bschmidt@techwires.net Received: by 10.152.122.145 with HTTP; Mon, 7 May 2012 11:28:50 -0700 (PDT) X-Originating-IP: [88.65.219.158] In-Reply-To: <20120507035405.GA47351@regency.nsu.ru> References: <20120507035405.GA47351@regency.nsu.ru> Date: Mon, 7 May 2012 20:28:50 +0200 X-Google-Sender-Auth: 2qU_bx0cWv10PdS7z-ZAKPFmfeQ Message-ID: From: Bernhard Schmidt To: Alexey Dokuchaev Content-Type: multipart/mixed; boundary=e89a8f22c4110c24e404bf767107 X-Gm-Message-State: ALoCoQm06kTRXm3E02n5jITWpzsjq86IlOrCSa2Qf1PKAa4Tc8TqO8Xd9937HzXusQ+d08uE6TVT Cc: stable@freebsd.org Subject: Re: panic with if_iwi(4) upon "netif restart" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 18:28:52 -0000 --e89a8f22c4110c24e404bf767107 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, May 7, 2012 at 5:54 AM, Alexey Dokuchaev wrote: > Folks, > > Weird panic occurs to me here with iwi(4) based laptop when trying to hoo= k > up to WPA-protected network with "service netif restart". =A0Kernel and > userland are not strictly in sync, with the latter lagging behind couple > of months, but presumably this fact should not matter on stable branch. > > I was only able to get online by manually running wpa_supplicant(8) and > dhclient(8). =A0if_iwi(4) loaded after system fully boots (i.e. manually = after > login). > > [snip] > > Feel free to ask for more information. does "ps" in kgdb reveal multiple instances of wpa_supplicant running? If so, this seems to be the well known devd+netif+supplicant+newstate race/missing refcount. Wanna try attached patch? --=20 Bernhard --e89a8f22c4110c24e404bf767107 Content-Type: application/octet-stream; name="iwi_vs_sta1.diff" Content-Disposition: attachment; filename="iwi_vs_sta1.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h1xv60o71 SW5kZXg6IHN5cy9kZXYvaXdpL2lmX2l3aS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9kZXYvaXdpL2lm X2l3aS5jCShyZXZpc2lvbiAyMzUxMzIpCisrKyBzeXMvZGV2L2l3aS9pZl9pd2kuYwkod29ya2lu ZyBjb3B5KQpAQCAtMjgxMSw3ICsyODExLDcgQEAgaXdpX2F1dGhfYW5kX2Fzc29jKHN0cnVjdCBp d2lfc29mdGMgKnNjLCBzdHJ1Y3QgaWUKIHsKIAlzdHJ1Y3QgaWVlZTgwMjExY29tICppYyA9IHZh cC0+aXZfaWM7CiAJc3RydWN0IGlmbmV0ICppZnAgPSB2YXAtPml2X2lmcDsKLQlzdHJ1Y3QgaWVl ZTgwMjExX25vZGUgKm5pID0gdmFwLT5pdl9ic3M7CisJc3RydWN0IGllZWU4MDIxMV9ub2RlICpu aTsKIAlzdHJ1Y3QgaXdpX2NvbmZpZ3VyYXRpb24gY29uZmlnOwogCXN0cnVjdCBpd2lfYXNzb2Np YXRlICphc3NvYyA9ICZzYy0+YXNzb2M7CiAJc3RydWN0IGl3aV9yYXRlc2V0IHJzOwpAQCAtMjgy Niw2ICsyODI2LDggQEAgaXdpX2F1dGhfYW5kX2Fzc29jKHN0cnVjdCBpd2lfc29mdGMgKnNjLCBz dHJ1Y3QgaWUKIAkJcmV0dXJuICgtMSk7CiAJfQogCisJbmkgPSBpZWVlODAyMTFfcmVmX25vZGUo dmFwLT5pdl9ic3MpOworCiAJSVdJX1NUQVRFX0JFR0lOKHNjLCBJV0lfRldfQVNTT0NJQVRJTkcp OwogCWVycm9yID0gMDsKIAltb2RlID0gMDsKQEAgLTI5ODIsNiArMjk4NCw4IEBAIGRvbmU6CiAJ aWYgKGVycm9yKQogCQlJV0lfU1RBVEVfRU5EKHNjLCBJV0lfRldfQVNTT0NJQVRJTkcpOwogCisJ aWVlZTgwMjExX2ZyZWVfbm9kZShuaSk7CisKIAlyZXR1cm4gKGVycm9yKTsKIH0KIAo= --e89a8f22c4110c24e404bf767107-- From owner-freebsd-stable@FreeBSD.ORG Tue May 8 16:50:51 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 B85651065672; Tue, 8 May 2012 16:50:51 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (r2b9.nsu.ru [212.192.164.39]) by mx1.freebsd.org (Postfix) with ESMTP id 597F18FC16; Tue, 8 May 2012 16:50:50 +0000 (UTC) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.69) (envelope-from ) id 1SRnby-0000Cn-JF; Tue, 08 May 2012 23:50:06 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id q48GpCrD016598; Tue, 8 May 2012 23:51:12 +0700 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id q48Gp7R2016544; Tue, 8 May 2012 23:51:07 +0700 (NOVT) (envelope-from danfe) Date: Tue, 8 May 2012 23:51:06 +0700 From: Alexey Dokuchaev To: Bernhard Schmidt Message-ID: <20120508165106.GA15063@regency.nsu.ru> References: <20120507035405.GA47351@regency.nsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: stable@freebsd.org Subject: Re: panic with if_iwi(4) upon "netif restart" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 16:50:51 -0000 On Mon, May 07, 2012 at 08:28:50PM +0200, Bernhard Schmidt wrote: > does "ps" in kgdb reveal multiple instances of wpa_supplicant running? Yes, grepping /var/crash/core.txt.0 shows two wpa_supplicant processes, one in "-/Rs" state and another in "select/Ds". > If so, this seems to be the well known devd+netif+supplicant+newstate > race/missing refcount. > > Wanna try attached patch? Thanks, I will. ./danfe From owner-freebsd-stable@FreeBSD.ORG Wed May 9 09:40:01 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76D6A106564A for ; Wed, 9 May 2012 09:40:01 +0000 (UTC) (envelope-from bartsch@dssgmbh.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id 2D2D18FC0A for ; Wed, 9 May 2012 09:40:01 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id AD1775C975 for ; Wed, 9 May 2012 11:30:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id 3WZxmIqnEuhi for ; Wed, 9 May 2012 11:29:55 +0200 (CEST) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id A7AC05C972 for ; Wed, 9 May 2012 11:29:55 +0200 (CEST) Received: from pcadmin.incore (pcadmin.incore [192.168.0.140]) by mail.incore (Postfix) with ESMTPSA id A076045087 for ; Wed, 9 May 2012 11:29:55 +0200 (CEST) Message-ID: <4FAA3912.3030801@dssgmbh.de> Date: Wed, 09 May 2012 11:29:54 +0200 From: Alfred Bartsch User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:7.0.1) Gecko/20111007 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: FreeBSD 8 i386 gptboot corrupt X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 09:40:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, after migrating some of our older servers to FeeBSD 8.3-stable (cvsupped May 4th), they don't boot anymore after installing the new boot blocks with gpart. These servers either boot in an endless loop or stop in BTX loader, due to different hardware environments. This behavior is restricted to 32-bit servers (i386), all 64-bit servers (amd64) work without any problem, as expected. After some analyzing, it seems to me that the actual size of gptboot does matter (16723 bytes, >16kB). In amd64 environment (same source version) the actual size of /boot/gptboot is only 15443 bytes. Since there is only one single Makefile for both architectures (/sys/boot/i386/gptboot/Makefile), some recent changes of CFLAGS seem to be responsible for this (Version 1.62 does work, Version 1.62.6.4 does not). Is there any advice available to solve this (compiler) problem, or is at last /sbin/gpart the culprit? - -- Kind regards Alfred Bartsch Data-Service GmbH mailto:bartsch@dssgmbh.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+qORIACgkQ5QGe2JdVf3jK9wCglOGPKHMuPfUr8YUU2N8Mw1++ NuIAoLQhibZk+PIHGc1/ql0nHkUx3qO2 =z29F -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Wed May 9 10:42:30 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85107106564A; Wed, 9 May 2012 10:42:30 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A0FF68FC14; Wed, 9 May 2012 10:42:29 +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 NAA22898; Wed, 09 May 2012 13:42:27 +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 1SS4Lj-000NcW-2a; Wed, 09 May 2012 13:42:27 +0300 Message-ID: <4FAA4A11.808@FreeBSD.org> Date: Wed, 09 May 2012 13:42:25 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: Alfred Bartsch References: <4FAA3912.3030801@dssgmbh.de> In-Reply-To: <4FAA3912.3030801@dssgmbh.de> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: FreeBSD 8 i386 gptboot corrupt X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 10:42:30 -0000 on 09/05/2012 12:29 Alfred Bartsch said the following: > Hello, after migrating some of our older servers to FeeBSD 8.3-stable > (cvsupped May 4th), they don't boot anymore after installing the new boot > blocks with gpart. These servers either boot in an endless loop or stop in > BTX loader, due to different hardware environments. > > This behavior is restricted to 32-bit servers (i386), all 64-bit servers > (amd64) work without any problem, as expected. > > After some analyzing, it seems to me that the actual size of gptboot does > matter (16723 bytes, >16kB). In amd64 environment (same source version) the > actual size of /boot/gptboot is only 15443 bytes. Weird. Both amd64 and i386 builds should produce the same binaries as the boot code is built with -m32 -march=i386 on amd64. But I can reproduce this, so it seems that the compilation is indeed done differently. Heh, it seems that it is -march=i386 flag that makes all the difference. Maybe we should use this flag even when doing native i386 builds... Anyway, the pmbr code is supposed to read the whole content of a GPT boot partition into memory (actually limited to 545KB), so 16KB limit should not matter/exist. What size are your GPT boot partitions? > Since there is only one single Makefile for both architectures > (/sys/boot/i386/gptboot/Makefile), some recent changes of CFLAGS seem to be > responsible for this (Version 1.62 does work, Version 1.62.6.4 does not). > > Is there any advice available to solve this (compiler) problem, or is at > last /sbin/gpart the culprit? You can always try to locally revert the commit that changed the CFLAGS, but as I've said above there should not be any 16KB limit for GPT boot. Or you can try to add -march=i386 to CFLAGS for your i386 boot block build. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed May 9 12:09:24 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2492B1065672; Wed, 9 May 2012 12:09:24 +0000 (UTC) (envelope-from bartsch@dssgmbh.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id D1AF18FC0A; Wed, 9 May 2012 12:09:23 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 10B265C980; Wed, 9 May 2012 14:09:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id BU0VTCBZCKJ9; Wed, 9 May 2012 14:09:21 +0200 (CEST) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id DE9F85C977; Wed, 9 May 2012 14:09:21 +0200 (CEST) Received: from pcadmin.incore (pcadmin.incore [192.168.0.140]) by mail.incore (Postfix) with ESMTPSA id D69A445084; Wed, 9 May 2012 14:09:21 +0200 (CEST) Message-ID: <4FAA5E70.7030508@dssgmbh.de> Date: Wed, 09 May 2012 14:09:20 +0200 From: Alfred Bartsch User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:7.0.1) Gecko/20111007 Thunderbird/7.0.1 MIME-Version: 1.0 To: Andriy Gapon References: <4FAA3912.3030801@dssgmbh.de> <4FAA4A11.808@FreeBSD.org> In-Reply-To: <4FAA4A11.808@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: FreeBSD 8 i386 gptboot corrupt - SOLVED X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 12:09:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 09.05.2012 12:42, schrieb Andriy Gapon: > on 09/05/2012 12:29 Alfred Bartsch said the following: >> Hello, after migrating some of our older servers to FeeBSD >> 8.3-stable (cvsupped May 4th), they don't boot anymore after >> installing the new boot blocks with gpart. These servers either >> boot in an endless loop or stop in BTX loader, due to different >> hardware environments. >> >> This behavior is restricted to 32-bit servers (i386), all 64-bit >> servers (amd64) work without any problem, as expected. >> >> After some analyzing, it seems to me that the actual size of >> gptboot does matter (16723 bytes, >16kB). In amd64 environment >> (same source version) the actual size of /boot/gptboot is only >> 15443 bytes. > > Weird. Both amd64 and i386 builds should produce the same binaries > as the boot code is built with -m32 -march=i386 on amd64. But I can > reproduce this, so it seems that the compilation is indeed done > differently. > > Heh, it seems that it is -march=i386 flag that makes all the > difference. Maybe we should use this flag even when doing native > i386 builds... > after adding "-march=i386" to CFLAGS in Makefile everything looks ok (filesize: 15443, as you predicted), so I would opt for using this flag in the future. > Anyway, the pmbr code is supposed to read the whole content of a > GPT boot partition into memory (actually limited to 545KB), so 16KB > limit should not matter/exist. What size are your GPT boot > partitions? They are all 64k (128 sectors), as recommended. > >> Since there is only one single Makefile for both architectures >> (/sys/boot/i386/gptboot/Makefile), some recent changes of CFLAGS >> seem to be responsible for this (Version 1.62 does work, Version >> 1.62.6.4 does not). >> >> Is there any advice available to solve this (compiler) problem, >> or is at last /sbin/gpart the culprit? > > You can always try to locally revert the commit that changed the > CFLAGS, but as I've said above there should not be any 16KB limit > for GPT boot. Or you can try to add -march=i386 to CFLAGS for your > i386 boot block build. > Thank you for your fast and helpful response. - -- Alfred Bartsch Data-Service GmbH mailto:bartsch@dssgmbh.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+qXnAACgkQ5QGe2JdVf3iCVwCgu3qQU49N2uGJ0g3Ej0UchV0q 1ecAnA/a4BiIFY6Acrc9ME9CR++dSJ3k =+w+l -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Wed May 9 12:14:31 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86EEE106566C for ; Wed, 9 May 2012 12:14:31 +0000 (UTC) (envelope-from adams-freebsd@ateamsystems.com) Received: from fss.sandiego.ateamservers.com (fss.sandiego.ateamservers.com [69.55.229.149]) by mx1.freebsd.org (Postfix) with ESMTP id 676A28FC15 for ; Wed, 9 May 2012 12:14:31 +0000 (UTC) Received: from [192.168.15.220] (unknown [118.175.84.92]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by fss.sandiego.ateamservers.com (Postfix) with ESMTPSA id 26A64B9067; Wed, 9 May 2012 08:14:23 -0400 (EDT) Message-ID: <4FAA5F9F.1080203@ateamsystems.com> Date: Wed, 09 May 2012 19:14:23 +0700 From: Adam Strohl Organization: A-Team Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <4F9EE487.6020609@ateamsystems.com> <4FA0CCF0.5000607@FreeBSD.org> <4FA0F872.4040008@ateamsystems.com> <4FA13C48.8010700@ateamsystems.com> <4FA15C0D.2050107@yandex.ru> In-Reply-To: <4FA15C0D.2050107@yandex.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 9 "gptboot: invalid backup GPT header" error (boots fine though) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 12:14:31 -0000 On 5/2/2012 23:08, Andrey V. Elsukov wrote: > On 02.05.2012 17:53, Adam Strohl wrote: >>> % gpart recover da0 >> >> Good thought, but no dice: >> >> $ gpart recover da0 >> da0 recovering is not needed > > I already saw several reports about gptboot's complains on 3ware > controllers, but don't know what is the problem. > The only guess is that a controller incorrectly handles BIOS requests, > when gptboot tries to read GPT header from the end of a large virtual disk. Thanks for your input on this Andrey. Just to clarify I am assuming that "da0 recovering is not needed" means that gpart has no problem reading and verifying the backup GPT header? (which is why its probably the BIOS for the RAID controller as the GPT is actually intact) From owner-freebsd-stable@FreeBSD.ORG Wed May 9 13:13:03 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DC12106567C for ; Wed, 9 May 2012 13:13:03 +0000 (UTC) (envelope-from prvs=0476080997=ob@gruft.de) Received: from main.mx.e-gitt.net (service.rules.org [IPv6:2001:1560:2342::2]) by mx1.freebsd.org (Postfix) with ESMTP id ACE4F8FC12 for ; Wed, 9 May 2012 13:13:02 +0000 (UTC) Received: from ob by main.mx.e-gitt.net with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SS6KU-0008T2-Dn; Wed, 09 May 2012 14:49:18 +0200 Date: Wed, 9 May 2012 14:49:18 +0200 From: Oliver Brandmueller To: Rick Macklem Message-ID: <20120509124913.GZ65313@e-Gitt.NET> Mail-Followup-To: Rick Macklem , freebsd-stable@FreeBSD.org References: <1693565170.26796.1335528520197.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1693565170.26796.1335528520197.JavaMail.root@erie.cs.uoguelph.ca> X-Face: "TT~P'b_)-jKU_0^a=usXryz`YTz)z.[FZrI,A~PREI2U}frrZ`>_J&; ^t|^.dR/mqtC,Vb.Y>~u8(|aL)vAv(k">zY"]*m*y|b8S7:WK[/qP5i>HO#Ek; C[X:b|FP0*Ly_4Ni User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Oliver Brandmueller Cc: freebsd-stable@FreeBSD.org Subject: Re: 9-STABLE, ZFS, NFS, ggatec - suspected memory leak X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 13:13:03 -0000 Hi, On Fri, Apr 27, 2012 at 08:08:40AM -0400, Rick Macklem wrote: > I'll commit it to head soon with a 1 month MFC, so that hopefully > Oliver will have a chance to try it on his production server before > the MFC. I could only give it short exposure by now, but NAMEI stays stable. From my side this is definitely a 'go'. Thanx, Oliver -- | Oliver Brandmueller http://sysadm.in/ ob@sysadm.in | | Ich bin das Internet. Sowahr ich Gott helfe. | From owner-freebsd-stable@FreeBSD.ORG Wed May 9 14:48: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 7CD9F106566C for ; Wed, 9 May 2012 14:48: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 C16A98FC15 for ; Wed, 9 May 2012 14:48:33 +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 RAA24438; Wed, 09 May 2012 17:48:31 +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 1SS8Br-000Njj-IB; Wed, 09 May 2012 17:48:31 +0300 Message-ID: <4FAA83BD.2030204@FreeBSD.org> Date: Wed, 09 May 2012 17:48:29 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: Alfred Bartsch References: <4FAA3912.3030801@dssgmbh.de> <4FAA4A11.808@FreeBSD.org> <4FAA5E70.7030508@dssgmbh.de> In-Reply-To: <4FAA5E70.7030508@dssgmbh.de> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: FreeBSD 8 i386 gptboot corrupt - SOLVED X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 14:48:34 -0000 on 09/05/2012 15:09 Alfred Bartsch said the following: > Am 09.05.2012 12:42, schrieb Andriy Gapon: >> on 09/05/2012 12:29 Alfred Bartsch said the following: >>> Hello, after migrating some of our older servers to FeeBSD 8.3-stable >>> (cvsupped May 4th), they don't boot anymore after installing the new >>> boot blocks with gpart. These servers either boot in an endless loop or >>> stop in BTX loader, due to different hardware environments. >>> >>> This behavior is restricted to 32-bit servers (i386), all 64-bit >>> servers (amd64) work without any problem, as expected. >>> >>> After some analyzing, it seems to me that the actual size of gptboot >>> does matter (16723 bytes, >16kB). In amd64 environment (same source >>> version) the actual size of /boot/gptboot is only 15443 bytes. > >> Weird. Both amd64 and i386 builds should produce the same binaries as >> the boot code is built with -m32 -march=i386 on amd64. But I can >> reproduce this, so it seems that the compilation is indeed done >> differently. > >> Heh, it seems that it is -march=i386 flag that makes all the difference. >> Maybe we should use this flag even when doing native i386 builds... > > > after adding "-march=i386" to CFLAGS in Makefile everything looks ok > (filesize: 15443, as you predicted), so I would opt for using this flag in > the future. > >> Anyway, the pmbr code is supposed to read the whole content of a GPT boot >> partition into memory (actually limited to 545KB), so 16KB limit should >> not matter/exist. What size are your GPT boot partitions? > > They are all 64k (128 sectors), as recommended. Strange. I wonder what kind of a problem you are running into. E.g. I use gptzfsboot and its size is ~40KB and I do not having any problems. >>> Since there is only one single Makefile for both architectures >>> (/sys/boot/i386/gptboot/Makefile), some recent changes of CFLAGS seem >>> to be responsible for this (Version 1.62 does work, Version 1.62.6.4 >>> does not). >>> >>> Is there any advice available to solve this (compiler) problem, or is >>> at last /sbin/gpart the culprit? > >> You can always try to locally revert the commit that changed the CFLAGS, >> but as I've said above there should not be any 16KB limit for GPT boot. >> Or you can try to add -march=i386 to CFLAGS for your i386 boot block >> build. > > > Thank you for your fast and helpful response. > -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed May 9 20:53:10 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 684BB106564A for ; Wed, 9 May 2012 20:53:10 +0000 (UTC) (envelope-from bounce+freebsd-stable=freebsd.org@to.cupid.com) Received: from me13.redut.net (me13.redut.net [193.105.182.132]) by mx1.freebsd.org (Postfix) with ESMTP id ADD418FC0C for ; Wed, 9 May 2012 20:53:09 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by me13.redut.net (Postfix) with QMQP id 052C412015A95 for ; Wed, 9 May 2012 20:53:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cupid.com; s=default; t=1336596789; bh=yzm5fLyPxnHRuhUy3QMCilt22cc=; h=MIME-Version:List-Unsubscribe:List-Id:From:Reply-To:Subject: Content-Type:Message-ID:Date:To; b=MYfBeU9OXnlN2Cz8cOFpJdCLTlJbUY70y10ElwVB1XqCwa6kbJb3GoF99gmBBfwMY CM3gpDODPxMPu45xZwTnhYthsugRby0kZObmAEN5sXXypwSR4V1SL2Pist0gkbxSzx Za3m3lUnE7zI8J6+upJpi8MDYXsKKtyUP4oA3jmo= MIME-Version: 1.0 Organization: Cupid plc X-Priority: 3 X-Mailer: Cupid X-Campaign-Id: 291709 X-Dating: cdf257371b1bcc998b3b4dd7df058cfeZnJlZWJzZC1zdGFibGVAZnJlZWJzZC5vcmc= From: Cupid.com Message-ID: <291709.m3rwok.jdrcix@cupid.com> Date: Wed, 09 May 12 21:53:08 +0100 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Welcome to Cupid.com! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Cupid.com" List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 20:53:10 -0000 Cupid.comUpgrade your account to contact all members │ Unsubscribe fr= om all types of emails.Keep your login information handy:email: freebsd-sta= ble@freebsd.orgpassword: hisexy123Welcome to Cupid.com!Activate your accoun= t and start looking for that special someoneActivate my accountIf the butto= n doesn't work, copy & paste this link into your browser.http://www.cupid.c= om/fbd4f28987e4a27fe1df30093b7f6d03/autologin.php?mid=3D10902&sendtime= =3D1336596788&&hid=3D13Activate your account and meet like-minded s= ingles!Unsubscribe from all types of emails │ Privacy policy │ = Terms & Conditions(c) 2012 Cupid Plc, 410 Park Avenue, 15th Floor, New = York, NY 10022, USATel: (212) 796 6946; your user ID: 20125267483 From owner-freebsd-stable@FreeBSD.ORG Wed May 9 20:53:10 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6862B106566B for ; Wed, 9 May 2012 20:53:10 +0000 (UTC) (envelope-from bounce+freebsd-stable=freebsd.org@to.cupid.com) Received: from me13.redut.net (me13.redut.net [193.105.182.132]) by mx1.freebsd.org (Postfix) with ESMTP id 9D77C8FC0A for ; Wed, 9 May 2012 20:53:09 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by me13.redut.net (Postfix) with QMQP id 9CA3412015A93 for ; Wed, 9 May 2012 20:53:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cupid.com; s=default; t=1336596788; bh=C1vCguQ6YKIbEcBoR15zrtuhawg=; h=MIME-Version:List-Unsubscribe:List-Id:From:Reply-To:Subject: Content-Type:Message-ID:Date:To; b=ivLL6Irv7VbC+FeKLWvNjgH4d7q0PE/klE7SrOQhFwSjiUDmFgmxHwXDUy4PopYXW kKzMcapMZvXxmFpetzBFv+QrLMhMtosJK+FIx3tURfTYm2gd0VpK7Lg/Lmty+FqzI0 euVFCez0Vv9Smy87IhjWgztVV7I6BLjJuEvSF9uo= MIME-Version: 1.0 Organization: Cupid plc X-Priority: 3 X-Mailer: Cupid X-Campaign-Id: 291709 X-Dating: cdf257371b1bcc998b3b4dd7df058cfeZnJlZWJzZC1zdGFibGVAZnJlZWJzZC5vcmc= From: Cupid.com Message-ID: <291709.m3rwok.58hikj@cupid.com> Date: Wed, 09 May 12 21:53:08 +0100 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Welcome to Cupid.com! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Cupid.com" List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 20:53:10 -0000 Cupid.comUpgrade your account to contact all members │ Unsubscribe fr= om all types of emails.Keep your login information handy:email: freebsd-sta= ble@freebsd.orgpassword: hisexy123Welcome to Cupid.com!Activate your accoun= t and start looking for that special someoneActivate my accountIf the butto= n doesn't work, copy & paste this link into your browser.http://www.cupid.c= om/fbd4f28987e4a27fe1df30093b7f6d03/autologin.php?mid=3D10902&sendtime= =3D1336596788&&hid=3D13Activate your account and meet like-minded s= ingles!Unsubscribe from all types of emails │ Privacy policy │ = Terms & Conditions(c) 2012 Cupid Plc, 410 Park Avenue, 15th Floor, New = York, NY 10022, USATel: (212) 796 6946; your user ID: 20125267483 From owner-freebsd-stable@FreeBSD.ORG Wed May 9 21:00:38 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 D754B10656DA for ; Wed, 9 May 2012 21:00:38 +0000 (UTC) (envelope-from bounce+freebsd-stable=freebsd.org@to.cupid.com) Received: from me13.redut.net (me13.redut.net [193.105.182.132]) by mx1.freebsd.org (Postfix) with ESMTP id 7B9A88FC0C for ; Wed, 9 May 2012 21:00:37 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by me13.redut.net (Postfix) with QMQP id 8C4CE12015AB5 for ; Wed, 9 May 2012 21:00:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cupid.com; s=default; t=1336597236; bh=eUyMdOrLxqbKOA1t/OJV3UFScDU=; h=MIME-Version:List-Unsubscribe:List-Id:From:Reply-To:Subject: Content-Type:Message-ID:Date:To; b=RmvpKiATfo1GJ8hbk5BgpooPOA8xDfiUYtQujRRVsh9hFr07Z4CcDB6YHmeocPtaX 67NkePdP1qk0DiESWTtOPpidKz4ktXGxG+scdNxeMsvkmqigrwDPfpnpmfx4bqRB+Z fVqqeR+Yk3atX+ClZK8NyUNU3j28QkD/GnZG3Hrc= MIME-Version: 1.0 Organization: Cupid plc X-Priority: 3 X-Mailer: Cupid X-Campaign-Id: 291532 X-Dating: 91edc7af2c8cd6664d1c0c75550d020aZnJlZWJzZC1zdGFibGVAZnJlZWJzZC5vcmc= From: Cupid.com Message-ID: <291532.m3rx0z.pe5d2r@cupid.com> Date: Wed, 09 May 12 22:00:35 +0100 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: freeb51853, Come check flirty singles who match you perfectly! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Cupid.com" List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 21:00:38 -0000 Cupid.comHave a look at your newest matches kittymagic, 25 ValdostaHere, ki= tty,, kitty,, kitty..Send EmailChat Nowlula89, 22 Jackson...LeperSend Email= Chat NowKSarv, 24 Columbusnew, in, town,, seeking,...Send EmailChat Now Se= xiiLa..., 25 BeaufortI, AM, WHO, I, AM....NOT,...Send EmailChat NowbigOboo.= .., 25 Richmon...A, Southtern, Bell, lookin,...Send EmailChat NowApril_89, = 23 Conwayim, Almost, 21,, im, a,...Send EmailChat Now brandi_..., 24 Alach= uaSweetButGuardSend EmailChat Nowms_bella, 21 PalatkaI, think, I, am, an,..= .Send EmailChat Nowsalsadi..., 22 RiverviewI'm, looking, for, the,...Send E= mailChat Now Blueber..., 19 BrunswickJust, Being, Send EmailChat Nowcheryl= sd, 21 Gainesv...I'm, adventurous,,...Send EmailChat Nowhotstuff01, 23 Tarp= on...alone, and, bored, as, heSend EmailChat Now saraa94592, 22 Sand Laked= o, you, want, to, see, my,...Send EmailChat NowMALASAD..., 22 MiamiGIVE, ME= , SOME, LUCK, ON,...Send EmailChat NowPeople are joining Cupid.com every da= y, don't miss that special someone who may have just registered and is wait= ing for your email!Unsubscribe by changing your email subscriptions │= Privacy policy │ Terms & ConditionsAvailable on Mobile:Follow us= on:(c) 2012 Cupid Plc, 410 Park Avenue, 15th Floor, New York, NY 10022, US= A, Tel: (212) 796 6946your user ID: 20125267483 From owner-freebsd-stable@FreeBSD.ORG Wed May 9 21:02: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 8E261106564A for ; Wed, 9 May 2012 21:02:58 +0000 (UTC) (envelope-from bounce-return-hisexy123413@bounce.adultfriendfinder.com) Received: from mta210.friendfinderinc.com (mta210.friendfinderinc.com [208.88.181.210]) by mx1.freebsd.org (Postfix) with ESMTP id 6014C8FC18 for ; Wed, 9 May 2012 21:02:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; d=adultfriendfinder.com; s=default; c=relaxed/relaxed; q=dns/txt; i=@adultfriendfinder.com; t=1336596172; h=From:Subject:Date:To:MIME-Version:Content-Type; bh=as03BHyWGOWmb7sqf0iPkcuszdU=; b=KA3nEneLgMryj6eYd0mraRflk44FetnaIHgdYTX+96lfgwx1n4dYwk7RHgwEyGQx gTWF2Oat+TAzSSAj9Hcx9XuThTD53oVC7CfQSE5uhdjkezo8FLyYf+l5b6k/Ok01; Received: from [10.92.17.3] ([10.92.17.3:8491] helo=ii33-25.friendfinderinc.com) by ii71-1.friendfinderinc.com (envelope-from ) (ecelerity 2.2.2.40 r(29895/29896)) with ESMTP id 14/BE-07512-CC6DAAF4; Wed, 09 May 2012 13:42:52 -0700 Received: by ii33-25.friendfinderinc.com (Postfix, from userid 65534) id 2A56CA704B6; Wed, 9 May 2012 13:42:51 -0700 (PDT) MIME-Version: 1.0 To: freebsd-stable@freebsd.org From: "Adult FriendFinder" X-Hostid: 10.91.1.204 X-CffUID: 307285189_81855 X-VirtualServerGroup: ffadult X-VirtualServerGroup-Source: app=new_password site=ffadult domain=freebsd.org msgid=1336596171.27001.freebsd-stable@freebsd.org X-Campaign-ID: new_password_27001 X-Ffncampaignrp-ID: new_password_27001 Message-Id: <20120509204252.2A56CA704B6@ii33-25.friendfinderinc.com> Date: Wed, 9 May 2012 13:42:51 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: binary Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Your New Adult FriendFinder Login Information! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adult FriendFinder List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 21:02:58 -0000 [This message is being sent to registered Adult FriendFinder customers. If you wish to no longer receive e-mails, please unsubscribe at the bottom of this message.] ====================================================== New Password Notification ====================================================== Dear , Because you recently updated your email address, your password has been changed as a security precaution. To reactivate your account, you must log in http://adultfriendfinder.com/e/?enc=r,DRDaBjVsT2PN05Eu4Z/1oypN0fOXreExpctwVaFdpr1IuF_pHqGUsxSxzXT7foA97l2V7zhK9mongYhj7F5OTVTCQ/vX3ChRoV/fNRVQG6e3ltzMaGcX0lqnCOTOxXOGjbbUZZk3Pj_xzmzq8IK_G0cW2cR6VjSHcyQxvZh5QK5p_p3B/i6Ad_VFky5wtWUUPU0ivSteHbL5yvA3zWSUAg--&site=ffadult&lfrom=np now with your new password. Username: hisexy123413 Password: 76288 You can log in automatically using this link: ==>http://adultfriendfinder.com/e/?enc=r,DRDaBjVsT2PN05Eu4Z/1oypN0fOXreExpctwVaFdpr1IuF_pHqGUsxSxzXT7foA97l2V7zhK9mongYhj7F5OTVTCQ/vX3ChRoV/fNRVQG6e3ltzMaGcX0lqnCOTOxXOGjbbUZZk3Pj_xzmzq8IK_G0cW2cR6VjSHcyQxvZh5QK5p_p3B/i6Ad_VFky5wtWUUPU0ivSteHbL5yvA3zWSUAg--&site=ffadult&lfrom=np Once you log in, you may change your password under "Personal Preferences". Sincerely, The Adult FriendFinder Team ====================================================== [You are currently registered as: freebsd-stable@freebsd.org] Please do not reply to this e-mail, For support-related questions, go here: ==> http://adultfriendfinder.com/e/?enc=r,5e_GhtmDGlXy4kh2Ls6NgzQHNkv473fn9sOkE24fiKuz7Y3fEhMv76CmjkGx4J8Ft8en6bXR/hbnjI7sA50LckG9_lhq2G730_qRFvDyqclDbuQAOHu5Wu0wFER9k6GtnXq2l5KOIQK8C8Lq2ocVUQ--&site=ffadult&lfrom=np Visit our corporate site: ==> http://adultfriendfinder.com/e/?enc=r,ROmyNX1ZADZcCM7I0HOq4rXa2ggYNoYgRtKOhr35WARNC3zTxx09/u3UxRmINF65ck_QUZa9PZdhni0pi0HPGjNDAv5Jmonl8YQMG6A2YX1BvfpYathu99PqkRbw8qnJ8tjZoEOZeOQ0FS_gcyy8KzUiRR4H2sWk/4kVP_PIuTA-&site=ffadult&lfrom=np If you prefer not to receive future e-mails from Adult FriendFinder, please unsubscribe here: ==> http://adultfriendfinder.com/e/?enc=r,ZAPY3KQk7_Pn0wWtl0_n91_ghKdVLQ4wHJsgn0GUUu7GyWsFWRGmVdALbho5hGoDQXlGAkArTlYquJgiYeYOd0G9_lhq2G730_qRFvDyqcnjPIlgknOYFSPFiM/ZUT1wF04axhuPJzXS0enoAd83cg--&site=ffadult&lfrom=np To view our privacy policy: ==> http://adultfriendfinder.com/e/?enc=r,eFNjqf8diJuC3SVeJDkoe_O6eB6C1/S9ADCff5HgFkz48j7oKkRwkNt2DaF2bEjlt8en6bXR/hbnjI7sA50LckG9_lhq2G730_qRFvDyqcn0_vuutlBTMs5YfqgP5VVG0WsQjgWPZz_gKa6ZIJzrFMDAmR4Mc1gdbvbyCO3WAnA-&site=ffadult&lfrom=np Adult FriendFinder is registered service mark of Various, Inc. Copyright(C) 1996-2012 Various, Inc. All rights reserved. 220 Humboldt Court, Sunnyvale, CA 94089, United States From owner-freebsd-stable@FreeBSD.ORG Wed May 9 21:24:47 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FA3D1065672 for ; Wed, 9 May 2012 21:24:47 +0000 (UTC) (envelope-from bounce+freebsd-stable=freebsd.org@to.cupid.com) Received: from me13.redut.net (me13.redut.net [193.105.182.132]) by mx1.freebsd.org (Postfix) with ESMTP id 974978FC19 for ; Wed, 9 May 2012 21:24:46 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by me13.redut.net (Postfix) with QMQP id 01FBA12015845 for ; Wed, 9 May 2012 20:52:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cupid.com; s=default; t=1336596726; bh=uv1ZV67jPvh1Irt0ysfzLbSwWQU=; h=MIME-Version:List-Unsubscribe:List-Id:From:Reply-To:Subject: Content-Type:Message-ID:Date:To; b=q4XRhPi36WtVQZeMPFL3EcqHBkH8ZwWHuXCIh4mKSs95EJzdX8LZ0FHfKNgai30w8 AkxnRFDiwt7SOCgi5qWhDu2EtlXFSAjC3eR6RkYUUwa4VTjS9ZhDAvdyxJ4IuaaJ3z ecGAfcPfc3+xGMo86aV7GwjNOqdJDRHcwD1ehIDI= MIME-Version: 1.0 Organization: Cupid plc X-Priority: 3 X-Mailer: Cupid X-Campaign-Id: 293 X-Dating: b58ef0bd228675ace993a8421d04f892ZnJlZWJzZC1zdGFibGVAZnJlZWJzZC5vcmc= From: Cupid.com Message-ID: <293.m3rwmt.236c62@cupid.com> Date: Wed, 09 May 12 21:52:05 +0100 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Welcome to Cupid.com! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Cupid.com" List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 21:24:47 -0000 Cupid.com Unsubscribe from all types of emails.Keep your login information handy:emai= l: freebsd-stable@freebsd.orgpassword: hisexy123Welcome to Cupid.com!Activa= te your account and start looking for that special someoneActivate my accou= ntIf the button doesn't work, copy & paste this link into your browser.http= ://us.cupid.com/fbd4f28987e4a27fe1df30093b7f6d03/autologin.php?mid=3D10050&= amp;sendtime=3D1336596725&&hid=3D13Activate your account and meet l= ike-minded singles!Unsubscribe from all types of emails │ Privacy pol= icy │ Terms & Conditions(c) 2012 Cupid Plc, 410 Park Avenue, 15th= Floor, New York, NY 10022, USA Tel: (212) 796 6946; your user ID: 20125267= 483 From owner-freebsd-stable@FreeBSD.ORG Wed May 9 21:24: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 5FC851065673 for ; Wed, 9 May 2012 21:24:47 +0000 (UTC) (envelope-from bounce+freebsd-stable=freebsd.org@to.cupid.com) Received: from me13.redut.net (me13.redut.net [193.105.182.132]) by mx1.freebsd.org (Postfix) with ESMTP id 972EB8FC17 for ; Wed, 9 May 2012 21:24:46 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by me13.redut.net (Postfix) with QMQP id 379C11201589D for ; Wed, 9 May 2012 20:52:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cupid.com; s=default; t=1336596727; bh=U9Ts1IWHWkk+SHqRMy4WHGu65L0=; h=MIME-Version:List-Unsubscribe:List-Id:From:Reply-To:Subject: Content-Type:Message-ID:Date:To; b=fTOXQl1kdR0GDXyD5f0iIjS9GWY/qtQyet34MjW534VAAluFz7d4ZgI90iyLWTX8t Npzric/qTx5+egRL7CnkCZbp43Si3F6K7QSXrf++Spem2nnoVt4V3K16PkhX/d0NVX dshOwuViLzgGKK1FOGHIedi7h7EkyYZa13fckG1s= MIME-Version: 1.0 Organization: Cupid plc X-Priority: 3 X-Mailer: Cupid X-Campaign-Id: 291709 X-Dating: cdf257371b1bcc998b3b4dd7df058cfeZnJlZWJzZC1zdGFibGVAZnJlZWJzZC5vcmc= From: Cupid.com Message-ID: <291709.m3rwmv.17hi9m@cupid.com> Date: Wed, 09 May 12 21:52:07 +0100 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Welcome to Cupid.com! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Cupid.com" List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 21:24:47 -0000 Cupid.comUpgrade your account to contact all members │ Unsubscribe fr= om all types of emails.Keep your login information handy:email: freebsd-sta= ble@freebsd.orgpassword: hisexy123Welcome to Cupid.com!Activate your accoun= t and start looking for that special someoneActivate my accountIf the butto= n doesn't work, copy & paste this link into your browser.http://www.cupid.c= om/fbd4f28987e4a27fe1df30093b7f6d03/autologin.php?mid=3D10902&sendtime= =3D1336596727&&hid=3D13Activate your account and meet like-minded s= ingles!Unsubscribe from all types of emails │ Privacy policy │ = Terms & Conditions(c) 2012 Cupid Plc, 410 Park Avenue, 15th Floor, New = York, NY 10022, USATel: (212) 796 6946; your user ID: 20125267483 From owner-freebsd-stable@FreeBSD.ORG Wed May 9 21:24:47 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7675C1065674 for ; Wed, 9 May 2012 21:24:47 +0000 (UTC) (envelope-from bounce+freebsd-stable=freebsd.org@to.cupid.com) Received: from me13.redut.net (me13.redut.net [193.105.182.132]) by mx1.freebsd.org (Postfix) with ESMTP id 9739B8FC18 for ; Wed, 9 May 2012 21:24:46 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by me13.redut.net (Postfix) with QMQP id D138B12015844 for ; Wed, 9 May 2012 20:52:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cupid.com; s=default; t=1336596726; bh=UJEQLmJlZkUbkQl+jsWgW0So/to=; h=MIME-Version:List-Unsubscribe:List-Id:From:Reply-To:Subject: Content-Type:Message-ID:Date:To; b=DT4Abk60iwSpTbrhGV1UOfCP9hFCTpmYXnb1nDM47Nv6exHkPwr8X+fie9CTVhVxb DUN8T0o4oMWtMlch0+Avbmz7IRnckn1a6vZ4LddN9xxXvbHnMdUaTlLPnvPgtiLphL gdyqNWsnbPGiQOgvtUh2JdsfI4hI7O8OUP4fGn2Q= MIME-Version: 1.0 Organization: Cupid plc X-Priority: 3 X-Mailer: Cupid X-Campaign-Id: 291709 X-Dating: cdf257371b1bcc998b3b4dd7df058cfeZnJlZWJzZC1zdGFibGVAZnJlZWJzZC5vcmc= From: Cupid.com Message-ID: <291709.m3rwmu.drzpr9@cupid.com> Date: Wed, 09 May 12 21:52:06 +0100 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Welcome to Cupid.com! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Cupid.com" List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 21:24:47 -0000 Cupid.comUpgrade your account to contact all members │ Unsubscribe fr= om all types of emails.Keep your login information handy:email: freebsd-sta= ble@freebsd.orgpassword: hisexy123Welcome to Cupid.com!Activate your accoun= t and start looking for that special someoneActivate my accountIf the butto= n doesn't work, copy & paste this link into your browser.http://www.cupid.c= om/fbd4f28987e4a27fe1df30093b7f6d03/autologin.php?mid=3D10902&sendtime= =3D1336596726&&hid=3D13Activate your account and meet like-minded s= ingles!Unsubscribe from all types of emails │ Privacy policy │ = Terms & Conditions(c) 2012 Cupid Plc, 410 Park Avenue, 15th Floor, New = York, NY 10022, USATel: (212) 796 6946; your user ID: 20125267483 From owner-freebsd-stable@FreeBSD.ORG Thu May 10 06:24:29 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF514106566B for ; Thu, 10 May 2012 06:24:29 +0000 (UTC) (envelope-from cowens@greatbaysoftware.com) Received: from ecbiz102.inmotionhosting.com (ecbiz102.inmotionhosting.com [70.39.235.94]) by mx1.freebsd.org (Postfix) with ESMTP id 8C2F78FC0C for ; Thu, 10 May 2012 06:24:29 +0000 (UTC) Received: from c-50-136-23-27.hsd1.nh.comcast.net ([50.136.23.27]:52070 helo=jack.bspruce.com) by ecbiz102.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SSB6l-0006rq-T4 for freebsd-stable@freebsd.org; Wed, 09 May 2012 13:55:28 -0400 Message-ID: <4FAAAF8E.40007@greatbaysoftware.com> Date: Wed, 09 May 2012 13:55:26 -0400 From: Charles Owens Organization: Great Bay Software User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz102.inmotionhosting.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - greatbaysoftware.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: superpages not solving "PV entries" limit warning X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 06:24:29 -0000 Hi fellow BSD-types, I have a buy system that forks lots of processes and I see repeatedly the message: "Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max tunable". My research suggested that enabling the "superpages" feature via sysctl vm.pmap.pg_ps_enabled was the best action... that doing so would quite the warning and improve memory mapping efficiency. As far as I can tell, however, "superpages" haven't done this -- well, to be specific, I can say at least that they haven't quieted the warning. Since I'm still seeing the warning, do I need to tune something else? Other comments? System details: * 8.1-RELEASE-p2 i386 PAE kernel * 6 GB RAM Thanks very much! Charles -- Charles Owens Great Bay Software, Inc. From owner-freebsd-stable@FreeBSD.ORG Thu May 10 07:13:04 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 4E952106566B; Thu, 10 May 2012 07:13:04 +0000 (UTC) (envelope-from bartsch@dssgmbh.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id D06A18FC08; Thu, 10 May 2012 07:13:03 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 0270E5C9BD; Thu, 10 May 2012 09:13:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id pDHG3BI2dQzi; Thu, 10 May 2012 09:13:01 +0200 (CEST) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id C34465C9BB; Thu, 10 May 2012 09:13:01 +0200 (CEST) Received: from pcadmin.incore (pcadmin.incore [192.168.0.140]) by mail.incore (Postfix) with ESMTPSA id BE0DB45087; Thu, 10 May 2012 09:13:01 +0200 (CEST) Message-ID: <4FAB6A7B.9050500@dssgmbh.de> Date: Thu, 10 May 2012 09:12:59 +0200 From: Alfred Bartsch User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:7.0.1) Gecko/20111007 Thunderbird/7.0.1 MIME-Version: 1.0 To: Andriy Gapon References: <4FAA3912.3030801@dssgmbh.de> <4FAA4A11.808@FreeBSD.org> <4FAA5E70.7030508@dssgmbh.de> <4FAA83BD.2030204@FreeBSD.org> In-Reply-To: <4FAA83BD.2030204@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: FreeBSD 8 i386 gptboot corrupt - SOLVED X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 07:13:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 09.05.2012 16:48, schrieb Andriy Gapon: > on 09/05/2012 15:09 Alfred Bartsch said the following: >> Am 09.05.2012 12:42, schrieb Andriy Gapon: >>> on 09/05/2012 12:29 Alfred Bartsch said the following: >>>> Hello, after migrating some of our older servers to FeeBSD >>>> 8.3-stable (cvsupped May 4th), they don't boot anymore after >>>> installing the new boot blocks with gpart. These servers >>>> either boot in an endless loop or stop in BTX loader, due to >>>> different hardware environments. >>>> >>>> This behavior is restricted to 32-bit servers (i386), all >>>> 64-bit servers (amd64) work without any problem, as >>>> expected. >>>> >>>> After some analyzing, it seems to me that the actual size of >>>> gptboot does matter (16723 bytes, >16kB). In amd64 >>>> environment (same source version) the actual size of >>>> /boot/gptboot is only 15443 bytes. >> >>> Weird. Both amd64 and i386 builds should produce the same >>> binaries as the boot code is built with -m32 -march=i386 on >>> amd64. But I can reproduce this, so it seems that the >>> compilation is indeed done differently. >> >>> Heh, it seems that it is -march=i386 flag that makes all the >>> difference. Maybe we should use this flag even when doing >>> native i386 builds... >> >> >> after adding "-march=i386" to CFLAGS in Makefile everything looks >> ok (filesize: 15443, as you predicted), so I would opt for using >> this flag in the future. >> >>> Anyway, the pmbr code is supposed to read the whole content of >>> a GPT boot partition into memory (actually limited to 545KB), >>> so 16KB limit should not matter/exist. What size are your GPT >>> boot partitions? >> >> They are all 64k (128 sectors), as recommended. > > Strange. I wonder what kind of a problem you are running into. > E.g. I use gptzfsboot and its size is ~40KB and I do not having any > problems. > I got this stupid idea of a "16k limit" during testing. It was unobvious to me that the build process in a standard environment (i386) simply produces invalid code. In i386 (32-bit) hardware, we don't use zfs at all, so I can't tell anything about gptzfsboot. For now, modifying /sys/boot/i386/gptboot/Makefile completely solves this actual build problem. IMHO the compiler should always know perfectly well in which hardware environment it runs and for which target environment it produces code. So the build environment should be modified to fix this. I would certainly give it a try, but unfortunately this is far beyond my knowledge. :-( >>>> Since there is only one single Makefile for both >>>> architectures (/sys/boot/i386/gptboot/Makefile), some recent >>>> changes of CFLAGS seem to be responsible for this (Version >>>> 1.62 does work, Version 1.62.6.4 does not). >>>> >>>> Is there any advice available to solve this (compiler) >>>> problem, or is at last /sbin/gpart the culprit? >> >>> You can always try to locally revert the commit that changed >>> the CFLAGS, but as I've said above there should not be any 16KB >>> limit for GPT boot. Or you can try to add -march=i386 to CFLAGS >>> for your i386 boot block build. >> >> >> Thank you for your fast and helpful response. >> > - -- Alfred Bartsch Data-Service GmbH mailto:bartsch@dssgmbh.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+ransACgkQ5QGe2JdVf3gwPgCglboYbXB4AIP/BXg+uyVf/CRN DxIAnAly7qqasYixQBNMcZFoZllURLRv =A/YX -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Thu May 10 07:19:07 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 03A851065674 for ; Thu, 10 May 2012 07:19:07 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 458AE8FC08 for ; Thu, 10 May 2012 07:19:05 +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 KAA01705; Thu, 10 May 2012 10:19:04 +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 1SSNeS-0000jk-4Z; Thu, 10 May 2012 10:19:04 +0300 Message-ID: <4FAB6BE7.9060500@FreeBSD.org> Date: Thu, 10 May 2012 10:19:03 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: Alfred Bartsch References: <4FAA3912.3030801@dssgmbh.de> <4FAA4A11.808@FreeBSD.org> <4FAA5E70.7030508@dssgmbh.de> <4FAA83BD.2030204@FreeBSD.org> <4FAB6A7B.9050500@dssgmbh.de> In-Reply-To: <4FAB6A7B.9050500@dssgmbh.de> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: FreeBSD 8 i386 gptboot corrupt - SOLVED X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 07:19:07 -0000 on 10/05/2012 10:12 Alfred Bartsch said the following: > I got this stupid idea of a "16k limit" during testing. It was unobvious to > me that the build process in a standard environment (i386) simply produces > invalid code. In i386 (32-bit) hardware, we don't use zfs at all, so I > can't tell anything about gptzfsboot. For now, modifying > /sys/boot/i386/gptboot/Makefile completely solves this actual build > problem. > > IMHO the compiler should always know perfectly well in which hardware > environment it runs and for which target environment it produces code. So > the build environment should be modified to fix this. I would certainly > give it a try, but unfortunately this is far beyond my knowledge. :-( That's an interesting theory. What kind of hardware do you have? Is it something non-mainstream or sufficiently old? As far as I can tell, our base GCC uses i686 target arch if none is explicitly requested. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu May 10 07:32:13 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 29EAF106564A for ; Thu, 10 May 2012 07:32:13 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9A6238FC0A for ; Thu, 10 May 2012 07:32:12 +0000 (UTC) Received: by laai10 with SMTP id i10so3145laa.13 for ; Thu, 10 May 2012 00:32:11 -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=iya9tMCkde715ausDH5FLUJCH+rHQeKt8RW6axtC+Sk=; b=iHIkPIS1NVK8FHy00SZQxl+5+ZBOWG+bDYTHJLtgsq/QMyyFiEgfD2ve4CHxW7xEJf Q44CJODOXDgblveluIMEaIOKZa96vxj1MGKJoSQ8ccXq3v68wo+AIaZK6nQwXYvSUPj+ 4pwBGjC0OzfTzrPRi9bLFYtwBbRIjY5uE5sSnItVfRpRioLecNOhMOTO3A19KHqhw4a6 IFRVlm31Xk8PjhIECFdAKhhE8BRDRMFpNikK1+MtxhikiQ5EiGqFHZnJBOxtJkJsdG6t kCOhv/D4g/G3Tu01/e1PP6KgYGbbaE+OZBNFRec/rwwUsvcp351LdzNUr5bcek1RPfqd L/ew== MIME-Version: 1.0 Received: by 10.152.146.39 with SMTP id sz7mr3195603lab.3.1336635131328; Thu, 10 May 2012 00:32:11 -0700 (PDT) Received: by 10.112.26.66 with HTTP; Thu, 10 May 2012 00:32:11 -0700 (PDT) In-Reply-To: <4FAAAF8E.40007@greatbaysoftware.com> References: <4FAAAF8E.40007@greatbaysoftware.com> Date: Thu, 10 May 2012 02:32:11 -0500 Message-ID: From: Adam Vande More To: Charles Owens Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: superpages not solving "PV entries" limit warning X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 07:32:13 -0000 On Wed, May 9, 2012 at 12:55 PM, Charles Owens wrote: > Hi fellow BSD-types, > > I have a buy system that forks lots of processes and I see repeatedly the > message: "Approaching the limit on PV entries, consider increasing either > the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max tunable". > > System details: > > * 8.1-RELEASE-p2 i386 PAE kernel > * 6 GB RAM > The warning is not applicable any longer including your version as well as several previous ones. The warning has been removed from current releases. -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Thu May 10 07:57:55 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7B29106564A; Thu, 10 May 2012 07:57:55 +0000 (UTC) (envelope-from bartsch@dssgmbh.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id A1D3B8FC14; Thu, 10 May 2012 07:57:55 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id EA5675C9BA; Thu, 10 May 2012 09:57:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id HMsq8qd3r_S3; Thu, 10 May 2012 09:57:53 +0200 (CEST) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id CA45B5C9B8; Thu, 10 May 2012 09:57:53 +0200 (CEST) Received: from pcadmin.incore (pcadmin.incore [192.168.0.140]) by mail.incore (Postfix) with ESMTPSA id C1AD245084; Thu, 10 May 2012 09:57:53 +0200 (CEST) Message-ID: <4FAB7500.7020204@dssgmbh.de> Date: Thu, 10 May 2012 09:57:52 +0200 From: Alfred Bartsch User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:7.0.1) Gecko/20111007 Thunderbird/7.0.1 MIME-Version: 1.0 To: Andriy Gapon References: <4FAA3912.3030801@dssgmbh.de> <4FAA4A11.808@FreeBSD.org> <4FAA5E70.7030508@dssgmbh.de> <4FAA83BD.2030204@FreeBSD.org> <4FAB6A7B.9050500@dssgmbh.de> <4FAB6BE7.9060500@FreeBSD.org> In-Reply-To: <4FAB6BE7.9060500@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: FreeBSD 8 i386 gptboot corrupt - SOLVED X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 07:57:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 10.05.2012 09:19, schrieb Andriy Gapon: > on 10/05/2012 10:12 Alfred Bartsch said the following: >> I got this stupid idea of a "16k limit" during testing. It was >> unobvious to me that the build process in a standard environment >> (i386) simply produces invalid code. In i386 (32-bit) hardware, >> we don't use zfs at all, so I can't tell anything about >> gptzfsboot. For now, modifying /sys/boot/i386/gptboot/Makefile >> completely solves this actual build problem. >> >> IMHO the compiler should always know perfectly well in which >> hardware environment it runs and for which target environment it >> produces code. So the build environment should be modified to fix >> this. I would certainly give it a try, but unfortunately this is >> far beyond my knowledge. :-( > > That's an interesting theory. What kind of hardware do you have? > Is it something non-mainstream or sufficiently old? As far as I can > tell, our base GCC uses i686 target arch if none is explicitly > requested. > Our i386 hardware is sufficiently old, and IMHO mainstream, e.g.: Intel SR1325 with Pentium-4 CPU, 2GB RAM Intel SR2200 with Pentium-III CPU(s), 2/4 GB RAM, Intel SR2300 with dual XEON, 4 GB RAM Even on my desktop (Intel MB DQ965CO, Intel Core2 CPU), this (wrong) behavior can be reproduced. dmesg output: FreeBSD 8.3-STABLE #0: Tue May 8 16:15:10 CEST 2012 root@pcadmin.incore:/usr/obj/usr/src/sys/PCADMIN i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz (2141.96-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Family = 6 Model = f Stepping = 6 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100000 AMD Features2=0x1 TSC: P-state invariant If you do need more information, let me know. - -- Alfred Bartsch Data-Service GmbH mailto:bartsch@dssgmbh.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+rdQAACgkQ5QGe2JdVf3iHZACcDnC5FOx+xGCpbal0Bt9LKFSz HO0An028jZdQGxnzkUpOHlKKoV+WPmUN =4tGu -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Thu May 10 08:20:29 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F12D106566B for ; Thu, 10 May 2012 08:20:29 +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 529FD8FC0A for ; Thu, 10 May 2012 08:20:27 +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 LAA02740; Thu, 10 May 2012 11:20:26 +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 1SSObq-0000lz-4L; Thu, 10 May 2012 11:20:26 +0300 Message-ID: <4FAB7A48.4070502@FreeBSD.org> Date: Thu, 10 May 2012 11:20:24 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: Alfred Bartsch References: <4FAA3912.3030801@dssgmbh.de> <4FAA4A11.808@FreeBSD.org> <4FAA5E70.7030508@dssgmbh.de> <4FAA83BD.2030204@FreeBSD.org> <4FAB6A7B.9050500@dssgmbh.de> <4FAB6BE7.9060500@FreeBSD.org> <4FAB7500.7020204@dssgmbh.de> In-Reply-To: <4FAB7500.7020204@dssgmbh.de> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: FreeBSD 8 i386 gptboot corrupt - SOLVED X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 08:20:29 -0000 on 10/05/2012 10:57 Alfred Bartsch said the following: > Am 10.05.2012 09:19, schrieb Andriy Gapon: >> on 10/05/2012 10:12 Alfred Bartsch said the following: >>> I got this stupid idea of a "16k limit" during testing. It was >>> unobvious to me that the build process in a standard environment (i386) >>> simply produces invalid code. In i386 (32-bit) hardware, we don't use >>> zfs at all, so I can't tell anything about gptzfsboot. For now, >>> modifying /sys/boot/i386/gptboot/Makefile completely solves this actual >>> build problem. >>> >>> IMHO the compiler should always know perfectly well in which hardware >>> environment it runs and for which target environment it produces code. >>> So the build environment should be modified to fix this. I would >>> certainly give it a try, but unfortunately this is far beyond my >>> knowledge. :-( > >> That's an interesting theory. What kind of hardware do you have? Is it >> something non-mainstream or sufficiently old? As far as I can tell, our >> base GCC uses i686 target arch if none is explicitly requested. > > > Our i386 hardware is sufficiently old, and IMHO mainstream, e.g.: Intel > SR1325 with Pentium-4 CPU, 2GB RAM Intel SR2200 with Pentium-III CPU(s), > 2/4 GB RAM, Intel SR2300 with dual XEON, 4 GB RAM > > Even on my desktop (Intel MB DQ965CO, Intel Core2 CPU), this (wrong) > behavior can be reproduced. dmesg output: > > FreeBSD 8.3-STABLE #0: Tue May 8 16:15:10 CEST 2012 > root@pcadmin.incore:/usr/obj/usr/src/sys/PCADMIN i386 Timecounter "i8254" > frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 CPU 6400 @ > 2.13GHz (2141.96-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6f6 > Family = 6 Model = f Stepping = 6 > > Features=0xbfebfbff > > Features2=0xe3bd > AMD Features=0x20100000 AMD Features2=0x1 TSC: P-state > invariant > > If you do need more information, let me know. This is not too old, indeed. I'd say relatively modern :-) You said that in some cases you were getting BTX error messages. Could you please get a screen capture of that (e.g. with a digital camera)? -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu May 10 09:45:26 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 481D0106566B; Thu, 10 May 2012 09:45:26 +0000 (UTC) (envelope-from bartsch@dssgmbh.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id B115E8FC12; Thu, 10 May 2012 09:45:24 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 7DE395C9CD; Thu, 10 May 2012 11:45:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id HNMycMOc3Ut3; Thu, 10 May 2012 11:45:21 +0200 (CEST) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 1D49E5C9C7; Thu, 10 May 2012 11:45:21 +0200 (CEST) Received: from pcadmin.incore (pcadmin.incore [192.168.0.140]) by mail.incore (Postfix) with ESMTPSA id 1129B4508A; Thu, 10 May 2012 11:45:21 +0200 (CEST) Message-ID: <4FAB8E2F.2040301@dssgmbh.de> Date: Thu, 10 May 2012 11:45:19 +0200 From: Alfred Bartsch User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:7.0.1) Gecko/20111007 Thunderbird/7.0.1 MIME-Version: 1.0 To: Andriy Gapon References: <4FAA3912.3030801@dssgmbh.de> <4FAA4A11.808@FreeBSD.org> <4FAA5E70.7030508@dssgmbh.de> <4FAA83BD.2030204@FreeBSD.org> <4FAB6A7B.9050500@dssgmbh.de> <4FAB6BE7.9060500@FreeBSD.org> <4FAB7500.7020204@dssgmbh.de> <4FAB7A48.4070502@FreeBSD.org> In-Reply-To: <4FAB7A48.4070502@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: multipart/mixed; boundary="------------080703060408030908070205" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@FreeBSD.org Subject: Re: FreeBSD 8 i386 gptboot corrupt - SOLVED X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 09:45:26 -0000 This is a multi-part message in MIME format. --------------080703060408030908070205 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 10.05.2012 10:20, schrieb Andriy Gapon: > on 10/05/2012 10:57 Alfred Bartsch said the following: >> Am 10.05.2012 09:19, schrieb Andriy Gapon: >>> on 10/05/2012 10:12 Alfred Bartsch said the following: >>>> I got this stupid idea of a "16k limit" during testing. It >>>> was unobvious to me that the build process in a standard >>>> environment (i386) simply produces invalid code. In i386 >>>> (32-bit) hardware, we don't use zfs at all, so I can't tell >>>> anything about gptzfsboot. For now, modifying >>>> /sys/boot/i386/gptboot/Makefile completely solves this >>>> actual build problem. >>>> >>>> IMHO the compiler should always know perfectly well in which >>>> hardware environment it runs and for which target environment >>>> it produces code. So the build environment should be modified >>>> to fix this. I would certainly give it a try, but >>>> unfortunately this is far beyond my knowledge. :-( >> >>> That's an interesting theory. What kind of hardware do you >>> have? Is it something non-mainstream or sufficiently old? As >>> far as I can tell, our base GCC uses i686 target arch if none >>> is explicitly requested. >> >> >> Our i386 hardware is sufficiently old, and IMHO mainstream, e.g.: >> Intel SR1325 with Pentium-4 CPU, 2GB RAM Intel SR2200 with >> Pentium-III CPU(s), 2/4 GB RAM, Intel SR2300 with dual XEON, 4 GB >> RAM >> >> Even on my desktop (Intel MB DQ965CO, Intel Core2 CPU), this >> (wrong) behavior can be reproduced. dmesg output: >> >> FreeBSD 8.3-STABLE #0: Tue May 8 16:15:10 CEST 2012 >> root@pcadmin.incore:/usr/obj/usr/src/sys/PCADMIN i386 Timecounter >> "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 >> CPU 6400 @ 2.13GHz (2141.96-MHz 686-class CPU) Origin = >> "GenuineIntel" Id = 0x6f6 Family = 6 Model = f Stepping = 6 >> >> Features=0xbfebfbff >> >> >> Features2=0xe3bd >> AMD Features=0x20100000 AMD Features2=0x1 TSC: >> P-state invariant >> >> If you do need more information, let me know. > > This is not too old, indeed. I'd say relatively modern :-) You > said that in some cases you were getting BTX error messages. Could > you please get a screen capture of that (e.g. with a digital > camera)? > Sure, A png file is attached. BTW: The BTX error only occurs on Intel SR2200 hardware, as far as I could test. - -- Alfred Bartsch Data-Service GmbH mailto:bartsch@dssgmbh.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+rji8ACgkQ5QGe2JdVf3gyVgCgnAtndM05jFN70z8cn6LgiBYK p+YAnR0ae+T2/oUiECbYiMbIuD08UB8m =Jere -----END PGP SIGNATURE----- --------------080703060408030908070205-- From owner-freebsd-stable@FreeBSD.ORG Thu May 10 15:24:38 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 36BBD106566B for ; Thu, 10 May 2012 15:24:38 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 083438FC1A for ; Thu, 10 May 2012 15:24:38 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so2388282pbb.13 for ; Thu, 10 May 2012 08:24:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=fn1ZT9bUIsiCKg0HFNT1wyLdzuE3+7zmkfsUUeDRmcg=; b=SXYW4uumAlLaMQrXYcfYbjMm2YFBH98HJSxM/yN0RISGXduQ+IOLGcg0bESPDqcgNi oBon48uwPcr101+slt2FsPZXyaq5cnrjW9zjBUfFuzBQS8ljMfkl+2rbnK/7k/5gIIEL mclxAXPmBmHDCL/2ULVAE2jRoc2YBbquYqrpXytCgbZx6YBl3/PzzMMt7L3CH4l4Rd7K vYCI4KssZJwe7LTCKV1dOrE1QVNPYbwmoBNNuwnF1arIQYlr5k7fxaipVwLo1bAJqgg8 snDk8Ksxc4bh5+l4mfDsBw9/RhjEvqiuvGWWN2AR/rwcuwmi1Cp41sL9zgEfcIs5v99a o6Uw== MIME-Version: 1.0 Received: by 10.68.225.104 with SMTP id rj8mr21062951pbc.135.1336663477572; Thu, 10 May 2012 08:24:37 -0700 (PDT) Received: by 10.68.63.199 with HTTP; Thu, 10 May 2012 08:24:37 -0700 (PDT) In-Reply-To: References: <4FAAAF8E.40007@greatbaysoftware.com> Date: Thu, 10 May 2012 10:24:37 -0500 Message-ID: From: Alan Cox To: Adam Vande More Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Charles Owens , freebsd-stable@freebsd.org Subject: Re: superpages not solving "PV entries" limit warning X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alc@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 15:24:38 -0000 On Thu, May 10, 2012 at 2:32 AM, Adam Vande More wrote: > On Wed, May 9, 2012 at 12:55 PM, Charles Owens > wrote: > > > Hi fellow BSD-types, > > > > I have a buy system that forks lots of processes and I see repeatedly the > > message: "Approaching the limit on PV entries, consider increasing > either > > the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max tunable". > > > > System details: > > > > * 8.1-RELEASE-p2 i386 PAE kernel > > * 6 GB RAM > > > > The warning is not applicable any longer including your version as well as > several previous ones. The warning has been removed from current releases. > > For amd64, yes, but not i386. It can't be removed from i386. Alan From owner-freebsd-stable@FreeBSD.ORG Thu May 10 15:52: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 3B7A9106564A; Thu, 10 May 2012 15:52:36 +0000 (UTC) (envelope-from cowens@greatbaysoftware.com) Received: from ecbiz102.inmotionhosting.com (ecbiz102.inmotionhosting.com [70.39.235.94]) by mx1.freebsd.org (Postfix) with ESMTP id E6F378FC08; Thu, 10 May 2012 15:52:35 +0000 (UTC) Received: from 173-14-128-81-newengland.hfc.comcastbusiness.net ([173.14.128.81]:59327 helo=jack.bspruce.com) by ecbiz102.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SSVfN-0001Z8-I1; Thu, 10 May 2012 11:52:33 -0400 Message-ID: <4FABE440.5000100@greatbaysoftware.com> Date: Thu, 10 May 2012 11:52:32 -0400 From: Charles Owens Organization: Great Bay Software User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: alc@freebsd.org References: <4FAAAF8E.40007@greatbaysoftware.com> In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz102.inmotionhosting.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - greatbaysoftware.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Adam Vande More , Alan Cox , freebsd-stable@freebsd.org Subject: Re: superpages not solving "PV entries" limit warning X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 15:52:36 -0000 That's very helpful! I had read about that and wondered if it applied to i386. Should I have expected "superpages" to completely cure the condition... or does it just help? Should I now be looking at tuning the related pmap sysctls to give further relief? Thanks! Charles On 5/10/12 11:24 AM, Alan Cox wrote: > On Thu, May 10, 2012 at 2:32 AM, Adam Vande More > > wrote: > > On Wed, May 9, 2012 at 12:55 PM, Charles Owens > >wrote: > > > Hi fellow BSD-types, > > > > I have a buy system that forks lots of processes and I see > repeatedly the > > message: "Approaching the limit on PV entries, consider > increasing either > > the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max tunable". > > > > System details: > > > > * 8.1-RELEASE-p2 i386 PAE kernel > > * 6 GB RAM > > > > The warning is not applicable any longer including your version as > well as > several previous ones. The warning has been removed from current > releases. > > > For amd64, yes, but not i386. It can't be removed from i386. > > Alan > > > From owner-freebsd-stable@FreeBSD.ORG Thu May 10 16:37:10 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 641CB106566C for ; Thu, 10 May 2012 16:37:10 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3315A8FC14 for ; Thu, 10 May 2012 16:37:10 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so2481424pbb.13 for ; Thu, 10 May 2012 09:37:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=0kP9EEiI41e+nrGvrhYNEbSZuGw/o3EbnffnxtES7OE=; b=iUWRa8CgW/KU44oQQkh3Tiwa8NOCZvzCkL41wWEJyio+/vXZJZqbNaUWqt5lNgM7Na TGGgXGR3HC8gVoYR2NITk2KbucpPZ3K0qUdNkmL4I5ScnFCnB69s3fWr2nEo1iGoe68Q ZDUbPEvd8horBNZf/23DYD73BiF+poXp4FZq7CYN32UwH/sJNOg+b30XMTr+lqyXP2fG UrNyy4TebQGDeAwgvvO/Qx2fVv2OTZu8weNWXqw7oFJbqXzKlMjyL24sVMAuf4eR/0Rr fW5sbtdxi85veqbVVxJTYxTKkbT1E2R1983o3g2O9arz+3vwSCyI3oiN5wW4bZNplvAK ZLSw== MIME-Version: 1.0 Received: by 10.68.190.7 with SMTP id gm7mr21443739pbc.156.1336667828217; Thu, 10 May 2012 09:37:08 -0700 (PDT) Received: by 10.68.63.199 with HTTP; Thu, 10 May 2012 09:37:08 -0700 (PDT) In-Reply-To: <4FABE440.5000100@greatbaysoftware.com> References: <4FAAAF8E.40007@greatbaysoftware.com> <4FABE440.5000100@greatbaysoftware.com> Date: Thu, 10 May 2012 11:37:08 -0500 Message-ID: From: Alan Cox To: Charles Owens Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Adam Vande More , freebsd-stable@freebsd.org Subject: Re: superpages not solving "PV entries" limit warning X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alc@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 16:37:10 -0000 On Thu, May 10, 2012 at 10:52 AM, Charles Owens wrote: > That's very helpful! I had read about that and wondered if it applied to > i386. > > Should I have expected "superpages" to completely cure the condition... or > does it just help? Should I now be looking at tuning the related pmap > sysctls to give further relief? > > Superpages won't cure the problem due to the nature of your workload. After a fork, writes to portions of the address space that are both superpages and copy-on-write will trigger demotion, or re-instantiation of the 4KB page granularity PV entries. Ultimately, repromotion to superpages may occur, but in the meantime, your peak usage of PV entries is only slightly reduced. The bottom line is that you'll need to resort to tuning. Alan From owner-freebsd-stable@FreeBSD.ORG Thu May 10 18:33: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 EAE36106566C; Thu, 10 May 2012 18:33:17 +0000 (UTC) (envelope-from cowens@greatbaysoftware.com) Received: from ecbiz102.inmotionhosting.com (ecbiz102.inmotionhosting.com [70.39.235.94]) by mx1.freebsd.org (Postfix) with ESMTP id 99FB18FC17; Thu, 10 May 2012 18:33:17 +0000 (UTC) Received: from c-50-136-23-27.hsd1.nh.comcast.net ([50.136.23.27]:56559 helo=jack.bspruce.com) by ecbiz102.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SSYAr-0003Ax-RR; Thu, 10 May 2012 14:33:13 -0400 Message-ID: <4FAC09E8.8050309@greatbaysoftware.com> Date: Thu, 10 May 2012 14:33:12 -0400 From: Charles Owens Organization: Great Bay Software User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: alc@freebsd.org References: <4FAAAF8E.40007@greatbaysoftware.com> <4FABE440.5000100@greatbaysoftware.com> In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz102.inmotionhosting.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - greatbaysoftware.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Adam Vande More , Alan Cox , freebsd-stable@freebsd.org Subject: Re: superpages not solving "PV entries" limit warning X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 18:33:18 -0000 On 5/10/12 12:37 PM, Alan Cox wrote: > On Thu, May 10, 2012 at 10:52 AM, Charles Owens > > wrote: > > That's very helpful! I had read about that and wondered if it > applied to i386. > > Should I have expected "superpages" to completely cure the > condition... or does it just help? Should I now be looking at > tuning the related pmap sysctls to give further relief? > > > Superpages won't cure the problem due to the nature of your workload. > After a fork, writes to portions of the address space that are both > superpages and copy-on-write will trigger demotion, or > re-instantiation of the 4KB page granularity PV entries. Ultimately, > repromotion to superpages may occur, but in the meantime, your peak > usage of PV entries is only slightly reduced. > > The bottom line is that you'll need to resort to tuning. > > Alan Ok. Very good. Lastly, since we're talking about this (for the future) -- is enabling of superpages generally recommended for amd64? Thanks, Charles From owner-freebsd-stable@FreeBSD.ORG Thu May 10 19:39: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 AFA3E106564A for ; Thu, 10 May 2012 19:39:20 +0000 (UTC) (envelope-from jeff+freebsd@wagsky.com) Received: from smtp.wagsky.com (wildside.wagsky.com [75.101.96.15]) by mx1.freebsd.org (Postfix) with ESMTP id 868D58FC08 for ; Thu, 10 May 2012 19:39:20 +0000 (UTC) Received: from [192.168.6.7] (port7.pn.wagsky.com [192.168.6.7]) by mailgw.pn.wagsky.com (Postfix) with ESMTP id 4D88061C2B; Thu, 10 May 2012 12:39:18 -0700 (PDT) Message-ID: <4FAC1965.7070800@wagsky.com> Date: Thu, 10 May 2012 12:39:17 -0700 From: Jeff Kletsky User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Two build problems -- "make memstick" and "make release" with -DWITHOUT_CLANG X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 19:39:20 -0000 I'm trying to do bisection to locate when a specific bug appeared and can replicate the issue when I boot from a memstick and use the LiveCD option. This keeps any questions of "upgrade or install" out of the picture. Unfortunately, I've run into a couple problems. After reading the new build(7) and release(7) information, I built everything locally then tried # cd /usr/src/release # make memstick At first, I attributed the hours of 100% CPU time for bsdtar to my reasonably slow Atom 330 box. After a day, I decided that wasn't the issue. Looking at the results, the files were being put in /usr/src/release, not under /usr/obj/ somewhere, as I would have expected. I believe that the process encountered a filesystem loop when copying the source for the memstick. If you look at the output of the make process, the first few lines are: mkdir /usr/src/release/dist mkdir /usr/src/release/dist mkdir -p /usr/src/release/dist/usr cd /usr/src/release/.. && make TARGET_ARCH=amd64 TARGET=amd64 distributeworld DISTDIR=/usr/src/release/dist mkdir -p /usr/src/release/dist/usr mkdir: /usr/src/release/dist: File exists cd /usr/src/release/.. && make TARGET_ARCH=amd64 TARGET=amd64 distributekernel packagekernel DISTDIR=/usr/src/release/dist ln -fs /usr/ports /usr/src/release/dist/usr/ports ln -fs /usr/src/release/.. /usr/src/release/dist/usr/src It looks like that last ln -fs creates a loop, which eventually results in tar output of: a usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/sys/dev/e1000/e1000_osdep.c a usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/sys/dev/e1000/e1000_osdep.h Running # cd /usr/src/release # make -n -p memstick indicates that .OBJDIR is set to /usr/src/release (and is set to /usr/obj/usr/src when make is executed in /usr/src). # cd /usr/src # make memstick tells me that "memstick" isn't a recognized target. I've tried setting MAKEOBJDIR in the environment, but that didn't change the value of .OBJDIR reported by make. So that is question #1 -- How can I build a memstick from an already-compiled tree? === I can successfully # cd /usr/src/release # ./generate_release.sh stable/9 /usr/release/stable-9 or the like, but a build with clang enabled takes me close to three hours. Since the issue isn't clang-related, I'd like to be able to build without clang to the point of having a bootable memstick. release(7) suggests that the environment variable MAKE_FLAGS could be used to pass flags, however # cd /usr/src/release # export MAKE_FLAGS='-DWITHOUT_CLANG' # ./generate_release.sh stable/9@226702 /usr/release/stable-9 ends up failing. >>> World build started on Wed May 9 06:59:00 PDT 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims [...] Checked out revision 226702. -------------------------------------------------------------- >>> World build started on Wed May 9 08:15:36 PDT 2012 -------------------------------------------------------------- -------------------------------------------------------------- >>> Rebuilding the temporary build tree -------------------------------------------------------------- rm -rf /usr/obj/usr/release/226702/usr/src/tmp rm -rf /usr/obj/usr/release/226702/usr/src/lib32 [...] >>> World build completed on Wed May 9 09:40:48 PDT 2012 >>> Making hierarchy >>> Installing everything starts off nicely, but then eventually dies with ===> usr.bin/clang (install) ===> usr.bin/clang/clang (install) install -s -o root -g wheel -m 555 clang /usr/release/226702/usr/bin install: clang: No such file or directory *** Error code 71 (plus the remaining errors up the chain) I'm guessing that -DWITHOUT_CLANG isn't being passed to the installworld process. Which leads to the second question -- how can I "clean-build" a memstick (or ISO) without having to build clang? While I understand the need to get clang vetted out, for the purposes of bisection, cutting an hour or two off of each of my builds is very desirable. Thanks! Jeff From owner-freebsd-stable@FreeBSD.ORG Fri May 11 03:30: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 87FE1106566B for ; Fri, 11 May 2012 03:30:30 +0000 (UTC) (envelope-from ctuffli@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 146798FC08 for ; Fri, 11 May 2012 03:30:29 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so2158767wgb.31 for ; Thu, 10 May 2012 20:30:29 -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=uxXxtTv2V7uOxDs3NzL5smCn3yZKTcG4E/d9GCxtnPw=; b=ZZVMZ/KNk9sDF3TtiV89+WcqyRwJP5I89aO9YZ+skP1lvZ6F8ZtZjol/1NNJelSRHT /FZivo1Xy06gDxQKgO3j8fQfurV4W1kZK7YXVu0LxnZua8zW8E8+BflibrovTdKaODDd PI8VgR4sJdwudGOey9aPaLstXeIeGiuK6wZelh51B6JwkguevVhiVxNCBgrKQzwhtR9B tt1jVRmDAK+8pJmR2U7sHIDOZZ/2p9c4Ud16I73C9nQE3koaj9CYCSjFtae5BVQHrsMv GTtI+MlaTwiWt/oSJWSepwxg7BWn5Y8fjlCB5Ey8Hh0qxJV3U9eNIZHwSeHoCC/cjiZL +TZg== MIME-Version: 1.0 Received: by 10.216.142.38 with SMTP id h38mr420353wej.54.1336707029173; Thu, 10 May 2012 20:30:29 -0700 (PDT) Received: by 10.216.46.85 with HTTP; Thu, 10 May 2012 20:30:29 -0700 (PDT) In-Reply-To: <4FAC1965.7070800@wagsky.com> References: <4FAC1965.7070800@wagsky.com> Date: Thu, 10 May 2012 20:30:29 -0700 Message-ID: From: Chuck Tuffli To: Jeff Kletsky Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: Two build problems -- "make memstick" and "make release" with -DWITHOUT_CLANG X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 03:30:30 -0000 On Thu, May 10, 2012 at 12:39 PM, Jeff Kletsky wrote: > I'm trying to do bisection to locate when a specific bug appeared and can > replicate the issue when I boot from a memstick and use the LiveCD option. > This keeps any questions of "upgrade or install" out of the picture. ... > It looks like that last ln -fs creates a loop, which eventually results in > tar output of: I've run into this before but assumed it was due to building outside of /usr/src For me, the one reliable way of building the memstick + iso has been env MAKEOBJDIRPREFIX=../obj make DISTDIR=../R release HTH ---chuck From owner-freebsd-stable@FreeBSD.ORG Fri May 11 06:37:22 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 8755C106564A; Fri, 11 May 2012 06:37:22 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 28FA08FC18; Fri, 11 May 2012 06:37:20 +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 JAA13450; Fri, 11 May 2012 09:37: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 1SSjTU-00049u-Gh; Fri, 11 May 2012 09:37:12 +0300 Message-ID: <4FACB396.6060800@FreeBSD.org> Date: Fri, 11 May 2012 09:37:10 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: Alfred Bartsch References: <4FAA3912.3030801@dssgmbh.de> <4FAA4A11.808@FreeBSD.org> <4FAA5E70.7030508@dssgmbh.de> In-Reply-To: <4FAA5E70.7030508@dssgmbh.de> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org, John Baldwin Subject: i386 -march=xxx behavior [Was: FreeBSD 8 i386 gptboot corrupt - SOLVED] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 06:37:22 -0000 on 09/05/2012 15:09 Alfred Bartsch said the following: > Am 09.05.2012 12:42, schrieb Andriy Gapon: >> on 09/05/2012 12:29 Alfred Bartsch said the following: >>> This behavior is restricted to 32-bit servers (i386), all 64-bit >>> servers (amd64) work without any problem, as expected. >>> >>> After some analyzing, it seems to me that the actual size of gptboot >>> does matter (16723 bytes, >16kB). In amd64 environment (same source >>> version) the actual size of /boot/gptboot is only 15443 bytes. > >> Weird. Both amd64 and i386 builds should produce the same binaries as >> the boot code is built with -m32 -march=i386 on amd64. But I can >> reproduce this, so it seems that the compilation is indeed done >> differently. > >> Heh, it seems that it is -march=i386 flag that makes all the difference. >> Maybe we should use this flag even when doing native i386 builds... > > > after adding "-march=i386" to CFLAGS in Makefile everything looks ok > (filesize: 15443, as you predicted), so I would opt for using this flag in > the future. Here is a small investigation into the -march flag. Not sure if it is of any practical significance, I just was curious. First, seems that neither of i386/i486/i586/i686 values for this flag nor absence of it implies features like MMX, SSE, and so on. (Saying this because of some assumptions about i686) For the base GCC specifying -march with the above values is equivalent to specifying -mtune with the same values, when mtune is not explicitly set. Using "i686" or omitting the flag is equivalent to -mtune=generic. Note that this happens despite a FreeBSD-specific change to (base) GCC that makes i486 a default arch. Derivation of the tune value from the arch value, if any, or defaulting it otherwise is done earlier than defaulting of the arch value. Specifically I am talking about the block that deals with ix86_tune_string that precedes the block for ix86_arch_string. So it seems that at the moment our sys/boot code is effectively compiled with -mtune=generic for i386 target (amd64 target has an explicit -march=i386 - I wonder why not i486). I think that in terms of instructions repertoire the difference is only in availability of cmpxchg, cmpxchg8b, and xadd instructions (ignoring the "system" instructions that should not be generated by a compiler from C code). And I guess that the sys/boot code is simple enough to not require these instructions? Otherwise, mtune seems to affect layout of the generated code and preference for some instructions over others. Again, not sure what conclusions can be made... -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri May 11 06:42: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 9D997106566C for ; Fri, 11 May 2012 06:42:06 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E03848FC0A for ; Fri, 11 May 2012 06:42:05 +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 JAA13490; Fri, 11 May 2012 09:42:04 +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 1SSjYB-0004A0-QF; Fri, 11 May 2012 09:42:03 +0300 Message-ID: <4FACB4BB.1000008@FreeBSD.org> Date: Fri, 11 May 2012 09:42:03 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: Alfred Bartsch References: <4FAA3912.3030801@dssgmbh.de> <4FAA4A11.808@FreeBSD.org> <4FAA5E70.7030508@dssgmbh.de> <4FAA83BD.2030204@FreeBSD.org> <4FAB6A7B.9050500@dssgmbh.de> <4FAB6BE7.9060500@FreeBSD.org> <4FAB7500.7020204@dssgmbh.de> In-Reply-To: <4FAB7500.7020204@dssgmbh.de> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: FreeBSD 8 i386 gptboot corrupt - SOLVED X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 06:42:06 -0000 on 10/05/2012 10:57 Alfred Bartsch said the following: > Our i386 hardware is sufficiently old, and IMHO mainstream, e.g.: Intel > SR1325 with Pentium-4 CPU, 2GB RAM Intel SR2200 with Pentium-III CPU(s), > 2/4 GB RAM, Intel SR2300 with dual XEON, 4 GB RAM > > Even on my desktop (Intel MB DQ965CO, Intel Core2 CPU), this (wrong) > behavior can be reproduced. dmesg output: There is also an interest in what board models and BIOS versions you have there. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri May 11 07:39: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 B3FFD106566B; Fri, 11 May 2012 07:39:42 +0000 (UTC) (envelope-from bartsch@dssgmbh.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id 44C348FC0A; Fri, 11 May 2012 07:39:42 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 6938C5CA34; Fri, 11 May 2012 09:39:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id dLErIfPpdXC9; Fri, 11 May 2012 09:39:38 +0200 (CEST) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 9DCB85CA33; Fri, 11 May 2012 09:39:38 +0200 (CEST) Received: from pcadmin.incore (pcadmin.incore [192.168.0.140]) by mail.incore (Postfix) with ESMTPSA id 98A7745087; Fri, 11 May 2012 09:39:38 +0200 (CEST) Message-ID: <4FACC239.3020609@dssgmbh.de> Date: Fri, 11 May 2012 09:39:37 +0200 From: Alfred Bartsch User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:7.0.1) Gecko/20111007 Thunderbird/7.0.1 MIME-Version: 1.0 To: Andriy Gapon References: <4FAA3912.3030801@dssgmbh.de> <4FAA4A11.808@FreeBSD.org> <4FAA5E70.7030508@dssgmbh.de> <4FAA83BD.2030204@FreeBSD.org> <4FAB6A7B.9050500@dssgmbh.de> <4FAB6BE7.9060500@FreeBSD.org> <4FAB7500.7020204@dssgmbh.de> <4FACB4BB.1000008@FreeBSD.org> In-Reply-To: <4FACB4BB.1000008@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: FreeBSD 8 i386 gptboot corrupt - SOLVED X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 07:39:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 11.05.2012 08:42, schrieb Andriy Gapon: > on 10/05/2012 10:57 Alfred Bartsch said the following: >> Our i386 hardware is sufficiently old, and IMHO mainstream, e.g.: >> Intel SR1325 with Pentium-4 CPU, 2GB RAM Intel SR2200 with >> Pentium-III CPU(s), 2/4 GB RAM, Intel SR2300 with dual XEON, 4 GB >> RAM >> >> Even on my desktop (Intel MB DQ965CO, Intel Core2 CPU), this >> (wrong) behavior can be reproduced. dmesg output: > > There is also an interest in what board models and BIOS versions > you have there. > Here you are (partial output of kenv): 1. Intel SR1325: smbios.bios.reldate="01/26/2006" smbios.bios.vendor="Intel Corporation" smbios.bios.version="SE7210TP10.86B.P.10.00.0042.012620061107" smbios.chassis.maker="Intel Corporation" smbios.chassis.serial="ECKA4190241 " smbios.chassis.tag="0000000000 " smbios.chassis.version="SR1325TP1 " smbios.memory.enabled="2097152" smbios.planar.maker="Intel " smbios.planar.product="SE7210TP1-E " smbios.planar.serial="BZTP41xxxxxx " smbios.planar.version="FRU Ver 0.01 " smbios.socket.enabled="1" smbios.socket.populated="1" smbios.system.maker="Intel " smbios.system.product="SE7210TP1-E " smbios.system.serial="0000000000 " smbios.system.version="1.0 " smbios.version="2.3" 2. Intel SR2200: smbios.bios.reldate="02/04/2003" smbios.bios.vendor="Intel Corporation" smbios.bios.version="SCB20.86B.0077.P22.0302041652 " smbios.chassis.maker=" " smbios.chassis.serial=" " smbios.chassis.tag=" " smbios.chassis.version="SR2200 " smbios.memory.enabled="2097152" smbios.planar.maker="Intel " smbios.planar.product="SCB2S " smbios.planar.serial="KKC22020xxxx " smbios.planar.version="A46044-607 " smbios.socket.enabled="2" smbios.socket.populated="2" smbios.system.maker="Intel " smbios.system.product=" " smbios.system.serial=" " smbios.system.uuid="e42007cf-4106-d611-0080-xxxxxxxxxxxx" smbios.system.version=" " smbios.version="2.3" 3. Intel SR2300: smbios.bios.reldate="01/25/2005" smbios.bios.vendor="Intel Corporation" smbios.bios.version="SWV25.86B.0250.P39.0501252032 " smbios.chassis.maker="Intel Corporation " smbios.chassis.serial=" " smbios.chassis.tag=" " smbios.chassis.version=" " smbios.memory.enabled="4194304" smbios.planar.maker="Intel " smbios.planar.product="SE7501WV2S" smbios.planar.serial="000E0C66Exxxxxx" smbios.planar.version="A99386-112 " smbios.socket.enabled="2" smbios.socket.populated="2" smbios.system.maker="Intel " smbios.system.product=" " smbios.system.serial=" " smbios.system.uuid="6f48ea00-3d14-11d9-bf93-xxxxxxxxxxxx" smbios.system.version=" " smbios.version="2.3" 4. Desktop: smbios.bios.reldate="04/07/2008" smbios.bios.vendor="Intel Corp." smbios.bios.version="CO96510J.54T.0033.2008.0407.2320" smbios.memory.enabled="2097152" smbios.planar.maker="Intel Corporation" smbios.planar.product="DQ965CO" smbios.planar.serial="AZCO6xxxxxxG" smbios.planar.version="AAD46478-501" smbios.socket.enabled="1" smbios.socket.populated="1" smbios.system.maker="MAXDATA" smbios.system.uuid="fec14987-6d67-11db-a763-xxxxxxxxxxxx" smbios.system.version="5123660003" smbios.version="2.4" HTH - -- Alfred Bartsch Data-Service GmbH mailto:bartsch@dssgmbh.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+swjkACgkQ5QGe2JdVf3ip0gCfYP9pcBTjEhnchroKlFG87wco H+YAn3tUYcYd5nLLkizBDAUmZKuLMBpE =VXvj -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri May 11 08:09: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 DDAC91065678; Fri, 11 May 2012 08:09:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 5D7E28FC15; Fri, 11 May 2012 08:09:20 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q4B897UY083402; Fri, 11 May 2012 11:09:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q4B896Zf001200; Fri, 11 May 2012 11:09:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q4B896P4001199; Fri, 11 May 2012 11:09:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 11 May 2012 11:09:06 +0300 From: Konstantin Belousov To: Andriy Gapon Message-ID: <20120511080906.GL2358@deviant.kiev.zoral.com.ua> References: <4FAA3912.3030801@dssgmbh.de> <4FAA4A11.808@FreeBSD.org> <4FAA5E70.7030508@dssgmbh.de> <4FACB396.6060800@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="K7v4p9QsotuTW/oA" Content-Disposition: inline In-Reply-To: <4FACB396.6060800@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-stable@freebsd.org, John Baldwin , Alfred Bartsch Subject: Re: i386 -march=xxx behavior [Was: FreeBSD 8 i386 gptboot corrupt - SOLVED] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 08:09:20 -0000 --K7v4p9QsotuTW/oA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 11, 2012 at 09:37:10AM +0300, Andriy Gapon wrote: > on 09/05/2012 15:09 Alfred Bartsch said the following: > > Am 09.05.2012 12:42, schrieb Andriy Gapon: > >> on 09/05/2012 12:29 Alfred Bartsch said the following: > >>> This behavior is restricted to 32-bit servers (i386), all 64-bit=20 > >>> servers (amd64) work without any problem, as expected. > >>>=20 > >>> After some analyzing, it seems to me that the actual size of gptboot > >>> does matter (16723 bytes, >16kB). In amd64 environment (same source > >>> version) the actual size of /boot/gptboot is only 15443 bytes. > >=20 > >> Weird. Both amd64 and i386 builds should produce the same binaries as > >> the boot code is built with -m32 -march=3Di386 on amd64. But I can=20 > >> reproduce this, so it seems that the compilation is indeed done=20 > >> differently. > >=20 > >> Heh, it seems that it is -march=3Di386 flag that makes all the differe= nce. > >> Maybe we should use this flag even when doing native i386 builds... > >=20 > >=20 > > after adding "-march=3Di386" to CFLAGS in Makefile everything looks ok= =20 > > (filesize: 15443, as you predicted), so I would opt for using this flag= in > > the future. >=20 > Here is a small investigation into the -march flag. Not sure if it is of= any > practical significance, I just was curious. >=20 > First, seems that neither of i386/i486/i586/i686 values for this flag nor > absence of it implies features like MMX, SSE, and so on. (Saying this be= cause > of some assumptions about i686) >=20 > For the base GCC specifying -march with the above values is equivalent to > specifying -mtune with the same values, when mtune is not explicitly set. > Using "i686" or omitting the flag is equivalent to -mtune=3Dgeneric. >=20 > Note that this happens despite a FreeBSD-specific change to (base) GCC th= at > makes i486 a default arch. Derivation of the tune value from the arch va= lue, > if any, or defaulting it otherwise is done earlier than defaulting of the= arch > value. > Specifically I am talking about the block that deals with ix86_tune_string > that precedes the block for ix86_arch_string. >=20 > So it seems that at the moment our sys/boot code is effectively compiled = with > -mtune=3Dgeneric for i386 target (amd64 target has an explicit -march=3Di= 386 - I > wonder why not i486). >=20 > I think that in terms of instructions repertoire the difference is only in > availability of cmpxchg, cmpxchg8b, and xadd instructions (ignoring the > "system" instructions that should not be generated by a compiler from C c= ode). > And I guess that the sys/boot code is simple enough to not require these > instructions? > Otherwise, mtune seems to affect layout of the generated code and prefere= nce > for some instructions over others. >=20 > Again, not sure what conclusions can be made... -march=3Di686 also turns on use of cmov*. --K7v4p9QsotuTW/oA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+sySIACgkQC3+MBN1Mb4jxSgCdFSGMbh8P08s87b4LwDLT19wr KcEAoKcNxpqeL8szwWNSnn9X2tTRZx8R =07m4 -----END PGP SIGNATURE----- --K7v4p9QsotuTW/oA-- From owner-freebsd-stable@FreeBSD.ORG Fri May 11 08:23: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 0DC42106566B; Fri, 11 May 2012 08:23:03 +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 04EFB8FC0A; Fri, 11 May 2012 08:23:01 +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 LAA14374; Fri, 11 May 2012 11:22:59 +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 1SSl7q-0004CL-TP; Fri, 11 May 2012 11:22:58 +0300 Message-ID: <4FACCC61.6030000@FreeBSD.org> Date: Fri, 11 May 2012 11:22:57 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: Konstantin Belousov References: <4FAA3912.3030801@dssgmbh.de> <4FAA4A11.808@FreeBSD.org> <4FAA5E70.7030508@dssgmbh.de> <4FACB396.6060800@FreeBSD.org> <20120511080906.GL2358@deviant.kiev.zoral.com.ua> In-Reply-To: <20120511080906.GL2358@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org, John Baldwin , Alfred Bartsch Subject: Re: i386 -march=xxx behavior X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 08:23:03 -0000 on 11/05/2012 11:09 Konstantin Belousov said the following: > On Fri, May 11, 2012 at 09:37:10AM +0300, Andriy Gapon wrote: >> on 09/05/2012 15:09 Alfred Bartsch said the following: >>> Am 09.05.2012 12:42, schrieb Andriy Gapon: >>>> on 09/05/2012 12:29 Alfred Bartsch said the following: >>>>> This behavior is restricted to 32-bit servers (i386), all 64-bit >>>>> servers (amd64) work without any problem, as expected. >>>>> >>>>> After some analyzing, it seems to me that the actual size of >>>>> gptboot does matter (16723 bytes, >16kB). In amd64 environment >>>>> (same source version) the actual size of /boot/gptboot is only >>>>> 15443 bytes. >>> >>>> Weird. Both amd64 and i386 builds should produce the same binaries >>>> as the boot code is built with -m32 -march=i386 on amd64. But I can >>>> reproduce this, so it seems that the compilation is indeed done >>>> differently. >>> >>>> Heh, it seems that it is -march=i386 flag that makes all the >>>> difference. Maybe we should use this flag even when doing native i386 >>>> builds... >>> >>> >>> after adding "-march=i386" to CFLAGS in Makefile everything looks ok >>> (filesize: 15443, as you predicted), so I would opt for using this flag >>> in the future. >> >> Here is a small investigation into the -march flag. Not sure if it is of >> any practical significance, I just was curious. >> >> First, seems that neither of i386/i486/i586/i686 values for this flag >> nor absence of it implies features like MMX, SSE, and so on. (Saying >> this because of some assumptions about i686) >> >> For the base GCC specifying -march with the above values is equivalent >> to specifying -mtune with the same values, when mtune is not explicitly >> set. Using "i686" or omitting the flag is equivalent to -mtune=generic. >> >> Note that this happens despite a FreeBSD-specific change to (base) GCC >> that makes i486 a default arch. Derivation of the tune value from the >> arch value, if any, or defaulting it otherwise is done earlier than >> defaulting of the arch value. Specifically I am talking about the block >> that deals with ix86_tune_string that precedes the block for >> ix86_arch_string. >> >> So it seems that at the moment our sys/boot code is effectively compiled >> with -mtune=generic for i386 target (amd64 target has an explicit >> -march=i386 - I wonder why not i486). >> >> I think that in terms of instructions repertoire the difference is only >> in availability of cmpxchg, cmpxchg8b, and xadd instructions (ignoring >> the "system" instructions that should not be generated by a compiler from >> C code). And I guess that the sys/boot code is simple enough to not >> require these instructions? Otherwise, mtune seems to affect layout of >> the generated code and preference for some instructions over others. >> >> Again, not sure what conclusions can be made... > > -march=i686 also turns on use of cmov*. So, this is the important thing that I missed. Then, it seems our default gcc behavior is -march=i486 -mtune=generic after all. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri May 11 18:27:33 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 870A0106566C for ; Fri, 11 May 2012 18:27:33 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 451148FC08 for ; Fri, 11 May 2012 18:27:33 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:839:5834:5e28:89f8] (unknown [IPv6:2001:7b8:3a7:0:839:5834:5e28:89f8]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 943425C37; Fri, 11 May 2012 20:27:32 +0200 (CEST) Message-ID: <4FAD5A17.1020200@FreeBSD.org> Date: Fri, 11 May 2012 20:27:35 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120425 Thunderbird/13.0 MIME-Version: 1.0 To: Jeff Kletsky References: <4FAC1965.7070800@wagsky.com> In-Reply-To: <4FAC1965.7070800@wagsky.com> X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Two build problems -- "make memstick" and "make release" with -DWITHOUT_CLANG X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 18:27:33 -0000 On 2012-05-10 21:39, Jeff Kletsky wrote: > I'm trying to do bisection to locate when a specific bug appeared and > can replicate the issue when I boot from a memstick and use the LiveCD > option. This keeps any questions of "upgrade or install" out of the picture. ... > or the like, but a build with clang enabled takes me close to three > hours. Since the issue isn't clang-related, I'd like to be able to build > without clang to the point of having a bootable memstick. release(7) > suggests that the environment variable MAKE_FLAGS could be used to pass > flags, however > > # cd /usr/src/release > # export MAKE_FLAGS='-DWITHOUT_CLANG' > # ./generate_release.sh stable/9@226702 /usr/release/stable-9 ... > starts off nicely, but then eventually dies with > > ===> usr.bin/clang (install) > ===> usr.bin/clang/clang (install) > install -s -o root -g wheel -m 555 clang /usr/release/226702/usr/bin > install: clang: No such file or directory > *** Error code 71 Try putting WITHOUT_CLANG= in your /etc/src.conf instead. I tried a generate-release.sh with just that in my src.conf (and no make.conf), and it just completed successfully. I don't think it is safe to pass WITH_ and WITHOUT_ settings via MAKE_FLAGS, at least not for this particular case. From owner-freebsd-stable@FreeBSD.ORG Fri May 11 20:39: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 BA124106564A for ; Fri, 11 May 2012 20:39:03 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 926CC8FC1F for ; Fri, 11 May 2012 20:39:03 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so4317547pbb.13 for ; Fri, 11 May 2012 13:39:03 -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=hBqttApeKCyIESIGLyjc8rnPqYlx0jl0lcIWxaKWRwY=; b=HpqCx4BaAVztiyOwCxLxxSk2UNid3RsQeAgv4x/8WOvyWqs4HSkSa1xQO4FadwjRlt ujfE3NON/G1MExC1W1+pNnDyge+C2UI7RMBBixGUHOKDYtmx9R6w8toE2PNPMBA8ZjP7 YbQhBdMNNWlhMdi77Tv+50tJmKZy7J0D3ru395duXu6kZBptC7imRg5STtROHVxTGirS FcU4LTq/QdzsB/cN7B7EMy2R6LLkqVzZBfdmnOkZvyvVLdFiTrfsOeQWwLM26/AQwC6h S1HMzqhDOyPqdezp7O1eMI6Kn5IxyZmyVpsLGHxSjzQn2+kKSM12zka9S/NflFmXuY+o gEdg== MIME-Version: 1.0 Received: by 10.68.138.135 with SMTP id qq7mr13599051pbb.124.1336768742969; Fri, 11 May 2012 13:39:02 -0700 (PDT) Received: by 10.68.200.66 with HTTP; Fri, 11 May 2012 13:39:02 -0700 (PDT) Date: Fri, 11 May 2012 13:39:02 -0700 Message-ID: From: Kevin Oberman To: "freebsd-stable@freebsd.org Stable" Content-Type: text/plain; charset=ISO-8859-1 Subject: 9.0-RELEASE hangs on probe of CD on upgraded 9.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 20:39:03 -0000 I just tried to upgrade my 8-STABLE system to 9.0. Upgrade went fine until I tried to boot the new kernel. It froze after probing the SCSI disks (da0). Further testing shows that it was the CD that was causing the problem. When I disconnect the DVD/CD, the kernel boots fine. The system is a SuperMicro C25BX mother board. The DVD is PATA, reported on boot (of 8-Stable) as: acd0: DVDR at ata2-master UDMA66 I seem to recall seeing a thread on this a while back on current, but I don't seem to find it, now. Any ideas of how to get around this? Perhaps I need to update to STABLE? -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Sat May 12 21:38:30 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 57FB21065670; Sat, 12 May 2012 21:38:30 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3F60E8FC17; Sat, 12 May 2012 21:38:30 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q4CLcUH7006019; Sat, 12 May 2012 21:38:30 GMT (envelope-from danger@freefall.freebsd.org) Received: (from danger@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q4CLcUqs006017; Sat, 12 May 2012 21:38:30 GMT (envelope-from danger) Date: Sat, 12 May 2012 21:38:30 +0000 From: Daniel Gerzo To: hackers@freebsd.org Message-ID: <20120512213829.GA5893@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org, current@freebsd.org Subject: FreeBSD Quarterly Status Report January-March, 2012 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: monthly@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2012 21:38:30 -0000 FreeBSD Quarterly Status Report January-March, 2012 Introduction This report covers FreeBSD-related projects between January and March 2012. It is the first of the four reports planned for 2012. This quarter was highlighted by releasing the next major version of FreeBSD, 9.0, which was finally released in the beginning of January 2012. The FreeBSD Project dedicates the FreeBSD 9.0-RELEASE to the memory of Dennis M. Ritchie, one of the founding fathers of the UNIXŽ operating system. Our release engineering team has been also busy with preparation of the 8.3-RELEASE, which was publicly announced in April. Thanks to all the reporters for the excellent work! This report contains 27 entries and we hope you enjoy reading it. Please note that the deadline for submissions covering the period between April and June 2012 is July 15th, 2012. __________________________________________________________________ Projects * FreeBSD Services Control * GNU-Free C++11 Stack * Growing filesystems online * The FreeNAS Project User-land Programs * Clang Replacing GCC in the Base System * Replacing the Regular Expression Code * The bsdconfig(8) utility FreeBSD Team Reports * Release Engineering Team Status Report * The FreeBSD Foundation Team Report Kernel * DTrace Probes for the linuxulator * HDMI/DisplayPort Audio Support in HDA Sound Driver (snd_hda) * Improved hwpmc(9) Support for MIPS * isci(4) SAS Driver Network Infrastructure * Atheros 802.11n Support * IPv6 Performance Analysis * Multi-FIB: IPv6 Support and Other Enhancements Documentation * The FreeBSD Japanese Documentation Project Architectures * FreeBSD/arm on Various TI Boards * FreeBSD/powerpc on Freescale QorIQ DPAA * NAND File System, NAND Flash Framework, NAND Simulator * Porting DTrace to MIPS and ARM Ports * A New linux_base Port Based Upon CentOS * BSD-licensed sort Utility (GNU sort Replacement) * KDE/FreeBSD * Perl Ports Testing * The FreeBSD Haskell Ports * The FreeBSD Ports Collection __________________________________________________________________ A New linux_base Port Based Upon CentOS Contact: Alexander Leidinger We got a PR with a linux_based port which is based upon CentOS 6. Currently this can only be used as a test environment, as it depends upon a more recent linux kernel version, than the linuxulator provides. As of this writing, I'm in the process of preparing a commit of this port. Open tasks: 1. Repocopy by portmgr. 2. Add conflicts in other linux_base ports. 3. Commit the CentOS based one. 4. Some cleanup. __________________________________________________________________ Atheros 802.11n Support URL: http://wiki.FreeBSD.org/AdrianChadd/AtherosTxAgg URL: http://wiki.FreeBSD.org/dev/ath(4) Contact: Adrian Chadd 802.11n station and hostap support is now fully functional, sans correct hostap side power saving. TX aggregation and TX BAR handling is implemented. Station chip power saving is not implemented at all yet, it's not in the scope of this work. Testers should disable bgscan (-bgscan) as scan/bgscan will simply drop any traffic in the TX/RX queues, causing potential traffic stalls. Open tasks: 1. Fix up hostap side power save handling. 2. Implement filtered frames support in the driver. 3. Fix scan/bgscan to correctly buffer and retransmit frames when going off channel, so frames are not just "dropped" - this causes issues in the aggregation sessions and may cause traffic stalls. 4. Test/fix any issues with adhoc 802.11n support. __________________________________________________________________ BSD-licensed sort Utility (GNU sort Replacement) URL: http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/textproc/bsdsort/ URL: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sort.html Contact: Oleg Moskalenko Contact: Gábor Kövesdán Currently the BSD sort reached usable stable stage. It is stable, it is as fast as the GNU sort, and it supports multi-byte locales (this is something that GNU sort does not do correctly). BSD sort has all features of GNU sort 5.3.0 (version included into FreeBSD) with some extra features and bug fixes. Open tasks: 1. Add BSD sort into HEAD as an alternative, installed as bsdsort. If proven to work as expected, change it to the default sort version and remove GNU sort. 2. Investigate the possibility of a multi-threaded sort implementation and implement it, if it proves more efficient. 3. Upgrade BSD sort features to include some obscure new features in the latest GNU sort version 8.15. __________________________________________________________________ Clang Replacing GCC in the Base System URL: http://wiki.FreeBSD.org/BuildingFreeBSDWithClang Contact: Brooks Davis Contact: David Chisnall Contact: Dimitry Andric Contact: Ed Schouten Contact: Pawel Worach Contact: Roman Divacky Both FreeBSD 10.0-CURRENT and 9.0-STABLE now have Clang 3.0 release installed by default. At least on 10.0-CURRENT, both world and the GENERIC kernel can be completely built without any -Werror warnings. This may not be the case for all custom kernel configurations yet. As of r231057, there is a WITH_CLANG_EXTRAS option for src.conf(5), which will enable a number of additional LLVM and Clang tools, such as 'llc' and 'opt'. These tools are mainly useful for people that want to manipulate LLVM bitcode (.bc) and LLVM assembly language (.ll) files, or want to tinker with LLVM and Clang themselves. Also, as of r232322, there is a WITH_CLANG_IS_CC option for src.conf(5), which will install Clang as /usr/bin/cc, /usr/bin/c++ and /usr/bin/cpp, making it the default system compiler. Unless you also use the WITHOUT_GCC option, gcc will still be available as /usr/bin/gcc, /usr/bin/g++ and /usr/bin/gcpp. The intent is to switch on this option by default rather sooner than later, so we can start preparing for shipping 10.0-RELEASE with Clang as as the default system compiler, and deprecating gcc. In other news, we will import a newer snapshot of Clang soon, since upstream LLVM/Clang has already announced their 3.1 release will be branched April 16, 2012. Most likely, the actual 3.1 release will be follow a few weeks later, after which we will do another import. Last but not least, there are many ports people working on making our ports compile properly with Clang. Fixes are checked in on a very regular basis now, and full exp-runs with Clang are also done fairly regularly. Of course, there are always a few difficult cases, especially with very old software that will not even compile with newer versions of gcc, let alone clang. Open tasks: 1. One of the most important tasks at the moment is to actually build and run your entire FreeBSD system with Clang, as much as possible. Any compile-time or run-time problems should be reported to the appropriate mailing list, or filed as a PR. If you have patches and/or workarounds, that would be even better. 2. Clang should have gotten better support for cross-compiling after 3.0, so as soon as a 3.1 version is imported, we will need to look at ways to get the FreeBSD world and kernels to cross-compile. This is mainly of use for ARM and MIPS, which are architectures you usually do not want to build natively on. 3. Help to make unwilling ports build with Clang is always needed, and greatly appreciated. Please mail the maintainer of your favorite port with patches, or file PRs. __________________________________________________________________ DTrace Probes for the linuxulator Contact: Alexander Leidinger Recently DTrace in the kernel was improved to be able to load kernel modules with static dtrace providers after the dtrace modules. This allows me to commit my linuxulator specific static provider work to -CURRENT. Together with the linuxulator DTrace probes I developed some D scripts to check various code paths in the linuxulator. Those scripts check various error cases which may be interesting to verify userland code, but also linuxulator internals like locks. As of this writing I'm in the process of updating a test machine to a more recent -current to prepare the commit. __________________________________________________________________ FreeBSD Services Control URL: http://people.FreeBSD.org/~trhodes/fsc/ Contact: Tom Rhodes After a while of moving and getting a new job, I finally got back to this project (also thanks to several submissions by Julian Fagir), a new version has been uploaded along with a short description page. The current version supports more options, a configuration file, and updated rc.d script. It also includes manual page updates and an optional debugging mode. __________________________________________________________________ FreeBSD/arm on Various TI Boards URL: http://svnweb.FreeBSD.org/base/projects/armv6/sys/arm/ti/ Contact: Ben Gray Contact: Olivier Houchard Contact: Damjan Marion Contact: Oleksandr Tymoshenko The goal of this project is to get FreeBSD running on various popular boards that use TI-based SoCs like OMAP3, OMAP4, AM335x. Project covers some ARM generic Cortex-A components: GIC (Generic Interrupt Controller), PL310 L2 Cache Controller and SCU. PandaBoard (TI OMAP4430) and PandaBoard ES (OMAP4460) Dual core ARM Cortex-A9 board support includes: USB, onboard Ethernet over USB, GPIO, I2C and MMC/SD card drivers. Board works in multiuser mode over NFS root. BeagleBone (TI AM3358/AM3359) single core ARM Cortex-A8 based board support currently includes: Ethernet, L2 cache, GPIO, I2C. Board works in multiuser mode over NFS root. Open tasks: 1. Completing missing peripherals: DMA, SPI, MMC/SD, Video, Audio. 2. Completing SMP support and testing. 3. Importing BeagleBoard (OMAP3) code to SVN. 4. Improving overall stability and performance. __________________________________________________________________ FreeBSD/powerpc on Freescale QorIQ DPAA URL: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=P2040 URL: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=P3041 URL: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=P5020 URL: http://www.freescale.com/webapp/sps/site/homepage.jsp?code=64BIT&fsrch= 1&sr=1 Contact: Michal Dubiel Contact: Rafal Jaworowski Contact: Piotr Ziecik This work is bringing up the FreeBSD on Freescale QorIQ Data Path Acceleration Architecture (DPAA) system-on-chips along with device drivers for integrated peripherals. Since the last status report, the following support has been added: * Ethernet (full network functionality using Regular Mode of DPAA infrastructure) * QorIQ P5020 SoC (e5500 core in legacy 32-bit mode) * P5020 QorIQ Development System support * Initial support for Enhanced SDHC The next step is: * e5500 core in native 64-bit mode Related publications: * Michal Dubiel, Piotr Ziecik, "FreeBSD on Freescale QorIQ Data Path Acceleration Architecture Devices", AsiaBSDCon, March 2012, Tokyo, Japan. __________________________________________________________________ GNU-Free C++11 Stack Contact: David Chisnall Since the last status report, the combination of libc++ and libcxxrt has received some additional testing and gained some new features including support for ARM EABI. With clang 3.1, we now pass all of the C++11 atomics tests. The xlocale implementation (required for libc++) has been tested with a variety of ports that were originally written for the Darwin implementation, and bugs that this testing uncovered have been fixed. This should be released in 9.1. In -CURRENT, we are now building libsupc++ as a shared library. This provides the ABI layer and building it as a shared library means that we can replace it with libcxxrt easily. If you are running -CURRENT, please try using libmap.conf to enable libcxxrt instead of libsupc++. If libstdc++ is using libcxxrt, you can now link against both libraries that are using libstdc++ and libc++, making the migration slightly easier, although you cannot pass STL objects between libraries using different STL versions. We still need a replacement for some parts of libgcc_s and for the linker, but we're on track for a BSD licensed C++ stack in 10.0. Open tasks: 1. Test ports with libc++. Hopefully most will Just Work, but others may need patches or have a hard dependency on libstdc++. 2. Enable building libc++ by default. This is dependent upon building with clang, because the version of gcc in the base system does not support C++11 and so can not be used to build libc++. 3. Removing libstdc++ from the base system and making it available through ports for backwards compatibility. __________________________________________________________________ Growing filesystems online Contact: Edward Tomasz Napierala The goal of this project is to make it possible to grow a filesystem, both UFS and ZFS, while it's mounted read-write. This includes changes to both filesystems, GEOM infrastructure, and the da(4) driver. For testing purposes, I've also added resizing to mdconfig(8) and implemented LUN resizing in CAM Target Layer. From the system administrator point of view, this makes it possible to resize mounted partition using gpart(8) and then resize the filesystem on it using growfs(8) - all without unmounting it first; especially useful if it's a root filesystem. All the functionality works and is in the process of being refined, reviewed and merged to HEAD. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. The write suspension infrastructure (/dev/ufssuspend) implemented to make resizing possible makes it also possible to implement online tunefs(8) and fsck(8). 2. Right now, there is no way for a GEOM class to veto resizing -- classes are notified about resize and they can either adapt, or wither. Many classes store their metadata in the last sector, though, so resizing a partition containing e.g. gmirror will make it inoperable. It would be nice if geom_mirror(4) could veto resizing, so the administrator attempting to shoot himself in the foot would get a warning. __________________________________________________________________ HDMI/DisplayPort Audio Support in HDA Sound Driver (snd_hda) Contact: Alexander Motin snd_hda(4) driver got number of improvements to better support HDMI/DisplayPort audio, such as: * Added fetching EDID-Like Data from the CODEC and video driver, describing audio capabilities of the display device. * Added setting HDMI/DP-specific CODEC options, such as number of channels, speakers configuration and channels mapping. * Added support for more multichannel formats. For HDMI and DisplayPort device now supported: 2.0, 2.1, 3.0, 3.1, 4.0, 4.1, 5.0, 5.1, 6.0, 6.1, 7.0 and 7.1 channels. * Added support for compressed streams passthrough with data rate 6.144 - 24Mbps, such as DTS-HD Master Audio or Dolby TrueHD. * Added support for HDA bus multiplexing to handle higher data rates (up to 92, 184 or more Mbps, depending on hardware capabilities). It allows to handle several 192/24/8 LPCM playback streams simultaneously. Above functionality was successfully tested on NVIDIA GT210 and GT520 video cards with nvidia-driver-290.10 driver. HDMI audio on older NVIDIA ION and Geforce 8300 boards still does not work for unknown reason. There are also successful reports about Intel video with latest KMS-based drivers. Support for ATI cards is limited to older cards, because video driver supporting newer cards does not support HDMI audio. The code was committed to HEAD and merged to 9-STABLE branch. Project sponsored by iXsystems, Inc. Open tasks: 1. Make better use of received EDID-Like Data. 2. Identify and fix problem with older NVIDIA cards. __________________________________________________________________ Improved hwpmc(9) Support for MIPS Contact: Oleksandr Tymoshenko hwpmc(9) for MIPS has been reworked. The changes include: * msip24k code was split to CPU-specific and arch-specific parts to make adding support for new CPUs easier * Added support for Octeon PMC * Added sampling support for MIPS in general __________________________________________________________________ IPv6 Performance Analysis URL: http://people.FreeBSD.org/~bz/bench/ Contact: Bjoern A. Zeeb IPv6 performance numbers were often seen (significantly) lower on FreeBSD when compared to IPv4. Continuing last years IPv6-only kernel efforts this project looked at various reasons for this and started fixing some. As part of the project a benchmark framework was created that could carry out various tests including reboots in between runs and gather results reproducibly without user intervention. It allows regular benchmarking with minimal configuration and easy future extension for more benchmarks. As a result of the initial analysis, UDP locking and route lookups were improved, and delayed checksumming, TSO6 and LRO support for IPv6 were implemented. Following this checksum "offload" for IPv6 on loopback was enabled and various further individual improvements, both locking and general code changes, as well as a reduction of the cache size footprint were carried out. Some of the changes were equally applied to IPv4. Performance numbers on physical and loopback interfaces are on par with IPv4 when using offload support with TCP/IPv6, which is a huge improvement. UDP and non-offload numbers on IPv6 have generally improved but are still lower than on IPv4 and will need future work to catch up with a decade of IPv4 benchmarking and code path optimizations. UDP IPv6 minimal size send path packets per second (pps) numbers however have increased beating IPv4 when sending to a local discard device. This gets us really close to being able to prefer IPv6 by default without causing loopback performance regressions. For physical interfaces, cxgb(4) in HEAD already supports IPv6 TCP offload and LRO/v6 support was added. To be able to get more test results on different hardware, both ixgbe(4) and cxgbe(4) were also updated to support TSO6 and LRO with IPv6. Some of the insights gained from this work will help upcoming discussions on both the lower/link-layer overhaul as well as for the mbuf changes to prepare our stack for more, future improvements (ahead of time). I once again want to thank the FreeBSD Foundation and iXsystems for their support of the project, as well as George Neville-Neil for providing review. Having set the start to close one of the biggest feature parity gaps left I will continue to improve IPv6 code paths and hope that we will see more contributions and independent results from the community as well soon. Open tasks: 1. Carefully merge code changes to SVN. __________________________________________________________________ isci(4) SAS Driver Contact: Jim Harris An Intel-supported isci(4) driver, for the integrated SAS controller in Intel's C600 chipsets, is now available in head, stable/9, stable/8 and stable/7. The isci(4) driver will also be part of the FreeBSD 8.3 release. __________________________________________________________________ KDE/FreeBSD URL: http://FreeBSD.kde.org URL: http://FreeBSD.kde.org/area51.php Contact: KDE FreeBSD The team has made many releases and upstreamed many fixes and patches. The latest round of releases include: * KDE SC: 4.7.4 (in ports) and 4.8.0, 4.8.1, 4.8.2 (in area51) * Qt: 4.8.0, 4.8.1 (in area51) * PyQt: 4.9.1; SIP: 4.13.2 (in area51) * KDevelop: 2.3.0; KDevPlatform: 1.3.0 (in area51) * Calligra: 2.3.87 (in area51) * Amarok: 2.5.0 * CMake: 2.8.7 Due to the prolonged port freeze the KDE team has not been able to update KDE in Ports as it is considered a intrusive change. The team is always looking for more testers and porters so please contact us at kde@FreeBSD.org and visit our home page at http://FreeBSD.kde.org. Open tasks: 1. Testing KDE SC 4.8.2. 2. Testing KDE PIM 4.8.2. 3. Testing phonon-gstreamer and phonon-vlc as the phonon-xine backend was deprecated (but will remain in the ports for now). 4. Testing the Calligra beta releases (in the area51 repository). __________________________________________________________________ Multi-FIB: IPv6 Support and Other Enhancements URL: http://svnweb.FreeBSD.org/base/projects/multi-fibv6/ Contact: Bjoern A. Zeeb Contact: Alexander V. Chernikov In 2008 the multiple forwarding information base (FIB) feature was introduced for IPv4 allowing up to 16 distinct forwarding ("routing") tables in the kernel. Thanks to the sponsorship from Cisco Systems, Inc. this feature is now also available for IPv6 and one of the bigger IPv6 feature-parity gaps is closed. The changes have been integrated to HEAD, were merged back to stable/9 and stable/8 and will be part of future releases for these branches. A backport to stable/7 is also available in the project branch. If more than one FIB is requested, IPv6 FIBs will be added along the extra IPv4 FIBs without any special configuration needed and programs like netstat and setfib, as well as ipfw, etc. were extended to seamlessly support the multi-FIB feature on both address families. Thanks to the help of Alexander V. Chernikov all usage of the multi-FIB feature is now using the boot-time variable rather than depending on the compile time option. In HEAD this now allows us you to use the multi-FIB feature with GENERIC kernels not needing to recompile your own anymore. The former kernel option can still be used to set a default value if desired. Otherwise the net.fibs loader tunable can be used to request more than one IPv6 and IPv4 FIB at boot time. Last, routing sockets are now aware of FIBs and will only show the routing messages targeted at the FIB attached to. This allows route monitor or routing daemons to get selective updates for just a specific FIB. __________________________________________________________________ NAND File System, NAND Flash Framework, NAND Simulator URL: http://svnweb.FreeBSD.org/base/projects/nand/ Contact: Grzegorz Bernacki Contact: Mateusz Guzik The NAND Flash stack consists of a driver framework for NAND controllers and memory chips, a NAND device simulator and a fault tolerant, log-structured file system, accompanied by tools, utilities and documentation. NAND FS support merged into "nand" project branch: * NAND FS filesystem * NAND FS userland tools NAND Framework and NAND simulator merged into "nand" project branch: * NAND framework: nandbus, generic nand chips drivers * NAND Flash controllers (NFC) drivers for NAND Simulator and Marvell MV-78100 (ARM) * NAND tool (which allows to erase, write/read pages/oob, etc. The next steps include: * Fix bugs * Merge into HEAD Work on this project is supported by the FreeBSD Foundation and Juniper Networks. __________________________________________________________________ Perl Ports Testing URL: http://wiki.FreeBSD.org/Perl#Test_Dependencies Contact: Steve Wills Many Perl modules in ports come with test cases included with their source. This project's goal is to ensure that all these tests pass. Significant progress has been made on this project. The change to build perl with -pthread was committed and no issues have been reported. Many ports have had missing dependencies added and/or other changes and approximately 90% of p5- ports pass tests. Work is being done on bringing testing support out of ports tinderbox. Open tasks: 1. Finish work on patch to bring testing support to ports. 2. Add additional support for testing other types of ports such as python and ruby. __________________________________________________________________ Porting DTrace to MIPS and ARM Contact: Oleksandr Tymoshenko The major part of DTrace has been ported to MIPS platform. Supported ABIs: o32 and n64. n32 has not been tested yet. MIPS implementation passes 853 of 927 tests from DTrace test suite. The fbt provider and userland DTrace are not supported yet. The port to ARM is in progress. Open tasks: 1. Userland DTrace support for MIPS. 2. Investigate amount of effort required for getting fbt provider work at least partially. 3. Find proper solution for cross-platform CTF data generation (required for ARM). __________________________________________________________________ Release Engineering Team Status Report URL: http://www.FreeBSD.org/releng/ Contact: Release Engineering Team On behalf of the FreeBSD Project the Release Engineering Team was are pleased to announce the release of the FreeBSD 8.3-RELEASE on April 18th, 2012. With the FreeBSD 8.3 release cycle completed our focus shifts to preparing for the FreeBSD 9.1-RELEASE. A schedule will be posted shortly, with the release target date set for mid-July 2012. __________________________________________________________________ Replacing the Regular Expression Code URL: http://svnweb.FreeBSD.org/base/user/gabor/tre-integration/ URL: http://laurikari.net/tre/ URL: http://www.tdk.aut.bme.hu/Files/TDK2011/POSIX-regularis-kifejezesek1.pd f Contact: Gábor Kövesdán Since the last status report, there has been a significant progress in optimizing TRE. The multiple pattern heuristic code is mostly finished and it distinguishes several different cases to speed up pattern matching. It extracts literal fragments from the original patterns and uses a multiple pattern matching algorithm to find any occurrence. GNU grep uses the Commentz-Walter algorithm, which is an automaton-based algorithm, while in this project, it has been decided to use a Wu-Manber algorithm, which is more efficient and also easier to implement. In the current state, it does not work entirely yet and some cases, like the REG_ICASE flag are not yet covered. This is the next major step to complete this multiple pattern interface. In the development branch, BSD grep is already modified to use this new interface so it can be used for testing and debugging purposes. Open tasks: 1. Finish multiple pattern heuristic regex matching. 2. Implement GNU-specific regex extensions. 3. Test standard-compliance and correct behavior. __________________________________________________________________ The bsdconfig(8) utility URL: http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdconfig/ URL: http://druidbsd.sf.net/download/bsdconfig/bsdconfig-20120512-1.svg URL: http://druidbsd.sf.net/download/bsdconfig/bsdconfig-20120512-1i.svg Contact: Devin Teske Contact: Ron McDowell Approaching 20,000 lines of sh(1) code, the bsdconfig(8) tool is approximately 70% complete. Upon completion of this project, bsdconfig(8) will represent (in conjunction with already-existing bsdinstall(8)) a complete set of utilities capable of purposefully deprecating sysinstall(8) in FreeBSD 9 and higher. This project has been a labor of love for Ron McDowell and I for over 90 days now and we are approaching the completion of this wonderful tool. Open tasks: 1. The "installer suite" modules for acquiring/installing binary packages and additional distribution sets. Startup services module. __________________________________________________________________ The FreeBSD Foundation Team Report URL: www.FreeBSDFoundation.org Contact: Deb Goodkin The Foundation sponsored AsiaBSDCon 2012 which was held in Tokyo, Japan, March 22-25. We were represented at SCALE on Jan 21 and NELF on March 17. This quarter we plan on being at ILF (Indiana LinuxFest) April 14th, BSDCan May 11-12, and SELF (Southeast LinuxFest) June 9. We are proud to be a gold sponsor of BSDCan 2012, which will be held in Ottawa, Canada, May 11-12. We are sponsoring 14 developers to attend the conference. We kicked off three foundation funded projects -- Growing Filesystems Online by Edward Tomasz Napierala, Implementing auditdistd daemon by Pawel Jakub Dawidek, and NAND Flash Support by Semihalf. We are pleased to announce the addition of George Neville-Neil to our board of directors. Deb Goodkin, our Director of Operations, was interviewed by bsdtalk. We announced a call for project proposals. We will accept proposals until April 30th. Please read Project Proposal Procedures to find out more. FreeBSD 9.0 was released and we are proud to say we funded 7 of the new features! __________________________________________________________________ The FreeBSD Haskell Ports URL: http://wiki.FreeBSD.org/Haskell URL: https://github.com/freebsd-haskell/freebsd-haskell/ URL: https://github.com/freebsd-haskell/hsporter/ URL: https://github.com/freebsd-haskell/hsmtk/ Contact: Gábor PÁLI Contact: Ashish SHUKLA We are proud announce that the FreeBSD Haskell Team has committed the Haskell Platform 2011.4.0.0 update, GHC 7.0.4 update, existing port updates, as well new port additions to FreeBSD ports repository, which were pending due to freeze for 9.0-RELEASE. Some of the new ports which were committed include Yesod, Happstack, wxHaskell, gitit, Threadscope, etc. and the count of Haskell ports in FreeBSD Ports tree is now almost 300. All of these updates will be available as part of upcoming 8.3-RELEASE. We started project hsporter to automate creation of new FreeBSD Haskell ports from .cabal file, as well as update existing ports. We also published scripts which we were using in the FreeBSD Haskell project under the project hsmtk. Open tasks: 1. Test GHC to work with clang/LLVM. 2. Add an option to the lang/ghc port to be able to build it with already installed GHC instead of requiring a separate GHC boostrap tarball. 3. Add more ports to the Ports Collection. __________________________________________________________________ The FreeBSD Japanese Documentation Project URL: http://www.FreeBSD.org/ja/ URL: http://www.jp.FreeBSD.org/doc-jp/ Contact: Hiroki Sato Contact: Ryusuke Suzuki The same as before, the outdated contents in the www/ja subtree were updated to the latest versions in the English counterpart. The updating work of the outdated translations in the www/ja subtree is almost complete. Only the translations of the release documents for old releases may be outdated. During this period, we translated the 9.0-RELEASE announcement and published it in a timely manner. It seems that the Japanese version of the release announcement is important for Japanese people as this page has frequently been referenced. For FreeBSD Handbook, translation work of the "cutting-edge" section is still on-going. Some updates in the "printing" and the "linuxemu" section were done. Open tasks: 1. Further translation work of outdated documents in both doc/ja_JP.eucJP and www/ja. __________________________________________________________________ The FreeBSD Ports Collection URL: http://www.FreeBSD.org/ports/ URL: http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributing-ports/ URL: http://portsmon.FreeBSD.org/index.html URL: http://www.FreeBSD.org/portmgr/index.html URL: http://blogs.FreeBSDish.org/portmgr/ URL: http://www.twitter.com/freebsd_portmgr/ URL: http://www.facebook.com/portmgr Contact: Thomas Abthorpe Contact: Port Management Team The ports tree slowly climbs above 23,000 ports. The PR count still remains at about 1100. In Q1 we added 2 new committers, took in 2 commit bits for safe keeping, and had one committer return to ports work. The Ports Management team have been running -exp runs on an ongoing basis, verifying how base system updates may affect the ports tree, as well as providing QA runs for major ports updates. Of note, -exp runs were done for: * Ports validation in the FreeBSD 10 environment * Updates to bison, libtool and libiconv * Set java/opendjdk6 as default java * Tests with clang set as default * Update to devel/boost and friends * Update of audio/sdl and friends * Tests for changes in the ports licensing infrastructure * Update to devel/ruby1[8|9] * Update to postresql * Update to apr * Checks for new x11/xorg * Security update to security/gnutls * Ongoing validation of infrastructure with pkgng A lot of focus during this period was put into getting the ports tree into a ready state for FreeBSD 8.3, including preparing packages for the release. Beat Gaetzi has been doing ongoing tests with the ports tree to ensure a smooth transition from CVS to Subversion. Open tasks: 1. Looking for help getting ports to build with clang. 2. Looking for help with Tier-2 architectures. 3. ports broken by src changes. 4. ports failing on pointyhat. 5. ports failing on pointyhat-west. 6. ports that are marked as BROKEN. 7. When did that port break? 8. Most ports PRs are assigned, we now need to focus on testing, committing and closing. __________________________________________________________________ The FreeNAS Project URL: http://www.FreeNAS.org Contact: Josh Paetzel Contact: Xin Li FreeNAS 8.0.4 was released last month, which marks the end of the 8.0.x branch in FreeNAS. FreeNAS 8.2.0 is in BETA currently, and will hopefully be released by the end of April. It features a number of improvements over the 8.0.x line, including plugin support, (the ability to run arbitrary software in jails), as well as better integration between command line ZFS and the GUI. Once 8.2.0 is out it will be quickly followed up with 8.3.0, which will include a number of driver updates as well as the long awaited ZFS v28. __________________________________________________________________ (c) 1995-2012 The FreeBSD Project. All rights reserved.