From owner-freebsd-current@FreeBSD.ORG Sun May 13 00:14:14 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 80CB9106564A; Sun, 13 May 2012 00:14:14 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 0E3348FC0C; Sun, 13 May 2012 00:14:13 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q4D0ECjL062488; Sat, 12 May 2012 20:14:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q4D0ECpO062474; Sun, 13 May 2012 00:14:12 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 13 May 2012 00:14:12 GMT Message-Id: <201205130014.q4D0ECpO062474@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 00:14:14 -0000 TB --- 2012-05-12 21:50:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-05-12 21:50:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-05-12 21:50:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-05-12 21:50:00 - cleaning the object tree TB --- 2012-05-12 21:55:25 - cvsupping the source tree TB --- 2012-05-12 21:55:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-05-12 21:59:02 - building world TB --- 2012-05-12 21:59:02 - CROSS_BUILD_TESTING=YES TB --- 2012-05-12 21:59:02 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-12 21:59:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-12 21:59:02 - SRCCONF=/dev/null TB --- 2012-05-12 21:59:02 - TARGET=pc98 TB --- 2012-05-12 21:59:02 - TARGET_ARCH=i386 TB --- 2012-05-12 21:59:02 - TZ=UTC TB --- 2012-05-12 21:59:02 - __MAKE_CONF=/dev/null TB --- 2012-05-12 21:59:02 - cd /src TB --- 2012-05-12 21:59:02 - /usr/bin/make -B buildworld >>> World build started on Sat May 12 21:59:03 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 [...] cc -O2 -pipe -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/pc98/loader/../../ficl -I/src/sys/boot/pc98/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -I/src/sys/boot/pc98/loader/../../common -I/src/sys/boot/pc98/loader/../../i386 -I. -Wall -I/src/sys/boot/pc98/loader/.. -I/src/sys/boot/pc98/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -Os -DPC98 -std=gnu99 -c /src/sys/boot/pc98/loader/../../common/isapnp.c cc -O2 -pipe -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/pc98/loader/../../ficl -I/src/sys/boot/pc98/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -I/src/sys/boot/pc98/loader/../../common -I/src/sys/boot/pc98/loader/../../i386 -I. -Wall -I/src/sys/boot/pc98/loader/.. -I/src/sys/boot/pc98/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -Os -DPC98 -std=gnu99 -c /src/sys/boot/pc98/loader/../../common/pnp.c cc -O2 -pipe -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/pc98/loader/../../ficl -I/src/sys/boot/pc98/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -I/src/sys/boot/pc98/loader/../../common -I/src/sys/boot/pc98/loader/../../i386 -I. -Wall -I/src/sys/boot/pc98/loader/.. -I/src/sys/boot/pc98/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -Os -DPC98 -std=gnu99 -c /src/sys/boot/pc98/loader/../../common/interp_forth.c cc -O2 -pipe -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/pc98/loader/../../ficl -I/src/sys/boot/pc98/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -I/src/sys/boot/pc98/loader/../../common -I/src/sys/boot/pc98/loader/../../i386 -I. -Wall -I/src/sys/boot/pc98/loader/.. -I/src/sys/boot/pc98/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -Os -DPC98 -std=gnu99 -static -Ttext 0x0 -nostdlib -o loader.sym /obj/pc98.i386/src/sys/boot/pc98/loader/../btx/lib/crt0.o main.o conf.o vers.o boot.o commands.o console.o devopen.o disk.o interp.o interp_backslash.o interp_parse.o ls.o misc.o module.o panic.o load_elf32.o load_elf32_obj.o reloc_elf32.o bcache.o isapnp.o pnp.o interp_forth.o /obj/pc98.i386/src/sys/boot/pc98/loader/../../ficl/libficl.a /obj/pc98.i386/src/sys/boot/pc98/loader/../libpc98/libpc98.a /obj/pc98.i386/src/tmp/usr/lib/libstand.a /obj/pc98.i386/src/sys/boot/pc98/loader/../libpc98/libpc98.a(devicename.o): In function `i386_parsedev': devicename.c:(.text+0x19b): undefined reference to `zfs_parsedev' /obj/pc98.i386/src/sys/boot/pc98/loader/../libpc98/libpc98.a(devicename.o): In function `i386_fmtdev': devicename.c:(.text+0x301): undefined reference to `zfs_fmtdev' *** Error code 1 Stop in /src/sys/boot/pc98/loader. *** Error code 1 Stop in /src/sys/boot/pc98. *** Error code 1 Stop in /src/sys/boot. *** Error code 1 Stop in /src/sys. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-05-13 00:14:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-05-13 00:14:12 - ERROR: failed to build world TB --- 2012-05-13 00:14:12 - 6047.19 user 842.48 system 8652.34 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sun May 13 03:23:23 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD04F106564A for ; Sun, 13 May 2012 03:23:23 +0000 (UTC) (envelope-from bryan@shatow.net) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) by mx1.freebsd.org (Postfix) with ESMTP id 6410B8FC0A for ; Sun, 13 May 2012 03:23:23 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=message-id :date:from:mime-version:to:subject:content-type; q=dns; s=sweb; b= CwCrRoqMTwBRr5PmJKoDsa8inC6HvWvbutYVcXtf7kr8/RYO2J4dHYm19MTgM8K/ 4Zozno+5usj6ChKmMVOw5z4tXvmr9jojnybDw/Poqh5q0sT0at+YqAd3aBNOnas6 1rXA0GsLqB1tlH/duQM273vQs/00OaV+uzrMDi8LGsY= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=message-id :date:from:mime-version:to:subject:content-type; s=sweb; bh=J+cu 2f97rx599p3HwM2GkIhGifjfPrCGXxdg3ZZ4Ya4=; b=D0SZKeKVU7a6NoDohRob dGX066Qc/Bf2onuOTITxOnxPqs77XBBW3EJK6sH+hn3udrIrU1ek8SllDkyvlwEZ 0/JWCiU9MvlR+vMuMkCFmzWFZjkTe3idV6BGgiXpJIUcCAiBcz6Ao0DNKWxFb0Jk YsJIBOGIKxKLK3dtJMDClfc= Received: (qmail 65444 invoked from network); 12 May 2012 22:23:16 -0500 Received: from unknown (HELO ?10.120.12.155?) (bryan@shatow.net@137.122.39.30) by sweb.xzibition.com with ESMTPA; 12 May 2012 22:23:16 -0500 Message-ID: <4FAF291C.8090401@shatow.net> Date: Sat, 12 May 2012 23:23:08 -0400 From: Bryan Drewery User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org, dougb@freebsd.org X-Enigmail-Version: 1.4.1 OpenPGP: id=3C9B0CF9; url=http://www.shatow.net/bryan/bryan.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig460A311166BD255386EB30B7" Cc: Subject: [review request] usr.sbin/service - make showing files configurable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 03:23:23 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig460A311166BD255386EB30B7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I found service(8) to be inconsistent that it listed files with `service -e`, but plain services with `service -l` My patch makes the default just list *service names*, and specifying -F will show the full path to the file. Patch: http://www.shatow.net/freebsd/patch-service.txt Regards, Bryan Drewery --------------enig460A311166BD255386EB30B7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPrykhAAoJEG54KsA8mwz5WcAQAIcYzax0AhsjxJLfEFn0DYQy uHu7zDZbBb6CQnlD/3n2BNLIUL4oHLH72sJxHzAxijv6XfZo5UbhNfAwZid10tl9 6ebKvfS4ZivUHDA+CF4K8CU/bqECJ+GKaDFq6MnXQeIgB88Wb2zjbRRdh2HtBvx0 BuhkEO2qGEl/6XIziZpP5UCEhMVEndhKt+nUgZSxDP0slg+IsnqUTv3jxhafXvZb S2rK+j9Z0woh/TQAxkkm/FRWnLr8r9slORBbHIs6Ey+vbuGzNfwicK/aFkqFMhkE +nEXj4MQECSNlx0TYN+TmNf2qizbZrqneljJhjzsFFrSCsiEzXU64PB+AdDo750k ThaLrTIvNWAuUNGSBkz4y9v/wSQq3J0EdtP8z7hYCLpToZjfdRGcgc7zxLr+kybL 2kH3xkzIBHYW8/3cKSwtrYfXqLDXfsXR4/tKILQteAw/BDb0GEIE1hKHLddD60lM ktyZij0kPHIOuCRk0znQW9uZVouNTukjw+MLEwIuQIoRDzSe/R6aa2RoSzHOaiNy lU5wf/xlqyDfEgDt/pfOQKgW+HNxZeiP3BwcQam+RfumirrB4SJmqk6FLnGuFdJc jitq68hWbvP8YM1rOsM8KLWqRpDVjypg+irUuRlvC0fulBLuwQ6P/Qt2L5JHDcIZ dg0fSTKv8GPeFeXp5gvz =Sm9N -----END PGP SIGNATURE----- --------------enig460A311166BD255386EB30B7-- From owner-freebsd-current@FreeBSD.ORG Sun May 13 08:30:18 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9CE971065676; Sun, 13 May 2012 08:30:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 6BBFB8FC16; Sun, 13 May 2012 08:30:18 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q4D8UBRV053564; Sun, 13 May 2012 04:30:11 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q4D8UB4x053554; Sun, 13 May 2012 08:30:11 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 13 May 2012 08:30:11 GMT Message-Id: <201205130830.q4D8UB4x053554@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 08:30:18 -0000 TB --- 2012-05-13 06:10:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-05-13 06:10:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-05-13 06:10:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-05-13 06:10:00 - cleaning the object tree TB --- 2012-05-13 06:14:23 - cvsupping the source tree TB --- 2012-05-13 06:14:23 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-05-13 06:15:16 - building world TB --- 2012-05-13 06:15:16 - CROSS_BUILD_TESTING=YES TB --- 2012-05-13 06:15:16 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-13 06:15:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-13 06:15:16 - SRCCONF=/dev/null TB --- 2012-05-13 06:15:16 - TARGET=pc98 TB --- 2012-05-13 06:15:16 - TARGET_ARCH=i386 TB --- 2012-05-13 06:15:16 - TZ=UTC TB --- 2012-05-13 06:15:16 - __MAKE_CONF=/dev/null TB --- 2012-05-13 06:15:16 - cd /src TB --- 2012-05-13 06:15:16 - /usr/bin/make -B buildworld >>> World build started on Sun May 13 06:15:17 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 [...] cc -O2 -pipe -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/pc98/loader/../../ficl -I/src/sys/boot/pc98/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -I/src/sys/boot/pc98/loader/../../common -I/src/sys/boot/pc98/loader/../../i386 -I. -Wall -I/src/sys/boot/pc98/loader/.. -I/src/sys/boot/pc98/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -Os -DPC98 -std=gnu99 -c /src/sys/boot/pc98/loader/../../common/isapnp.c cc -O2 -pipe -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/pc98/loader/../../ficl -I/src/sys/boot/pc98/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -I/src/sys/boot/pc98/loader/../../common -I/src/sys/boot/pc98/loader/../../i386 -I. -Wall -I/src/sys/boot/pc98/loader/.. -I/src/sys/boot/pc98/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -Os -DPC98 -std=gnu99 -c /src/sys/boot/pc98/loader/../../common/pnp.c cc -O2 -pipe -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/pc98/loader/../../ficl -I/src/sys/boot/pc98/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -I/src/sys/boot/pc98/loader/../../common -I/src/sys/boot/pc98/loader/../../i386 -I. -Wall -I/src/sys/boot/pc98/loader/.. -I/src/sys/boot/pc98/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -Os -DPC98 -std=gnu99 -c /src/sys/boot/pc98/loader/../../common/interp_forth.c cc -O2 -pipe -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/pc98/loader/../../ficl -I/src/sys/boot/pc98/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -I/src/sys/boot/pc98/loader/../../common -I/src/sys/boot/pc98/loader/../../i386 -I. -Wall -I/src/sys/boot/pc98/loader/.. -I/src/sys/boot/pc98/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -Os -DPC98 -std=gnu99 -static -Ttext 0x0 -nostdlib -o loader.sym /obj/pc98.i386/src/sys/boot/pc98/loader/../btx/lib/crt0.o main.o conf.o vers.o boot.o commands.o console.o devopen.o disk.o interp.o interp_backslash.o interp_parse.o ls.o misc.o module.o panic.o load_elf32.o load_elf32_obj.o reloc_elf32.o bcache.o isapnp.o pnp.o interp_forth.o /obj/pc98.i386/src/sys/boot/pc98/loader/../../ficl/libficl.a /obj/pc98.i386/src/sys/boot/pc98/loader/../libpc98/libpc98.a /obj/pc98.i386/src/tmp/usr/lib/libstand.a /obj/pc98.i386/src/sys/boot/pc98/loader/../libpc98/libpc98.a(devicename.o): In function `i386_parsedev': devicename.c:(.text+0x19b): undefined reference to `zfs_parsedev' /obj/pc98.i386/src/sys/boot/pc98/loader/../libpc98/libpc98.a(devicename.o): In function `i386_fmtdev': devicename.c:(.text+0x301): undefined reference to `zfs_fmtdev' *** Error code 1 Stop in /src/sys/boot/pc98/loader. *** Error code 1 Stop in /src/sys/boot/pc98. *** Error code 1 Stop in /src/sys/boot. *** Error code 1 Stop in /src/sys. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-05-13 08:30:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-05-13 08:30:11 - ERROR: failed to build world TB --- 2012-05-13 08:30:11 - 6029.41 user 827.75 system 8411.09 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sun May 13 08:39:35 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99B2B106564A for ; Sun, 13 May 2012 08:39:35 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 28A2B8FC0A for ; Sun, 13 May 2012 08:39:35 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 05167E6503 for ; Sun, 13 May 2012 09:39:44 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; s=mail; bh=KJ9atAicsf55JQTkOdPs9QpC5 xc=; b=aKYAeLZpfwOWCHZC/49+EzT8DFF5JHC+R/KFbjZls6Q6SlO9N1o4cOUGx 0L3jS7l8Joft9opKoIRw004CPi8Lr/ZW9cY6ycOa0129jElInaom90JYiyOOs0MS ZqKuyb2dQUTm+fgGvBDtKvxt3UUXPlJNh+nyp3fcpPFwtvWhtI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; q=dns; s=mail; b=Q+szS/a6ZotJlRW++ky pM/Z0SBX73DbN7WQpdH108q97XFNq8PsSrTCNeOl9X8ipuz7jNwcTZhbKnXdLTDt +4ihbFAIXSTMksY1CuqdPaqOOCdNi8417bKLHiX3e2Mo0rlNuAkXD96AGSGvzua8 ApKEcNLWtXTMV7n5chqWCl20= Received: from [192.168.2.2] (unknown [109.249.223.4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 98E3CE6482 for ; Sun, 13 May 2012 09:39:44 +0100 (BST) Message-ID: <4FAF7343.8010808@cran.org.uk> Date: Sun, 13 May 2012 09:39:31 +0100 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: ACPI 'driver bug: Unable to set devclass' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 08:39:35 -0000 I've just updated to -current and noticed the following errors in dmesg: acpi0: on motherboard acpi0: Power Button (fixed) acpi0: reservation of fee00000, 1000 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, bbf00000 (3) failed driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) driver bug: Unable to set devclass (class: acpi_timer devname: (unknown)) cpu0: on acpi0 ACPI Warning: Incorrect checksum in table [OEMB] - 0x45, should be 0x44 (20120420/tbutils-293) driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) cpu2: on acpi0 driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) cpu1: on acpi0 driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sun May 13 08:53:26 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 22391106566C for ; Sun, 13 May 2012 08:53:26 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id CB54B8FC15 for ; Sun, 13 May 2012 08:53:25 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 8820AE6503 for ; Sun, 13 May 2012 09:53:29 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; s=mail; bh=6jvNreYTE7156AjIg2vkriejD 5Y=; b=D/1k/rKuLNqu4lEoZCAdLgNBO29fWHUswRe6OZojOqzdxiezXGzKhuf6s dgTtnOt+BhffBntyTGmIVw4w0V2QKxhwcSot7cpFbjjkIDr1YeSzNgUQH6lAgXuK 0CFAk9zZwW1cRA8gVLJMYCIIo6/k5X/BhQOD6TdDPw1Nwn7hUE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; q=dns; s=mail; b=TeH/WjKw+Nc6uTJ5iWc UVwgRS3KNfUl/Sav9IiL2HNZgZTfabBIGUJxmGM+4u0KuonHE8Wxk06W4nEuYa1v HeiWietWOujbH18DLaQAVc/wVLMy1HbDdjr4X7CFvuojJjd/QEdd/bZMv/HMAt8o 3OVOcZ3qayT64GN8iecS4E5M= Received: from [192.168.2.2] (unknown [109.249.223.4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 5709BE6482 for ; Sun, 13 May 2012 09:53:29 +0100 (BST) Message-ID: <4FAF767C.8030500@cran.org.uk> Date: Sun, 13 May 2012 09:53:16 +0100 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Default directory used for 'zpool import' broken (/dev/dsk)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 08:53:26 -0000 When running 'zpool import' without -d I get the error: "cannot open '/dev/dsk': must be an absolute path" zpool(8) suggests the default should have been updated for FreeBSD: "If the -d option is not specified, this command searches for devices in "/dev"" Was this broken recently? -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sun May 13 09:23:37 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F508106564A; Sun, 13 May 2012 09:23:37 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by mx1.freebsd.org (Postfix) with ESMTP id D88A78FC16; Sun, 13 May 2012 09:23:34 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id q4D7v2wT022863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 13 May 2012 09:57:02 +0200 Received: from portgus.lan (17.Red-83-38-184.dynamicIP.rima-tde.net [83.38.184.17]) (authenticated bits=0) by ackerman2.upc.es (8.14.4/8.14.4) with ESMTP id q4D7v0Bw012801 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 13 May 2012 09:57:01 +0200 Message-ID: <4FAF696D.3060806@entel.upc.edu> Date: Sun, 13 May 2012 09:57:33 +0200 From: =?ISO-8859-1?Q?Gustau_P=E9rez_i_Querol?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120422 Thunderbird/12.0 MIME-Version: 1.0 To: FreeBSD current , freebsd-acpi@freebsd.org References: <20120511.111019.90116031.iwasaki@jp.FreeBSD.org> In-Reply-To: <20120511.111019.90116031.iwasaki@jp.FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.70 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Sun, 13 May 2012 09:57:02 +0200 (CEST) Cc: Mitsuru IWASAKI Subject: Re: [CFT] SMP/i386 suspend/resume X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 09:23:37 -0000 Al 11/05/2012 04:10, En/na Mitsuru IWASAKI ha escrit: > Hi > > I've been working on suspend/resume for SMP/i386 for a week > and created patches against CURRENT, RELENG_9 and RELENG_8 > available at: > > http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-CURRENT-20120511.diff > http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-RELENG_9-20120511.diff > http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-RELENG_8-20120511.diff > > A lot of portion of the patches was ported from amd64. > Testing on Thinkpad X60 (Core Duo T2300), so far so good :) > > I'll commit them against CURRENT hopefully next week. > Reporting from an Acer Centrino Duo, running CURRENT r235266. The machine has an nvidia card (Ge7300go). The acpi_video and nvidia modules are there. I did test it a few times with X running (plain twm) and worked just fine. Setting hw.acpi.lid_switch_state=S3 allowed me to use the close-the-lid-to-sleep functionality. The problem comes when I suspend the machine in the console. The machine resumes fine (I can ping and ssh it) but the screen remains black. I set hw.acpi.reset_video to 0 or 1 but no go. If I'm in a console but X is running, after the resume I can CTRL+ALT+F9 and get my video back; then I can return to the console. If I don't have X running, I don't know how to get my console back. Thanks From owner-freebsd-current@FreeBSD.ORG Sun May 13 13:53:37 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 32221106564A; Sun, 13 May 2012 13:53:37 +0000 (UTC) (envelope-from iwasaki@jp.FreeBSD.org) Received: from locore.org (ns01.locore.org [218.45.21.227]) by mx1.freebsd.org (Postfix) with ESMTP id DA8398FC0A; Sun, 13 May 2012 13:53:36 +0000 (UTC) Received: from localhost (celeron.v4.locore.org [192.168.0.10]) by locore.org (8.14.5/8.14.5/iwasaki) with ESMTP/inet id q4DDrTnN079627; Sun, 13 May 2012 22:53:29 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) Date: Sun, 13 May 2012 22:53:28 +0900 (JST) Message-Id: <20120513.225328.10294857.iwasaki@jp.FreeBSD.org> To: peter@rulingia.com From: Mitsuru IWASAKI In-Reply-To: <20120511112005.GA87299@server.rulingia.com> References: <20120511.111019.90116031.iwasaki@jp.FreeBSD.org> <20120511112005.GA87299@server.rulingia.com> X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org Subject: Re: [CFT] SMP/i386 suspend/resume X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 13:53:37 -0000 Hi, Thanks for your report. From: Peter Jeremy Subject: Re: [CFT] SMP/i386 suspend/resume Date: Fri, 11 May 2012 21:20:05 +1000 Message-ID: <20120511112005.GA87299@server.rulingia.com> > On 2012-May-11 11:10:19 +0900, Mitsuru IWASAKI wrote: > >I've been working on suspend/resume for SMP/i386 for a week > >and created patches against CURRENT, RELENG_9 and RELENG_8 > >available at: > > Thank you for that. Since I was in the process of upgrading my > netbook (Acer Aspire One AOA-110 - Atom N270), I rolled your RELENG_8 > patch on top of r235229. > > Unfortunately, the result hasn't been a complete success. I can > suspend to S3 with no problems (though that worked before). The > resume is less successful. If X is running, I get a garbage screen. > If I suspend at a VTY, the screen comes back correctly but there is no > response from keyboard, touchpad or wired network (though it has the > correct lights). > > Let me know if you have any suggestions for debugging. I think graphic driver (or pic?) has some problems on resume and they are out of scope of my patches. HEAD and RELENG_9 have better support on interrupt re-enabling than RELENG_8 I think. Could you try them? And for ps/2 mouse, kernel option PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND would be useful. Thanks > > -- > Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Sun May 13 13:59:18 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BBB33106564A; Sun, 13 May 2012 13:59:18 +0000 (UTC) (envelope-from iwasaki@jp.FreeBSD.org) Received: from locore.org (ns01.locore.org [218.45.21.227]) by mx1.freebsd.org (Postfix) with ESMTP id 6DE838FC16; Sun, 13 May 2012 13:59:18 +0000 (UTC) Received: from localhost (celeron.v4.locore.org [192.168.0.10]) by locore.org (8.14.5/8.14.5/iwasaki) with ESMTP/inet id q4DDxHaY079665; Sun, 13 May 2012 22:59:17 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) Date: Sun, 13 May 2012 22:59:17 +0900 (JST) Message-Id: <20120513.225917.02304793.iwasaki@jp.FreeBSD.org> To: dhw@FreeBSD.org From: Mitsuru IWASAKI In-Reply-To: <20120511132257.GA96585@freefall.freebsd.org> References: <20120511.111019.90116031.iwasaki@jp.FreeBSD.org> <20120511132257.GA96585@freefall.freebsd.org> X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: [CFT] SMP/i386 suspend/resume X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 13:59:18 -0000 Hi, Thanks for you report. From: David Wolfskill Subject: Re: [CFT] SMP/i386 suspend/resume Date: Fri, 11 May 2012 13:22:57 +0000 Message-ID: <20120511132257.GA96585@freefall.freebsd.org> > On Fri, May 11, 2012 at 11:10:19AM +0900, Mitsuru IWASAKI wrote: > > Hi > > > > I've been working on suspend/resume for SMP/i386 for a week > > and created patches against CURRENT, RELENG_9 and RELENG_8 > > available at: > > > > http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-CURRENT-20120511.diff > > http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-RELENG_9-20120511.diff > > http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-RELENG_8-20120511.diff > > ... > > I'm sorry to report that while head & stable/9 did work for me (see > previous notes in this thread), stable/8 did not. Well, suspend > seemed to, but on resume, the screen stayed dark and the machine > was (as far as I could tell without trying to ping it from another > machine) unresponsive. OK, we need some more investigation on RELENG_8 SMP. I think Core 2 Duo can run amd64, would like to confirm this problem can be reproduced only on i386 or not. Could you try same thing on amd64? Thanks > > This was on the same Dell Precision M4400 as before (Core(TM)2 Duo CPU > T9600), running: > > FreeBSD localhost 8.3-STABLE FreeBSD 8.3-STABLE #382 235262M: Fri May 11 04:45:52 EDT 2012 root@localhost:/common/S1/obj/usr/src/sys/CANARY i386 > > Peace, > david > -- > David H. Wolfskill dhw@freebsd.org > There is a use for spam: it helps identify spammers. > I have no use for spammers. > From owner-freebsd-current@FreeBSD.ORG Sun May 13 14:03:03 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 41A6A106564A; Sun, 13 May 2012 14:03:03 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 158C78FC15; Sun, 13 May 2012 14:03:02 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id q4DE32qL021203; Sun, 13 May 2012 07:03:02 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id q4DE323f021202; Sun, 13 May 2012 07:03:02 -0700 (PDT) (envelope-from david) Date: Sun, 13 May 2012 07:03:02 -0700 From: David Wolfskill To: Mitsuru IWASAKI Message-ID: <20120513140302.GI13138@albert.catwhisker.org> References: <20120511.111019.90116031.iwasaki@jp.FreeBSD.org> <20120511132257.GA96585@freefall.freebsd.org> <20120513.225917.02304793.iwasaki@jp.FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="svExV93C05KqedWb" Content-Disposition: inline In-Reply-To: <20120513.225917.02304793.iwasaki@jp.FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-acpi@FreeBSD.org, freebsd-current@FreeBSD.org, dhw@FreeBSD.org Subject: Re: [CFT] SMP/i386 suspend/resume X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 14:03:03 -0000 --svExV93C05KqedWb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 13, 2012 at 10:59:17PM +0900, Mitsuru IWASAKI wrote: > .... > OK, we need some more investigation on RELENG_8 SMP. > I think Core 2 Duo can run amd64, would like to confirm > this problem can be reproduced only on i386 or not. > Could you try same thing on amd64? Well, that will require a bit more work -- I'm pretty sure the hardware can run amd64, but I only have i386 inistalled presently. And I'm getting ready to head to the airport to fly back home now. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --svExV93C05KqedWb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk+vvxUACgkQmprOCmdXAD3X2ACfdPO192dSLiJexjCjmkKf8UcX NZEAn03z3mmDsFaTRtDedcwVJdUP5jUV =cwGV -----END PGP SIGNATURE----- --svExV93C05KqedWb-- From owner-freebsd-current@FreeBSD.ORG Sun May 13 14:36:59 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E3AA2106566B for ; Sun, 13 May 2012 14:36:59 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.freebsd.org (Postfix) with SMTP id A13878FC1C for ; Sun, 13 May 2012 14:36:59 +0000 (UTC) Received: (qmail 16232 invoked from network); 13 May 2012 14:33:08 -0000 Received: from 87.58.144.241 (HELO x2.osted.lan) (87.58.144.241) by relay02.pair.com with SMTP; 13 May 2012 14:33:08 -0000 X-pair-Authenticated: 87.58.144.241 Received: from x2.osted.lan (localhost [127.0.0.1]) by x2.osted.lan (8.14.5/8.14.5) with ESMTP id q4DEaufN075148; Sun, 13 May 2012 16:36:56 +0200 (CEST) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.5/8.14.5/Submit) id q4DEaub6075147; Sun, 13 May 2012 16:36:56 +0200 (CEST) (envelope-from pho) Date: Sun, 13 May 2012 16:36:56 +0200 From: Peter Holm To: Mateusz Guzik Message-ID: <20120513143656.GA75074@x2.osted.lan> References: <4FA6F324.4080107@FreeBSD.org> <4FA82269.6080406@FreeBSD.org> <20120507201153.GA19942@dft-labs.eu> <20120508194514.GA10688@x2.osted.lan> <20120510102118.GA26472@dft-labs.eu> <20120510103900.GA77554@x2.osted.lan> <20120512224938.GA1322@dft-labs.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120512224938.GA1322@dft-labs.eu> User-Agent: Mutt/1.4.2.3i Cc: Doug Barton , Sergey Kandaurov , freebsd-current , mckusick@freebsd.org Subject: Re: panic, seems related to r234386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 14:37:00 -0000 On Sun, May 13, 2012 at 12:49:38AM +0200, Mateusz Guzik wrote: > On Thu, May 10, 2012 at 12:39:00PM +0200, Peter Holm wrote: > > On Thu, May 10, 2012 at 12:21:18PM +0200, Mateusz Guzik wrote: > > > On Tue, May 08, 2012 at 09:45:14PM +0200, Peter Holm wrote: > > > > On Mon, May 07, 2012 at 10:11:53PM +0200, Mateusz Guzik wrote: > > > > > On Mon, May 07, 2012 at 12:28:41PM -0700, Doug Barton wrote: > > > > > > On 05/06/2012 15:19, Sergey Kandaurov wrote: > > > > > > > On 7 May 2012 01:54, Doug Barton wrote: > > > > > > >> I got this with today's current, previous (working) kernel is r232719. > > > > > > >> > > > > > > >> panic: _mtx_lock_sleep: recursed on non-recursive mutex struct mount mtx > > > > > > >> @ /frontier/svn/head/sys/kern/vfs_subr.c:4595 > > > > > > > > > > > > ... > > > > > > > > > > > > > Please try this patch. > > > > > > > > > > > > > > Index: fs/ext2fs/ext2_vfsops.c > > > > > > > =================================================================== > > > > > > > --- fs/ext2fs/ext2_vfsops.c (revision 235108) > > > > > > > +++ fs/ext2fs/ext2_vfsops.c (working copy) > > > > > > > @@ -830,7 +830,6 @@ > > > > > > > /* > > > > > > > * Write back each (modified) inode. > > > > > > > */ > > > > > > > - MNT_ILOCK(mp); > > > > > > > loop: > > > > > > > MNT_VNODE_FOREACH_ALL(vp, mp, mvp) { > > > > > > > if (vp->v_type == VNON) { > > > > > > > > > > > > > > > > > > > Didn't help, sorry. I put 234385 through some pretty heavy load > > > > > > yesterday, and everything was fine. As soon as I move up to 234386, the > > > > > > panic triggered again. So I cleaned everything up, applied your patch, > > > > > > built a kernel from scratch, and rebooted. It was Ok for a few seconds > > > > > > after boot, then panic'ed again, I think in a different place, but I'm > > > > > > not sure because subsequent attempts to fsck the file systems caused new > > > > > > panics which overwrote the old ones before they could be saved. > > > > > > > > > > > > > > > > Another MNT_ILOCK was hiding few lines below, try this patch: > > > > > > > > > > http://student.agh.edu.pl/~mjguzik/patches/ext2fs-ilock.patch > > > > > > > > > > I've tested this a bit and I believe this fixes your problem. > > > > > > > > > > > > > Gave this a spin and found what looks like a deadlock: > > > > > > > > http://people.freebsd.org/~pho/stress/log/ext2fs.txt > > > > > > > > Not a new problem, it would seem. Same issue with 8.3-PRERELEASE r232656M. > > > > > > > > > > pid 2680 (fts) holds lock for vnode cb4be414 and tries to lock cc0ac15c > > > pid 2581 (openat) holds lock for vnode cc0ac15c and tries to lock cb4be414 > > > > > > openat calls rmdir foo/bar and ext2_rmdir unlocks and tries to lock > > > again foo's vnode. > > > > > > This is fairly easly reproducible with concurrently running mkdir and fts > > > testcase programs that are provided by stress2. > > > > > > I'll try to come up with a patch by the end of the week. > > > > > > > Easier way to reproduce: mkdir from stress2 and "while true; do find /mnt > > /dev/null; done" on another terminal. > > Assuming foo/bar directory tree, deadlock happens during removal of bar > with simultaneous lookup of .. in bar. > > Proposed trivial patch: > http://student.agh.edu.pl/~mjguzik/patches/ext2fs_rmdir-deadlock.patch > > If the lock cannot be acquired immediately unlocks 'bar' vnode and then > locks both vnodes in order. > > After patching this I ran into another issue - wrong vnode type panics > from cache_enter_time after calls by ext2_lookup. (It takes some time to > reproduce this, testcase as before.) > > It looks like ext2_lookup is actually adapted version of ufs_lookup and > lacks some bugfixes present in current ufs_lookup. I believe those > bugfixes address this bug. > > Here is my attempt to fix the problem (based on ufs_lookup changes): > http://student.agh.edu.pl/~mjguzik/patches/ext2fs_lookup-relookup.patch > I have tested these two patches for a few hours and they do indeed seem to fix the problem I had seen before. Regards, - Peter From owner-freebsd-current@FreeBSD.ORG Sun May 13 14:40:28 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BA851065672; Sun, 13 May 2012 14:40:28 +0000 (UTC) (envelope-from iwasaki@jp.FreeBSD.org) Received: from locore.org (ns01.locore.org [218.45.21.227]) by mx1.freebsd.org (Postfix) with ESMTP id 014A58FC0C; Sun, 13 May 2012 14:40:27 +0000 (UTC) Received: from localhost (celeron.v4.locore.org [192.168.0.10]) by locore.org (8.14.5/8.14.5/iwasaki) with ESMTP/inet id q4DEeFsq079851; Sun, 13 May 2012 23:40:15 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) Date: Sun, 13 May 2012 23:40:14 +0900 (JST) Message-Id: <20120513.234014.26960250.iwasaki@jp.FreeBSD.org> To: gperez@entel.upc.edu From: Mitsuru IWASAKI In-Reply-To: <4FAF696D.3060806@entel.upc.edu> References: <20120511.111019.90116031.iwasaki@jp.FreeBSD.org> <4FAF696D.3060806@entel.upc.edu> X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org Subject: Re: [CFT] SMP/i386 suspend/resume X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 14:40:28 -0000 Hi, Thanks for your report. From: Gustau P=E9rez i Querol Subject: Re: [CFT] SMP/i386 suspend/resume Date: Sun, 13 May 2012 09:57:33 +0200 Message-ID: <4FAF696D.3060806@entel.upc.edu> > Al 11/05/2012 04:10, En/na Mitsuru IWASAKI ha escrit: > > Hi > > > > I've been working on suspend/resume for SMP/i386 for a week > > and created patches against CURRENT, RELENG_9 and RELENG_8 > > available at: > > > > http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-CURRENT-20= 120511.diff > > http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-RELENG_9-2= 0120511.diff > > http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-RELENG_8-2= 0120511.diff > > > > A lot of portion of the patches was ported from amd64. > > Testing on Thinkpad X60 (Core Duo T2300), so far so good :) > > > > I'll commit them against CURRENT hopefully next week. > > > = > Reporting from an Acer Centrino Duo, running CURRENT r235266. The = > machine has an nvidia card (Ge7300go). The acpi_video and nvidia modu= les = > are there. > = > I did test it a few times with X running (plain twm) and worked ju= st = > fine. Setting hw.acpi.lid_switch_state=3DS3 allowed me to use the = > close-the-lid-to-sleep functionality. > = > The problem comes when I suspend the machine in the console. The = > machine resumes fine (I can ping and ssh it) but the screen remains = > black. I set hw.acpi.reset_video to 0 or 1 but no go. If I'm in a = > console but X is running, after the resume I can CTRL+ALT+F9 and get = my = > video back; then I can return to the console. If I don't have X runni= ng, = > I don't know how to get my console back. I think this is graphic driver problem. nvidia's driver seems to have correct suspend/resume method. http://www.nvidia.com/object/freebsd_archive.html Have you try it? Thanks > = > Thanks > = > = From owner-freebsd-current@FreeBSD.ORG Sun May 13 15:01:00 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 17CFE1065673; Sun, 13 May 2012 15:01:00 +0000 (UTC) (envelope-from iwasaki@jp.FreeBSD.org) Received: from locore.org (ns01.locore.org [218.45.21.227]) by mx1.freebsd.org (Postfix) with ESMTP id B814B8FC0A; Sun, 13 May 2012 15:00:59 +0000 (UTC) Received: from localhost (celeron.v4.locore.org [192.168.0.10]) by locore.org (8.14.5/8.14.5/iwasaki) with ESMTP/inet id q4DF0mlW079938; Mon, 14 May 2012 00:00:48 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) Date: Mon, 14 May 2012 00:00:48 +0900 (JST) Message-Id: <20120514.000048.08647576.iwasaki@jp.FreeBSD.org> To: david@catwhisker.org From: Mitsuru IWASAKI In-Reply-To: <20120513140302.GI13138@albert.catwhisker.org> References: <20120511132257.GA96585@freefall.freebsd.org> <20120513.225917.02304793.iwasaki@jp.FreeBSD.org> <20120513140302.GI13138@albert.catwhisker.org> X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org, dhw@freebsd.org Subject: Re: [CFT] SMP/i386 suspend/resume X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 15:01:00 -0000 Hi, From: David Wolfskill Subject: Re: [CFT] SMP/i386 suspend/resume Date: Sun, 13 May 2012 07:03:02 -0700 Message-ID: <20120513140302.GI13138@albert.catwhisker.org> > On Sun, May 13, 2012 at 10:59:17PM +0900, Mitsuru IWASAKI wrote: > > .... > > OK, we need some more investigation on RELENG_8 SMP. > > I think Core 2 Duo can run amd64, would like to confirm > > this problem can be reproduced only on i386 or not. > > Could you try same thing on amd64? > > Well, that will require a bit more work -- I'm pretty sure the hardware > can run amd64, but I only have i386 inistalled presently. And I'm > getting ready to head to the airport to fly back home now. Understood. I don't need to hurry on this. BTW, amd64 Live CD might be useful for this purpose. Thanks! > > Peace, > david > -- > David H. Wolfskill david@catwhisker.org > Depriving a girl or boy of an opportunity for education is evil. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. From owner-freebsd-current@FreeBSD.ORG Sun May 13 18:21:15 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 831541065674; Sun, 13 May 2012 18:21:15 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by mx1.freebsd.org (Postfix) with ESMTP id F2BE68FC1B; Sun, 13 May 2012 18:21:14 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id q4DILD2H002578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 13 May 2012 20:21:13 +0200 Received: from [10.1.170.94] (99.Red-80-27-97.dynamicIP.rima-tde.net [80.27.97.99]) (authenticated bits=0) by ackerman2.upc.es (8.14.4/8.14.4) with ESMTP id q4DIL9uQ022662 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 13 May 2012 20:21:10 +0200 References: <20120511.111019.90116031.iwasaki@jp.FreeBSD.org> <4FAF696D.3060806@entel.upc.edu> <20120513.234014.26960250.iwasaki@jp.FreeBSD.org> In-Reply-To: <20120513.234014.26960250.iwasaki@jp.FreeBSD.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <9E61BC2D-2654-40D9-936F-A99CD7AC1354@entel.upc.edu> X-Mailer: iPhone Mail (9B206) From: Gustau Perez Date: Sun, 13 May 2012 20:21:05 +0200 To: Mitsuru IWASAKI X-Scanned-By: MIMEDefang 2.70 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Sun, 13 May 2012 20:21:13 +0200 (CEST) Cc: "freebsd-acpi@freebsd.org" , "freebsd-current@freebsd.org" Subject: Re: [CFT] SMP/i386 suspend/resume X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 18:21:15 -0000 Enviat des del meu iTotxo El 13/05/2012, a les 16:40, Mitsuru IWASAKI va escr= iure: > Hi, Thanks for your report. >=20 > From: Gustau P=C3=A9rez i Querol > Subject: Re: [CFT] SMP/i386 suspend/resume > Date: Sun, 13 May 2012 09:57:33 +0200 > Message-ID: <4FAF696D.3060806@entel.upc.edu> >=20 >> Al 11/05/2012 04:10, En/na Mitsuru IWASAKI ha escrit: >>> Hi >>>=20 >>> I've been working on suspend/resume for SMP/i386 for a week >>> and created patches against CURRENT, RELENG_9 and RELENG_8 >>> available at: >>>=20 >>> http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-CURRENT-2012051= 1.diff >>> http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-RELENG_9-201205= 11.diff >>> http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-RELENG_8-201205= 11.diff >>>=20 >>> A lot of portion of the patches was ported from amd64. >>> Testing on Thinkpad X60 (Core Duo T2300), so far so good :) >>>=20 >>> I'll commit them against CURRENT hopefully next week. >>>=20 >>=20 >> Reporting from an Acer Centrino Duo, running CURRENT r235266. The=20 >> machine has an nvidia card (Ge7300go). The acpi_video and nvidia modules=20= >> are there. >>=20 >> I did test it a few times with X running (plain twm) and worked just=20= >> fine. Setting hw.acpi.lid_switch_state=3DS3 allowed me to use the=20 >> close-the-lid-to-sleep functionality. >>=20 >> The problem comes when I suspend the machine in the console. The=20 >> machine resumes fine (I can ping and ssh it) but the screen remains=20 >> black. I set hw.acpi.reset_video to 0 or 1 but no go. If I'm in a=20 >> console but X is running, after the resume I can CTRL+ALT+F9 and get my=20= >> video back; then I can return to the console. If I don't have X running,=20= >> I don't know how to get my console back. >=20 > I think this is graphic driver problem. nvidia's driver seems > to have correct suspend/resume method. > http://www.nvidia.com/object/freebsd_archive.html >=20 > Have you try it? Yes, it is running the propietary driver. Everything was done with it load= ed. Do you want me to try without the nvidia binary driver? OTOH, IIRC the console only test (without X) without acpi_video lead to f= reeze. No crash dump. The machine has no serial or fwire ports :( Thanks Gus =20 >=20 > Thanks >=20 >>=20 >> Thanks >>=20 >>=20 From owner-freebsd-current@FreeBSD.ORG Sun May 13 20:06:21 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAE2B1065677; Sun, 13 May 2012 20:06:21 +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 B09748FC1E; Sun, 13 May 2012 20:06: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 XAA11953; Sun, 13 May 2012 23:06:16 +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 1STf3Y-000Cv5-Jj; Sun, 13 May 2012 23:06:16 +0300 Message-ID: <4FB01437.6030608@FreeBSD.org> Date: Sun, 13 May 2012 23:06:15 +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: Bruce Cran References: <4FAF7343.8010808@cran.org.uk> In-Reply-To: <4FAF7343.8010808@cran.org.uk> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, freebsd-current , Jung-uk Kim Subject: Re: ACPI 'driver bug: Unable to set devclass' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 20:06:21 -0000 on 13/05/2012 11:39 Bruce Cran said the following: > I've just updated to -current and noticed the following errors in dmesg: > > acpi0: on motherboard > acpi0: Power Button (fixed) > acpi0: reservation of fee00000, 1000 (3) failed > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, bbf00000 (3) failed > driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > driver bug: Unable to set devclass (class: acpi_timer devname: (unknown)) > cpu0: on acpi0 > ACPI Warning: Incorrect checksum in table [OEMB] - 0x45, should be 0x44 > (20120420/tbutils-293) > driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > cpu2: on acpi0 > driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > cpu1: on acpi0 > driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > Can you produce an equivalent snippet with verbose logging enabled? I have a suspicion that these messages are a byproduct from r231161. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun May 13 22:35:59 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4B13F106566B for ; Sun, 13 May 2012 22:35:59 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 0B7F08FC15 for ; Sun, 13 May 2012 22:35:58 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q4DMZwcK083400 for freebsd-current@freebsd.org; Sun, 13 May 2012 22:35:58 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 9ub9k5fpr45rrsign9rzk95w4a; for freebsd-current@freebsd.org; Sun, 13 May 2012 22:35:58 +0000 (UTC) (envelope-from tim@kientzle.com) From: Tim Kientzle Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 13 May 2012 15:35:58 -0700 Message-Id: <2103A722-43BF-4BCF-AEDE-2E0CB13DF620@kientzle.com> To: freebsd-current FreeBSD Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: SUJ file system corruption. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 22:35:59 -0000 FYI: Saw a crash due to filesystem corruption when running SUJ. This is on a ARM AM335x system (BeagleBone) that is still pretty experimental, so I certainly cannot rule out other problems, but in case it means something to someone, here's the scenario: Reset the board to reboot (which is routine for these small embedded boards) and when it came back up it went through SUJ recovery, and then a little later the kernel panicked with this stack trace: rm: /var/run/dmesg.boot: Bad file descriptor panic: ffs_write: type 0xc1e86660 0 (0,1024) KDB: enter: panic [ thread pid 492 tid 100044 ] Stopped at $d: ldrb r15, [r15, r15, ror r15]! db> bt Tracing pid 492 tid 100044 td 0xc1dbc5c0 kdb_enter() at kdb_enter+0xc scp=0xc0321c08 rlv=0xc02f0024 (panic+0xe8) rsp=0xcb3e3ba8 rfp=0xcb3e3bbc r4=0x00000100 panic() at panic+0x10 scp=0xc02eff4c rlv=0xc043b2f4 (ffs_write+0x114) rsp=0xcb3e3bd0 rfp=0xcb3e3c48 ffs_write() at ffs_write+0xc scp=0xc043b1ec rlv=0xc049d55c (VOP_WRITE_APV+0x128) rsp=0xcb3e3c4c rfp=0xcb3e3cf0 r10=0x00020001 r9=0x00000000 r8=0x00000000 r7=0x00000000 r6=0x00000000 r5=0xcb3e3cfc r4=0xc055a78c VOP_WRITE_APV() at VOP_WRITE_APV+0xc scp=0xc049d440 rlv=0xc0390ca4 (vn_write+0x28c) rsp=0xcb3e3cf4 rfp=0xcb3e3d3c r7=0xcb3e3db4 r6=0xc1dc09a0 r5=0xc1e86660 r4=0x00000000 vn_write() at vn_write+0xc scp=0xc0390a24 rlv=0xc0339c88 (dofilewrite+0x98) rsp=0xcb3e3d40 rfp=0xcb3e3d70 r10=0x00000000 r9=0x00000400 r8=0xc1dc09a0 r7=0xc1dbc5c0 r6=0x00000001 r5=0xcb3e3db4 r4=0xffffffff dofilewrite() at dofilewrite+0xc scp=0xc0339bfc rlv=0xc033b508 (kern_writev+0x60) rsp=0xcb3e3d74 rfp=0xcb3e3da8 r10=0x00000000 r9=0xbfffecec r8=0xc1dbc5c0 r7=0xcb3e3db4 r6=0x00000001 r5=0x00000000 r4=0x00000000 kern_writev() at kern_writev+0xc scp=0xc033b4b4 rlv=0xc033b620 (sys_write+0x58) rsp=0xcb3e3dac rfp=0xcb3e3de0 r8=0x00000000 r7=0xc1d9a000 r6=0xc1dbc5c0 r5=0xcb3e3eac r4=0x2047c400 sys_write() at sys_write+0xc scp=0xc033b5d4 rlv=0xc048934c (swi_handler+0x2d0) rsp=0xcb3e3de4 rfp=0xcb3e3ea8 swi_handler() at swi_handler+0xc scp=0xc0489088 rlv=0xc047c440 (swi_entry+0x28) rsp=0xcb3e3eac rfp=0xbfffea5c r10=0x2017be50 r8=0x2041c000 r7=0x0000002d r6=0x00000400 r5=0x2017cc18 r4=0x2047c400 Rebooted and ran fsck -y without using the journal and noticed: ** Phase 2 - Check Pathnames UNALLOCATED I=244 OWNER=root MODE=0 SIZE=0 MTIME=Jan 1 00:00 1970 NAME=/var/run/dmesg.boot UNEXPECTED SOFT UPDATE INCONSISTENCY If I can find a way to reproduce this, I'll let you know. Cheers, Tim From owner-freebsd-current@FreeBSD.ORG Sun May 13 22:43:44 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 690CE1065676; Sun, 13 May 2012 22:43:44 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [93.89.92.64]) by mx1.freebsd.org (Postfix) with ESMTP id 1BB748FC19; Sun, 13 May 2012 22:43:44 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id F21AFE6503; Sun, 13 May 2012 23:43:54 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=P9vexZF1B51q irlqH785imScAc0=; b=eGGRiypUeZbejCC7VCRjFVF+x30aF2KLKuCvqrW3v5ql FMCWHxCqOgdE2nAYDxb1ECPWJWulCdiBWXu59KqAC1mUBgJSuOHaLy6NdSzcRH77 jd9WJZJ1Mw5LrfMq7k1PIYPKT2whNkmO+++PbF9QwiRFI3t2PiSZNa1T5k1u4B0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=e6LBdJ sroFCCakMx+ogdjam5qi63NAM9jBOMRxwe1x9yNJEHfHefTg6oTL0wh42llk2xtg 8c9phhnCc8zZ7aZTMEuoPAsPTtVQ6pi3+iQ+6C1oWPmoa/gFGdhjkSu+eV+VQF3j xd8ZxDT84wXX0PDpx0oTXDPioM946nV+yzcu8= Received: from [192.168.2.2] (unknown [89.194.1.1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 43F2BE6482; Sun, 13 May 2012 23:43:54 +0100 (BST) Message-ID: <4FB0391D.3040501@cran.org.uk> Date: Sun, 13 May 2012 23:43:41 +0100 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Andriy Gapon References: <4FAF7343.8010808@cran.org.uk> <4FB01437.6030608@FreeBSD.org> In-Reply-To: <4FB01437.6030608@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, freebsd-current , Jung-uk Kim Subject: Re: ACPI 'driver bug: Unable to set devclass' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 22:43:44 -0000 On 13/05/2012 21:06, Andriy Gapon wrote: > Can you produce an equivalent snippet with verbose logging enabled? I > have a suspicion that these messages are a byproduct from r231161. acpi0: reservation of fee00000, 1000 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, bbf00000 (3) failed acpi_sysresource: acpi_sysresource0 already exists; skipping it driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) acpi_timer: acpi_timer0 already exists; skipping it driver bug: Unable to set devclass (class: acpi_timer devname: (unknown)) cpu0: on acpi0 ACPI Warning: Incorrect checksum in table [OEMB] - 0x45, should be 0x44 (20120420/tbutils-293) ACPI: SSDT 0xbb7900f0 01340 (v01 DpgPmm P001Ist 00000011 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 01340 (v01 DpgPmm P001Ist 00000011 INTL 20051117) ACPI: SSDT 0xbb791430 004F4 (v01 PmRef P001Cst 00003001 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 004F4 (v01 PmRef P001Cst 00003001 INTL 20051117) acpi_sysresource: acpi_sysresource2 already exists; skipping it driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) cpu2: on acpi0 acpi_sysresource: acpi_sysresource1 already exists; skipping it driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) cpu1: on acpi0 acpi_sysresource: acpi_sysresource3 already exists; skipping it driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sun May 13 23:15:19 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id B133E106564A for ; Sun, 13 May 2012 23:15:19 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 37A4114D8EE; Sun, 13 May 2012 23:15:19 +0000 (UTC) Message-ID: <4FB04084.5070202@FreeBSD.org> Date: Sun, 13 May 2012 16:15:16 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Bryan Drewery References: <4FAF291C.8090401@shatow.net> In-Reply-To: <4FAF291C.8090401@shatow.net> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: [review request] usr.sbin/service - make showing files configurable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 23:15:19 -0000 On 5/12/2012 8:23 PM, Bryan Drewery wrote: > Hi, > > I found service(8) to be inconsistent that it listed files with `service > -e`, but plain services with `service -l` That behavior is by design. Thanks for your interest, Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Sun May 13 23:36:02 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 1D463106566B; Sun, 13 May 2012 23:36:02 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 89E3614DBCD; Sun, 13 May 2012 23:36:01 +0000 (UTC) Message-ID: <4FB0455F.9010602@FreeBSD.org> Date: Sun, 13 May 2012 16:35:59 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ulrich Spoerlein References: <201205111608.q4BG8ppa090644@svn.freebsd.org> In-Reply-To: <201205111608.q4BG8ppa090644@svn.freebsd.org> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current , src-committers@freebsd.org, svn-src-user@freebsd.org Subject: Re: svn commit: r235275 - projects user X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 23:36:02 -0000 When you proposed these changes not only did I not see a consensus for you to move forward, I saw a non-zero number of people push back. Why did you proceed? Doug On 5/11/2012 9:08 AM, Ulrich Spoerlein wrote: > Author: uqs > Date: Fri May 11 16:08:51 2012 > New Revision: 235275 > URL: http://svn.freebsd.org/changeset/base/235275 > > Log: > Update guidelines on user/ and projects/ > > The goal is to make it clearer where future branches should be created. A > consistent layout under projects/ would also help with conversions to other > VCSes that do not follow the everything-is-a-subdir dogma. > > TL;DR > - If it's a branch of head that you want to merge back -> projects/ > - If it's something else -> user/your-login/ (e.g. portmaster, stress2, etc.) > > Discussed on: developers > Silence by: peter > > Modified: > user/GUIDELINES.txt > > Changes in other areas also in this revision: > Modified: > projects/GUIDELINES.txt > > Modified: user/GUIDELINES.txt > ============================================================================== > --- user/GUIDELINES.txt Fri May 11 16:04:55 2012 (r235274) > +++ user/GUIDELINES.txt Fri May 11 16:08:51 2012 (r235275) > @@ -1,16 +1,9 @@ > $FreeBSD$ > > -Golden rules: > -Rule #1: TAKE IT EASY! DON'T RUSH AND MAKE A MESS! ASK IF NEEDED! > -Rule #2: See rule #1, repeat as needed > +Guidelines for what can go in /user > +----------------------------------- > > -Peril sensitive sunglasses advisory: > -This is in flux. Expect refinement. Expect typos. > - > -Guidelines for what can go in /user and /projects > -------------------------------------------------- > - > -First of all, eveyrbody needs to keep in mind that this repository is > +First of all, everybody needs to keep in mind that this repository is > replicated as a unit. Anything that goes into the repository uses project > and volunteer resources. Once something goes in, it essentially never comes > out. Therefore, these are not dumping grounds to put random junk in the > @@ -19,82 +12,39 @@ tree that we have to mirror forever. > General guidelines: > > * Should be relevant to FreeBSD. > -* Should be at least concievably of interest to somebody else. > -* Should be in a format that is suitable to merge into the base tree. > +* Should be at least conceivably of interest to somebody else. > * Should be something that is worth people's time to read commit mail for. > * Write decent commit messages! > > +The difference between /projects and /user wasn't very clear in the past. > +Going forward /projects is reserved for branches of FreeBSD itself for possible > +re-integration into /head. Branches shall not be nested into e.g. > +/projects/foo/stable8, instead /projects/foo_stable8 shall be used. > > -The difference between /projects and /user is mostly one of intentions. > - > -If some WIP is intended to be committed to the main src tree, then it > -should go in /projects/$name/*. We encourage people to subscribe to projects > -commit messages. The reason is that WIP in projects can be expected to hit > -the base tree at some point. > - > -If some WIP is more of an experiment or speculative, that might not ever be > -merged, then it goes in /user/$username/$name/*. We don't encourage > -people to subscribe to user commit messages. > - > -If it is something unrelated to the src tree, it should probably go elsewhere. > -There will be a separate repostory made available for such things, whether it > -be a special version of mysql or xorg or gcc or whatever. > - > +/user can be used for tools and software tightly related to FreeBSD, but which > +is not a copy/branch of FreeBSD itself. > > Layout: > -Since this is for WIP that can concievably be merged, there is an argument > -that can be made that teaching the pre-commit scripts to sanity check WIP > -as it goes, rather than having a mammoth fixup being needed prior to merging. > - > -For that to work, the layout has to be predictable. eg: a branch of > -"head/sys/*" for a project called "ia65" should be /projects/ia65/sys/*. > -An experimental X11-aware verison of bin/ls/* in a user directory for jdoe > -would be /user/jdoe/x11-ls/bin/ls/*. > - > > -Creation and merging: > - > -Merging is in flux. The procedure as understood right now: > - > -Assume projects/ia65/sys. $BASE="svn+ssh://svn.freebsd.org/base" > +Since this is for auxiliary/experimental projects that might not be branched > +from head, an argument can be made that we teach the pre-commit scripts to > +sanity check WIP as it goes in. > > Initial creation: > - $ svn cp --parents $BASE/head/sys $BASE/projects/ia65/sys > + Assume user/pho/stress2. BASE="svn+ssh://svn.freebsd.org/base" > > -Then check it out: > - $ svn co $BASE/projects/ia65 > + $ svn mkdir $BASE/user/pho/stress2 > > -To integrate changes from head into your branch: > - $ cd ia65/sys ; svn update; svn status | read output! Should preferably be clean. > - (you may prefer to do merges in a second, clean checkout. It will be easier!) > - $ svn merge $BASE/head/sys > - (this merges head/sys/* into ., which is projects/ia65/sys) > +Then check it out: > + $ svn co $BASE/user/pho/stress2 > + $ hack, hack, hack > + $ svn add . > + (should schedule all files/dirs for addition) > + $ svn status > + (verify all files you want added, and only those are scheduled) > $ svn commit > > -To merge your changes into head/sys. > - $ mail -s 'Is it ok to merge projects/ia65 to head?' peter@freebsd.org > - $ wait_for_reply (the point is to have somebody on hand for the first > - timeto help rescue you if things go horribly wrong.) > - (set up a clean checkout of head/sys and projects/ia65/sys. MUST BE CLEAN!!) > - $ cd work > - $ svn co $BASE/head/sys > - $ svn co $BASE/projects/ia65/sys > - (If you've already got clean checkouts handy, replace with appropriate > - svn update commands) > - $ svn info head - NOTE CHANGE NUMBER!!! assume 12345 for this example. > - (now, bring projects/ia65 up to date with head, AS YOU JUST CHECKED IT OUT) > - $ svn merge $BASE/head/sys@12345 projects/ia65/sys > - (resolve conflicts) > - $ svn commit projects/ia65/sys > - (now, projects/ia65 is in sync with @12345, as is your head checkout) > - (reverse merge to base tree!) > - $ svn merge $BASE/projects/ia65/sys head/sys > - (resolve conflicts) > - $ svn commit head/sys > - $ profit! > - (regular svn users might wonder about merge --reintegrate. Our tree breaks > - it, sorry. We can't use it.) > - > -Tags: > - Place tags in your /user area if possible, even if the origin is a project. > - Tag by using svn cp $BASE/projects/xxx $BASE/user/jdoe/yyy. > +Other: > + > +If it is not covered here, and there's no established practice of doing what > +you're trying to achieve, always ask your peers first! > -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Mon May 14 00:03:19 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F134B106566C for ; Mon, 14 May 2012 00:03:18 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7D8DB8FC15 for ; Mon, 14 May 2012 00:02:55 +0000 (UTC) Received: by bkvi18 with SMTP id i18so3334287bkv.13 for ; Sun, 13 May 2012 17:02:49 -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=WvA34WXdv2H15smraXwvWRyAhnkYR0/NWTwlD61w7dE=; b=h+V8nGqa3hIkh8Xlna1znVZe11Uy1iRcfwnXhkc7ZwBtx7QSuGdEPAZ/Og4kVo4rwn jVuLQ4vu4VjjRpc6WVkSZsWs1QtDqqFpygsejdPlVLBG/0meciunEsfETU0w2e2tyCjL 2PhURMNqjPxkaZ0tiKRZJWSALYDadUYjPMr0hHpCAeWqyb3vh53Zi+/W1L1cJfoc2UTO vUID4go+wTIKp8Ko/aWE0aRAPs9xJKaiW9qh/lN/62QU+fLsOTAdL1OFZLyYSBx5AcC9 OaNdwmbduZhJ1OCeCW5ceuHnhX6YgocWKlqw8OMAY27ok147XphRNMwrj+2RLAdbY8J/ bt3w== MIME-Version: 1.0 Received: by 10.204.133.200 with SMTP id g8mr2232653bkt.110.1336953769275; Sun, 13 May 2012 17:02:49 -0700 (PDT) Received: by 10.204.157.11 with HTTP; Sun, 13 May 2012 17:02:49 -0700 (PDT) Date: Sun, 13 May 2012 20:02:49 -0400 Message-ID: From: Outback Dingo To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 Subject: FYI FreeBSD clang build fails on new import of sort X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 00:03:19 -0000 trying to rerun a clang build of FreeBSD CURRENT fails on new import of sort, cat /etc/src.conf WITH_CLANG_IS_CC=1 make world ---------------------SNIP--------------------------- clang -O2 -pipe -DSORT_THREADS -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -c /usr/src/usr.bin/sort/coll.c clang -O2 -pipe -DSORT_THREADS -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -c /usr/src/usr.bin/sort/file.c /usr/src/usr.bin/sort/file.c:601:12: error: format string is not a string literal (potentially insecure) [-Werror,-Wformat-security] err(2, getstr(7)); ^~~~~~~~~ /usr/src/usr.bin/sort/sort.h:52:20: note: expanded from macro 'getstr' #define getstr(n) catgets(catalog, 1, n, nlsstr[n]) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/src/usr.bin/sort/file.c:942:11: error: format string is not a string literal (potentially insecure) [-Werror,-Wformat-security] err(2, getstr(8)); ^~~~~~~~~ /usr/src/usr.bin/sort/sort.h:52:20: note: expanded from macro 'getstr' #define getstr(n) catgets(catalog, 1, n, nlsstr[n]) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/src/usr.bin/sort/file.c:1279:10: error: format string is not a string literal (potentially insecure) [-Werror,-Wformat-security] err(2, getstr(9)); ^~~~~~~~~ /usr/src/usr.bin/sort/sort.h:52:20: note: expanded from macro 'getstr' #define getstr(n) catgets(catalog, 1, n, nlsstr[n]) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/src/usr.bin/sort/file.c:1295:12: error: format string is not a string literal (potentially insecure) [-Werror,-Wformat-security] errx(2, getstr(10)); ^~~~~~~~~~ /usr/src/usr.bin/sort/sort.h:52:20: note: expanded from macro 'getstr' #define getstr(n) catgets(catalog, 1, n, nlsstr[n]) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 4 errors generated. *** [file.o] Error code 1 Stop in /usr/src/usr.bin/sort. From owner-freebsd-current@FreeBSD.ORG Mon May 14 00:49:15 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEEDD106566C for ; Mon, 14 May 2012 00:49:14 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8EDF48FC1A for ; Mon, 14 May 2012 00:49:14 +0000 (UTC) Received: by vbmv11 with SMTP id v11so5935166vbm.13 for ; Sun, 13 May 2012 17:49:13 -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:content-transfer-encoding; bh=bk7zDYv+5keVcW5k5A8ipHHokObrA2l3dYez4Ua7YnE=; b=DbzsrsAW5UnhUhAbXNC6iSBaB3ep0quYt8IZdAuQWpRM1neRwETe3Q+SN2p21PVwWF 02K73BzqKLJvNJ1QzLxwRQT5iUxwEoz3ivA9gYwuxaJDGA/bR8LuzikwI4EAjayhv9lP AsRit6wfEUlSLnEMzJ19IO2SpfAwG5SfkA/3pOkVHcpx1H1+vKqyOhyvf0g93I9SY3Qr MgHJaAmj+1HFut/WZkk3TNmyjByKQdDY5qIuy5NRiHgD+gRcp1SvWxyoUPviCZev8ael LjmXfOBT6k5OC1liZJD2BuBab54Wx9eW23ME/qNeKdpr6poIQan7qpJMN5xAGyKhmc80 /vmg== MIME-Version: 1.0 Received: by 10.52.100.9 with SMTP id eu9mr3208925vdb.28.1336956553688; Sun, 13 May 2012 17:49:13 -0700 (PDT) Received: by 10.220.7.148 with HTTP; Sun, 13 May 2012 17:49:13 -0700 (PDT) In-Reply-To: References: Date: Sun, 13 May 2012 17:49:13 -0700 Message-ID: From: Garrett Cooper To: Outback Dingo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current Subject: Re: FYI FreeBSD clang build fails on new import of sort X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 00:49:15 -0000 On Sun, May 13, 2012 at 5:02 PM, Outback Dingo wro= te: > trying to rerun a clang build of FreeBSD CURRENT fails on new import of s= ort, > > cat /etc/src.conf > WITH_CLANG_IS_CC=3D1 > make world > ---------------------SNIP--------------------------- > clang -O2 -pipe =A0-DSORT_THREADS -std=3Dgnu99 -Qunused-arguments > -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch > -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline > -Wnested-externs -Wredundant-decls -Wold-style-definition > -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -c > /usr/src/usr.bin/sort/coll.c > clang -O2 -pipe =A0-DSORT_THREADS -std=3Dgnu99 -Qunused-arguments > -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch > -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline > -Wnested-externs -Wredundant-decls -Wold-style-definition > -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -c > /usr/src/usr.bin/sort/file.c > /usr/src/usr.bin/sort/file.c:601:12: error: format string is not a > string literal (potentially insecure) [-Werror,-Wformat-security] > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0err(2, get= str(7)); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 ^~~~~~~~~ > /usr/src/usr.bin/sort/sort.h:52:20: note: expanded from macro 'getstr' > #define getstr(n) =A0 =A0 =A0 =A0catgets(catalog, 1, n, nlsstr[n]) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~ > /usr/src/usr.bin/sort/file.c:942:11: error: format string is not a > string literal (potentially insecure) [-Werror,-Wformat-security] > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0err(2, getstr(8)); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^~~~~~~~~ > /usr/src/usr.bin/sort/sort.h:52:20: note: expanded from macro 'getstr' > #define getstr(n) =A0 =A0 =A0 =A0catgets(catalog, 1, n, nlsstr[n]) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~ > /usr/src/usr.bin/sort/file.c:1279:10: error: format string is not a > string literal (potentially insecure) [-Werror,-Wformat-security] > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0err(2, getstr(9)); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^~~~~~~~~ > /usr/src/usr.bin/sort/sort.h:52:20: note: expanded from macro 'getstr' > #define getstr(n) =A0 =A0 =A0 =A0catgets(catalog, 1, n, nlsstr[n]) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~ > /usr/src/usr.bin/sort/file.c:1295:12: error: format string is not a > string literal (potentially insecure) [-Werror,-Wformat-security] > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0errx(2, getstr(10)); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^~~~~~~~~~ > /usr/src/usr.bin/sort/sort.h:52:20: note: expanded from macro 'getstr' > #define getstr(n) =A0 =A0 =A0 =A0catgets(catalog, 1, n, nlsstr[n]) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~ > 4 errors generated. > *** [file.o] Error code 1 > > Stop in /usr/src/usr.bin/sort. Yeah... errx(2, getstr(9)) should be errx(2, "%s", getstr(9))... -Garrett From owner-freebsd-current@FreeBSD.ORG Mon May 14 01:09:55 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B93F3106567F for ; Mon, 14 May 2012 01:09:55 +0000 (UTC) (envelope-from oleg.moskalenko@citrix.com) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) by mx1.freebsd.org (Postfix) with ESMTP id 776448FC21 for ; Mon, 14 May 2012 01:09:55 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.75,582,1330923600"; d="scan'208";a="194629445" Received: from sjcpmailmx02.citrite.net ([10.216.14.75]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 13 May 2012 21:09:48 -0400 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.73]) by SJCPMAILMX02.citrite.net ([10.216.14.75]) with mapi; Sun, 13 May 2012 18:09:47 -0700 From: Oleg Moskalenko To: 'Garrett Cooper' , Outback Dingo Date: Sun, 13 May 2012 18:09:47 -0700 Thread-Topic: FYI FreeBSD clang build fails on new import of sort Thread-Index: Ac0xa4DhISbtapomT2elGVqZ3f2o2gAArAAg Message-ID: <031222CBCF33214AB2EB4ABA279428A3011A2C2D1AD3@SJCPMAILBOX01.citrite.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: freebsd-current Subject: RE: FYI FreeBSD clang build fails on new import of sort X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 01:09:55 -0000 Thank you for the error report, we are going to fix it ASAP. Oleg > -----Original Message----- > From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- > current@freebsd.org] On Behalf Of Garrett Cooper > Sent: Sunday, May 13, 2012 5:49 PM > To: Outback Dingo > Cc: freebsd-current > Subject: Re: FYI FreeBSD clang build fails on new import of sort >=20 > On Sun, May 13, 2012 at 5:02 PM, Outback Dingo > wrote: > > trying to rerun a clang build of FreeBSD CURRENT fails on new import > of sort, > > > > cat /etc/src.conf > > WITH_CLANG_IS_CC=3D1 > > make world > > ---------------------SNIP--------------------------- > > clang -O2 -pipe =A0-DSORT_THREADS -std=3Dgnu99 -Qunused-arguments > > -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W > > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > > -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch > > -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline > > -Wnested-externs -Wredundant-decls -Wold-style-definition > > -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -c > > /usr/src/usr.bin/sort/coll.c > > clang -O2 -pipe =A0-DSORT_THREADS -std=3Dgnu99 -Qunused-arguments > > -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W > > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > > -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch > > -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline > > -Wnested-externs -Wredundant-decls -Wold-style-definition > > -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -c > > /usr/src/usr.bin/sort/file.c > > /usr/src/usr.bin/sort/file.c:601:12: error: format string is not a > > string literal (potentially insecure) [-Werror,-Wformat-security] > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0err(2, g= etstr(7)); > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 ^~~~~~~~~ > > /usr/src/usr.bin/sort/sort.h:52:20: note: expanded from macro > 'getstr' > > #define getstr(n) =A0 =A0 =A0 =A0catgets(catalog, 1, n, nlsstr[n]) > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~ > > /usr/src/usr.bin/sort/file.c:942:11: error: format string is not a > > string literal (potentially insecure) [-Werror,-Wformat-security] > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0err(2, getstr(8)); > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^~~~~~~~~ > > /usr/src/usr.bin/sort/sort.h:52:20: note: expanded from macro > 'getstr' > > #define getstr(n) =A0 =A0 =A0 =A0catgets(catalog, 1, n, nlsstr[n]) > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~ > > /usr/src/usr.bin/sort/file.c:1279:10: error: format string is not a > > string literal (potentially insecure) [-Werror,-Wformat-security] > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0err(2, getstr(9)); > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^~~~~~~~~ > > /usr/src/usr.bin/sort/sort.h:52:20: note: expanded from macro > 'getstr' > > #define getstr(n) =A0 =A0 =A0 =A0catgets(catalog, 1, n, nlsstr[n]) > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~ > > /usr/src/usr.bin/sort/file.c:1295:12: error: format string is not a > > string literal (potentially insecure) [-Werror,-Wformat-security] > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0errx(2, getstr(10)); > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^~~~~~~~= ~~ > > /usr/src/usr.bin/sort/sort.h:52:20: note: expanded from macro > 'getstr' > > #define getstr(n) =A0 =A0 =A0 =A0catgets(catalog, 1, n, nlsstr[n]) > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~ > > 4 errors generated. > > *** [file.o] Error code 1 > > > > Stop in /usr/src/usr.bin/sort. >=20 > Yeah... errx(2, getstr(9)) should be errx(2, "%s", getstr(9))... > -Garrett > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current- > unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon May 14 02:06:03 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 09CBD106566C for ; Mon, 14 May 2012 02:06:03 +0000 (UTC) (envelope-from oleg.moskalenko@citrix.com) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) by mx1.freebsd.org (Postfix) with ESMTP id BBFE58FC12 for ; Mon, 14 May 2012 02:06:02 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.75,583,1330923600"; d="scan'208";a="25140441" Received: from sjcpmailmx02.citrite.net ([10.216.14.75]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 13 May 2012 22:05:55 -0400 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.73]) by SJCPMAILMX02.citrite.net ([10.216.14.75]) with mapi; Sun, 13 May 2012 19:05:55 -0700 From: Oleg Moskalenko To: 'Garrett Cooper' , Outback Dingo Date: Sun, 13 May 2012 19:05:55 -0700 Thread-Topic: FYI FreeBSD clang build fails on new import of sort Thread-Index: Ac0xa4DhISbtapomT2elGVqZ3f2o2gACf6nA Message-ID: <031222CBCF33214AB2EB4ABA279428A3011A2C2D1AD5@SJCPMAILBOX01.citrite.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: freebsd-current Subject: RE: FYI FreeBSD clang build fails on new import of sort X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 02:06:03 -0000 Obviously, the option -Wall implies -Wformat-security in clang. The compile= r that we used for the development does not turns on -Wformat-security with= -Wall. It is an easy fix, we will submit it soon. Thanks Oleg > -----Original Message----- > From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- > current@freebsd.org] On Behalf Of Garrett Cooper > Sent: Sunday, May 13, 2012 5:49 PM > To: Outback Dingo > Cc: freebsd-current > Subject: Re: FYI FreeBSD clang build fails on new import of sort >=20 > On Sun, May 13, 2012 at 5:02 PM, Outback Dingo > wrote: > > trying to rerun a clang build of FreeBSD CURRENT fails on new import > of sort, > > > > cat /etc/src.conf > > WITH_CLANG_IS_CC=3D1 > > make world > > ---------------------SNIP--------------------------- > > clang -O2 -pipe =A0-DSORT_THREADS -std=3Dgnu99 -Qunused-arguments > > -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W > > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > > -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch > > -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline > > -Wnested-externs -Wredundant-decls -Wold-style-definition > > -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -c > > /usr/src/usr.bin/sort/coll.c > > clang -O2 -pipe =A0-DSORT_THREADS -std=3Dgnu99 -Qunused-arguments > > -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W > > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > > -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch > > -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline > > -Wnested-externs -Wredundant-decls -Wold-style-definition > > -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -c > > /usr/src/usr.bin/sort/file.c > > /usr/src/usr.bin/sort/file.c:601:12: error: format string is not a > > string literal (potentially insecure) [-Werror,-Wformat-security] > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0err(2, g= etstr(7)); > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 ^~~~~~~~~ > > /usr/src/usr.bin/sort/sort.h:52:20: note: expanded from macro > 'getstr' > > #define getstr(n) =A0 =A0 =A0 =A0catgets(catalog, 1, n, nlsstr[n]) > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~ > > /usr/src/usr.bin/sort/file.c:942:11: error: format string is not a > > string literal (potentially insecure) [-Werror,-Wformat-security] > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0err(2, getstr(8)); > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^~~~~~~~~ > > /usr/src/usr.bin/sort/sort.h:52:20: note: expanded from macro > 'getstr' > > #define getstr(n) =A0 =A0 =A0 =A0catgets(catalog, 1, n, nlsstr[n]) > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~ > > /usr/src/usr.bin/sort/file.c:1279:10: error: format string is not a > > string literal (potentially insecure) [-Werror,-Wformat-security] > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0err(2, getstr(9)); > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^~~~~~~~~ > > /usr/src/usr.bin/sort/sort.h:52:20: note: expanded from macro > 'getstr' > > #define getstr(n) =A0 =A0 =A0 =A0catgets(catalog, 1, n, nlsstr[n]) > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~ > > /usr/src/usr.bin/sort/file.c:1295:12: error: format string is not a > > string literal (potentially insecure) [-Werror,-Wformat-security] > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0errx(2, getstr(10)); > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^~~~~~~~= ~~ > > /usr/src/usr.bin/sort/sort.h:52:20: note: expanded from macro > 'getstr' > > #define getstr(n) =A0 =A0 =A0 =A0catgets(catalog, 1, n, nlsstr[n]) > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~ > > 4 errors generated. > > *** [file.o] Error code 1 > > > > Stop in /usr/src/usr.bin/sort. >=20 > Yeah... errx(2, getstr(9)) should be errx(2, "%s", getstr(9))... > -Garrett > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current- > unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon May 14 04:16:25 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9A99106566C; Mon, 14 May 2012 04:16:25 +0000 (UTC) (envelope-from iwasaki@jp.FreeBSD.org) Received: from locore.org (ns01.locore.org [218.45.21.227]) by mx1.freebsd.org (Postfix) with ESMTP id 7BB448FC0C; Mon, 14 May 2012 04:16:25 +0000 (UTC) Received: from localhost (celeron.v4.locore.org [192.168.0.10]) by locore.org (8.14.5/8.14.5/iwasaki) with ESMTP/inet id q4E4GHXD082844; Mon, 14 May 2012 13:16:17 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) Date: Mon, 14 May 2012 13:16:17 +0900 (JST) Message-Id: <20120514.131617.129792413.iwasaki@jp.FreeBSD.org> To: gperez@entel.upc.edu From: Mitsuru IWASAKI In-Reply-To: <9E61BC2D-2654-40D9-936F-A99CD7AC1354@entel.upc.edu> References: <4FAF696D.3060806@entel.upc.edu> <20120513.234014.26960250.iwasaki@jp.FreeBSD.org> <9E61BC2D-2654-40D9-936F-A99CD7AC1354@entel.upc.edu> X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org Subject: Re: [CFT] SMP/i386 suspend/resume X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 04:16:25 -0000 Hi, > >> Reporting from an Acer Centrino Duo, running CURRENT r235266. The > >> machine has an nvidia card (Ge7300go). The acpi_video and nvidia modules > >> are there. > >> > >> I did test it a few times with X running (plain twm) and worked just > >> fine. Setting hw.acpi.lid_switch_state=S3 allowed me to use the > >> close-the-lid-to-sleep functionality. > >> > >> The problem comes when I suspend the machine in the console. The > >> machine resumes fine (I can ping and ssh it) but the screen remains > >> black. I set hw.acpi.reset_video to 0 or 1 but no go. If I'm in a > >> console but X is running, after the resume I can CTRL+ALT+F9 and get my > >> video back; then I can return to the console. If I don't have X running, > >> I don't know how to get my console back. > > > > I think this is graphic driver problem. nvidia's driver seems > > to have correct suspend/resume method. > > http://www.nvidia.com/object/freebsd_archive.html > > > > Have you try it? > > Yes, it is running the propietary driver. Everything was done with it loaded. Do you want me to try without the nvidia binary driver? Yes, if it doesn't bother you. Hmmm, it doesn't seem related with my SMP/i386 sleep patches. Could you try also Uni-processer kernel (w/o SMP and apic from config file) without my patches? > OTOH, IIRC the console only test (without X) without acpi_video lead to freeze. No crash dump. The machine has no serial or fwire ports :( We can improve video initialization on another opportunity. Linux have many video hacks while we have only hw.acpi.reset_video ;) http://www.kernel.org/doc/Documentation/power/video.txt I believe there are some solutions for you in this document, then we can implement them in our source if found. Thanks From owner-freebsd-current@FreeBSD.ORG Mon May 14 06:45:00 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5A301106566B; Mon, 14 May 2012 06:45:00 +0000 (UTC) (envelope-from joel@vnode.se) Received: from mail.vnode.se (mail.vnode.se [62.119.52.80]) by mx1.freebsd.org (Postfix) with ESMTP id 0B5718FC17; Mon, 14 May 2012 06:44:59 +0000 (UTC) Received: from mail.vnode.se (localhost [127.0.0.1]) by mail.vnode.se (Postfix) with ESMTP id EB55EE3F07A; Mon, 14 May 2012 08:39:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at vnode.se Received: from mail.vnode.se ([127.0.0.1]) by mail.vnode.se (mail.vnode.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWowGX82UZTh; Mon, 14 May 2012 08:39:36 +0200 (CEST) Received: from goofy01.vnodelab.local (jd.benders.se [212.247.52.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.vnode.se (Postfix) with ESMTPSA id AB4FBE3F079; Mon, 14 May 2012 08:39:36 +0200 (CEST) Date: Mon, 14 May 2012 08:39:35 +0200 From: Joel Dahl To: Konstantin Belousov Message-ID: <20120514063934.GG6475@goofy01.vnodelab.local> References: <20120512213950.GZ2358@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120512213950.GZ2358@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: x11@freebsd.org, current@freebsd.org Subject: Re: Intel GPU driver import X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 06:45:00 -0000 On 13-05-2012 0:39, Konstantin Belousov wrote: > The positive points to the second approach is that we still have older > kernel drivers around. Also, I have more freedom in changing the DRM > core, without fearing breakage in the DRI1 land. Since I do not really > want to deal with Gen2-3 hardware What is Gen2-3 hardware in this context? Can you give examples? -- Joel From owner-freebsd-current@FreeBSD.ORG Mon May 14 06:54:35 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DDFF106564A for ; Mon, 14 May 2012 06:54:35 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id D7F7D8FC14 for ; Mon, 14 May 2012 06:54:34 +0000 (UTC) Received: from ncsd.bris.ac.uk ([137.222.10.59] helo=ncs.bris.ac.uk) by dirj.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1STpAq-00045G-0Z for freebsd-current@freebsd.org; Mon, 14 May 2012 07:54:28 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1STpAp-0005ZL-S1 for freebsd-current@freebsd.org; Mon, 14 May 2012 07:54:27 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5) with ESMTP id q4E6sRdQ036892 for ; Mon, 14 May 2012 07:54:27 +0100 (BST) (envelope-from mexas@bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5/Submit) id q4E6sRvb036891 for freebsd-current@freebsd.org; Mon, 14 May 2012 07:54:27 +0100 (BST) (envelope-from mexas@bris.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bris.ac.uk using -f Date: Mon, 14 May 2012 07:54:27 +0100 From: Anton Shterenlikht To: freebsd-current@freebsd.org Message-ID: <20120514065427.GA36884@mech-cluster241.men.bris.ac.uk> Mail-Followup-To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: [clang] r234928 amd64 buildworld error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 06:54:35 -0000 clang -O2 -pipe -DSORT_THREADS -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict -prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwri te-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts - Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-s ign -Wno-empty-body -Wno-string-plus-int -c /usr/src/usr.bin/sort/file.c /usr/src/usr.bin/sort/file.c:601:12: error: format string is not a string literal (potentially insecure) [-Werror,-Wformat-security] err(2, getstr(7)); ^~~~~~~~~ /usr/src/usr.bin/sort/sort.h:52:20: note: expanded from macro 'getstr' #define getstr(n) catgets(catalog, 1, n, nlsstr[n]) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/src/usr.bin/sort/file.c:942:11: error: format string is not a string literal (potentially insecure) [-Werror,-Wformat-security] err(2, getstr(8)); ^~~~~~~~~ /usr/src/usr.bin/sort/sort.h:52:20: note: expanded from macro 'getstr' #define getstr(n) catgets(catalog, 1, n, nlsstr[n]) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/src/usr.bin/sort/file.c:1279:10: error: format string is not a string literal (potentially insecure) [-Werror,-Wformat-security] err(2, getstr(9)); ^~~~~~~~~ /usr/src/usr.bin/sort/sort.h:52:20: note: expanded from macro 'getstr' #define getstr(n) catgets(catalog, 1, n, nlsstr[n]) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/src/usr.bin/sort/file.c:1295:12: error: format string is not a string literal (potentially insecure) [-Werror,-Wformat-security] errx(2, getstr(10)); ^~~~~~~~~~ /usr/src/usr.bin/sort/sort.h:52:20: note: expanded from macro 'getstr' #define getstr(n) catgets(catalog, 1, n, nlsstr[n]) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 4 errors generated. *** [file.o] Error code 1 Stop in /usr/src/usr.bin/sort. *** [all] Error code 1 -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Mon May 14 07:00:33 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91B901065672 for ; Mon, 14 May 2012 07:00:33 +0000 (UTC) (envelope-from oleg.moskalenko@citrix.com) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) by mx1.freebsd.org (Postfix) with ESMTP id 517AF8FC12 for ; Mon, 14 May 2012 07:00:33 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.75,584,1330923600"; d="scan'208";a="194648255" Received: from sjcpmailmx02.citrite.net ([10.216.14.75]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 May 2012 03:00:32 -0400 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.73]) by SJCPMAILMX02.citrite.net ([10.216.14.75]) with mapi; Mon, 14 May 2012 00:00:31 -0700 From: Oleg Moskalenko To: 'Anton Shterenlikht' , "freebsd-current@freebsd.org" Date: Mon, 14 May 2012 00:00:31 -0700 Thread-Topic: [clang] r234928 amd64 buildworld error Thread-Index: Ac0xnornPvabHR9eT1GDaBwOCHkEnwAAD4vA Message-ID: <031222CBCF33214AB2EB4ABA279428A3011A2C2D1AD6@SJCPMAILBOX01.citrite.net> References: <20120514065427.GA36884@mech-cluster241.men.bris.ac.uk> In-Reply-To: <20120514065427.GA36884@mech-cluster241.men.bris.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Subject: RE: [clang] r234928 amd64 buildworld error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 07:00:33 -0000 We already have a fix for this problem with clang, and we are going to subm= it it soon. gcc behaves differently on the same sources, they can be compiled just fine= with gcc. Thanks Oleg > -----Original Message----- > From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- > current@freebsd.org] On Behalf Of Anton Shterenlikht > Sent: Sunday, May 13, 2012 11:54 PM > To: freebsd-current@freebsd.org > Subject: [clang] r234928 amd64 buildworld error >=20 > clang -O2 -pipe -DSORT_THREADS -std=3Dgnu99 -Qunused-arguments -fstack- > protector > -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter > -Wstrict > -prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast- > qual -Wwri > te-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar- > subscripts - > Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno- > pointer-s > ign -Wno-empty-body -Wno-string-plus-int -c > /usr/src/usr.bin/sort/file.c > /usr/src/usr.bin/sort/file.c:601:12: error: format string is not a > string > literal (potentially insecure) [-Werror,-Wformat-security] > err(2, getstr(7)); > ^~~~~~~~~ > /usr/src/usr.bin/sort/sort.h:52:20: note: expanded from macro 'getstr' > #define getstr(n) catgets(catalog, 1, n, nlsstr[n]) > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > /usr/src/usr.bin/sort/file.c:942:11: error: format string is not a > string > literal (potentially insecure) [-Werror,-Wformat-security] > err(2, getstr(8)); > ^~~~~~~~~ > /usr/src/usr.bin/sort/sort.h:52:20: note: expanded from macro 'getstr' > #define getstr(n) catgets(catalog, 1, n, nlsstr[n]) > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > /usr/src/usr.bin/sort/file.c:1279:10: error: format string is not a > string > literal (potentially insecure) [-Werror,-Wformat-security] > err(2, getstr(9)); > ^~~~~~~~~ > /usr/src/usr.bin/sort/sort.h:52:20: note: expanded from macro 'getstr' > #define getstr(n) catgets(catalog, 1, n, nlsstr[n]) > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > /usr/src/usr.bin/sort/file.c:1295:12: error: format string is not a > string > literal (potentially insecure) [-Werror,-Wformat-security] > errx(2, getstr(10)); > ^~~~~~~~~~ > /usr/src/usr.bin/sort/sort.h:52:20: note: expanded from macro 'getstr' > #define getstr(n) catgets(catalog, 1, n, nlsstr[n]) > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 4 errors generated. > *** [file.o] Error code 1 >=20 > Stop in /usr/src/usr.bin/sort. > *** [all] Error code 1 >=20 >=20 > -- > Anton Shterenlikht > Room 2.6, Queen's Building > Mech Eng Dept > Bristol University > University Walk, Bristol BS8 1TR, UK > Tel: +44 (0)117 331 5944 > Fax: +44 (0)117 929 4423 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current- > unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon May 14 07:02:32 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6F041065670; Mon, 14 May 2012 07:02:32 +0000 (UTC) (envelope-from uqs@FreeBSD.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 5A5958FC0C; Mon, 14 May 2012 07:02:29 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.5/8.14.5) with ESMTP id q4E72SeG091364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 14 May 2012 09:02:28 +0200 (CEST) (envelope-from uqs@FreeBSD.org) Date: Mon, 14 May 2012 09:02:28 +0200 From: Ulrich Spoerlein To: Doug Barton Message-ID: <20120514070228.GW71676@acme.spoerlein.net> Mail-Followup-To: Doug Barton , src-committers@freebsd.org, svn-src-user@freebsd.org, freebsd-current References: <201205111608.q4BG8ppa090644@svn.freebsd.org> <4FB0455F.9010602@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FB0455F.9010602@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current , src-committers@FreeBSD.org, svn-src-user@FreeBSD.org Subject: Re: svn commit: r235275 - projects user X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 07:02:33 -0000 On Sun, 2012-05-13 at 16:35:59 -0700, Doug Barton wrote: > When you proposed these changes not only did I not see a consensus for > you to move forward, I saw a non-zero number of people push back. > > Why did you proceed? - I had a non-zero number of people tell me that it looked good. - Peter doesn't seem to mind the clarification. - No objections were raised after I send out the changed patch which basically keeps things the way they were originally intended. Did you actually read what has been committed? Uli - amazed that a change to a document that apparently no one is reading can cause such a fuss. From owner-freebsd-current@FreeBSD.ORG Mon May 14 07:28:31 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC0C01065676; Mon, 14 May 2012 07:28:30 +0000 (UTC) (envelope-from gleb.kurtsou@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 2211D8FC12; Mon, 14 May 2012 07:28:29 +0000 (UTC) Received: by laai10 with SMTP id i10so3133545laa.13 for ; Mon, 14 May 2012 00:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=azpMRlMTpF9i0gwdIyiJXZiwDn/Tdfj13ffYNPLCWlE=; b=wQo+jAam2y56UGXynRWVV59YPhC/Zke25S0C6UcN29LCk+P9jeCC/cAnfhc43g36Ua 57m8r9jycTOtRJo1ajFz8y2v3cy59kLRz/udpt4FHLTaO0In36eNCOc1i9SUV4hULbs/ 2qq0W1RGp/BUV6G5omJaedtAez9q2+T+bkqARWPeALhlnN0LqStb0YBLQzl+jsQyWMee qlgBtnADHCVAE6Ik6KTjwmoOLlptsLTibzAKETdWJvFHU/6MLDu/tGpPgMDiMvHamtze aW6wPgbbB4Y3H0o4LskrF3HV9Cyq+F/kcPwkYZ5zbfBxONnDyDz+g41wmo06diso3xJ2 lOhQ== Received: by 10.112.44.233 with SMTP id h9mr3298725lbm.26.1336980508952; Mon, 14 May 2012 00:28:28 -0700 (PDT) Received: from localhost ([78.157.92.5]) by mx.google.com with ESMTPS id k4sm23084722lbb.12.2012.05.14.00.28.26 (version=SSLv3 cipher=OTHER); Mon, 14 May 2012 00:28:27 -0700 (PDT) Date: Mon, 14 May 2012 10:28:25 +0300 From: Gleb Kurtsou To: Konstantin Belousov Message-ID: <20120514072825.GA22399@reks> References: <20120512213950.GZ2358@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20120512213950.GZ2358@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: x11@freebsd.org, current@freebsd.org Subject: Re: Intel GPU driver import X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 07:28:31 -0000 On (13/05/2012 00:39), Konstantin Belousov wrote: > With r235375, all required VM support for new Intel GPU driver was > committed into HEAD. There are still some things to improve and > change, but now the all.14.9.patch does not touch anything outside agp > or drm. This allows to start the process of importing the new Intel > GPU driver into HEAD. > > I am writing this as initial head-up and to discuss some questions, > for which I do have answers but would prefer to have additional > feedback from people doing Xorg work. > > The patch as-is just replaces the Intel DRI1 bits with DRI2 > driver. Patch added most of the KMS infrastructure into DRM > core. Also, patch completely changed the locking model used by Intel > driver. I made absolutely minimal efforts needed to keep other DRI1 > drivers compilable. Despite that, I got several surpising reports that > Radeon DRI1 still works. > > That said, for import I can (first choice) just apply the patch, > replacing the Intel driver with new one. Or (second choice) I may > create another directory, say sys/dev/drm2, and import _only_ Intel > driver together with updated DRM core, there. > > The positive points to the second approach is that we still have older > kernel drivers around. Also, I have more freedom in changing the DRM > core, without fearing breakage in the DRI1 land. Since I do not really > want to deal with Gen2-3 hardware, and VGA console does not work with > new driver (yet), there are definite advantages. > > On the other hand, driver automatic loading will not work with > dev/drm2 approach. New driver have to use different module name to > co-exist with dri1 driver, so ddx driver cannot load new driver by old > name. As result, users need to manually kldload new driver before > starting Xorg. > > My own preference is to implement second choice and put the driver > into dev/drm2. We had somewhat similar situation with new USB stack import. First imported as 'usb2' then renamed to 'usb'. Considering there will be no new DRI1 drivers in tree we could import drm2 into sys/dev/drm and move old implementation under sys/dev/drm_compat1. It will break POLA until automatic driver loading by X fixed. Thanks, Gleb. From owner-freebsd-current@FreeBSD.ORG Mon May 14 08:50:01 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 97C001065672; Mon, 14 May 2012 08:50:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 6497E8FC08; Mon, 14 May 2012 08:50:01 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q4E8nstk053648; Mon, 14 May 2012 04:49:54 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q4E8nscn053644; Mon, 14 May 2012 08:49:54 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 14 May 2012 08:49:54 GMT Message-Id: <201205140849.q4E8nscn053644@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 08:50:01 -0000 TB --- 2012-05-14 08:10:01 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-05-14 08:10:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-05-14 08:10:01 - starting HEAD tinderbox run for arm/arm TB --- 2012-05-14 08:10:01 - cleaning the object tree TB --- 2012-05-14 08:10:01 - cvsupping the source tree TB --- 2012-05-14 08:10:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-05-14 08:12:13 - building world TB --- 2012-05-14 08:12:13 - CROSS_BUILD_TESTING=YES TB --- 2012-05-14 08:12:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-14 08:12:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-14 08:12:13 - SRCCONF=/dev/null TB --- 2012-05-14 08:12:13 - TARGET=arm TB --- 2012-05-14 08:12:13 - TARGET_ARCH=arm TB --- 2012-05-14 08:12:13 - TZ=UTC TB --- 2012-05-14 08:12:13 - __MAKE_CONF=/dev/null TB --- 2012-05-14 08:12:13 - cd /src TB --- 2012-05-14 08:12:13 - /usr/bin/make -B buildworld >>> World build started on Mon May 14 08:12:13 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 [...] if [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_is_swapped.3pcap ]; then F=pcap_is_swapped.3pcap; elif [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_is_swapped.3 ]; then F=pcap_is_swapped.3; else F=pcap_is_swapped.3; fi; sed -e 's/3PCAP/3/g' /src/lib/libpcap/../../contrib/libpcap/$F > pcap_is_swapped.3 gzip -cn pcap_is_swapped.3 > pcap_is_swapped.3.gz if [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_lib_version.3pcap ]; then F=pcap_lib_version.3pcap; elif [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_lib_version.3 ]; then F=pcap_lib_version.3; else F=pcap_lib_version.3; fi; sed -e 's/3PCAP/3/g' /src/lib/libpcap/../../contrib/libpcap/$F > pcap_lib_version.3 gzip -cn pcap_lib_version.3 > pcap_lib_version.3.gz if [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_list_datalinks.3pcap ]; then F=pcap_list_datalinks.3pcap; elif [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_list_datalinks.3 ]; then F=pcap_list_datalinks.3; else F=pcap_list_datalinks.3; fi; sed -e 's/3PCAP/3/g' /src/lib/libpcap/../../contrib/libpcap/$F > pcap_list_datalinks.3 gzip -cn pcap_list_datalinks.3 > pcap_list_datalinks.3.gz if [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_list_tstamp_types.3pcap ]; then F=pcap_list_tstamp_types.3pcap; elif [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_list_tstamp_types.3 ]; then F=pcap_list_tstamp_types.3; else F=pcap_list_tstamp_types.3; fi; sed -e 's/3PCAP/3/g' /src/lib/libpcap/../../contrib/libpcap/$F > pcap_list_tstamp_types.3 sed: /src/lib/libpcap/../../contrib/libpcap/pcap_list_tstamp_types.3: No such file or directory *** Error code 1 Stop in /src/lib/libpcap. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-05-14 08:49:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-05-14 08:49:54 - ERROR: failed to build world TB --- 2012-05-14 08:49:54 - 1430.11 user 379.14 system 2393.66 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Mon May 14 09:03:13 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A26EC106564A; Mon, 14 May 2012 09:03:13 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by mx1.freebsd.org (Postfix) with ESMTP id 67B288FC12; Mon, 14 May 2012 09:03:11 +0000 (UTC) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id q4E7o1b8018671; Mon, 14 May 2012 09:50:01 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.es [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 203DE2CBD0E; Mon, 14 May 2012 09:49:56 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 14 May 2012 09:49:56 +0200 From: Gustau Perez Querol To: , In-Reply-To: <20120514.131617.129792413.iwasaki@jp.FreeBSD.org> References: <4FAF696D.3060806@entel.upc.edu> <20120513.234014.26960250.iwasaki@jp.FreeBSD.org> <9E61BC2D-2654-40D9-936F-A99CD7AC1354@entel.upc.edu> <20120514.131617.129792413.iwasaki@jp.FreeBSD.org> Message-ID: X-Sender: gperez@entel.upc.edu User-Agent: RoundCube Webmail/0.5.1 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Mon, 14 May 2012 09:50:03 +0200 (CEST) Cc: iwasaki@jp.FreeBSD.org Subject: Re: [CFT] SMP/i386 suspend/resume X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 09:03:13 -0000 > >> >> Reporting from an Acer Centrino Duo, running CURRENT r235266. >> The >> >> machine has an nvidia card (Ge7300go). The acpi_video and nvidia >> modules >> >> are there. >> >> >> >> I did test it a few times with X running (plain twm) and worked >> just >> >> fine. Setting hw.acpi.lid_switch_state=S3 allowed me to use the >> >> close-the-lid-to-sleep functionality. >> >> >> >> The problem comes when I suspend the machine in the console. >> The >> >> machine resumes fine (I can ping and ssh it) but the screen >> remains >> >> black. I set hw.acpi.reset_video to 0 or 1 but no go. If I'm in a >> >> console but X is running, after the resume I can CTRL+ALT+F9 and >> get my >> >> video back; then I can return to the console. If I don't have X >> running, >> >> I don't know how to get my console back. >> > >> > I think this is graphic driver problem. nvidia's driver seems >> > to have correct suspend/resume method. >> > http://www.nvidia.com/object/freebsd_archive.html >> > >> > Have you try it? >> >> Yes, it is running the propietary driver. Everything was done with >> it loaded. Do you want me to try without the nvidia binary driver? > > Yes, if it doesn't bother you. What follows was still done with your patch there. First, I tried with acpi_bounce. I saw this on dmesg: vgapci0: calling BIOS POST I also tried the complete suspend/resume without the nvidia blob. The machine showed the same behavior; it came online after suspending. Everything working but the video. After the suspend/resume cycle and w/o the nvidia blob, I tried to ssh it. The screen was completely black. After logging in, I kldload'ed the nvidia blob and tried to start X. I got a panic (I was unable to read it) and a core after rebooting. The relevant part was: ************************************************* Unread portion of the kernel message buffer: NVRM: failed to copy vbios to system memory. NVRM: RmInitAdapter failed! (0x30:0xffffffff:858) nvidia0: NVRM: rm_init_adapter() failed! ************************************************* So I would say the bios is doing something during the suspend/resume cycle. I would say the nvidia module knows to handle this, but the module must be loaded before the first suspend/resume cycle. That would explain why it works with X running. That would also somehow explain why I can resume while working with ttyv1 having X working on ttvy9 (remember, in that case I had to vidcontrol -s 9 < /dev/console to get my screen back online). I'm just guessing. Could it be that > Hmmm, it doesn't seem related with my SMP/i386 sleep patches. > Could you try also Uni-processer kernel (w/o SMP and apic from config > file) without my patches? I tried smp disabled on boot (kern.smp.disabled=1) and failed the same way. I'm compiling w/o your patch (will take it a while) but I guess it will do worst. Last time I tried, when 9 was head, it did not resume at all. > >> OTOH, IIRC the console only test (without X) without acpi_video >> lead to freeze. No crash dump. The machine has no serial or fwire >> ports :( > > We can improve video initialization on another opportunity. > Linux have many video hacks while we have only hw.acpi.reset_video ;) > http://www.kernel.org/doc/Documentation/power/video.txt > I believe there are some solutions for you in this document, then > we can implement them in our source if found. Could this all be an ASL problem? Thanks, Gus > From owner-freebsd-current@FreeBSD.ORG Mon May 14 09:05:48 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1180B106566C; Mon, 14 May 2012 09:05:48 +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 822798FC0A; Mon, 14 May 2012 09:05:47 +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 q4E95W4s043647; Mon, 14 May 2012 12:05:32 +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 q4E95Wb8083003; Mon, 14 May 2012 12:05:32 +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 q4E95W8E083002; Mon, 14 May 2012 12:05:32 +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: Mon, 14 May 2012 12:05:32 +0300 From: Konstantin Belousov To: Joel Dahl Message-ID: <20120514090532.GE2358@deviant.kiev.zoral.com.ua> References: <20120512213950.GZ2358@deviant.kiev.zoral.com.ua> <20120514063934.GG6475@goofy01.vnodelab.local> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9UqxYhE6UwMzcsnf" Content-Disposition: inline In-Reply-To: <20120514063934.GG6475@goofy01.vnodelab.local> 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: x11@freebsd.org, current@freebsd.org Subject: Re: Intel GPU driver import X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 09:05:48 -0000 --9UqxYhE6UwMzcsnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 14, 2012 at 08:39:35AM +0200, Joel Dahl wrote: > On 13-05-2012 0:39, Konstantin Belousov wrote: > > The positive points to the second approach is that we still have older > > kernel drivers around. Also, I have more freedom in changing the DRM > > core, without fearing breakage in the DRI1 land. Since I do not really > > want to deal with Gen2-3 hardware >=20 > What is Gen2-3 hardware in this context? Can you give examples? It is 810/815/865/915/945/G33/IDG chipsets. They currently work without GEM/KMS in kernel. See http://wiki.freebsd.org/AGP_Testing for full list. --9UqxYhE6UwMzcsnf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+wytwACgkQC3+MBN1Mb4jtJwCgud3el3PcFWTyrh13e2y/kqsw +4wAoNzeMS7HeMSnBnK1YwM1SsCPJaFX =sn1N -----END PGP SIGNATURE----- --9UqxYhE6UwMzcsnf-- From owner-freebsd-current@FreeBSD.ORG Mon May 14 09:14:00 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 5F810106564A; Mon, 14 May 2012 09:14:00 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id EBEB6153312; Mon, 14 May 2012 09:13:59 +0000 (UTC) Message-ID: <4FB0CCD7.3000802@FreeBSD.org> Date: Mon, 14 May 2012 02:13:59 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: src-committers@freebsd.org, svn-src-user@freebsd.org, freebsd-current References: <201205111608.q4BG8ppa090644@svn.freebsd.org> <4FB0455F.9010602@FreeBSD.org> <20120514070228.GW71676@acme.spoerlein.net> In-Reply-To: <20120514070228.GW71676@acme.spoerlein.net> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: svn commit: r235275 - projects user X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 09:14:00 -0000 On 5/14/2012 12:02 AM, Ulrich Spoerlein wrote: > Uli - amazed that a change to a document that apparently no one is > reading can cause such a fuss. ... which is the point that several of us tried to make, and which you seem to have ignored. The problem with committers not reading the documentation (such as it is) is not properly solved by changing the documentation. What I'm objecting to is your pointless deck-chair rearranging rather than addressing the real problem. -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Mon May 14 09:39:04 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09DA4106564A; Mon, 14 May 2012 09:39:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id CBB848FC08; Mon, 14 May 2012 09:39:03 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q4E9d2eN092927; Mon, 14 May 2012 05:39:02 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q4E9d2lY092926; Mon, 14 May 2012 09:39:02 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 14 May 2012 09:39:02 GMT Message-Id: <201205140939.q4E9d2lY092926@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 09:39:04 -0000 TB --- 2012-05-14 08:49:55 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-05-14 08:49:55 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-05-14 08:49:55 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-05-14 08:49:55 - cleaning the object tree TB --- 2012-05-14 08:49:55 - cvsupping the source tree TB --- 2012-05-14 08:49:55 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2012-05-14 08:51:59 - building world TB --- 2012-05-14 08:51:59 - CROSS_BUILD_TESTING=YES TB --- 2012-05-14 08:51:59 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-14 08:51:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-14 08:51:59 - SRCCONF=/dev/null TB --- 2012-05-14 08:51:59 - TARGET=ia64 TB --- 2012-05-14 08:51:59 - TARGET_ARCH=ia64 TB --- 2012-05-14 08:51:59 - TZ=UTC TB --- 2012-05-14 08:51:59 - __MAKE_CONF=/dev/null TB --- 2012-05-14 08:51:59 - cd /src TB --- 2012-05-14 08:51:59 - /usr/bin/make -B buildworld >>> World build started on Mon May 14 08:52:00 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 [...] if [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_is_swapped.3pcap ]; then F=pcap_is_swapped.3pcap; elif [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_is_swapped.3 ]; then F=pcap_is_swapped.3; else F=pcap_is_swapped.3; fi; sed -e 's/3PCAP/3/g' /src/lib/libpcap/../../contrib/libpcap/$F > pcap_is_swapped.3 gzip -cn pcap_is_swapped.3 > pcap_is_swapped.3.gz if [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_lib_version.3pcap ]; then F=pcap_lib_version.3pcap; elif [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_lib_version.3 ]; then F=pcap_lib_version.3; else F=pcap_lib_version.3; fi; sed -e 's/3PCAP/3/g' /src/lib/libpcap/../../contrib/libpcap/$F > pcap_lib_version.3 gzip -cn pcap_lib_version.3 > pcap_lib_version.3.gz if [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_list_datalinks.3pcap ]; then F=pcap_list_datalinks.3pcap; elif [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_list_datalinks.3 ]; then F=pcap_list_datalinks.3; else F=pcap_list_datalinks.3; fi; sed -e 's/3PCAP/3/g' /src/lib/libpcap/../../contrib/libpcap/$F > pcap_list_datalinks.3 gzip -cn pcap_list_datalinks.3 > pcap_list_datalinks.3.gz if [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_list_tstamp_types.3pcap ]; then F=pcap_list_tstamp_types.3pcap; elif [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_list_tstamp_types.3 ]; then F=pcap_list_tstamp_types.3; else F=pcap_list_tstamp_types.3; fi; sed -e 's/3PCAP/3/g' /src/lib/libpcap/../../contrib/libpcap/$F > pcap_list_tstamp_types.3 sed: /src/lib/libpcap/../../contrib/libpcap/pcap_list_tstamp_types.3: No such file or directory *** Error code 1 Stop in /src/lib/libpcap. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-05-14 09:39:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-05-14 09:39:02 - ERROR: failed to build world TB --- 2012-05-14 09:39:02 - 2130.80 user 383.93 system 2947.83 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Mon May 14 09:48:26 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 43DDF106566C; Mon, 14 May 2012 09:48:26 +0000 (UTC) (envelope-from tuchinsky@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id EE91D8FC1C; Mon, 14 May 2012 09:48:25 +0000 (UTC) Received: by obcni5 with SMTP id ni5so9552365obc.13 for ; Mon, 14 May 2012 02:48:25 -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=Jq+qz/501MVy7aIBeUJnv+4bEtmgYDO8Bcz7mj/2giY=; b=XnojUawAtT10Y5b304pQ9UDJHV3Hv+lYILVwkNxMtK4vnpyCT5epPZGEOfY04vV652 VaH2vkm033sAZI3kRdLv13kELow1TW9Lc0wf2yX3XXaU/y6oVi69m4XNZjt5Cpfe29rt G8aJvUCmzQTKbcG6HZ7JCiJxZbglGlbk6Z+QVfr0/3YyRELN4La8q9DHObs9cEghABRh wRUHgO0JxNrrnG+NGHf9BsWD29D+H9S9PMylOekdEzHr+rQxA8Z2bxwvPSgblGq2X5ro 2KAr/zbaKt8fAT9q+ASs3IvwuL3Uvgix2pSi+1a2RT9iayx6FW/eVop8UDNne1HrgWMh 1cBw== MIME-Version: 1.0 Received: by 10.60.11.136 with SMTP id q8mr2804160oeb.58.1336988905397; Mon, 14 May 2012 02:48:25 -0700 (PDT) Received: by 10.60.64.69 with HTTP; Mon, 14 May 2012 02:48:25 -0700 (PDT) In-Reply-To: <20120514090532.GE2358@deviant.kiev.zoral.com.ua> References: <20120512213950.GZ2358@deviant.kiev.zoral.com.ua> <20120514063934.GG6475@goofy01.vnodelab.local> <20120514090532.GE2358@deviant.kiev.zoral.com.ua> Date: Mon, 14 May 2012 13:48:25 +0400 Message-ID: From: Artem Tuchinsky To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Cc: x11@freebsd.org, current@freebsd.org, Joel Dahl Subject: Re: Intel GPU driver import X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 09:48:26 -0000 On some laptops they didn't work with xf86-video-intel 2.7/2.9, this bug fixed in 2.11 and above, which does not work without GEM/KMS 2012/5/14 Konstantin Belousov : >> What is Gen2-3 hardware in this context? Can you give examples? > It is 810/815/865/915/945/G33/IDG chipsets. They currently work without > GEM/KMS in kernel. > -- wBR, Artem Tuchinsky From owner-freebsd-current@FreeBSD.ORG Mon May 14 10:05:25 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 822C9106564A; Mon, 14 May 2012 10:05:25 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 52B488FC0A; Mon, 14 May 2012 10:05:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q4EA5OiB034415; Mon, 14 May 2012 06:05:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q4EA5O3h034405; Mon, 14 May 2012 10:05:24 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 14 May 2012 10:05:24 GMT Message-Id: <201205141005.q4EA5O3h034405@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 10:05:25 -0000 TB --- 2012-05-14 08:10:01 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-05-14 08:10:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-05-14 08:10:01 - starting HEAD tinderbox run for i386/i386 TB --- 2012-05-14 08:10:01 - cleaning the object tree TB --- 2012-05-14 08:10:01 - cvsupping the source tree TB --- 2012-05-14 08:10:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-05-14 08:12:12 - building world TB --- 2012-05-14 08:12:12 - CROSS_BUILD_TESTING=YES TB --- 2012-05-14 08:12:12 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-14 08:12:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-14 08:12:12 - SRCCONF=/dev/null TB --- 2012-05-14 08:12:12 - TARGET=i386 TB --- 2012-05-14 08:12:12 - TARGET_ARCH=i386 TB --- 2012-05-14 08:12:12 - TZ=UTC TB --- 2012-05-14 08:12:12 - __MAKE_CONF=/dev/null TB --- 2012-05-14 08:12:12 - cd /src TB --- 2012-05-14 08:12:12 - /usr/bin/make -B buildworld >>> World build started on Mon May 14 08:12:13 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 [...] if [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_is_swapped.3pcap ]; then F=pcap_is_swapped.3pcap; elif [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_is_swapped.3 ]; then F=pcap_is_swapped.3; else F=pcap_is_swapped.3; fi; sed -e 's/3PCAP/3/g' /src/lib/libpcap/../../contrib/libpcap/$F > pcap_is_swapped.3 gzip -cn pcap_is_swapped.3 > pcap_is_swapped.3.gz if [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_lib_version.3pcap ]; then F=pcap_lib_version.3pcap; elif [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_lib_version.3 ]; then F=pcap_lib_version.3; else F=pcap_lib_version.3; fi; sed -e 's/3PCAP/3/g' /src/lib/libpcap/../../contrib/libpcap/$F > pcap_lib_version.3 gzip -cn pcap_lib_version.3 > pcap_lib_version.3.gz if [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_list_datalinks.3pcap ]; then F=pcap_list_datalinks.3pcap; elif [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_list_datalinks.3 ]; then F=pcap_list_datalinks.3; else F=pcap_list_datalinks.3; fi; sed -e 's/3PCAP/3/g' /src/lib/libpcap/../../contrib/libpcap/$F > pcap_list_datalinks.3 gzip -cn pcap_list_datalinks.3 > pcap_list_datalinks.3.gz if [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_list_tstamp_types.3pcap ]; then F=pcap_list_tstamp_types.3pcap; elif [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_list_tstamp_types.3 ]; then F=pcap_list_tstamp_types.3; else F=pcap_list_tstamp_types.3; fi; sed -e 's/3PCAP/3/g' /src/lib/libpcap/../../contrib/libpcap/$F > pcap_list_tstamp_types.3 sed: /src/lib/libpcap/../../contrib/libpcap/pcap_list_tstamp_types.3: No such file or directory *** Error code 1 Stop in /src/lib/libpcap. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-05-14 10:05:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-05-14 10:05:24 - ERROR: failed to build world TB --- 2012-05-14 10:05:24 - 5041.84 user 687.47 system 6923.37 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Mon May 14 10:05:25 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8269D1065670; Mon, 14 May 2012 10:05:25 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5391C8FC0C; Mon, 14 May 2012 10:05:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q4EA5OfK034414; Mon, 14 May 2012 06:05:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q4EA5ON1034404; Mon, 14 May 2012 10:05:24 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 14 May 2012 10:05:24 GMT Message-Id: <201205141005.q4EA5ON1034404@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 10:05:25 -0000 TB --- 2012-05-14 08:10:01 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-05-14 08:10:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-05-14 08:10:01 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-05-14 08:10:01 - cleaning the object tree TB --- 2012-05-14 08:10:01 - cvsupping the source tree TB --- 2012-05-14 08:10:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-05-14 08:12:12 - building world TB --- 2012-05-14 08:12:12 - CROSS_BUILD_TESTING=YES TB --- 2012-05-14 08:12:12 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-14 08:12:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-14 08:12:12 - SRCCONF=/dev/null TB --- 2012-05-14 08:12:12 - TARGET=pc98 TB --- 2012-05-14 08:12:12 - TARGET_ARCH=i386 TB --- 2012-05-14 08:12:12 - TZ=UTC TB --- 2012-05-14 08:12:12 - __MAKE_CONF=/dev/null TB --- 2012-05-14 08:12:12 - cd /src TB --- 2012-05-14 08:12:12 - /usr/bin/make -B buildworld >>> World build started on Mon May 14 08:12:13 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 [...] if [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_is_swapped.3pcap ]; then F=pcap_is_swapped.3pcap; elif [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_is_swapped.3 ]; then F=pcap_is_swapped.3; else F=pcap_is_swapped.3; fi; sed -e 's/3PCAP/3/g' /src/lib/libpcap/../../contrib/libpcap/$F > pcap_is_swapped.3 gzip -cn pcap_is_swapped.3 > pcap_is_swapped.3.gz if [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_lib_version.3pcap ]; then F=pcap_lib_version.3pcap; elif [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_lib_version.3 ]; then F=pcap_lib_version.3; else F=pcap_lib_version.3; fi; sed -e 's/3PCAP/3/g' /src/lib/libpcap/../../contrib/libpcap/$F > pcap_lib_version.3 gzip -cn pcap_lib_version.3 > pcap_lib_version.3.gz if [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_list_datalinks.3pcap ]; then F=pcap_list_datalinks.3pcap; elif [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_list_datalinks.3 ]; then F=pcap_list_datalinks.3; else F=pcap_list_datalinks.3; fi; sed -e 's/3PCAP/3/g' /src/lib/libpcap/../../contrib/libpcap/$F > pcap_list_datalinks.3 gzip -cn pcap_list_datalinks.3 > pcap_list_datalinks.3.gz if [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_list_tstamp_types.3pcap ]; then F=pcap_list_tstamp_types.3pcap; elif [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_list_tstamp_types.3 ]; then F=pcap_list_tstamp_types.3; else F=pcap_list_tstamp_types.3; fi; sed -e 's/3PCAP/3/g' /src/lib/libpcap/../../contrib/libpcap/$F > pcap_list_tstamp_types.3 sed: /src/lib/libpcap/../../contrib/libpcap/pcap_list_tstamp_types.3: No such file or directory *** Error code 1 Stop in /src/lib/libpcap. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-05-14 10:05:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-05-14 10:05:24 - ERROR: failed to build world TB --- 2012-05-14 10:05:24 - 5041.98 user 682.03 system 6923.34 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Mon May 14 10:08:53 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 35948106564A; Mon, 14 May 2012 10:08:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 04C7F8FC1B; Mon, 14 May 2012 10:08:51 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q4EA8pvj046987; Mon, 14 May 2012 06:08:51 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q4EA8plH046980; Mon, 14 May 2012 10:08:51 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 14 May 2012 10:08:51 GMT Message-Id: <201205141008.q4EA8plH046980@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 10:08:53 -0000 TB --- 2012-05-14 08:10:01 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-05-14 08:10:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-05-14 08:10:01 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-05-14 08:10:01 - cleaning the object tree TB --- 2012-05-14 08:10:01 - cvsupping the source tree TB --- 2012-05-14 08:10:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2012-05-14 08:16:07 - building world TB --- 2012-05-14 08:16:07 - CROSS_BUILD_TESTING=YES TB --- 2012-05-14 08:16:07 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-14 08:16:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-14 08:16:07 - SRCCONF=/dev/null TB --- 2012-05-14 08:16:07 - TARGET=amd64 TB --- 2012-05-14 08:16:07 - TARGET_ARCH=amd64 TB --- 2012-05-14 08:16:07 - TZ=UTC TB --- 2012-05-14 08:16:07 - __MAKE_CONF=/dev/null TB --- 2012-05-14 08:16:07 - cd /src TB --- 2012-05-14 08:16:07 - /usr/bin/make -B buildworld >>> World build started on Mon May 14 08:16:08 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 [...] if [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_is_swapped.3pcap ]; then F=pcap_is_swapped.3pcap; elif [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_is_swapped.3 ]; then F=pcap_is_swapped.3; else F=pcap_is_swapped.3; fi; sed -e 's/3PCAP/3/g' /src/lib/libpcap/../../contrib/libpcap/$F > pcap_is_swapped.3 gzip -cn pcap_is_swapped.3 > pcap_is_swapped.3.gz if [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_lib_version.3pcap ]; then F=pcap_lib_version.3pcap; elif [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_lib_version.3 ]; then F=pcap_lib_version.3; else F=pcap_lib_version.3; fi; sed -e 's/3PCAP/3/g' /src/lib/libpcap/../../contrib/libpcap/$F > pcap_lib_version.3 gzip -cn pcap_lib_version.3 > pcap_lib_version.3.gz if [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_list_datalinks.3pcap ]; then F=pcap_list_datalinks.3pcap; elif [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_list_datalinks.3 ]; then F=pcap_list_datalinks.3; else F=pcap_list_datalinks.3; fi; sed -e 's/3PCAP/3/g' /src/lib/libpcap/../../contrib/libpcap/$F > pcap_list_datalinks.3 gzip -cn pcap_list_datalinks.3 > pcap_list_datalinks.3.gz if [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_list_tstamp_types.3pcap ]; then F=pcap_list_tstamp_types.3pcap; elif [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_list_tstamp_types.3 ]; then F=pcap_list_tstamp_types.3; else F=pcap_list_tstamp_types.3; fi; sed -e 's/3PCAP/3/g' /src/lib/libpcap/../../contrib/libpcap/$F > pcap_list_tstamp_types.3 sed: /src/lib/libpcap/../../contrib/libpcap/pcap_list_tstamp_types.3: No such file or directory *** Error code 1 Stop in /src/lib/libpcap. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-05-14 10:08:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-05-14 10:08:51 - ERROR: failed to build world TB --- 2012-05-14 10:08:51 - 5041.20 user 685.35 system 7130.48 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Mon May 14 10:20:40 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D7F33106566B; Mon, 14 May 2012 10:20:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A83AE8FC19; Mon, 14 May 2012 10:20:40 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q4EAKdH5064019; Mon, 14 May 2012 06:20:39 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q4EAKdn5064014; Mon, 14 May 2012 10:20:39 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 14 May 2012 10:20:39 GMT Message-Id: <201205141020.q4EAKdn5064014@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 10:20:41 -0000 TB --- 2012-05-14 09:39:03 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-05-14 09:39:03 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-05-14 09:39:03 - starting HEAD tinderbox run for mips/mips TB --- 2012-05-14 09:39:03 - cleaning the object tree TB --- 2012-05-14 09:39:03 - cvsupping the source tree TB --- 2012-05-14 09:39:03 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2012-05-14 09:39:32 - building world TB --- 2012-05-14 09:39:32 - CROSS_BUILD_TESTING=YES TB --- 2012-05-14 09:39:32 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-14 09:39:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-14 09:39:32 - SRCCONF=/dev/null TB --- 2012-05-14 09:39:32 - TARGET=mips TB --- 2012-05-14 09:39:32 - TARGET_ARCH=mips TB --- 2012-05-14 09:39:32 - TZ=UTC TB --- 2012-05-14 09:39:32 - __MAKE_CONF=/dev/null TB --- 2012-05-14 09:39:32 - cd /src TB --- 2012-05-14 09:39:32 - /usr/bin/make -B buildworld >>> World build started on Mon May 14 09:39:32 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 [...] if [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_is_swapped.3pcap ]; then F=pcap_is_swapped.3pcap; elif [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_is_swapped.3 ]; then F=pcap_is_swapped.3; else F=pcap_is_swapped.3; fi; sed -e 's/3PCAP/3/g' /src/lib/libpcap/../../contrib/libpcap/$F > pcap_is_swapped.3 gzip -cn pcap_is_swapped.3 > pcap_is_swapped.3.gz if [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_lib_version.3pcap ]; then F=pcap_lib_version.3pcap; elif [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_lib_version.3 ]; then F=pcap_lib_version.3; else F=pcap_lib_version.3; fi; sed -e 's/3PCAP/3/g' /src/lib/libpcap/../../contrib/libpcap/$F > pcap_lib_version.3 gzip -cn pcap_lib_version.3 > pcap_lib_version.3.gz if [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_list_datalinks.3pcap ]; then F=pcap_list_datalinks.3pcap; elif [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_list_datalinks.3 ]; then F=pcap_list_datalinks.3; else F=pcap_list_datalinks.3; fi; sed -e 's/3PCAP/3/g' /src/lib/libpcap/../../contrib/libpcap/$F > pcap_list_datalinks.3 gzip -cn pcap_list_datalinks.3 > pcap_list_datalinks.3.gz if [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_list_tstamp_types.3pcap ]; then F=pcap_list_tstamp_types.3pcap; elif [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_list_tstamp_types.3 ]; then F=pcap_list_tstamp_types.3; else F=pcap_list_tstamp_types.3; fi; sed -e 's/3PCAP/3/g' /src/lib/libpcap/../../contrib/libpcap/$F > pcap_list_tstamp_types.3 sed: /src/lib/libpcap/../../contrib/libpcap/pcap_list_tstamp_types.3: No such file or directory *** Error code 1 Stop in /src/lib/libpcap. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-05-14 10:20:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-05-14 10:20:39 - ERROR: failed to build world TB --- 2012-05-14 10:20:39 - 1509.34 user 360.96 system 2496.67 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Mon May 14 11:31:42 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E1ED8106564A; Mon, 14 May 2012 11:31:42 +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 DE5658FC0A; Mon, 14 May 2012 11:31:41 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA23612; Mon, 14 May 2012 14:31:39 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4FB0ED1A.3020909@FreeBSD.org> Date: Mon, 14 May 2012 14:31:38 +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: <20120512213950.GZ2358__17671.8018287376$1336859020$gmane$org@deviant.kiev.zoral.com.ua> In-Reply-To: <20120512213950.GZ2358__17671.8018287376$1336859020$gmane$org@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: x11@FreeBSD.org, current@FreeBSD.org Subject: Re: Intel GPU driver import X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 11:31:43 -0000 on 13/05/2012 00:39 Konstantin Belousov said the following: > With r235375, all required VM support for new Intel GPU driver was > committed into HEAD. There are still some things to improve and > change, but now the all.14.9.patch does not touch anything outside agp > or drm. This allows to start the process of importing the new Intel > GPU driver into HEAD. > > I am writing this as initial head-up and to discuss some questions, > for which I do have answers but would prefer to have additional > feedback from people doing Xorg work. > > The patch as-is just replaces the Intel DRI1 bits with DRI2 > driver. Patch added most of the KMS infrastructure into DRM > core. Also, patch completely changed the locking model used by Intel > driver. I made absolutely minimal efforts needed to keep other DRI1 > drivers compilable. Despite that, I got several surpising reports that > Radeon DRI1 still works. > > That said, for import I can (first choice) just apply the patch, > replacing the Intel driver with new one. Or (second choice) I may > create another directory, say sys/dev/drm2, and import _only_ Intel > driver together with updated DRM core, there. > > The positive points to the second approach is that we still have older > kernel drivers around. Also, I have more freedom in changing the DRM > core, without fearing breakage in the DRI1 land. Since I do not really > want to deal with Gen2-3 hardware, and VGA console does not work with > new driver (yet), there are definite advantages. > > On the other hand, driver automatic loading will not work with > dev/drm2 approach. New driver have to use different module name to > co-exist with dri1 driver, so ddx driver cannot load new driver by old > name. As result, users need to manually kldload new driver before > starting Xorg. > > My own preference is to implement second choice and put the driver > into dev/drm2. I think that I would prefer this path too for the reasons you already mentioned above: - potential problems for other drivers - need to easily fallback for those who use the intel driver and may run into problems with the new code - some missing bits related to kms like syscons support, which makes troubleshooting harder BTW, I think that we should patch xf86-video-intel port to try loading "i915kms"/"i915gem"/... if i915 is not available. I think that that should be fine for a FreeBSD-specific patch. Alternatively, we could keep the same names for drivers/modules and then have a global knob (WITH_DRM2/WITH_KMS/etc) to select which source is code is used to build the drivers. Finally, thank you very much for this work! Looking forward to having it in the tree. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon May 14 11:33:47 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 291021065673 for ; Mon, 14 May 2012 11:33:47 +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 76A288FC15 for ; Mon, 14 May 2012 11:33:46 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA23627; Mon, 14 May 2012 14:33:43 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4FB0ED96.6010100@FreeBSD.org> Date: Mon, 14 May 2012 14:33:42 +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: Bruce Cran References: <4FAF767C.8030500@cran.org.uk> In-Reply-To: <4FAF767C.8030500@cran.org.uk> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current Subject: Re: Default directory used for 'zpool import' broken (/dev/dsk)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 11:33:47 -0000 on 13/05/2012 11:53 Bruce Cran said the following: > When running 'zpool import' without -d I get the error: > "cannot open '/dev/dsk': must be an absolute path" > > zpool(8) suggests the default should have been updated for FreeBSD: > "If the -d option is not specified, this command searches for devices in "/dev"" > > Was this broken recently? > Not sure, but maybe /dev/dsk is recorded somewhere in the pool metadata or in zpool.cache. It could have happened with the older version of the code. I think that you could check that with zdb. I think that a fresh import should fix it, though. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon May 14 11:37:31 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6898C106566B; Mon, 14 May 2012 11:37:31 +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 DB0318FC0C; Mon, 14 May 2012 11:37:30 +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 q4EBbRjF077038; Mon, 14 May 2012 14:37:27 +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 q4EBbQ5E029790; Mon, 14 May 2012 14:37:26 +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 q4EBbQJM029789; Mon, 14 May 2012 14:37:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 14 May 2012 14:37:26 +0300 From: Konstantin Belousov To: Andriy Gapon Message-ID: <20120514113726.GH2358@deviant.kiev.zoral.com.ua> References: <20120512213950.GZ2358__17671.8018287376$1336859020$gmane$org@deviant.kiev.zoral.com.ua> <4FB0ED1A.3020909@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JD3qPFYKz0/ozIPR" Content-Disposition: inline In-Reply-To: <4FB0ED1A.3020909@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: x11@freebsd.org, current@freebsd.org Subject: Re: Intel GPU driver import X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 11:37:31 -0000 --JD3qPFYKz0/ozIPR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 14, 2012 at 02:31:38PM +0300, Andriy Gapon wrote: > on 13/05/2012 00:39 Konstantin Belousov said the following: > > With r235375, all required VM support for new Intel GPU driver was > > committed into HEAD. There are still some things to improve and > > change, but now the all.14.9.patch does not touch anything outside agp > > or drm. This allows to start the process of importing the new Intel > > GPU driver into HEAD. > >=20 > > I am writing this as initial head-up and to discuss some questions, > > for which I do have answers but would prefer to have additional > > feedback from people doing Xorg work. > >=20 > > The patch as-is just replaces the Intel DRI1 bits with DRI2 > > driver. Patch added most of the KMS infrastructure into DRM > > core. Also, patch completely changed the locking model used by Intel > > driver. I made absolutely minimal efforts needed to keep other DRI1 > > drivers compilable. Despite that, I got several surpising reports that > > Radeon DRI1 still works. > >=20 > > That said, for import I can (first choice) just apply the patch, > > replacing the Intel driver with new one. Or (second choice) I may > > create another directory, say sys/dev/drm2, and import _only_ Intel > > driver together with updated DRM core, there. > >=20 > > The positive points to the second approach is that we still have older > > kernel drivers around. Also, I have more freedom in changing the DRM > > core, without fearing breakage in the DRI1 land. Since I do not really > > want to deal with Gen2-3 hardware, and VGA console does not work with > > new driver (yet), there are definite advantages. > >=20 > > On the other hand, driver automatic loading will not work with > > dev/drm2 approach. New driver have to use different module name to > > co-exist with dri1 driver, so ddx driver cannot load new driver by old > > name. As result, users need to manually kldload new driver before > > starting Xorg. > >=20 > > My own preference is to implement second choice and put the driver > > into dev/drm2. >=20 >=20 > I think that I would prefer this path too for the reasons you already men= tioned above: > - potential problems for other drivers > - need to easily fallback for those who use the intel driver and may run = into > problems with the new code > - some missing bits related to kms like syscons support, which makes > troubleshooting harder >=20 > BTW, I think that we should patch xf86-video-intel port to try loading > "i915kms"/"i915gem"/... if i915 is not available. I think that that shou= ld be > fine for a FreeBSD-specific patch. > Alternatively, we could keep the same names for drivers/modules and then = have a > global knob (WITH_DRM2/WITH_KMS/etc) to select which source is code is us= ed to > build the drivers. No, I want both drivers to be presented in /boot/kernel in default=20 install. Also, I want to avoid forcing user to recompile her kernel for driver switching. Regarding the patching xf86-video-intel, I am completely fine with this, but the work should be done by xorg porters. Assuming they will to do this and then maintain the (should be quite trivial) patch. And I like the 'i915kms' name for the module. This and drm2.ko for core drm infrastructure sound good, thank you. --JD3qPFYKz0/ozIPR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+w7nYACgkQC3+MBN1Mb4gNMACg5BN/FrMl/d5qf12ZIp6jIwyF Z7sAoNt/T6Kq4ZSFfzyAVxt7+X7EKWzh =znef -----END PGP SIGNATURE----- --JD3qPFYKz0/ozIPR-- From owner-freebsd-current@FreeBSD.ORG Mon May 14 11:24:14 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7DC71065701 for ; Mon, 14 May 2012 11:24:14 +0000 (UTC) (envelope-from gabor@t-hosting.hu) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 684398FC1F for ; Mon, 14 May 2012 11:24:14 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 511D214E75DA; Mon, 14 May 2012 13:24:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fDdZr8uiKAix; Mon, 14 May 2012 13:23:59 +0200 (CEST) Received: from [192.168.1.117] (catv-80-98-232-12.catv.broadband.hu [80.98.232.12]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 2FEED14E729F; Mon, 14 May 2012 13:23:58 +0200 (CEST) Message-ID: <4FB0EB4C.5090000@t-hosting.hu> Date: Mon, 14 May 2012 13:23:56 +0200 From: =?ISO-8859-1?Q?G=E1bor_K=F6vesd=E1n?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120328 Thunderbird/13.0a2 MIME-Version: 1.0 To: Garrett Cooper References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 14 May 2012 11:44:43 +0000 Cc: Outback Dingo , freebsd-current , Oleg Moskalenko Subject: Re: FYI FreeBSD clang build fails on new import of sort X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 11:24:14 -0000 On 2012.05.14. 2:49, Garrett Cooper wrote: > Yeah... errx(2, getstr(9)) should be errx(2, "%s", getstr(9))... > -Garrett Thanks, should be fixed now. Gabor From owner-freebsd-current@FreeBSD.ORG Mon May 14 13:35:32 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C1D681065673 for ; Mon, 14 May 2012 13:35:32 +0000 (UTC) (envelope-from bryan@shatow.net) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) by mx1.freebsd.org (Postfix) with ESMTP id 66F298FC17 for ; Mon, 14 May 2012 13:35:32 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sweb; b=XbnslI bAfLale6JdtvIf8xnYdgDsHY6Xg0VNNcoItlyLjDvidX1aEtKtaTR34sWYqK6eDF 6LmhLCFyCOLxswQxGdbpgAg3cbErtajw1XI7iJ/6Wsp0XctWjtF4yA85t8n0ez2e qtIBwXbyFQAg6s+of200F7NCwqexdQsgusQuw= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sweb; bh=Mddf0u5a2vBC yOUySP2ehdOK2WY5qfPlUoJy2Qw/UVk=; b=djyxwHPUlShv4NG5qg758PGSGZeF FajuPttzpJSzVyAQlbf10fOINEbt1u3jXAQLVM+gd8SHVguU3HDk1V5iUWLtAJiR MfWtA2LbGiGHSPFn3c3o8GupdTurQ0/rKmlGpz1CTE1FvnD7b+lCMPLxZkmbFzqS XDWv5csDw0FGSy0= Received: (qmail 99693 invoked from network); 14 May 2012 08:35:24 -0500 Received: from unknown (HELO ?10.10.1.87?) (bryan@shatow.net@10.10.1.87) by sweb.xzibition.com with ESMTPA; 14 May 2012 08:35:24 -0500 Message-ID: <4FB10A1B.7090102@shatow.net> Date: Mon, 14 May 2012 08:35:23 -0500 From: Bryan Drewery User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Doug Barton References: <4FAF291C.8090401@shatow.net> <4FB04084.5070202@FreeBSD.org> In-Reply-To: <4FB04084.5070202@FreeBSD.org> X-Enigmail-Version: 1.4.1 OpenPGP: id=3C9B0CF9; url=http://www.shatow.net/bryan/bryan.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: [review request] usr.sbin/service - make showing files configurable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 13:35:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/13/2012 6:15 PM, Doug Barton wrote: > On 5/12/2012 8:23 PM, Bryan Drewery wrote: >> Hi, >> >> I found service(8) to be inconsistent that it listed files with `service >> -e`, but plain services with `service -l` > > That behavior is by design. > Could you please elaborate on the design decision? I did of course look in base for uses of service -e and service -l, before considering this patch. The only case I can find is in a cshrc example, which my patch does not affect. I had expected service -e to behave like service -l, so I could for example, put it into a loop and check all services, using the service(8) script itself. for service_name in `service -e`; do service status $service_name || service start $service_name; done Of course this doesn't work as -e returns files. /etc/rc.d/ntpd does not exist in /etc/rc.d or the local startup directories (/usr/local/etc/rc.d) This may be a poor example, but it's something I tried and was surprised by not working. My patch allows for the old behavior of listing the file, but improves it so now -e -l and -r all support showing files by specifying -F, while without, it just lists the service names. I consider this change to be fairly trivial since -e doesn't appear to be used anywhere currently. > Thanks for your interest, > > Doug > Regards, Bryan Drewery -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPsQobAAoJEG54KsA8mwz55UcP/3m/6JnfNauEBr4/YB+fClyq 0+q6qkZIue7iXvZKxbE86Zyg4PxBMEvsteVrqZHSwSbwJmvrRj8o1aQkKS2FDgjW 0urKhNnzY2nd5cgDfE9HLSsg9gm25KWbVEcPKNhY5ru8BltRaLQ4V5XGu5XIsxYM E2660rX71q1+GgjuU4TqKUj3m/PjNeAw37uwJTvhmWwP2EK8Aw3zOfipQAsYo4ng ehha1gG0y6fqK44hlgr/SByiGmcN2+5OxCFQp/GFCwvVjXIUTnMN0xLs77GN1/S6 P4yMz6bE605uEaHQfbyPminfE/5t5Zisr9ctk4Vckwj+ixHetcVEa692NXGb5YwP +WygJ6HJk7pwJnQwjFwXUSKJSA/Iy0ktXBaJDawLZWAKl2CuADq9H6fnOqdTJWF2 tgXYufvuWNzCmdfW+kOuDbzUxcUcK/GMN5y4z41Ee245h/GQ5otECD/lybeBwnZF S90Hpc8nuctedDw5GuisQMBNNOfctdl/gRL+zmLIEDD7lzO90bz6bJlUMZt2Umzq 1vou2brIpMqmN+ci1PMSpXRIRufXSHOAPRzfPOORYZWb7t51C173YjwFt6Zkk6nt WKXVQzM9oArfClAUilVbiqlq4PSMVh/9iCTZSsNrNWRiPjIpapxAIlXg/idgxTZA YX6eL2j3vXWahCP0PKtP =woA8 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon May 14 15:25:42 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C89F9106564A; Mon, 14 May 2012 15:25:42 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by mx1.freebsd.org (Postfix) with ESMTP id 570668FC17; Mon, 14 May 2012 15:25:42 +0000 (UTC) Received: from [78.35.145.73] (helo=fabiankeil.de) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1STx9Y-00072i-62; Mon, 14 May 2012 17:25:40 +0200 Date: Mon, 14 May 2012 17:19:14 +0200 From: Fabian Keil To: Andriy Gapon Message-ID: <20120514171914.7a1e9d10@fabiankeil.de> In-Reply-To: <4FB0ED96.6010100@FreeBSD.org> References: <4FAF767C.8030500@cran.org.uk> <4FB0ED96.6010100@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/kHJMmgyrRv=HxoPDst7oJDj"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: Bruce Cran , freebsd-current Subject: Re: Default directory used for 'zpool import' broken (/dev/dsk)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 15:25:42 -0000 --Sig_/kHJMmgyrRv=HxoPDst7oJDj Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Andriy Gapon wrote: > on 13/05/2012 11:53 Bruce Cran said the following: > > When running 'zpool import' without -d I get the error: > > "cannot open '/dev/dsk': must be an absolute path" > >=20 > > zpool(8) suggests the default should have been updated for FreeBSD: > > "If the -d option is not specified, this command searches for devices > > in "/dev"" > >=20 > > Was this broken recently? > Not sure, but maybe /dev/dsk is recorded somewhere in the pool metadata > or in zpool.cache. It could have happened with the older version of the > code. I think that you could check that with zdb. I think that a fresh > import should fix it, though. The following patch seems to work for me: #### commit 7ec69700f2d6944a61f5c7a826e67f46fa160221 Author: Fabian Keil Date: Mon May 12 16:53:56 2012 +0200 Default to searching vdevs in /dev. /dev/dsk doesn't exist on FreeBSD. =20 Fixes import issues if no cachefile exists and -d isn't used: =20 fk@r500 ~ $sudo zpool import wde2 cannot open '/dev/dsk': must be an absolute path diff --git a/cddl/contrib/opensolaris/cmd/zpool/zpool_main.c b/cddl/contrib= /opensolaris/cmd/zpool/zpool_main.c index fe76250..5d1e454 100644 --- a/cddl/contrib/opensolaris/cmd/zpool/zpool_main.c +++ b/cddl/contrib/opensolaris/cmd/zpool/zpool_main.c @@ -1909,7 +1909,7 @@ zpool_do_import(int argc, char **argv) =20 if (searchdirs =3D=3D NULL) { searchdirs =3D safe_malloc(sizeof (char *)); - searchdirs[0] =3D "/dev/dsk"; + searchdirs[0] =3D "/dev"; nsearch =3D 1; } #### The cachefile part is speculation ... Fabian --Sig_/kHJMmgyrRv=HxoPDst7oJDj Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk+xInUACgkQBYqIVf93VJ3rVgCfUWL4pmXd2OmAGuJ6fhyupY+7 KiYAoI5TmuQ4iEt7wREROjFAdF4U1lOm =INd4 -----END PGP SIGNATURE----- --Sig_/kHJMmgyrRv=HxoPDst7oJDj-- From owner-freebsd-current@FreeBSD.ORG Mon May 14 15:39:00 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0226D1065670 for ; Mon, 14 May 2012 15:39:00 +0000 (UTC) (envelope-from oleg.moskalenko@citrix.com) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) by mx1.freebsd.org (Postfix) with ESMTP id B328E8FC12 for ; Mon, 14 May 2012 15:38:59 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.75,586,1330923600"; d="scan'208";a="194717787" Received: from sjcpmailmx02.citrite.net ([10.216.14.75]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 May 2012 11:38:58 -0400 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.73]) by SJCPMAILMX02.citrite.net ([10.216.14.75]) with mapi; Mon, 14 May 2012 08:38:57 -0700 From: Oleg Moskalenko To: =?iso-8859-1?Q?=27G=E1bor_K=F6vesd=E1n=27?= , Garrett Cooper Date: Mon, 14 May 2012 08:38:58 -0700 Thread-Topic: FYI FreeBSD clang build fails on new import of sort Thread-Index: Ac0xxB64L5VcO84jTEG3Uadl9J4pfAAI3FFQ Message-ID: <031222CBCF33214AB2EB4ABA279428A3011A2C2D1AD7@SJCPMAILBOX01.citrite.net> References: <4FB0EB4C.5090000@t-hosting.hu> In-Reply-To: <4FB0EB4C.5090000@t-hosting.hu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Outback Dingo , freebsd-current Subject: RE: FYI FreeBSD clang build fails on new import of sort X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 15:39:00 -0000 I found another problem with sort compilation with clang, I'll send the fix= soon. Thanks Oleg > -----Original Message----- > From: G=E1bor K=F6vesd=E1n [mailto:gabor@t-hosting.hu] > Sent: Monday, May 14, 2012 4:24 AM > To: Garrett Cooper > Cc: Outback Dingo; freebsd-current; Oleg Moskalenko > Subject: Re: FYI FreeBSD clang build fails on new import of sort >=20 > On 2012.05.14. 2:49, Garrett Cooper wrote: > > Yeah... errx(2, getstr(9)) should be errx(2, "%s", getstr(9))... > > -Garrett > Thanks, should be fixed now. >=20 > Gabor From owner-freebsd-current@FreeBSD.ORG Mon May 14 16:11:56 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 289EB106564A for ; Mon, 14 May 2012 16:11:56 +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 6DB168FC14 for ; Mon, 14 May 2012 16:11:55 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA26571; Mon, 14 May 2012 19:11:44 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4FB12EBF.2030804@FreeBSD.org> Date: Mon, 14 May 2012 19:11:43 +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: Fabian Keil References: <4FAF767C.8030500@cran.org.uk> <4FB0ED96.6010100@FreeBSD.org> <20120514171914.7a1e9d10@fabiankeil.de> In-Reply-To: <20120514171914.7a1e9d10@fabiankeil.de> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Bruce Cran , freebsd-current Subject: Re: Default directory used for 'zpool import' broken (/dev/dsk)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 16:11:56 -0000 on 14/05/2012 18:19 Fabian Keil said the following: > Andriy Gapon wrote: > >> on 13/05/2012 11:53 Bruce Cran said the following: >>> When running 'zpool import' without -d I get the error: >>> "cannot open '/dev/dsk': must be an absolute path" >>> >>> zpool(8) suggests the default should have been updated for FreeBSD: >>> "If the -d option is not specified, this command searches for devices >>> in "/dev"" >>> >>> Was this broken recently? > >> Not sure, but maybe /dev/dsk is recorded somewhere in the pool metadata >> or in zpool.cache. It could have happened with the older version of the >> code. I think that you could check that with zdb. I think that a fresh >> import should fix it, though. > > The following patch seems to work for me: > > #### > commit 7ec69700f2d6944a61f5c7a826e67f46fa160221 > Author: Fabian Keil > Date: Mon May 12 16:53:56 2012 +0200 > > Default to searching vdevs in /dev. /dev/dsk doesn't exist on FreeBSD. > > Fixes import issues if no cachefile exists and -d isn't used: > > fk@r500 ~ $sudo zpool import wde2 > cannot open '/dev/dsk': must be an absolute path Hah, so this hasn't been fixed actually. Thank you for the patch! > diff --git a/cddl/contrib/opensolaris/cmd/zpool/zpool_main.c b/cddl/contrib/opensolaris/cmd/zpool/zpool_main.c > index fe76250..5d1e454 100644 > --- a/cddl/contrib/opensolaris/cmd/zpool/zpool_main.c > +++ b/cddl/contrib/opensolaris/cmd/zpool/zpool_main.c > @@ -1909,7 +1909,7 @@ zpool_do_import(int argc, char **argv) > > if (searchdirs == NULL) { > searchdirs = safe_malloc(sizeof (char *)); > - searchdirs[0] = "/dev/dsk"; > + searchdirs[0] = "/dev"; > nsearch = 1; > } > #### > > The cachefile part is speculation ... -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon May 14 16:40:13 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74BC51065672; Mon, 14 May 2012 16:40:13 +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 4C8678FC0C; Mon, 14 May 2012 16:40:12 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA26852; Mon, 14 May 2012 19:40:07 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4FB13567.3050705@FreeBSD.org> Date: Mon, 14 May 2012 19:40:07 +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: Fabian Keil References: <4FAF767C.8030500@cran.org.uk> <4FB0ED96.6010100@FreeBSD.org> <20120514171914.7a1e9d10@fabiankeil.de> <4FB12EBF.2030804@FreeBSD.org> In-Reply-To: <4FB12EBF.2030804@FreeBSD.org> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Bruce Cran , freebsd-current Subject: Re: Default directory used for 'zpool import' broken (/dev/dsk)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 16:40:13 -0000 on 14/05/2012 19:11 Andriy Gapon said the following: > on 14/05/2012 18:19 Fabian Keil said the following: >> The following patch seems to work for me: >> >> #### >> commit 7ec69700f2d6944a61f5c7a826e67f46fa160221 >> Author: Fabian Keil >> Date: Mon May 12 16:53:56 2012 +0200 >> >> Default to searching vdevs in /dev. /dev/dsk doesn't exist on FreeBSD. >> >> Fixes import issues if no cachefile exists and -d isn't used: >> >> fk@r500 ~ $sudo zpool import wde2 >> cannot open '/dev/dsk': must be an absolute path > > Hah, so this hasn't been fixed actually. > Thank you for the patch! > >> diff --git a/cddl/contrib/opensolaris/cmd/zpool/zpool_main.c b/cddl/contrib/opensolaris/cmd/zpool/zpool_main.c >> index fe76250..5d1e454 100644 >> --- a/cddl/contrib/opensolaris/cmd/zpool/zpool_main.c >> +++ b/cddl/contrib/opensolaris/cmd/zpool/zpool_main.c >> @@ -1909,7 +1909,7 @@ zpool_do_import(int argc, char **argv) >> >> if (searchdirs == NULL) { >> searchdirs = safe_malloc(sizeof (char *)); >> - searchdirs[0] = "/dev/dsk"; >> + searchdirs[0] = "/dev"; >> nsearch = 1; >> } >> #### >> >> The cachefile part is speculation ... > > Not sure if the following is also necessary, but it looks like it makes sense: --- a/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_import.c +++ b/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_import.c @@ -1145,7 +1145,7 @@ zpool_find_import_impl char *end, **dir = iarg->path; size_t pathleft; nvlist_t *ret = NULL; - static char *default_dir = "/dev/dsk"; + static char *default_dir = "/dev"; pool_list_t pools = { 0 }; pool_entry_t *pe, *penext; vdev_entry_t *ve, *venext; I am not sure if zpool_find_import_impl is ever called with empty/zero paths/path in the importargs_t parameter. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon May 14 16:41:42 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 197A7106566B; Mon, 14 May 2012 16:41:42 +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 DDD968FC12; Mon, 14 May 2012 16:41:40 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA26869; Mon, 14 May 2012 19:41:38 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4FB135C1.4000505@FreeBSD.org> Date: Mon, 14 May 2012 19:41:37 +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: Bruce Cran References: <4FAF7343.8010808@cran.org.uk> <4FB01437.6030608@FreeBSD.org> <4FB0391D.3040501@cran.org.uk> In-Reply-To: <4FB0391D.3040501@cran.org.uk> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, freebsd-current , Jung-uk Kim Subject: Re: ACPI 'driver bug: Unable to set devclass' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 16:41:42 -0000 on 14/05/2012 01:43 Bruce Cran said the following: > On 13/05/2012 21:06, Andriy Gapon wrote: >> Can you produce an equivalent snippet with verbose logging enabled? I have a >> suspicion that these messages are a byproduct from r231161. > > acpi0: reservation of fee00000, 1000 (3) failed > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, bbf00000 (3) failed > acpi_sysresource: acpi_sysresource0 already exists; skipping it > driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > acpi_timer: acpi_timer0 already exists; skipping it > driver bug: Unable to set devclass (class: acpi_timer devname: (unknown)) > cpu0: on acpi0 > ACPI Warning: Incorrect checksum in table [OEMB] - 0x45, should be 0x44 > (20120420/tbutils-293) > ACPI: SSDT 0xbb7900f0 01340 (v01 DpgPmm P001Ist 00000011 INTL 20051117) > ACPI: Dynamic OEM Table Load: > ACPI: SSDT 0 01340 (v01 DpgPmm P001Ist 00000011 INTL 20051117) > ACPI: SSDT 0xbb791430 004F4 (v01 PmRef P001Cst 00003001 INTL 20051117) > ACPI: Dynamic OEM Table Load: > ACPI: SSDT 0 004F4 (v01 PmRef P001Cst 00003001 INTL 20051117) > acpi_sysresource: acpi_sysresource2 already exists; skipping it > driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > cpu2: on acpi0 > acpi_sysresource: acpi_sysresource1 already exists; skipping it > driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > cpu1: on acpi0 > acpi_sysresource: acpi_sysresource3 already exists; skipping it > driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > I think that the following is what happens here in the acpi_timer case. Previously one acpi_timer device_t was added with an order of zero and a fixed unit number of zero in acpi_timer_identify(). Then, another acpi_timer device_t could be added when walking the ACPI device tree, that device would always have a later order and a wildcard unit number (-1). Now both the "hardwired" device and "auto-probed" device are added with the same order of 2 and it also so happens that the hardwired device is after the auto-probed in the device list. So first the auto-probed device just takes the unit number of zero because it is free and then the hardwired device fails to claim the same unit number. The call chain is: device_probe_child -> device_set_devclass -> devclass_add_device -> devclass_alloc_unit. BTW, it seems that acpi_timer_probe is hardcoded to succeed only for the hardwired device, so I am not if we should just skip creating an auto-probed device. In any case, setting any special properties for the auto-probed device (like the order) seems to be completely pointless. I am not really sure what happens for the acpi_sysresource devices. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon May 14 17:26:26 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2122E1065670 for ; Mon, 14 May 2012 17:26:26 +0000 (UTC) (envelope-from gabor@t-hosting.hu) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id C2F758FC08 for ; Mon, 14 May 2012 17:26:25 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 7A19914E75E6; Mon, 14 May 2012 19:26:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id g73cJrUAQsb8; Mon, 14 May 2012 19:26:23 +0200 (CEST) Received: from [192.168.1.117] (catv-80-98-232-12.catv.broadband.hu [80.98.232.12]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id EAC4514E729F; Mon, 14 May 2012 19:26:22 +0200 (CEST) Message-ID: <4FB1403D.5090408@t-hosting.hu> Date: Mon, 14 May 2012 19:26:21 +0200 From: =?ISO-8859-1?Q?G=E1bor_K=F6vesd=E1n?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120328 Thunderbird/13.0a2 MIME-Version: 1.0 To: Oleg Moskalenko References: <4FB0EB4C.5090000@t-hosting.hu> <031222CBCF33214AB2EB4ABA279428A3011A2C2D1AD7@SJCPMAILBOX01.citrite.net> In-Reply-To: <031222CBCF33214AB2EB4ABA279428A3011A2C2D1AD7@SJCPMAILBOX01.citrite.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 14 May 2012 17:45:16 +0000 Cc: Garrett Cooper , Outback Dingo , freebsd-current Subject: Re: FYI FreeBSD clang build fails on new import of sort X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 17:26:26 -0000 On 2012.05.14. 17:38, Oleg Moskalenko wrote: > I found another problem with sort compilation with clang, I'll send the fix soon. I also found them and fixed them when committing your another fixes, so it should be ok now. Gabor From owner-freebsd-current@FreeBSD.ORG Mon May 14 17:55:05 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F9EC1065672; Mon, 14 May 2012 17:55:05 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 96BEE8FC17; Mon, 14 May 2012 17:55:04 +0000 (UTC) Message-ID: <4FB146F8.9090901@FreeBSD.org> Date: Mon, 14 May 2012 13:55:04 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120502 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mitsuru IWASAKI References: <4FAF696D.3060806@entel.upc.edu> <20120513.234014.26960250.iwasaki@jp.FreeBSD.org> <9E61BC2D-2654-40D9-936F-A99CD7AC1354@entel.upc.edu> <20120514.131617.129792413.iwasaki@jp.FreeBSD.org> In-Reply-To: <20120514.131617.129792413.iwasaki@jp.FreeBSD.org> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, gperez@entel.upc.edu, freebsd-current@freebsd.org Subject: Re: [CFT] SMP/i386 suspend/resume X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 17:55:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-05-14 00:16:17 -0400, Mitsuru IWASAKI wrote: > Hi, > >>>> Reporting from an Acer Centrino Duo, running CURRENT r235266. >>>> The machine has an nvidia card (Ge7300go). The acpi_video and >>>> nvidia modules are there. >>>> >>>> I did test it a few times with X running (plain twm) and >>>> worked just fine. Setting hw.acpi.lid_switch_state=S3 allowed >>>> me to use the close-the-lid-to-sleep functionality. >>>> >>>> The problem comes when I suspend the machine in the console. >>>> The machine resumes fine (I can ping and ssh it) but the >>>> screen remains black. I set hw.acpi.reset_video to 0 or 1 but >>>> no go. If I'm in a console but X is running, after the resume >>>> I can CTRL+ALT+F9 and get my video back; then I can return to >>>> the console. If I don't have X running, I don't know how to >>>> get my console back. >>> >>> I think this is graphic driver problem. nvidia's driver seems >>> to have correct suspend/resume method. >>> http://www.nvidia.com/object/freebsd_archive.html >>> >>> Have you try it? >> >> Yes, it is running the propietary driver. Everything was done >> with it loaded. Do you want me to try without the nvidia binary >> driver? First of all, thank you very much for your work! I wanted to do it for very long time but I had no time to actually implement it. :-) > Yes, if it doesn't bother you. Hmmm, it doesn't seem related with > my SMP/i386 sleep patches. I know for sure it is not related to your patches. In fact, we cannot resume most NVIDIA controllers without NVIDIA kernel driver + binary X.org driver + VT switching hack (i.e., hw.syscons.sc_no_suspend_vtswitch=0, which is default). Also, there is ACPI_PM option for ports/x11/nvidia-driver but it doesn't help much because it doesn't seem to save/restore GPU registers by itself (off by default). Very few NVIDIA controllers can be reset with BIOS POST or saved/restored with VBE functions. Many Intel controllers have similar issues and they need kib's KMS driver. Usually, ATI/AMD controllers have no problem when (relatively recent) vesa.ko is compiled into kernel or loaded as module as they have complete VBE save/restore functions. Similarly, any video controllers with correct save/restore functions should work with vesa.ko. > Could you try also Uni-processer kernel (w/o SMP and apic from > config file) without my patches? > >> OTOH, IIRC the console only test (without X) without acpi_video >> lead to freeze. No crash dump. The machine has no serial or fwire >> ports :( > > We can improve video initialization on another opportunity. Linux > have many video hacks while we have only hw.acpi.reset_video ;) FYI, we don't need hw.acpi.reset_video any more (and it is even harmful). It is done from vesa.ko now. > http://www.kernel.org/doc/Documentation/power/video.txt I believe > there are some solutions for you in this document, then we can > implement them in our source if found. Most of these Linux hacks are completely obsolete since KMS. I really don't want to reiterate Linux mistakes again. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+xRvcACgkQmlay1b9qnVP1NwCfVPMz1YhvUcyyhWkQjs4JZdgd B0gAoKuv4ST+N7FInyfaMwMYuFe4AfNx =jk3/ -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon May 14 18:17:50 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B758106564A for ; Mon, 14 May 2012 18:17:49 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 529498FC14 for ; Mon, 14 May 2012 18:17:49 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 1D79BE6503 for ; Mon, 14 May 2012 19:18:01 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; s=mail; bh=2OSbZVW6HrKWkW90W6cVu8MZ9 vc=; b=pUOQg+HqETr/D0hUGuAvl3coIRm9hAdED7E2mf1+xTdXPVa8PevrOwi7k 7ly45CG5zhU5QLU0boV72d8gJ4N2N25Px+klRdkjR8NuJcnbFJR9qCj3Ishuoixz 1aJLSOEwO+CjKvRTz3PpOLZK5m6+QJ/AUYhQHoolAnNIrJMM9U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; q=dns; s=mail; b=AOv9u7iMem/ShFbmqGG 2I6qIGJCyR3ETpFeotvhCBthlUTH/VvrOsZdyOTwZ5UnGjUs+VuA8XVvbRUi3Xo4 CpIwQw3Bn8PYCzB5WSA8yfM7KfmovHHmJO/eFyiH0AfWpWMVkgCznjO/SSrgSrYa R/HXj/ZEnJEWAWVqRcu1UDO0= Received: from [192.168.2.2] (unknown [109.249.232.2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id D73BFE6463 for ; Mon, 14 May 2012 19:18:00 +0100 (BST) Message-ID: <4FB14C48.1030002@cran.org.uk> Date: Mon, 14 May 2012 19:17:44 +0100 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: "random device not loaded; using insecure entropy" during boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 18:17:50 -0000 While booting -current I noticed a new warning introduced in r230230** (though it's not in 'dmesg' once booted): FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 5 random device not loaded; using insecure entropy I guess something's wanting random data before its been initialized? Once booted kern.random shows that it is loaded and working. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Mon May 14 18:23:21 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D7CA1065673 for ; Mon, 14 May 2012 18:23:21 +0000 (UTC) (envelope-from bryan@shatow.net) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) by mx1.freebsd.org (Postfix) with ESMTP id 1FE188FC18 for ; Mon, 14 May 2012 18:23:20 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:content-type :content-transfer-encoding; q=dns; s=sweb; b=IdevXwDh2XkOyYN2uOt opjiEaQFc8JRPuZ7Gd3BvY+KR7JHF2sn2rgMIWEjZjjDmaYMIAH9RTxEjYxtpBz/ cv8lJ3HrcIB8aSOv4p2GBceqCThnTOX8S02pWDgQoYsauRAxqItspbs5Ccv0m3LY heR3QjQwqVDzB8JU6+pvQiKA= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:content-type :content-transfer-encoding; s=sweb; bh=AoJbG9qSGreHl19Mo9z58I64H DrNJ+72SvdJcACdJq0=; b=nU5BG+SG5Oym2aKwZIFH1zjEg25WuPFnUdOlAj05K WUYag5UL6cFWAzE/BepW/nI2sWLBDzRwXBDzg5CvjfrGlXvBNQyBimgBrC8rBfS3 V0DjpAk2NvPswwlJzOY+5qCSixvSunxem3DmTcsp0TPW+BMtbL5mBk6ceW1dxPBZ s8= Received: (qmail 37755 invoked from network); 14 May 2012 13:23:18 -0500 Received: from unknown (HELO ?192.168.0.107?) (bryan@shatow.net@74.94.87.209) by sweb.xzibition.com with ESMTPA; 14 May 2012 13:23:18 -0500 Message-ID: <4FB14D95.7060003@shatow.net> Date: Mon, 14 May 2012 13:23:17 -0500 From: Bryan Drewery User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: jpaetzel@FreeBSD.org, nwhitehorn@freebsd.org, kris@freebsd.org X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: bsdinstall+ZFS / pc-sysinstall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 18:23:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Josh / Nate / Kris, I have taken interest in adding basic ZFS support to bsdinstall. I especially want to ensure that the default layout supports "Boot Environments" for future use. So rpool/ROOT/freebsd/* instead of rpool/*. I see that pc-sysinstall has been in the works for a while now. Is the plan still to hook bsdinstall into using pc-sysinstall as the backend? What's the general status of pc-sysinstall in FreeBSD? Unless someone else is already tackling getting ZFS support into bsdinstall, or working to get bsdinstall to use pc-sysinstall, I'd love to take that project on and/or help in any way. Regards, Bryan Drewery -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPsU2SAAoJEG54KsA8mwz51swP/2xuhDDm4+rPZEmjgbHcQ2ib qmjIs9pAvanP6K1dsldmIIAXG8CzZR0+hYJ7MEh95fLK3jelcbsepxwguo8/Yl7p w3iKuULmctkbyQdAr29TXQ/IcZjIGCpsS31LtnFOezkuahrl2ReSlFsbP16UOTbB Evx0QOdkly7hL+Dy61mQJaUQlCsQQ1fU52EUgOLeQIMJByYMmNZ6gn11jGW73WWW dl2ETxJwftzeB7/AkcRgtDRgzrDC/HjXtHftFDiD6koXbryWxHnpvXrTFhAGNe5V uAvdJ0SNY+PHuGPG4mcTHJVEXAkox4LEYNuK+5NALAFqdSOjTHdbEaG1RS5woPPR rPyQ/vyLLwcqQymdp0cOxta6q3tKqQAeshymQelnB4MsBvDlx1ORJP1unXZb7+R8 d9ArW+DB24eUqzeztOTmoUJkG6Ir44hWQPO7ZX5NW2ZwP9PDWqo1Frf95NtNsQ6C NmzeUlpDDwZQI5jDK1BiIyMpHPSgZyHXRq3/uiEwEJ5JTrZ1kQIz4P7Bw+ZB4UYj KRRw8CKvEx6MFOghiiqf55QqmU6/IR7gVKNtRhv4hv48CLDbw5gH0fwkS2JtSUkv mI23IoykuLJDx/HjSLL3q+F1CMjDSDoNbaf2yAQfFjiJSx+49Cnq1dSwvwznU9JI n7O7UHB+ryUHxgsfGz7t =SQtL -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon May 14 19:34:13 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9055B106566B for ; Mon, 14 May 2012 19:34:13 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id DB0598FC14 for ; Mon, 14 May 2012 19:34:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:To:From:Subject:Date:Message-ID; bh=KSARsDqisUbo2A4Ow86t4q1FPY06yWDWqFngcPw4REw=; b=lwPM+kRkcH5eOYKJVju+YlGOfWkD1V/kBFS3aFJaPe9LWheF1x9W7GGeyf2n8MOq0GmuiKApnItFj2onZIbHhlk0V2ikeTb2X3RIQMOXcxCvmd3uc5ZfS4uNX0nwEKtBxS5LleHLpnvn8RG7oPnrKkR1R25X+TTvBP+ITC61ixk=; Received: from localhost.lerctr.org ([127.0.0.1]:13216 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SU122-0005yj-Uz for freebsd-current@freebsd.org; Mon, 14 May 2012 14:34:12 -0500 Received: from 32.97.110.60 (SquirrelMail authenticated user ler) by webmail.lerctr.org with HTTP; Mon, 14 May 2012 14:34:10 -0500 Message-ID: <12a0614ee013e6be6bd58185ce538b70.squirrel@webmail.lerctr.org> Date: Mon, 14 May 2012 14:34:10 -0500 From: "Larry Rosenman" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20120514143410_65565" X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: No reboot on shutdown -r? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 19:34:13 -0000 ------=_20120514143410_65565 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit In the last week or 3 I've seen a regression where my FreeBSD 10.0-CURRENT system will NOT reboot. It'll hang at "all buffers synced". Usually I do this remote, and do have an IPMI card in it, but that precludes responding to a prompt, or sending keystrokes (since it looks like a USB keyboard). What can I do when I'm local to the box to see why it's hanging? Current SVN: r235453 See attached picture. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ------=_20120514143410_65565-- From owner-freebsd-current@FreeBSD.ORG Mon May 14 19:37:11 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90CFF106564A for ; Mon, 14 May 2012 19:37:11 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4C6A68FC0C for ; Mon, 14 May 2012 19:37:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:To:From:Subject:Date:References:In-Reply-To:Message-ID; bh=+VO/au96dSMFz98HWvi4MKFlmLJdtvTx7ksRCpHvlCw=; b=ROipJed4rYZsV5uJBbDHGUOhIZULi5FqfNDrorSKi6W2VQsCA+7Dv1lhC3XQ295PMxZilShRnWMHvYNISnc10ozHNu00bjYdEFotQdGUZTGMFlBBubN6USMrdtmwXuwZn00+iVUORmorjMB81uz6HZsQPpJkn2jvfYp888+TuE4=; Received: from localhost.lerctr.org ([127.0.0.1]:15825 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SU14v-00060B-Cl; Mon, 14 May 2012 14:37:10 -0500 Received: from 32.97.110.60 (SquirrelMail authenticated user ler) by webmail.lerctr.org with HTTP; Mon, 14 May 2012 14:37:09 -0500 Message-ID: <1531d882ad3657e22ab11868c42f219c.squirrel@webmail.lerctr.org> In-Reply-To: <12a0614ee013e6be6bd58185ce538b70.squirrel@webmail.lerctr.org> References: <12a0614ee013e6be6bd58185ce538b70.squirrel@webmail.lerctr.org> Date: Mon, 14 May 2012 14:37:09 -0500 From: "Larry Rosenman" To: "Larry Rosenman" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 Cc: freebsd-current@freebsd.org Subject: Re: No reboot on shutdown -r? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 19:37:11 -0000 On Mon, May 14, 2012 2:34 pm, Larry Rosenman wrote: > In the last week or 3 I've seen a regression where my FreeBSD 10.0-CURRENT > system will NOT reboot. It'll hang at "all buffers synced". > > Usually I do this remote, and do have an IPMI card in it, but that > precludes responding to a prompt, or sending keystrokes (since it looks > like a USB keyboard). > > What can I do when I'm local to the box to see why it's hanging? > > Current SVN: r235453 > See attached picture. I forgot this list strips attachments. picture at: http://www.lerctr.org/~ler/FreeBSD%20-%20NoReboot.PNG > > > > > > -- > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 512-248-2683 E-Mail: ler@lerctr.org > US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Mon May 14 20:00:21 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 40A351065673 for ; Mon, 14 May 2012 20:00:21 +0000 (UTC) (envelope-from krivenok.dmitry@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id C32B38FC12 for ; Mon, 14 May 2012 20:00:20 +0000 (UTC) Received: by bkvi18 with SMTP id i18so4437488bkv.13 for ; Mon, 14 May 2012 13:00:19 -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:cc:content-type :content-transfer-encoding; bh=9IgYLL2dQ/iHbhtDpd9RIDYC7o3ZdbR13C84k3Rwnz8=; b=WI/ywVWmU04asNYVzGdrftXAggJlWV2Mz7EuqhnDkeO7rv4JEj1c9I7NuKLg7danrd l1/4dqCTR4wHDnNtuJxZowcBKHxsE5wRSxlDRbenJAQlNkUE/+oa//got9f8MgGBwg5j jY4V/wv7+1ZncezOGsSkCRxT/yfKu6Jbz5xgBueqYWbGn8XRy/7Ny0x+HkCWMsS4U/cW cAvrMuM1RmnDORTgNCfWMzC1WJEgWsGuhrL9kWYeBHCA2Z0IHkZZpNwvJjIyRmBb6k30 chRfJXObTcoDR85L03Yr9aWCAr+rZ5kt3iTZJ6K48q35G3Y9LYOK/Wjr4lQr7Auo9HY3 WtHA== MIME-Version: 1.0 Received: by 10.205.128.8 with SMTP id hc8mr3584815bkc.17.1337025619616; Mon, 14 May 2012 13:00:19 -0700 (PDT) Received: by 10.205.129.16 with HTTP; Mon, 14 May 2012 13:00:19 -0700 (PDT) Date: Tue, 15 May 2012 00:00:19 +0400 Message-ID: From: Dmitry Krivenok To: freebsd-current@freebsd.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: dmitry.krivenok@emc.com Subject: CURRENT (r235416) build error (/usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `log') X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 20:00:21 -0000 Hello Hackers, I=92m trying to build -CURRENT (r235416) and getting build error: =3D=3D=3D> lib/clang/libllvmx86utils (all) =3D=3D=3D> lib/clang/include (all) =3D=3D=3D> libexec (all) =3D=3D=3D> libexec/atrun (all) cc -O2 -pipe -DATJOB_DIR=3D\"/var/at/jobs/\" -DLFILE=3D\"/var/at/jobs/.lockfile\" -DLOADAVG_MX=3D1.5 -DATSPOOL_DIR=3D\"/var/at/spool\" -DVERSION=3D\"2.9\" -DDAEMON_UID=3D1 -DDAEMON_GID=3D1 -DDEFAULT_BATCH_QUEUE=3D\'E\' -DDEFAULT_AT_QUEUE=3D\'c\' -DPERM_PATH=3D\"/var/at/\" -I/usr/src/libexec/atrun/../../usr.bin/at -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -g -O0 -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/libexec/atrun/atrun.c cc -O2 -pipe -DATJOB_DIR=3D\"/var/at/jobs/\" -DLFILE=3D\"/var/at/jobs/.lockfile\" -DLOADAVG_MX=3D1.5 -DATSPOOL_DIR=3D\"/var/at/spool\" -DVERSION=3D\"2.9\" -DDAEMON_UID=3D1 -DDAEMON_GID=3D1 -DDEFAULT_BATCH_QUEUE=3D\'E\' -DDEFAULT_AT_QUEUE=3D\'c\' -DPERM_PATH=3D\"/var/at/\" -I/usr/src/libexec/atrun/../../usr.bin/at -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -g -O0 -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/libexec/atrun/gloadavg.c cc -O2 -pipe -DATJOB_DIR=3D\"/var/at/jobs/\" -DLFILE=3D\"/var/at/jobs/.lockfile\" -DLOADAVG_MX=3D1.5 -DATSPOOL_DIR=3D\"/var/at/spool\" -DVERSION=3D\"2.9\" -DDAEMON_UID=3D1 -DDAEMON_GID=3D1 -DDEFAULT_BATCH_QUEUE=3D\'E\' -DDEFAULT_AT_QUEUE=3D\'c\' -DPERM_PATH=3D\"/var/at/\" -I/usr/src/libexec/atrun/../../usr.bin/at -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -g -O0 -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o atrun atrun.o gloadavg.o -lpam -lutil /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `log' *** [atrun] Error code 1 Stop in /usr/src/libexec/atrun. *** [all] Error code 1 Stop in /usr/src/libexec. *** [libexec.all__D] Error code 1 Stop in /usr/src. *** [everything] Error code 1 Stop in /usr/src. *** [buildworld] Error code 1 Stop in /usr/src. Last time I successfully built -CURRENT was in the middle of February. I have checked UPDATING file, but didn=92t find anything interesting there. I wonder if it=92s a known issue? Is there a known solution for this? Thanks in advance! P.S. My system info: $ uname -a FreeBSD csx-spb-freebsd-current 10.0-CURRENT FreeBSD 10.0-CURRENT #8 r231565: Mon Feb 13 05:28:23 MSK 2012 root@csx-spb-freebsd-current:/usr/obj/usr/src/sys/CSXDEBUG amd64 $ gcc --version gcc (GCC) 4.2.1 20070831 patched [FreeBSD] Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ clang --version FreeBSD clang version 3.0 (tags/RELEASE_30/final 145349) 20111210 Target: x86_64-unknown-freebsd10.0 Thread model: posix $ --=20 Sincerely yours, Dmitry V. Krivenok e-mail: krivenok.dmitry@gmail.com skype: krivenok_dmitry jabber: krivenok_dmitry@jabber.ru icq: 242-526-443 From owner-freebsd-current@FreeBSD.ORG Mon May 14 20:03:27 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EA237106566B; Mon, 14 May 2012 20:03:27 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4CC028FC19; Mon, 14 May 2012 20:03:26 +0000 (UTC) Received: by bkvi18 with SMTP id i18so4440916bkv.13 for ; Mon, 14 May 2012 13:03:26 -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=l1d7bD1MTo0VYXPzSREEMEMM5dC5a0r0tvEFihXdzho=; b=oBi0QdUqpWs7WfLPJnC8tM1wf6Fdz2mREWQAyyjOCcUfuOvCOnW/qhBNPeQ26+y3N5 wlaVKbynK8WoZkbfo7qLAJcm9n/7oICdps/ef4iJX8q/QQW662tdOlen1OO6N2dwVhPv rATQRJJv1uaUXXlMIEN42PrCV1P5qGyZyO6dtbY1U+ionJNM0KOf8qvHbTPjCOXxq8x/ e2mwaIliBCtkgEujS3j2+/WYpP/PLDJGOT6lfJIN2fWPB4URi2iXSOXJGM9EhB1NAPzM I+eV4IjlR43jBLHtJ/7Gn/daZ3Vp5qiEv+PySB3i5BlO2csYmH9MpZfCn+RR89iouQWE JIEA== MIME-Version: 1.0 Received: by 10.204.131.71 with SMTP id w7mr3339740bks.92.1337025806179; Mon, 14 May 2012 13:03:26 -0700 (PDT) Received: by 10.204.157.11 with HTTP; Mon, 14 May 2012 13:03:26 -0700 (PDT) Date: Mon, 14 May 2012 16:03:26 -0400 Message-ID: From: Outback Dingo To: freebsd-current , freebsd-ports@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: FYI clang fails to build ports argp-standalone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 20:03:28 -0000 build on CURRENT Not sure if its appropriate here, but when trying to get through a new glusterfs FYI clang fails to build ports argp-standalone on CURRENT From owner-freebsd-current@FreeBSD.ORG Mon May 14 20:21:28 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C0B5106564A; Mon, 14 May 2012 20:21:28 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id 6A5488FC08; Mon, 14 May 2012 20:21:28 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 2C3CD56205; Mon, 14 May 2012 15:21:22 -0500 (CDT) Date: Mon, 14 May 2012 15:21:22 -0500 From: Mark Linimon To: Outback Dingo Message-ID: <20120514202122.GA7554@lonesome.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current , freebsd-ports@freebsd.org Subject: Re: FYI clang fails to build ports argp-standalone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 20:21:28 -0000 a) the best place is freebsd-ports@ b) we do periodic builds of ports with clang as default but in general clang is not ready to be the default compiler yet. Please see http://wiki.freebsd.org/PortsAndClang . mcl From owner-freebsd-current@FreeBSD.ORG Mon May 14 21:41:35 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A4FEE106566C; Mon, 14 May 2012 21:41:35 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3BCE38FC20; Mon, 14 May 2012 21:41:35 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:5957:8207:d7b1:fbe7]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 00D214AC35; Tue, 15 May 2012 01:41:33 +0400 (MSK) Date: Tue, 15 May 2012 01:41:31 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1119727136.20120515014131@serebryakov.spb.ru> To: freebsd-current MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: delphij@FreeBSD.org Subject: libpcap 1.2.1 import breaks (not-rebuilded) ports -- need version bump? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 21:41:35 -0000 Hello, freebsd-current. It seems, that import of libpcap 1.2.1 changes something in library API: port p5-Net-Pcap, build BEFORE world with libpcap 1.2.1 (yes, world and kernel were reinstalled and ports weren't) crash perl when it is used: : /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:912: Failed assertion: "((uintptr_t)ptr & PAGE_MASK) == 0" Abort (core dumped) Perl itself and other scripts, which don't use p5-NEt-Pcap, works. -- // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Mon May 14 23:10:35 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E48E0106564A; Mon, 14 May 2012 23:10:34 +0000 (UTC) (envelope-from jbeich@tormail.org) Received: from server2.allsitecontrol.com (server2.allsitecontrol.com [63.143.36.210]) by mx1.freebsd.org (Postfix) with ESMTP id A69C28FC15; Mon, 14 May 2012 23:10:34 +0000 (UTC) Received: from h-234-182.a189.priv.bahnhof.se ([81.170.234.182]:40555 helo=internal.tormail.org) by server2.allsitecontrol.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.77) (envelope-from ) id 1SU4PO-002kCM-TL; Mon, 14 May 2012 19:10:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tormail.org; s=tm; h=Message-Id:X-TorMail-User:Content-Type:MIME-Version:References:Date:In-Reply-To:Subject:Cc:To:From; bh=cR14TDyKm9SsS5pdltNktvzT2UODw8rRvn3ZhVidMVo=; b=PfEc87ujnWp8whMOHmXqObg5r3ZUsJVlxPq98HoVCwUJ6o6JdwUOYVOoffNC7QK/GikpXrjAznqfWFXCYk2KaQkGc4Ng69ANN4P3hQkwSgBb5y+z08Y93P/ykSU0R12jDaefS/vG7xLdWnfcM4jXFnVWKU8ePWSL+lw9Hiy4K1w=; Received: from jbeich by internal.tormail.org with local (Exim 4.63) (envelope-from ) id 1SU4OR-000Hev-Gq; Mon, 14 May 2012 23:09:33 +0000 From: Jan Beich To: Andriy Gapon In-Reply-To: <4FB13567.3050705@FreeBSD.org> (Andriy Gapon's message of "Mon, 14 May 2012 19:40:07 +0300") Date: Mon, 14 May 2012 13:09:01 -1000 References: <4FAF767C.8030500@cran.org.uk> <4FB0ED96.6010100@FreeBSD.org> <20120514171914.7a1e9d10@fabiankeil.de> <4FB12EBF.2030804@FreeBSD.org> <4FB13567.3050705@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain X-TorMail-User: jbeich Message-Id: <1SU4OR-000Hev-Gq@internal.tormail.org> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server2.allsitecontrol.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tormail.org X-Source: X-Source-Args: X-Source-Dir: X-Mailman-Approved-At: Tue, 15 May 2012 00:55:15 +0000 Cc: Bruce Cran , freebsd-current Subject: Re: Default directory used for 'zpool import' broken (/dev/dsk)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 23:10:35 -0000 Andriy Gapon writes: > on 14/05/2012 19:11 Andriy Gapon said the following: > >> on 14/05/2012 18:19 Fabian Keil said the following: >>> The following patch seems to work for me: >>> >>> #### >>> commit 7ec69700f2d6944a61f5c7a826e67f46fa160221 >>> Author: Fabian Keil >>> Date: Mon May 12 16:53:56 2012 +0200 >>> >>> Default to searching vdevs in /dev. /dev/dsk doesn't exist on FreeBSD. >>> >>> Fixes import issues if no cachefile exists and -d isn't used: >>> >>> fk@r500 ~ $sudo zpool import wde2 >>> cannot open '/dev/dsk': must be an absolute path >> >> Hah, so this hasn't been fixed actually. >> Thank you for the patch! >> >>> diff --git a/cddl/contrib/opensolaris/cmd/zpool/zpool_main.c b/cddl/contrib/opensolaris/cmd/zpool/zpool_main.c >>> index fe76250..5d1e454 100644 >>> --- a/cddl/contrib/opensolaris/cmd/zpool/zpool_main.c >>> +++ b/cddl/contrib/opensolaris/cmd/zpool/zpool_main.c >>> @@ -1909,7 +1909,7 @@ zpool_do_import(int argc, char **argv) >>> >>> if (searchdirs == NULL) { >>> searchdirs = safe_malloc(sizeof (char *)); >>> - searchdirs[0] = "/dev/dsk"; >>> + searchdirs[0] = "/dev"; >>> nsearch = 1; >>> } >>> #### >>> >>> The cachefile part is speculation ... >> >> > > Not sure if the following is also necessary, but it looks like it > makes sense: It looks like bin/155104 which affects zdb -e. > > --- a/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_import.c > +++ b/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_import.c > @@ -1145,7 +1145,7 @@ zpool_find_import_impl > char *end, **dir = iarg->path; > size_t pathleft; > nvlist_t *ret = NULL; > - static char *default_dir = "/dev/dsk"; > + static char *default_dir = "/dev"; > pool_list_t pools = { 0 }; > pool_entry_t *pe, *penext; > vdev_entry_t *ve, *venext; > > I am not sure if zpool_find_import_impl is ever called with empty/zero > paths/path in the importargs_t parameter. From owner-freebsd-current@FreeBSD.ORG Tue May 15 07:30:20 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95B98106567A; Tue, 15 May 2012 07:30:20 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from mail36.syd.optusnet.com.au (mail36.syd.optusnet.com.au [211.29.133.76]) by mx1.freebsd.org (Postfix) with ESMTP id 258B98FC14; Tue, 15 May 2012 07:30:19 +0000 (UTC) Received: from server.rulingia.com (c220-239-254-65.belrs5.nsw.optusnet.com.au [220.239.254.65]) by mail36.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q4F7U9xW016889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 May 2012 17:30:12 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q4F7U4dc021123; Tue, 15 May 2012 17:30:04 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q4F7U2K4021122; Tue, 15 May 2012 17:30:02 +1000 (EST) (envelope-from peter) Date: Tue, 15 May 2012 17:30:02 +1000 From: Peter Jeremy To: Mitsuru IWASAKI Message-ID: <20120515073002.GA21005@server.rulingia.com> References: <20120511.111019.90116031.iwasaki@jp.FreeBSD.org> <20120511112005.GA87299@server.rulingia.com> <20120513.225328.10294857.iwasaki@jp.FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline In-Reply-To: <20120513.225328.10294857.iwasaki@jp.FreeBSD.org> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org Subject: Re: [CFT] SMP/i386 suspend/resume X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 07:30:20 -0000 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I wrote: >> Thank you for that. Since I was in the process of upgrading my >> netbook (Acer Aspire One AOA-110 - Atom N270), I rolled your RELENG_8 >> patch on top of r235229. >>=20 >> Unfortunately, the result hasn't been a complete success. On 2012-May-13 22:53:28 +0900, Mitsuru IWASAKI wro= te: >I think graphic driver (or pic?) has some problems on resume and they >are out of scope of my patches. >HEAD and RELENG_9 have better support on interrupt re-enabling than >RELENG_8 I think. Could you try them? >And for ps/2 mouse, kernel option PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND >would be useful. I've tried stable/9 r235399 with your patches as well as PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND and suspend/resume now works (for the first time) from VTY. I haven't tried suspending directly =66rom X but expect that is still broken. Thank you very much. --=20 Peter Jeremy --4Ckj6UjgE2iN1+kY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk+yBfoACgkQ/opHv/APuIdzgwCeNpwQSpdrUomm10If3/aXxyIh VPYAn0m/xkqL0goAj+UqT+9QxCtuTfBx =gCdw -----END PGP SIGNATURE----- --4Ckj6UjgE2iN1+kY-- From owner-freebsd-current@FreeBSD.ORG Tue May 15 08:09:52 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 50657106566B; Tue, 15 May 2012 08:09:52 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 1838F8FC0A; Tue, 15 May 2012 08:09:51 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q4F89ouW055276; Tue, 15 May 2012 04:09:50 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q4F89o3s055275; Tue, 15 May 2012 08:09:50 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 15 May 2012 08:09:50 GMT Message-Id: <201205150809.q4F89o3s055275@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 08:09:52 -0000 TB --- 2012-05-15 07:00:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-05-15 07:00:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-05-15 07:00:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-05-15 07:00:00 - cleaning the object tree TB --- 2012-05-15 07:00:00 - cvsupping the source tree TB --- 2012-05-15 07:00:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-05-15 07:02:23 - building world TB --- 2012-05-15 07:02:23 - CROSS_BUILD_TESTING=YES TB --- 2012-05-15 07:02:23 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-15 07:02:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-15 07:02:23 - SRCCONF=/dev/null TB --- 2012-05-15 07:02:23 - TARGET=arm TB --- 2012-05-15 07:02:23 - TARGET_ARCH=arm TB --- 2012-05-15 07:02:23 - TZ=UTC TB --- 2012-05-15 07:02:23 - __MAKE_CONF=/dev/null TB --- 2012-05-15 07:02:23 - cd /src TB --- 2012-05-15 07:02:23 - /usr/bin/make -B buildworld >>> World build started on Tue May 15 07:02:24 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 Tue May 15 08:08:08 UTC 2012 TB --- 2012-05-15 08:08:08 - cd /src/sys/arm/conf TB --- 2012-05-15 08:08:08 - /usr/sbin/config -m AVILA TB --- 2012-05-15 08:08:08 - building AVILA kernel TB --- 2012-05-15 08:08:08 - CROSS_BUILD_TESTING=YES TB --- 2012-05-15 08:08:08 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-15 08:08:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-15 08:08:08 - SRCCONF=/dev/null TB --- 2012-05-15 08:08:08 - TARGET=arm TB --- 2012-05-15 08:08:08 - TARGET_ARCH=arm TB --- 2012-05-15 08:08:08 - TZ=UTC TB --- 2012-05-15 08:08:08 - __MAKE_CONF=/dev/null TB --- 2012-05-15 08:08:08 - cd /src TB --- 2012-05-15 08:08:08 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Tue May 15 08:08:08 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 [...] /src/sys/kern/sched_4bsd.c: In function 'sched_add': /src/sys/kern/sched_4bsd.c:1350: warning: implicit declaration of function 'STD_PROBE4' /src/sys/kern/sched_4bsd.c:1350: warning: nested extern declaration of 'STD_PROBE4' [-Wnested-externs] /src/sys/kern/sched_4bsd.c:1350: error: 'sched' undeclared (first use in this function) /src/sys/kern/sched_4bsd.c:1350: error: (Each undeclared identifier is reported only once /src/sys/kern/sched_4bsd.c:1350: error: for each function it appears in.) /src/sys/kern/sched_4bsd.c:1350: error: expected expression before ',' token /src/sys/kern/sched_4bsd.c:1350: error: 'enqueue' undeclared (first use in this function) *** Error code 1 Stop in /obj/arm.arm/src/sys/AVILA. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-05-15 08:09:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-05-15 08:09:50 - ERROR: failed to build AVILA kernel TB --- 2012-05-15 08:09:50 - 2505.58 user 570.33 system 4190.16 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Tue May 15 10:08:15 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 76433106579B; Tue, 15 May 2012 10:08:15 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 44C2F8FC16; Tue, 15 May 2012 10:08:15 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q4FA888b038089; Tue, 15 May 2012 06:08:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q4FA88tL038082; Tue, 15 May 2012 10:08:08 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 15 May 2012 10:08:08 GMT Message-Id: <201205151008.q4FA88tL038082@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 10:08:15 -0000 TB --- 2012-05-15 07:00:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-05-15 07:00:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-05-15 07:00:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-05-15 07:00:00 - cleaning the object tree TB --- 2012-05-15 07:00:00 - cvsupping the source tree TB --- 2012-05-15 07:00:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-05-15 07:05:25 - building world TB --- 2012-05-15 07:05:25 - CROSS_BUILD_TESTING=YES TB --- 2012-05-15 07:05:25 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-15 07:05:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-15 07:05:25 - SRCCONF=/dev/null TB --- 2012-05-15 07:05:25 - TARGET=pc98 TB --- 2012-05-15 07:05:25 - TARGET_ARCH=i386 TB --- 2012-05-15 07:05:25 - TZ=UTC TB --- 2012-05-15 07:05:25 - __MAKE_CONF=/dev/null TB --- 2012-05-15 07:05:25 - cd /src TB --- 2012-05-15 07:05:25 - /usr/bin/make -B buildworld >>> World build started on Tue May 15 07:05:27 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 Tue May 15 09:34:01 UTC 2012 TB --- 2012-05-15 09:34:01 - generating LINT kernel config TB --- 2012-05-15 09:34:01 - cd /src/sys/pc98/conf TB --- 2012-05-15 09:34:01 - /usr/bin/make -B LINT TB --- 2012-05-15 09:34:01 - cd /src/sys/pc98/conf TB --- 2012-05-15 09:34:01 - /usr/sbin/config -m LINT TB --- 2012-05-15 09:34:01 - building LINT kernel TB --- 2012-05-15 09:34:01 - CROSS_BUILD_TESTING=YES TB --- 2012-05-15 09:34:01 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-15 09:34:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-15 09:34:01 - SRCCONF=/dev/null TB --- 2012-05-15 09:34:01 - TARGET=pc98 TB --- 2012-05-15 09:34:01 - TARGET_ARCH=i386 TB --- 2012-05-15 09:34:01 - TZ=UTC TB --- 2012-05-15 09:34:01 - __MAKE_CONF=/dev/null TB --- 2012-05-15 09:34:01 - cd /src TB --- 2012-05-15 09:34:01 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue May 15 09:34:01 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 >>> Kernel build for LINT completed on Tue May 15 10:03:32 UTC 2012 TB --- 2012-05-15 10:03:32 - cd /src/sys/pc98/conf TB --- 2012-05-15 10:03:32 - /usr/sbin/config -m GENERIC TB --- 2012-05-15 10:03:32 - building GENERIC kernel TB --- 2012-05-15 10:03:32 - CROSS_BUILD_TESTING=YES TB --- 2012-05-15 10:03:32 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-15 10:03:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-15 10:03:32 - SRCCONF=/dev/null TB --- 2012-05-15 10:03:32 - TARGET=pc98 TB --- 2012-05-15 10:03:32 - TARGET_ARCH=i386 TB --- 2012-05-15 10:03:32 - TZ=UTC TB --- 2012-05-15 10:03:32 - __MAKE_CONF=/dev/null TB --- 2012-05-15 10:03:32 - cd /src TB --- 2012-05-15 10:03:32 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue May 15 10:03:32 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 [...] /src/sys/kern/sched_4bsd.c: In function 'sched_add': /src/sys/kern/sched_4bsd.c:1350: warning: implicit declaration of function 'STD_PROBE4' /src/sys/kern/sched_4bsd.c:1350: warning: nested extern declaration of 'STD_PROBE4' [-Wnested-externs] /src/sys/kern/sched_4bsd.c:1350: error: 'sched' undeclared (first use in this function) /src/sys/kern/sched_4bsd.c:1350: error: (Each undeclared identifier is reported only once /src/sys/kern/sched_4bsd.c:1350: error: for each function it appears in.) /src/sys/kern/sched_4bsd.c:1350: error: expected expression before ',' token /src/sys/kern/sched_4bsd.c:1350: error: 'enqueue' undeclared (first use in this function) *** Error code 1 Stop in /obj/pc98.i386/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-05-15 10:08:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-05-15 10:08:08 - ERROR: failed to build GENERIC kernel TB --- 2012-05-15 10:08:08 - 7969.25 user 1112.75 system 11288.67 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Tue May 15 11:11:26 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E5F7106566C; Tue, 15 May 2012 11:11:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id EA7528FC08; Tue, 15 May 2012 11:11:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q4FBBPu8067106; Tue, 15 May 2012 07:11:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q4FBBPm0067104; Tue, 15 May 2012 11:11:25 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 15 May 2012 11:11:25 GMT Message-Id: <201205151111.q4FBBPm0067104@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 11:11:26 -0000 TB --- 2012-05-15 10:08:09 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-05-15 10:08:09 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-05-15 10:08:09 - starting HEAD tinderbox run for mips/mips TB --- 2012-05-15 10:08:09 - cleaning the object tree TB --- 2012-05-15 10:08:09 - cvsupping the source tree TB --- 2012-05-15 10:08:09 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2012-05-15 10:09:51 - building world TB --- 2012-05-15 10:09:51 - CROSS_BUILD_TESTING=YES TB --- 2012-05-15 10:09:51 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-15 10:09:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-15 10:09:51 - SRCCONF=/dev/null TB --- 2012-05-15 10:09:51 - TARGET=mips TB --- 2012-05-15 10:09:51 - TARGET_ARCH=mips TB --- 2012-05-15 10:09:51 - TZ=UTC TB --- 2012-05-15 10:09:51 - __MAKE_CONF=/dev/null TB --- 2012-05-15 10:09:51 - cd /src TB --- 2012-05-15 10:09:51 - /usr/bin/make -B buildworld >>> World build started on Tue May 15 10:09:52 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 Tue May 15 11:09:37 UTC 2012 TB --- 2012-05-15 11:09:37 - cd /src/sys/mips/conf TB --- 2012-05-15 11:09:37 - /usr/sbin/config -m ADM5120 TB --- 2012-05-15 11:09:37 - skipping ADM5120 kernel TB --- 2012-05-15 11:09:37 - cd /src/sys/mips/conf TB --- 2012-05-15 11:09:37 - /usr/sbin/config -m ALCHEMY TB --- 2012-05-15 11:09:37 - skipping ALCHEMY kernel TB --- 2012-05-15 11:09:37 - cd /src/sys/mips/conf TB --- 2012-05-15 11:09:37 - /usr/sbin/config -m AP93 TB --- 2012-05-15 11:09:37 - building AP93 kernel TB --- 2012-05-15 11:09:37 - CROSS_BUILD_TESTING=YES TB --- 2012-05-15 11:09:37 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-15 11:09:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-15 11:09:37 - SRCCONF=/dev/null TB --- 2012-05-15 11:09:37 - TARGET=mips TB --- 2012-05-15 11:09:37 - TARGET_ARCH=mips TB --- 2012-05-15 11:09:37 - TZ=UTC TB --- 2012-05-15 11:09:37 - __MAKE_CONF=/dev/null TB --- 2012-05-15 11:09:37 - cd /src TB --- 2012-05-15 11:09:37 - /usr/bin/make -B buildkernel KERNCONF=AP93 >>> Kernel build for AP93 started on Tue May 15 11:09:37 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 [...] /src/sys/kern/sched_4bsd.c: In function 'sched_add': /src/sys/kern/sched_4bsd.c:1350: warning: implicit declaration of function 'STD_PROBE4' /src/sys/kern/sched_4bsd.c:1350: warning: nested extern declaration of 'STD_PROBE4' [-Wnested-externs] /src/sys/kern/sched_4bsd.c:1350: error: 'sched' undeclared (first use in this function) /src/sys/kern/sched_4bsd.c:1350: error: (Each undeclared identifier is reported only once /src/sys/kern/sched_4bsd.c:1350: error: for each function it appears in.) /src/sys/kern/sched_4bsd.c:1350: error: expected expression before ',' token /src/sys/kern/sched_4bsd.c:1350: error: 'enqueue' undeclared (first use in this function) *** Error code 1 Stop in /obj/mips.mips/src/sys/AP93. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-05-15 11:11:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-05-15 11:11:24 - ERROR: failed to build AP93 kernel TB --- 2012-05-15 11:11:24 - 2602.42 user 557.06 system 3795.77 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Tue May 15 12:48:54 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8530D106566C; Tue, 15 May 2012 12:48:54 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 535928FC15; Tue, 15 May 2012 12:48:54 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q4FCmrnb041625; Tue, 15 May 2012 08:48:53 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q4FCmrVW041610; Tue, 15 May 2012 12:48:53 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 15 May 2012 12:48:53 GMT Message-Id: <201205151248.q4FCmrVW041610@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 12:48:54 -0000 TB --- 2012-05-15 07:00:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-05-15 07:00:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-05-15 07:00:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-05-15 07:00:00 - cleaning the object tree TB --- 2012-05-15 07:00:00 - cvsupping the source tree TB --- 2012-05-15 07:00:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-05-15 07:02:14 - building world TB --- 2012-05-15 07:02:14 - CROSS_BUILD_TESTING=YES TB --- 2012-05-15 07:02:14 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-15 07:02:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-15 07:02:14 - SRCCONF=/dev/null TB --- 2012-05-15 07:02:14 - TARGET=i386 TB --- 2012-05-15 07:02:14 - TARGET_ARCH=i386 TB --- 2012-05-15 07:02:14 - TZ=UTC TB --- 2012-05-15 07:02:14 - __MAKE_CONF=/dev/null TB --- 2012-05-15 07:02:14 - cd /src TB --- 2012-05-15 07:02:14 - /usr/bin/make -B buildworld >>> World build started on Tue May 15 07:02:15 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 Tue May 15 09:33:04 UTC 2012 TB --- 2012-05-15 09:33:04 - generating LINT kernel config TB --- 2012-05-15 09:33:04 - cd /src/sys/i386/conf TB --- 2012-05-15 09:33:04 - /usr/bin/make -B LINT TB --- 2012-05-15 09:33:04 - cd /src/sys/i386/conf TB --- 2012-05-15 09:33:04 - /usr/sbin/config -m LINT TB --- 2012-05-15 09:33:04 - building LINT kernel TB --- 2012-05-15 09:33:04 - CROSS_BUILD_TESTING=YES TB --- 2012-05-15 09:33:04 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-15 09:33:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-15 09:33:04 - SRCCONF=/dev/null TB --- 2012-05-15 09:33:04 - TARGET=i386 TB --- 2012-05-15 09:33:04 - TARGET_ARCH=i386 TB --- 2012-05-15 09:33:04 - TZ=UTC TB --- 2012-05-15 09:33:04 - __MAKE_CONF=/dev/null TB --- 2012-05-15 09:33:04 - cd /src TB --- 2012-05-15 09:33:04 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue May 15 09:33:04 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 >>> Kernel build for LINT completed on Tue May 15 10:07:22 UTC 2012 TB --- 2012-05-15 10:07:22 - cd /src/sys/i386/conf TB --- 2012-05-15 10:07:22 - /usr/sbin/config -m LINT-NOINET TB --- 2012-05-15 10:07:22 - building LINT-NOINET kernel TB --- 2012-05-15 10:07:22 - CROSS_BUILD_TESTING=YES TB --- 2012-05-15 10:07:22 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-15 10:07:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-15 10:07:22 - SRCCONF=/dev/null TB --- 2012-05-15 10:07:22 - TARGET=i386 TB --- 2012-05-15 10:07:22 - TARGET_ARCH=i386 TB --- 2012-05-15 10:07:22 - TZ=UTC TB --- 2012-05-15 10:07:22 - __MAKE_CONF=/dev/null TB --- 2012-05-15 10:07:22 - cd /src TB --- 2012-05-15 10:07:22 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Tue May 15 10:07:22 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 >>> Kernel build for LINT-NOINET completed on Tue May 15 10:39:40 UTC 2012 TB --- 2012-05-15 10:39:40 - cd /src/sys/i386/conf TB --- 2012-05-15 10:39:40 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-05-15 10:39:40 - building LINT-NOINET6 kernel TB --- 2012-05-15 10:39:40 - CROSS_BUILD_TESTING=YES TB --- 2012-05-15 10:39:40 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-15 10:39:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-15 10:39:40 - SRCCONF=/dev/null TB --- 2012-05-15 10:39:40 - TARGET=i386 TB --- 2012-05-15 10:39:40 - TARGET_ARCH=i386 TB --- 2012-05-15 10:39:40 - TZ=UTC TB --- 2012-05-15 10:39:40 - __MAKE_CONF=/dev/null TB --- 2012-05-15 10:39:40 - cd /src TB --- 2012-05-15 10:39:40 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Tue May 15 10:39:40 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 >>> Kernel build for LINT-NOINET6 completed on Tue May 15 11:11:26 UTC 2012 TB --- 2012-05-15 11:11:26 - cd /src/sys/i386/conf TB --- 2012-05-15 11:11:26 - /usr/sbin/config -m LINT-NOIP TB --- 2012-05-15 11:11:26 - building LINT-NOIP kernel TB --- 2012-05-15 11:11:26 - CROSS_BUILD_TESTING=YES TB --- 2012-05-15 11:11:26 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-15 11:11:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-15 11:11:26 - SRCCONF=/dev/null TB --- 2012-05-15 11:11:26 - TARGET=i386 TB --- 2012-05-15 11:11:26 - TARGET_ARCH=i386 TB --- 2012-05-15 11:11:26 - TZ=UTC TB --- 2012-05-15 11:11:26 - __MAKE_CONF=/dev/null TB --- 2012-05-15 11:11:26 - cd /src TB --- 2012-05-15 11:11:26 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Tue May 15 11:11:26 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 >>> Kernel build for LINT-NOIP completed on Tue May 15 11:40:48 UTC 2012 TB --- 2012-05-15 11:40:48 - cd /src/sys/i386/conf TB --- 2012-05-15 11:40:48 - /usr/sbin/config -m LINT-VIMAGE TB --- 2012-05-15 11:40:48 - building LINT-VIMAGE kernel TB --- 2012-05-15 11:40:48 - CROSS_BUILD_TESTING=YES TB --- 2012-05-15 11:40:48 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-15 11:40:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-15 11:40:48 - SRCCONF=/dev/null TB --- 2012-05-15 11:40:48 - TARGET=i386 TB --- 2012-05-15 11:40:48 - TARGET_ARCH=i386 TB --- 2012-05-15 11:40:48 - TZ=UTC TB --- 2012-05-15 11:40:48 - __MAKE_CONF=/dev/null TB --- 2012-05-15 11:40:48 - cd /src TB --- 2012-05-15 11:40:48 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Tue May 15 11:40:48 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 >>> Kernel build for LINT-VIMAGE completed on Tue May 15 12:12:19 UTC 2012 TB --- 2012-05-15 12:12:19 - cd /src/sys/i386/conf TB --- 2012-05-15 12:12:19 - /usr/sbin/config -m GENERIC TB --- 2012-05-15 12:12:19 - building GENERIC kernel TB --- 2012-05-15 12:12:19 - CROSS_BUILD_TESTING=YES TB --- 2012-05-15 12:12:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-15 12:12:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-15 12:12:19 - SRCCONF=/dev/null TB --- 2012-05-15 12:12:19 - TARGET=i386 TB --- 2012-05-15 12:12:19 - TARGET_ARCH=i386 TB --- 2012-05-15 12:12:19 - TZ=UTC TB --- 2012-05-15 12:12:19 - __MAKE_CONF=/dev/null TB --- 2012-05-15 12:12:19 - cd /src TB --- 2012-05-15 12:12:19 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue May 15 12:12:19 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 >>> Kernel build for GENERIC completed on Tue May 15 12:39:19 UTC 2012 TB --- 2012-05-15 12:39:19 - cd /src/sys/i386/conf TB --- 2012-05-15 12:39:19 - /usr/sbin/config -m PAE TB --- 2012-05-15 12:39:19 - building PAE kernel TB --- 2012-05-15 12:39:19 - CROSS_BUILD_TESTING=YES TB --- 2012-05-15 12:39:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-15 12:39:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-15 12:39:19 - SRCCONF=/dev/null TB --- 2012-05-15 12:39:19 - TARGET=i386 TB --- 2012-05-15 12:39:19 - TARGET_ARCH=i386 TB --- 2012-05-15 12:39:19 - TZ=UTC TB --- 2012-05-15 12:39:19 - __MAKE_CONF=/dev/null TB --- 2012-05-15 12:39:19 - cd /src TB --- 2012-05-15 12:39:19 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Tue May 15 12:39:19 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 >>> Kernel build for PAE completed on Tue May 15 12:47:03 UTC 2012 TB --- 2012-05-15 12:47:03 - cd /src/sys/i386/conf TB --- 2012-05-15 12:47:03 - /usr/sbin/config -m XBOX TB --- 2012-05-15 12:47:04 - building XBOX kernel TB --- 2012-05-15 12:47:04 - CROSS_BUILD_TESTING=YES TB --- 2012-05-15 12:47:04 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-15 12:47:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-15 12:47:04 - SRCCONF=/dev/null TB --- 2012-05-15 12:47:04 - TARGET=i386 TB --- 2012-05-15 12:47:04 - TARGET_ARCH=i386 TB --- 2012-05-15 12:47:04 - TZ=UTC TB --- 2012-05-15 12:47:04 - __MAKE_CONF=/dev/null TB --- 2012-05-15 12:47:04 - cd /src TB --- 2012-05-15 12:47:04 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Tue May 15 12:47:04 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 [...] /src/sys/kern/sched_4bsd.c: In function 'sched_add': /src/sys/kern/sched_4bsd.c:1350: warning: implicit declaration of function 'STD_PROBE4' /src/sys/kern/sched_4bsd.c:1350: warning: nested extern declaration of 'STD_PROBE4' [-Wnested-externs] /src/sys/kern/sched_4bsd.c:1350: error: 'sched' undeclared (first use in this function) /src/sys/kern/sched_4bsd.c:1350: error: (Each undeclared identifier is reported only once /src/sys/kern/sched_4bsd.c:1350: error: for each function it appears in.) /src/sys/kern/sched_4bsd.c:1350: error: expected expression before ',' token /src/sys/kern/sched_4bsd.c:1350: error: 'enqueue' undeclared (first use in this function) *** Error code 1 Stop in /obj/i386.i386/src/sys/XBOX. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-05-15 12:48:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-05-15 12:48:53 - ERROR: failed to build XBOX kernel TB --- 2012-05-15 12:48:53 - 15747.94 user 2129.88 system 20933.19 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Tue May 15 15:35:21 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 95376106564A; Tue, 15 May 2012 15:35:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 685598FC14; Tue, 15 May 2012 15:35:21 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CE30DB93E; Tue, 15 May 2012 11:35:20 -0400 (EDT) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Tue, 15 May 2012 10:34:13 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <4FAF7343.8010808@cran.org.uk> <4FB0391D.3040501@cran.org.uk> <4FB135C1.4000505@FreeBSD.org> In-Reply-To: <4FB135C1.4000505@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201205151034.13994.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 15 May 2012 11:35:20 -0400 (EDT) Cc: Bruce Cran , freebsd-current , Jung-uk Kim , Andriy Gapon Subject: Re: ACPI 'driver bug: Unable to set devclass' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 15:35:21 -0000 On Monday, May 14, 2012 12:41:37 pm Andriy Gapon wrote: > on 14/05/2012 01:43 Bruce Cran said the following: > > On 13/05/2012 21:06, Andriy Gapon wrote: > >> Can you produce an equivalent snippet with verbose logging enabled? I have a > >> suspicion that these messages are a byproduct from r231161. > > > > acpi0: reservation of fee00000, 1000 (3) failed > > acpi0: reservation of 0, a0000 (3) failed > > acpi0: reservation of 100000, bbf00000 (3) failed > > acpi_sysresource: acpi_sysresource0 already exists; skipping it > > driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > > acpi_timer: acpi_timer0 already exists; skipping it > > driver bug: Unable to set devclass (class: acpi_timer devname: (unknown)) > > cpu0: on acpi0 > > ACPI Warning: Incorrect checksum in table [OEMB] - 0x45, should be 0x44 > > (20120420/tbutils-293) > > ACPI: SSDT 0xbb7900f0 01340 (v01 DpgPmm P001Ist 00000011 INTL 20051117) > > ACPI: Dynamic OEM Table Load: > > ACPI: SSDT 0 01340 (v01 DpgPmm P001Ist 00000011 INTL 20051117) > > ACPI: SSDT 0xbb791430 004F4 (v01 PmRef P001Cst 00003001 INTL 20051117) > > ACPI: Dynamic OEM Table Load: > > ACPI: SSDT 0 004F4 (v01 PmRef P001Cst 00003001 INTL 20051117) > > acpi_sysresource: acpi_sysresource2 already exists; skipping it > > driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > > cpu2: on acpi0 > > acpi_sysresource: acpi_sysresource1 already exists; skipping it > > driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > > cpu1: on acpi0 > > acpi_sysresource: acpi_sysresource3 already exists; skipping it > > driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > > > > I think that the following is what happens here in the acpi_timer case. > Previously one acpi_timer device_t was added with an order of zero and a fixed > unit number of zero in acpi_timer_identify(). Then, another acpi_timer device_t > could be added when walking the ACPI device tree, that device would always have a > later order and a wildcard unit number (-1). > Now both the "hardwired" device and "auto-probed" device are added with the same > order of 2 and it also so happens that the hardwired device is after the > auto-probed in the device list. So first the auto-probed device just takes the > unit number of zero because it is free and then the hardwired device fails to > claim the same unit number. Eh. This should not be true. The unit 0 is reserved when device_add_child() is called in the acpi_timer identify routine. The wildcard device will not be assigned a unit number until device_probe_child time. > The call chain is: > device_probe_child -> device_set_devclass -> devclass_add_device -> > devclass_alloc_unit. That is, the unit for the wildcard devices should still be -1 here and should not even get to this message. I wonder if this is related to the recent changes to set the unit number for CPUs? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue May 15 16:35:24 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DD6A3106566B; Tue, 15 May 2012 16:35:23 +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 814EC8FC14; Tue, 15 May 2012 16:35:22 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA12485; Tue, 15 May 2012 19:35:14 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4FB285C0.1090905@FreeBSD.org> Date: Tue, 15 May 2012 19:35:12 +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: John Baldwin References: <4FAF7343.8010808@cran.org.uk> <4FB0391D.3040501@cran.org.uk> <4FB135C1.4000505@FreeBSD.org> <201205151034.13994.jhb@freebsd.org> In-Reply-To: <201205151034.13994.jhb@freebsd.org> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Bruce Cran , freebsd-acpi@FreeBSD.org, freebsd-current , Jung-uk Kim Subject: Re: ACPI 'driver bug: Unable to set devclass' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 16:35:24 -0000 on 15/05/2012 17:34 John Baldwin said the following: > On Monday, May 14, 2012 12:41:37 pm Andriy Gapon wrote: >> on 14/05/2012 01:43 Bruce Cran said the following: >>> On 13/05/2012 21:06, Andriy Gapon wrote: >>>> Can you produce an equivalent snippet with verbose logging enabled? I have a >>>> suspicion that these messages are a byproduct from r231161. >>> >>> acpi0: reservation of fee00000, 1000 (3) failed >>> acpi0: reservation of 0, a0000 (3) failed >>> acpi0: reservation of 100000, bbf00000 (3) failed >>> acpi_sysresource: acpi_sysresource0 already exists; skipping it >>> driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) >>> acpi_timer: acpi_timer0 already exists; skipping it >>> driver bug: Unable to set devclass (class: acpi_timer devname: (unknown)) >>> cpu0: on acpi0 >>> ACPI Warning: Incorrect checksum in table [OEMB] - 0x45, should be 0x44 >>> (20120420/tbutils-293) >>> ACPI: SSDT 0xbb7900f0 01340 (v01 DpgPmm P001Ist 00000011 INTL 20051117) >>> ACPI: Dynamic OEM Table Load: >>> ACPI: SSDT 0 01340 (v01 DpgPmm P001Ist 00000011 INTL 20051117) >>> ACPI: SSDT 0xbb791430 004F4 (v01 PmRef P001Cst 00003001 INTL 20051117) >>> ACPI: Dynamic OEM Table Load: >>> ACPI: SSDT 0 004F4 (v01 PmRef P001Cst 00003001 INTL 20051117) >>> acpi_sysresource: acpi_sysresource2 already exists; skipping it >>> driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) >>> cpu2: on acpi0 >>> acpi_sysresource: acpi_sysresource1 already exists; skipping it >>> driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) >>> cpu1: on acpi0 >>> acpi_sysresource: acpi_sysresource3 already exists; skipping it >>> driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) >>> >> >> I think that the following is what happens here in the acpi_timer case. >> Previously one acpi_timer device_t was added with an order of zero and a fixed >> unit number of zero in acpi_timer_identify(). Then, another acpi_timer device_t >> could be added when walking the ACPI device tree, that device would always have a >> later order and a wildcard unit number (-1). >> Now both the "hardwired" device and "auto-probed" device are added with the same >> order of 2 and it also so happens that the hardwired device is after the >> auto-probed in the device list. So first the auto-probed device just takes the >> unit number of zero because it is free and then the hardwired device fails to >> claim the same unit number. > > Eh. This should not be true. The unit 0 is reserved when device_add_child() > is called in the acpi_timer identify routine. The wildcard device will not be > assigned a unit number until device_probe_child time. Not sure what you disagree with... First, the wildcard device is added to the child list during the walk. Then, the unit 0 device is added to the list when acpi_timer identify is executed. Then, the wildcard device is probed and gets unit number of zero. Then, the fixed device is being probed and the unit number conflict arises. Am I misunderstanding something? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue May 15 17:03:30 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A1EB106564A for ; Tue, 15 May 2012 17:03:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0B6248FC16 for ; Tue, 15 May 2012 17:03:30 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 63B1EB96C; Tue, 15 May 2012 13:03:29 -0400 (EDT) From: John Baldwin To: Anton Shterenlikht Date: Tue, 15 May 2012 12:11:09 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <20120426224215.GA79891@mech-cluster241.men.bris.ac.uk> <201205071039.51737.jhb@freebsd.org> <20120507212502.GA8936@mech-cluster241.men.bris.ac.uk> In-Reply-To: <20120507212502.GA8936@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201205151211.09161.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 15 May 2012 13:03:29 -0400 (EDT) Cc: freebsd-current@freebsd.org Subject: Re: updating from r231158 to 234465: mounting from ufs:/dev/ad4s1a failed with error 19 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 17:03:30 -0000 On Monday, May 07, 2012 5:25:02 pm Anton Shterenlikht wrote: > On Mon, May 07, 2012 at 10:39:51AM -0400, John Baldwin wrote: > > On Friday, May 04, 2012 4:07:24 pm Anton Shterenlikht wrote: > > > On Fri, May 04, 2012 at 11:07:59AM -0400, John Baldwin wrote: > > > > On Friday, May 04, 2012 7:51:33 am Anton Shterenlikht wrote: > > > > > On Thu, May 03, 2012 at 02:46:18PM -0400, John Baldwin wrote: > > > > > > On Thursday, May 03, 2012 11:35:19 am Anton Shterenlikht wrote: > > > > > > > On Tue, May 01, 2012 at 12:35:26PM +0100, Anton Shterenlikht wrote: > > > > > > > > On Mon, Apr 30, 2012 at 08:43:14AM -0400, John Baldwin wrote: > > > > > > > > > > > > > > > > > > > > I also see: > > > > > > > > > > > > > > > > > > > > ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0exb > > > > > > > > > > ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 > > > > > > > > > > ata0: reset tp2 stat0=00 stat1=00 devices=0x10000 > > > > > > > > > > > > > > > > > > Hmmm, I don't know how to grok these lines, but does your disk work > > > > at > > > > > > all now > > > > > > > > > with any kernel? It may be that your disk has died (or a cable, > > > > etc.) > > > > > > and it > > > > > > > > > just happened to coincide with your upgrade? > > > > > > > > > > > > > > > > I reverted back to r231158, built world and generic > > > > > > > > kernel (minus all modules, i.e. "option MODULES_OVERRIDE="). > > > > > > > > This works, see the verbose boot dmesg at the end. > > > > > > > > > > > > > > > > I think I'll just do a binary search. > > > > > > > > > > > > > > I traced it to r233677. > > > > > > > The only change from 233676 to 233677 is > > > > > > > in /sys/dev/pci/pci.c > > > > > > > > > > > > > > My kernel is GENERIC with no modules > > > > > > > and with various bits removed, e.g. all raid devices > > > > > > > and PCI network devices, which I definitely > > > > > > > haven't got on this laptop. > > > > > > > > > > > > > > Below is the verbose boot with r233676. > > > > > > > Apparently at the beginning there's also > > > > > > > the previous unsuccessful boot with r233677. > > > > > > > Is this a new feature? I didn't know the > > > > > > > previous dmesg is preserved after a reboot. > > > > > > > Anyway, you can see clearly the error with r233677. > > > > > > > > > > > > > > I guess this is something to do with > > > > > > > ata -> ada change? > > > > > > > > > > > > I don't think so. > > > > > > > > > > > > Please try just this change: > > > > > > > > > > > > Index: pci.c > > > > > > =================================================================== > > > > > > --- pci.c (revision 234928) > > > > > > +++ pci.c (working copy) > > > > > > @@ -2822,10 +2822,14 @@ pci_add_map(device_t bus, device_t dev, int reg, s > > > > > > * from the parent. > > > > > > */ > > > > > > resource_list_delete(rl, type, reg); > > > > > > - } else { > > > > > > + start = 0; > > > > > > + device_printf(bus, > > > > > > + "pci%d:%d:%d:%d bar %#x failed to allocate", > > > > > > + pci_get_domain(dev), pci_get_bus(dev), pci_get_slot(dev), > > > > > > + pci_get_function(dev), reg); > > > > > > + } else > > > > > > start = rman_get_start(res); > > > > > > - pci_write_bar(dev, pm, start); > > > > > > - } > > > > > > + pci_write_bar(dev, pm, start); > > > > > > return (barlen); > > > > > > } > > > > > > > > > > > > > > > > That helped, thank you. > > > > > > > > Bizarre, can you get a regular dmesg with that change applied? > > > > > > > Hmm, I missed a newline at the end. :) Looks like this happened twice. > > I've added the relevant verbose boot messages from your earlier kernel > > below each one: > > > > > pci0: on pcib0 > > > pci0: pci0:0:20:2 bar 0x10 failed to allocate > > > pcib1: at device 1.0 on pci0 > > > > found-> vendor=0x1002, dev=0x4383, revid=0x00 > > domain=0, bus=0, slot=20, func=2 > > class=04-03-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0006, statreg=0x0410, cachelnsz=16 (dwords) > > lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=10 > > powerspec 2 supports D0 D3 current D0 > > map[10]: type Memory, range 64, base 0xcc408000, size 14, enabled > > pcib0: matched entry for 0.20.INTA > > pcib0: slot 20 INTA hardwired to IRQ 16 > > > > > pcib4: at device 20.4 on pci0 > > > pcib4: failed to allocate initial memory window: 0xcc100000-0xcc1fffff > > > pci2: on pcib4 > > > pci2: pci0:2:4:0 bar 0x10 failed to allocate > > > cbb0: irq 20 at device 4.0 on pci2 > > > > found-> vendor=0x1180, dev=0x0476, revid=0xb6 > > domain=0, bus=2, slot=4, func=0 > > class=06-07-00, hdrtype=0x02, mfdev=1 > > cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) > > lattimer=0x40 (1920 ns), mingnt=0x80 (32000 ns), maxlat=0x07 (1750 ns) > > intpin=a, irq=10 > > powerspec 2 supports D0 D1 D2 D3 current D0 > > map[10]: type Memory, range 32, base 0xcc100000, size 12, enabled > > pcib4: failed to allocate initial memory window (0xcc100000-0xcc1fffff,0x100000) > > pcib4: matched entry for 2.4.INTA > > pcib4: slot 4 INTA hardwired to IRQ 20 > > cbb0: irq 20 at device 4.0 on pci2 > > pcib0: allocated type 3 (0xcc500000-0xcc5fffff) for rid 20 of pcib4 > > pcib4: allocated initial memory window of 0xcc500000-0xcc5fffff > > pcib4: allocated memory range (0xcc500000-0xcc500fff) for rid 10 of cbb0 > > cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xcc500000 > > > > So the second case actually recovers and allocates a different range. > > > > Can you try booting with 'debug.acpi.disabled=sysres' set in the loader? > > You mean without the patch? Either way. > > Also, can you get the output of 'devinfo -rv' from a working kernel? Oops, I meant to ask for devinfo -u, sorry. :( Oh, I see it now. Your BIOS is broken. The hdac0 device is assigned a resource that conflicts with pcib4, though that is the one we recover from: > hdac0 pnpinfo vendor=0x1002 device=0x4383 subvendor=0x103c subdevice=0x30c2 class=0x040300 at slot=20 function=2 handle=\_SB_.C08B.C0FD > Interrupt request lines: > 16 > I/O memory addresses: > 0xcc100000-0xcc103fff For the CardBus Bridge, the issue is this device: > ahci0 pnpinfo vendor=0x1002 device=0x4380 subvendor=0x1002 subdevice=0x4380 class=0x01018f at slot=18 function=0 handle=\_SB_.C08B.C275 > Interrupt request lines: > 16 > I/O ports: > 0x5018-0x501b > 0x5020-0x502f > 0x9000-0x9007 > 0x9008-0x900b > 0x9010-0x9017 > I/O memory addresses: > 0xcc409000-0xcc4093ff That last memory BAR conflicts with the desired range of 0xcc408000-0xcc40c000. I'm not sure why BIOS writers are so grossly incompetent, but such is life. Try this: Index: pci.c =================================================================== --- pci.c (revision 235475) +++ pci.c (working copy) @@ -2815,13 +2815,36 @@ pci_add_map(device_t bus, device_t dev, int reg, s */ res = resource_list_reserve(rl, bus, dev, type, ®, start, end, count, prefetch ? RF_PREFETCHABLE : 0); + if (res == NULL && (start != 0 || end != ~0ul)) { + /* + * If the allocation fails, try to allocate a resource for + * this BAR using any available range. The firmware felt + * it was important enough to assign a resource, so don't + * disable decoding if we can help it. + */ + resource_list_delete(rl, type, reg); + start = 0; + end = ~0ul; + resource_list_add(rl, type, reg, 0, ~0ul, count); + resource_list_add(rl, type, reg, start, end, count); + res = resource_list_reserve(rl, bus, dev, type, ®, 0, ~0ul, + count, prefetch ? RF_PREFETCHABLE : 0); + } if (res == NULL) { /* * If the allocation fails, delete the resource list entry - * to force pci_alloc_resource() to allocate resources - * from the parent. + * and disable decoding for this device. + * + * If the driver requests this resource in the future, + * pci_reserve_map() will try to allocate fresh resources. */ resource_list_delete(rl, type, reg); + pci_disable_io(dev, type); + start = 0; + device_printf(bus, + "pci%d:%d:%d:%d bar %#x failed to allocate", + pci_get_domain(dev), pci_get_bus(dev), pci_get_slot(dev), + pci_get_function(dev), reg); } else { start = rman_get_start(res); pci_write_bar(dev, pm, start); -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue May 15 17:04:02 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BA67106566B; Tue, 15 May 2012 17:04:02 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0EB898FC0A; Tue, 15 May 2012 17:04:01 +0000 (UTC) Message-ID: <4FB28C81.9090401@FreeBSD.org> Date: Tue, 15 May 2012 13:04:01 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120502 Thunderbird/12.0.1 MIME-Version: 1.0 To: Peter Jeremy References: <20120511.111019.90116031.iwasaki@jp.FreeBSD.org> <20120511112005.GA87299@server.rulingia.com> <20120513.225328.10294857.iwasaki@jp.FreeBSD.org> <20120515073002.GA21005@server.rulingia.com> In-Reply-To: <20120515073002.GA21005@server.rulingia.com> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org, Mitsuru IWASAKI Subject: Re: [CFT] SMP/i386 suspend/resume X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 17:04:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-05-15 03:30:02 -0400, Peter Jeremy wrote: > I wrote: >>> Thank you for that. Since I was in the process of upgrading my >>> netbook (Acer Aspire One AOA-110 - Atom N270), I rolled your >>> RELENG_8 patch on top of r235229. >>> >>> Unfortunately, the result hasn't been a complete success. > > On 2012-May-13 22:53:28 +0900, Mitsuru IWASAKI > wrote: >> I think graphic driver (or pic?) has some problems on resume and >> they are out of scope of my patches. HEAD and RELENG_9 have >> better support on interrupt re-enabling than RELENG_8 I think. >> Could you try them? And for ps/2 mouse, kernel option >> PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND would be useful. > > I've tried stable/9 r235399 with your patches as well as > PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND and suspend/resume now > works (for the first time) from VTY. FYI, you don't need the kernel options. You just have to add the following line to /boot/loader.conf: hint.psm.0.flags="0x6000" It is much easier for us to debug the issue. Please revert the kernel options and give us the following results. 1. Test psm and moused without the above hint. 2. Test psm and moused with "hint.psm.0.flags="0x2000". 3. Test psm and moused with "hint.psm.0.flags="0x6000". 4. Verbose dmesg output (for the touch pad model strings). > I haven't tried suspending directly from X but expect that is > still broken. I believe you have Intel graphics, right? Then, you need kib's KMS patchset to make it happen. http://wiki.freebsd.org/Intel_GPU Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+yjIEACgkQmlay1b9qnVPogACgj+HUK/lYje8MBvca1oUI6A82 gJMAoKkDSb/KW/CEZ8+Hw7RAUGDIOw8t =IFVX -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue May 15 21:07:18 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2C4D106566C for ; Tue, 15 May 2012 21:07:18 +0000 (UTC) (envelope-from jas@cse.yorku.ca) Received: from bronze.cs.yorku.ca (bronze.cs.yorku.ca [130.63.95.34]) by mx1.freebsd.org (Postfix) with ESMTP id 3E95F8FC08 for ; Tue, 15 May 2012 21:07:18 +0000 (UTC) Received: from [130.63.97.125] (ident=jas) by bronze.cs.yorku.ca with esmtp (Exim 4.76) (envelope-from ) id 1SUOei-0004WO-QP for freebsd-current@freebsd.org; Tue, 15 May 2012 16:47:41 -0400 Message-ID: <4FB2C0EC.802@cse.yorku.ca> Date: Tue, 15 May 2012 16:47:40 -0400 From: Jason Keltz User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.4) Gecko/20120421 Thunderbird/10.0.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 X-Spam-Level: - X-Spam-Report: Content preview: Hi. I'm experimenting with FreeBSD for the first time today. I have a new Dell R720 that has an integrated Dell Perc H310 mini which is connected to 2 x 500 GB NLSAS disks in the R720 enclosure. I have also added dual LSI 9205-8e, each connected to the same Dell MD1220 array (24 x 2.5" 900 GB 10K RPM drives). I was hoping to multipath the connection to those disks, but I haven't got far enough to understand whether that's possible with FreeBSD yet. The disks on the H310 were for root. The disks on the MD1220 were for data (eventually ZFS). [...] Content analysis details: (-1.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SHORTCIRCUIT Not all rules were run, due to a shortcircuited rule -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP Subject: freebsd-current mfi X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 21:07:18 -0000 Hi. I'm experimenting with FreeBSD for the first time today. I have a new Dell R720 that has an integrated Dell Perc H310 mini which is connected to 2 x 500 GB NLSAS disks in the R720 enclosure. I have also added dual LSI 9205-8e, each connected to the same Dell MD1220 array (24 x 2.5" 900 GB 10K RPM drives). I was hoping to multipath the connection to those disks, but I haven't got far enough to understand whether that's possible with FreeBSD yet. The disks on the H310 were for root. The disks on the MD1220 were for data (eventually ZFS). I tried installing FreeBSD 9. It picked up the 9205-8e's fine, and I can see da0 through da47. Everything there looks okay. The Dell H310 was not recognized. Now, doing some research, the Dell H310 seems to be equivalent to LSI 9240... Apparently, work was done in freebsd-current to add support for this controller to MFI. Apparently, this is the LSI MegaRAID SAS driver. (I'm learning!) So .. I figured out how to download freebsd-current, and to compile it. I was hoping that if I could make this work, I might be able to figure out how to extract just mfi from freebsd-current and bring it back to 9.0 so that I could use a stable system with just the support for the H310. (I then have to figure out how to bring that kernel back to the installer). After I compiled freebsd-current, and installed the new kernel, the system now recognized the H310, but a few issues: My root drive which happened to be the disk in slot 20 on my MD1220 array, was oddly enough da22p2 when I first installed FreeBSD 8.X. When I upgraded to FreeBSD 9.0, it became da20p2. That made sense. I figured it was just a bug that was fixed. However, now, after installing the new freebsd-current, the root is back to da22p2 again! I don't know if that's a bug or a feature! I don't think this is because the addition of the 2 disks on the H310 since they are mfisyspd0 and mfisyspd1 so they shouldn't interfere with the daXX mapping. The disks on the LSI 9205-8e controllers are da0 through da47 which seems to make sense. As I was saying, H310 card is recognized, and so are the disks, but there are errors in dmesg, and lots and lots of output (attached below). However, I was able to do for a test: # dd if=/dev/zero of=/dev/mfisyspd0 count=2 # newfs /dev/mfisyspd0 /dev/mfisyspd0: 476940.0MB (976773168 sectors) block size 32768, fragment size 4096 using 645 cylinder groups of 740.00MB, 23680 blks, 47360 inodes. super-block backups (for fsck -b #) at: 192, 1515712, 3031232, 4546752, 6062272, 7577792, 9093312, 10608832, 12124352, 13639872, 15155392, 16670912, 18186432, 19701952, 21217472, 22732992, 24248512, 25764032, 27279552, 28795072, 30310592, 31826112, 33341632, 34857152, 36372672, 37888192, 39403712, 40919232, 42434752, 43950272, 45465792, 46981312, 48496832, 50012352, 51527872, 53043392, 54558912, 56074432, 57589952, 59105472, 60620992, 62136512, 63652032, 65167552, 66683072, 68198592, 69714112, 71229632, 72745152, 74260672, 75776192, 77291712, 78807232, 80322752, 81838272, 83353792, 84869312, 86384832, 87900352, 89415872, 90931392, 92446912, 93962432, 95477952, 96993472, 98508992, 100024512, 101540032, 103055552, 104571072, 106086592, 107602112, 109117632, 110633152, 112148672, 113664192, 115179712, 116695232, 118210752, 119726272, 121241792, 122757312, 124272832, 125788352, 127303872, 128819392, 130334912, 131850432, 133365952, 134881472, 136396992, 137912512, 139428032, 140943552, 142459072, 143974592, 145490112, 147005632, 148521152, 150036672, 151552192, 153067712, 154583232, 156098752, 157614272, 159129792, 160645312, 162160832, 163676352, 165191872, 166707392, 168222912, 169738432, 171253952, 172769472, 174284992, 175800512, 177316032, 178831552, 180347072, 181862592, 183378112, 184893632, 186409152, 187924672, 189440192, 190955712, 192471232, 193986752, 195502272, 197017792, 198533312, 200048832, 201564352, 203079872, 204595392, 206110912, 207626432, 209141952, 210657472, 212172992, 213688512, 215204032, 216719552, 218235072, 219750592, 221266112, 222781632, 224297152, 225812672, 227328192, 228843712, 230359232, 231874752, 233390272, 234905792, 236421312, 237936832, 239452352, 240967872, 242483392, 243998912, 245514432, 247029952, 248545472, 250060992, 251576512, 253092032, 254607552, 256123072, 257638592, 259154112, 260669632, 262185152, 263700672, 265216192, 266731712, 268247232, 269762752, 271278272, 272793792, 274309312, 275824832, 277340352, 278855872, 280371392, 281886912, 283402432, 284917952, 286433472, 287948992, 289464512, 290980032, 292495552, 294011072, 295526592, 297042112, 298557632, 300073152, 301588672, 303104192, 304619712, 306135232, 307650752, 309166272, 310681792, 312197312, 313712832, 315228352, 316743872, 318259392, 319774912, 321290432, 322805952, 324321472, 325836992, 327352512, 328868032, 330383552, 331899072, 333414592, 334930112, 336445632, 337961152, 339476672, 340992192, 342507712, 344023232, 345538752, 347054272, 348569792, 350085312, 351600832, 353116352, 354631872, 356147392, 357662912, 359178432, 360693952, 362209472, 363724992, 365240512, 366756032, 368271552, 369787072, 371302592, 372818112, 374333632, 375849152, 377364672, 378880192, 380395712, 381911232, 383426752, 384942272, 386457792, 387973312, 389488832, 391004352, 392519872, 394035392, 395550912, 397066432, 398581952, 400097472, 401612992, 403128512, 404644032, 406159552, 407675072, 409190592, 410706112, 412221632, 413737152, 415252672, 416768192, 418283712, 419799232, 421314752, 422830272, 424345792, 425861312, 427376832, 428892352, 430407872, 431923392, 433438912, 434954432, 436469952, 437985472, 439500992, 441016512, 442532032, 444047552, 445563072, 447078592, 448594112, 450109632, 451625152, 453140672, 454656192, 456171712, 457687232, 459202752, 460718272, 462233792, 463749312, 465264832, 466780352, 468295872, 469811392, 471326912, 472842432, 474357952, 475873472, 477388992, 478904512, 480420032, 481935552, 483451072, 484966592, 486482112, 487997632, 489513152, 491028672, 492544192, 494059712, 495575232, 497090752, 498606272, 500121792, 501637312, 503152832, 504668352, 506183872, 507699392, 509214912, 510730432, 512245952, 513761472, 515276992, 516792512, 518308032, 519823552, 521339072, 522854592, 524370112, 525885632, 527401152, 528916672, 530432192, 531947712, 533463232, 534978752, 536494272, 538009792, 539525312, 541040832, 542556352, 544071872, 545587392, 547102912, 548618432, 550133952, 551649472, 553164992, 554680512, 556196032, 557711552, 559227072, 560742592, 562258112, 563773632, 565289152, 566804672, 568320192, 569835712, 571351232, 572866752, 574382272, 575897792, 577413312, 578928832, 580444352, 581959872, 583475392, 584990912, 586506432, 588021952, 589537472, 591052992, 592568512, 594084032, 595599552, 597115072, 598630592, 600146112, 601661632, 603177152, 604692672, 606208192, 607723712, 609239232, 610754752, 612270272, 613785792, 615301312, 616816832, 618332352, 619847872, 621363392, 622878912, 624394432, 625909952, 627425472, 628940992, 630456512, 631972032, 633487552, 635003072, 636518592, 638034112, 639549632, 641065152, 642580672, 644096192, 645611712, 647127232, 648642752, 650158272, 651673792, 653189312, 654704832, 656220352, 657735872, 659251392, 660766912, 662282432, 663797952, 665313472, 666828992, 668344512, 669860032, 671375552, 672891072, 674406592, 675922112, 677437632, 678953152, 680468672, 681984192, 683499712, 685015232, 686530752, 688046272, 689561792, 691077312, 692592832, 694108352, 695623872, 697139392, 698654912, 700170432, 701685952, 703201472, 704716992, 706232512, 707748032, 709263552, 710779072, 712294592, 713810112, 715325632, 716841152, 718356672, 719872192, 721387712, 722903232, 724418752, 725934272, 727449792, 728965312, 730480832, 731996352, 733511872, 735027392, 736542912, 738058432, 739573952, 741089472, 742604992, 744120512, 745636032, 747151552, 748667072, 750182592, 751698112, 753213632, 754729152, 756244672, 757760192, 759275712, 760791232, 762306752, 763822272, 765337792, 766853312, 768368832, 769884352, 771399872, 772915392, 774430912, 775946432, 777461952, 778977472, 780492992, 782008512, 783524032, 785039552, 786555072, 788070592, 789586112, 791101632, 792617152, 794132672, 795648192, 797163712, 798679232, 800194752, 801710272, 803225792, 804741312, 806256832, 807772352, 809287872, 810803392, 812318912, 813834432, 815349952, 816865472, 818380992, 819896512, 821412032, 822927552, 824443072, 825958592, 827474112, 828989632, 830505152, 832020672, 833536192, 835051712, 836567232, 838082752, 839598272, 841113792, 842629312, 844144832, 845660352, 847175872, 848691392, 850206912, 851722432, 853237952, 854753472, 856268992, 857784512, 859300032, 860815552, 862331072, 863846592, 865362112, 866877632, 868393152, 869908672, 871424192, 872939712, 874455232, 875970752, 877486272, 879001792, 880517312, 882032832, 883548352, 885063872, 886579392, 888094912, 889610432, 891125952, 892641472, 894156992, 895672512, 897188032, 898703552, 900219072, 901734592, 903250112, 904765632, 906281152, 907796672, 909312192, 910827712, 912343232, 913858752, 915374272, 916889792, 918405312, 919920832, 921436352, 922951872, 924467392, 925982912, 927498432, 929013952, 930529472, 932044992, 933560512, 935076032, 936591552, 938107072, 939622592, 941138112, 942653632, 944169152, 945684672, 947200192, 948715712, 950231232, 951746752, 953262272, 954777792, 956293312, 957808832, 959324352, 960839872, 962355392, 963870912, 965386432, 966901952, 968417472, 969932992, 971448512, 972964032, 974479552, 975995072 and again on 1.. (same thing) Any clues as to exactly which directories I could extract from freebsd-current and add to 9.0 so that I would just get the updated mfi driver with the current code? Here is the output from dmesg -a .. (looks like some of it got cut off .. some of it is immensely repetitive, but the unexpected sense errors are the most interesting...): maybe a timeout issue? re initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1144 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1145 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1146 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1147 (boot + 29s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5e4ae02084308b00, CDB: 1c 01 00 00 20 00, Sense: 6/29/00 mfi0: 1148 (boot + 31s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1149 (boot + 31s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1150 (boot + 31s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1151 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1152 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1153 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1154 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1155 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1156 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1157 (389784768s/0x0020/info) - Time established as 05/08/12 9:32:48; (95 seconds since power on) mfi0: 1158 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1159 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1160 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1161 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1162 (boot + 29s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5e4ae02084308b00, CDB: 1c 01 00 00 20 00, Sense: 6/29/00 mfi0: 1163 (boot + 31s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1164 (boot + 31s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1165 (boot + 31s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1166 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1167 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1168 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1169 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1170 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1171 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1172 (389787315s/0x0020/info) - Time established as 05/08/12 10:15:15; (76 seconds since power on) mfi0: 1173 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1174 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1175 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1176 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1177 (boot + 29s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5e4ae02084308b00, CDB: 1c 01 00 00 20 00, Sense: 6/29/00 mfi0: 1178 (boot + 31s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1179 (boot + 31s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1180 (boot + 31s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1181 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1182 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1183 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1184 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1185 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1186 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1187 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1188 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1189 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1190 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1191 (boot + 29s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5e4ae02084308b00, CDB: 1c 01 00 00 20 00, Sense: 6/29/00 mfi0: 1192 (boot + 31s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1193 (boot + 31s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1194 (boot + 31s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1195 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1196 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1197 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1198 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1199 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1200 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1201 (389796808s/0x0020/info) - Time established as 05/08/12 12:53:28; (81 seconds since power on) mfi0: 1202 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1203 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1204 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1205 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1206 (boot + 29s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5e4ae02084308b00, CDB: 1c 01 00 00 20 00, Sense: 6/29/00 mfi0: 1207 (boot + 31s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1208 (boot + 31s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1209 (boot + 31s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1210 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1211 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1212 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1213 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1214 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1215 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1216 (389796936s/0x0020/info) - Time established as 05/08/12 12:55:36; (61 seconds since power on) mfi0: 1217 (boot + 1s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1218 (boot + 1s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1219 (389819400s/0x0020/CRIT) - Controller encountered a fatal error and was reset mfi0: 1220 (389819402s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1221 (389819402s/0x0020/info) - Board Revision A00 mfi0: 1222 (389819426s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1223 (389819426s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1224 (389819426s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1225 (389819426s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1226 (389819426s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1227 (389819426s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1228 (389819426s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1229 (389819426s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1230 (389819426s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1231 (boot + 1s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1232 (boot + 1s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1233 (389819460s/0x0020/CRIT) - Controller encountered a fatal error and was reset mfi0: 1234 (389819462s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1235 (389819462s/0x0020/info) - Board Revision A00 mfi0: 1236 (389819487s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1237 (389819487s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1238 (389819487s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1239 (389819487s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1240 (389819487s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1241 (389819487s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1242 (389819487s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1243 (389819487s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1244 (389819487s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1245 (boot + 1s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1246 (boot + 1s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1247 (389819521s/0x0020/CRIT) - Controller encountered a fatal error and was reset mfi0: 1248 (389819523s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1249 (389819523s/0x0020/info) - Board Revision A00 mfi0: 1250 (389819547s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1251 (389819547s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1252 (389819547s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1253 (389819547s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1254 (389819547s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1255 (389819547s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1256 (389819547s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1257 (389819547s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1258 (389819547s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1259 (boot + 1s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1260 (boot + 1s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1261 (389819581s/0x0020/CRIT) - Controller encountered a fatal error and was reset mfi0: 1262 (389819583s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1263 (389819583s/0x0020/info) - Board Revision A00 mfi0: 1264 (389819607s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1265 (389819607s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1266 (389819607s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1267 (389819607s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1268 (389819607s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1269 (389819607s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1270 (389819607s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1271 (389819607s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1272 (389819607s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1273 (boot + 1s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1274 (boot + 1s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1275 (389819641s/0x0020/CRIT) - Controller encountered a fatal error and was reset mfi0: 1276 (389819643s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1277 (389819643s/0x0020/info) - Board Revision A00 mfi0: 1278 (389819667s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1279 (389819667s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1280 (389819667s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1281 (389819667s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1282 (389819667s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1283 (389819667s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1284 (389819667s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1285 (389819667s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1286 (389819667s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1287 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1288 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1289 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1290 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1291 (boot + 29s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5e4ae02084308b00, CDB: 1c 01 00 00 20 00, Sense: 6/29/00 mfi0: 1292 (boot + 31s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1293 (boot + 31s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1294 (boot + 31s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1295 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1296 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1297 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1298 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1299 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1300 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1301 (389869105s/0x0020/info) - Time established as 05/09/12 8:58:25; (61 seconds since power on) mfi0: 1302 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1303 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1304 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1305 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1306 (boot + 29s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5e4ae02084308b00, CDB: 1c 01 00 00 20 00, Sense: 6/29/00 mfi0: 1307 (boot + 31s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1308 (boot + 31s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1309 (boot + 31s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1310 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1311 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1312 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1313 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1314 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1315 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1316 (389869233s/0x0020/info) - Time established as 05/09/12 9:00:33; (61 seconds since power on) mfi0: 1317 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1318 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1319 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1320 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1321 (boot + 29s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5e4ae02084308b00, CDB: 1c 01 00 00 20 00, Sense: 6/29/00 mfi0: 1322 (boot + 31s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1323 (boot + 31s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1324 (boot + 31s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1325 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1326 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1327 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1328 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1329 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1330 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1331 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1332 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1333 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1334 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1335 (boot + 29s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5e4ae02084308b00, CDB: 1c 01 00 00 20 00, Sense: 6/29/00 mfi0: 1336 (boot + 31s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1337 (boot + 31s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1338 (boot + 31s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1339 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1340 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1341 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1342 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1343 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1344 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1345 (389872803s/0x0020/info) - Time established as 05/09/12 10:00:03; (81 seconds since power on) mfi0: 1346 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1347 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1348 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1349 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1350 (boot + 30s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1351 (boot + 30s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1352 (boot + 30s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1353 (boot + 30s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1354 (boot + 30s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1355 (boot + 30s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1356 (boot + 30s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1357 (boot + 30s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1358 (boot + 30s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1359 (389873221s/0x0020/info) - Time established as 05/09/12 10:07:01; (66 seconds since power on) mfi0: 1360 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1361 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1362 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1363 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1364 (boot + 30s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1365 (boot + 30s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1366 (boot + 30s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1367 (boot + 30s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1368 (boot + 30s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1369 (boot + 30s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1370 (boot + 30s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1371 (boot + 30s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1372 (boot + 30s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1373 (389874887s/0x0020/info) - Time established as 05/09/12 10:34:47; (65 seconds since power on) mfi0: 1374 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1375 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1376 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1377 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1378 (boot + 29s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5e4ae02084308b00, CDB: 1c 01 00 00 20 00, Sense: 6/29/00 mfi0: 1379 (boot + 31s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1380 (boot + 31s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1381 (boot + 31s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1382 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1383 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1384 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1385 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1386 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1387 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1388 (389888110s/0x0020/info) - Time established as 05/09/12 14:15:10; (73 seconds since power on) mfi0: 1389 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1390 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1391 (boot + 6s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1392 (boot + 6s/0x0020/info) - Board Revision A00 mfi0: 1393 (boot + 29s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5e4ae02084308b00, CDB: 1c 01 00 00 20 00, Sense: 6/29/00 mfi0: 1394 (boot + 31s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1395 (boot + 31s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1396 (boot + 31s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1397 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1398 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1399 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1400 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1401 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1402 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1403 (389888251s/0x0020/info) - Time established as 05/09/12 14:17:31; (72 seconds since power on) mfi0: 1404 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1405 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1406 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1407 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1408 (boot + 29s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5e4ae02084308b00, CDB: 1c 01 00 00 20 00, Sense: 6/29/00 mfi0: 1409 (boot + 31s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1410 (boot + 31s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1411 (boot + 31s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1412 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1413 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1414 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1415 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1416 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1417 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1418 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1419 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1420 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1421 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1422 (boot + 29s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5e4ae02084308b00, CDB: 1c 01 00 00 20 00, Sense: 6/29/00 mfi0: 1423 (boot + 31s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1424 (boot + 31s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1425 (boot + 31s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1426 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1427 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1428 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1429 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1430 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1431 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1432 (389921040s/0x0020/info) - Time established as 05/09/12 23:24:00; (92 seconds since power on) mfi0: 1433 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1434 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1435 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1436 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1437 (boot + 29s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5e4ae02084308b00, CDB: 1c 01 00 00 20 00, Sense: 6/29/00 mfi0: 1438 (boot + 31s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1439 (boot + 31s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1440 (boot + 31s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1441 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1442 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1443 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1444 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1445 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1446 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1447 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1448 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1449 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1450 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1451 (boot + 29s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5e4ae02084308b00, CDB: 1c 01 00 00 20 00, Sense: 6/29/00 mfi0: 1452 (boot + 31s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1453 (boot + 31s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1454 (boot + 31s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1455 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1456 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1457 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1458 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1459 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1460 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1461 (389921624s/0x0020/info) - Time established as 05/09/12 23:33:44; (93 seconds since power on) mfi0: 1462 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1463 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1464 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1465 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1466 (boot + 29s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5e4ae02084308b00, CDB: 1c 01 00 00 20 00, Sense: 6/29/00 mfi0: 1467 (boot + 31s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1468 (boot + 31s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1469 (boot + 31s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1470 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1471 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1472 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1473 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1474 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1475 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1476 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1477 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1478 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1479 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1480 (boot + 29s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5e4ae02084308b00, CDB: 1c 01 00 00 20 00, Sense: 6/29/00 mfi0: 1481 (boot + 31s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1482 (boot + 31s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1483 (boot + 31s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1484 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1485 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1486 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1487 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1488 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1489 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1490 (389922366s/0x0020/info) - Time established as 05/09/12 23:46:06; (93 seconds since power on) mfi0: 1491 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1492 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1493 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1494 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1495 (boot + 29s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5e4ae02084308b00, CDB: 1c 01 00 00 20 00, Sense: 6/29/00 mfi0: 1496 (boot + 31s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1497 (boot + 31s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1498 (boot + 31s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1499 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1500 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1501 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1502 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1503 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1504 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1505 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1506 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1507 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1508 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1509 (boot + 29s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5e4ae02084308b00, CDB: 1c 01 00 00 20 00, Sense: 6/29/00 mfi0: 1510 (boot + 31s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1511 (boot + 31s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1512 (boot + 31s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1513 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1514 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1515 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1516 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1517 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1518 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1519 (389943481s/0x0020/info) - Time established as 05/10/12 5:38:01; (92 seconds since power on) mfi0: 1520 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1521 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1522 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1523 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1524 (boot + 29s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5e4ae02084308b00, CDB: 1c 01 00 00 20 00, Sense: 6/29/00 mfi0: 1525 (boot + 31s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1526 (boot + 31s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1527 (boot + 31s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1528 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1529 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1530 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1531 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1532 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1533 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1534 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1535 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1536 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1537 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1538 (boot + 29s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5e4ae02084308b00, CDB: 1c 01 00 00 20 00, Sense: 6/29/00 mfi0: 1539 (boot + 31s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1540 (boot + 31s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1541 (boot + 31s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1542 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1543 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1544 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1545 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1546 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1547 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1548 (389944338s/0x0020/info) - Time established as 05/10/12 5:52:18; (93 seconds since power on) mfi0: 1549 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1550 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1551 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1552 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1553 (boot + 30s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1554 (boot + 30s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1555 (boot + 30s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1556 (boot + 30s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1557 (boot + 30s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1558 (boot + 30s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1559 (boot + 30s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1560 (boot + 30s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1561 (boot + 30s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1562 (389945469s/0x0020/info) - Time established as 05/10/12 6:11:09; (73 seconds since power on) mfi0: 1563 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1564 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1565 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1566 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1567 (boot + 29s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5e4ae02084308b00, CDB: 1c 01 00 00 20 00, Sense: 6/29/00 mfi0: 1568 (boot + 31s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1569 (boot + 31s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1570 (boot + 31s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1571 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1572 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1573 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1574 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1575 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1576 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1577 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1578 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1579 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1580 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1581 (boot + 29s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5e4ae02084308b00, CDB: 1c 01 00 00 20 00, Sense: 6/29/00 mfi0: 1582 (boot + 31s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1583 (boot + 31s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1584 (boot + 31s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1585 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1586 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1587 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1588 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1589 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1590 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1591 (389947600s/0x0020/info) - Time established as 05/10/12 6:46:40; (92 seconds since power on) mfi0: 1592 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1593 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1594 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1595 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1596 (boot + 29s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5e4ae02084308b00, CDB: 1c 01 00 00 20 00, Sense: 6/29/00 mfi0: 1597 (boot + 31s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1598 (boot + 31s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1599 (boot + 31s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1600 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1601 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1602 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1603 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1604 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1605 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1606 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1607 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1608 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1609 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1610 (boot + 29s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5e4ae02084308b00, CDB: 1c 01 00 00 20 00, Sense: 6/29/00 mfi0: 1611 (boot + 31s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1612 (boot + 31s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1613 (boot + 31s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1614 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1615 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1616 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1617 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1618 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1619 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1620 (389948008s/0x0020/info) - Time established as 05/10/12 6:53:28; (91 seconds since power on) mfi0: 1621 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1622 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1623 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1624 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1625 (boot + 29s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5e4ae02084308b00, CDB: 1c 01 00 00 20 00, Sense: 6/29/00 mfi0: 1626 (boot + 31s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1627 (boot + 31s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1628 (boot + 31s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1629 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1630 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1631 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1632 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1633 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1634 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1635 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1636 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1637 (boot + 6s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1638 (boot + 6s/0x0020/info) - Board Revision A00 mfi0: 1639 (boot + 29s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5e4ae02084308b00, CDB: 1c 01 00 00 20 00, Sense: 6/29/00 mfi0: 1640 (boot + 31s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1641 (boot + 31s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1642 (boot + 31s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1643 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1644 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1645 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1646 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1647 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1648 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1649 (389974347s/0x0020/info) - Time established as 05/10/12 14:12:27; (92 seconds since power on) mfi0: 1650 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1651 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1652 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1653 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1654 (boot + 30s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1655 (boot + 30s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1656 (boot + 30s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1657 (boot + 30s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1658 (boot + 30s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1659 (boot + 30s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1660 (boot + 30s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1661 (boot + 30s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1662 (boot + 30s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1663 (389974557s/0x0020/info) - Time established as 05/10/12 14:15:57; (73 seconds since power on) mfi0: 1664 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1665 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1666 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1667 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1668 (boot + 30s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1669 (boot + 30s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1670 (boot + 30s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1671 (boot + 30s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1672 (boot + 30s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1673 (boot + 30s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1674 (boot + 30s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1675 (boot + 30s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1676 (boot + 30s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1677 (389975538s/0x0020/info) - Time established as 05/10/12 14:32:18; (71 seconds since power on) mfi0: 1678 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1679 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1680 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1681 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1682 (boot + 30s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1683 (boot + 30s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1684 (boot + 30s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1685 (boot + 30s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1686 (boot + 30s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1687 (boot + 30s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1688 (boot + 30s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1689 (boot + 30s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1690 (boot + 30s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1691 (389975914s/0x0020/info) - Time established as 05/10/12 14:38:34; (76 seconds since power on) mfi0: 1692 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1693 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1694 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1695 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1696 (boot + 30s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1697 (boot + 30s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1698 (boot + 30s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1699 (boot + 30s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1700 (boot + 30s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1701 (boot + 30s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1702 (boot + 30s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1703 (boot + 30s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1704 (boot + 30s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1705 (389976157s/0x0020/info) - Time established as 05/10/12 14:42:37; (77 seconds since power on) mfi0: 1706 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1707 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1708 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1709 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1710 (boot + 29s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5e4ae02084308b00, CDB: 1c 01 00 00 20 00, Sense: 6/29/00 mfi0: 1711 (boot + 31s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1712 (boot + 31s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1713 (boot + 31s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1714 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1715 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1716 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1717 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1718 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1719 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1720 (389976651s/0x0020/info) - Time established as 05/10/12 14:50:51; (77 seconds since power on) mfi0: 1721 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1722 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1723 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1724 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1725 (boot + 30s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1726 (boot + 30s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1727 (boot + 30s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1728 (boot + 30s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1729 (boot + 30s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1730 (boot + 30s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1731 (boot + 30s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1732 (boot + 30s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1733 (boot + 30s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1734 (389978408s/0x0020/info) - Time established as 05/10/12 15:20:08; (77 seconds since power on) mfi0: 1735 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1736 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1737 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1738 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1739 (boot + 29s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5e4ae02084308b00, CDB: 1c 01 00 00 20 00, Sense: 6/29/00 mfi0: 1740 (boot + 31s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1741 (boot + 31s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1742 (boot + 31s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1743 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1744 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1745 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1746 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1747 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1748 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1749 (389978635s/0x0020/info) - Time established as 05/10/12 15:23:55; (77 seconds since power on) mfi0: 1750 (390033161s/0x0020/info) - Host driver is loaded and operational mfi0: 1751 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1752 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1753 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1754 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1755 (boot + 30s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1756 (boot + 30s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1757 (boot + 30s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1758 (boot + 30s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1759 (boot + 30s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1760 (boot + 30s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1761 (boot + 30s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1762 (boot + 30s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1763 (boot + 30s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1764 (390033476s/0x0020/info) - Time established as 05/11/12 6:37:56; (76 seconds since power on) mfi0: 1765 (390033785s/0x0020/info) - Host driver is loaded and operational mfi0: 1766 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1767 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1768 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1769 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1770 (boot + 30s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1771 (boot + 30s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1772 (boot + 30s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1773 (boot + 30s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1774 (boot + 30s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1775 (boot + 30s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1776 (boot + 30s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1777 (boot + 30s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1778 (boot + 30s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1779 (390034782s/0x0020/info) - Time established as 05/11/12 6:59:42; (77 seconds since power on) mfi0: 1780 (390034917s/0x0020/info) - Host driver is loaded and operational mfi0: 1781 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1782 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1783 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1784 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1785 (boot + 30s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1786 (boot + 30s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1787 (boot + 30s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1788 (boot + 30s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1789 (boot + 30s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1790 (boot + 30s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1791 (boot + 30s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1792 (boot + 30s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1793 (boot + 30s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1794 (390042257s/0x0020/info) - Time established as 05/11/12 9:04:17; (77 seconds since power on) mfi0: 1795 (390042389s/0x0020/info) - Host driver is loaded and operational mfi0: 1796 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1797 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1798 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1799 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1800 (boot + 30s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1801 (boot + 30s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1802 (boot + 30s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1803 (boot + 30s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1804 (boot + 30s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1805 (boot + 30s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1806 (boot + 30s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1807 (boot + 30s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1808 (boot + 30s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1809 (390052477s/0x0020/info) - Time established as 05/11/12 11:54:37; (77 seconds since power on) mfi0: 1810 (390052607s/0x0020/info) - Host driver is loaded and operational mfi0: 1811 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1812 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1813 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1814 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1815 (boot + 30s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1816 (boot + 30s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1817 (boot + 30s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1818 (boot + 30s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1819 (boot + 30s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1820 (boot + 30s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1821 (boot + 30s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1822 (boot + 30s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1823 (boot + 30s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1824 (390052896s/0x0020/info) - Time established as 05/11/12 12:01:36; (77 seconds since power on) mfi0: 1825 (390053025s/0x0020/info) - Host driver is loaded and operational mfi0: 1826 (390106800s/0x0020/WARN) - Patrol Read can't be started, as PDs are either not ONLINE, or are in a VD with an active process, or are in an excluded VD mfi0: 1827 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1828 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1829 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1830 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1831 (boot + 29s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5e4ae02084308b00, CDB: 1c 01 00 00 20 00, Sense: 6/29/00 mfi0: 1832 (boot + 31s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1833 (boot + 31s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1834 (boot + 31s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1835 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1836 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1837 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1838 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1839 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1840 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1841 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1842 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1843 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1844 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1845 (boot + 29s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5e4ae02084308b00, CDB: 1c 01 00 00 20 00, Sense: 6/29/00 mfi0: 1846 (boot + 31s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1847 (boot + 31s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1848 (boot + 31s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1849 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1850 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1851 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1852 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1853 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1854 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1855 (390306319s/0x0020/info) - Time established as 05/14/12 10:25:19; (96 seconds since power on) mfi0: 1856 (390306571s/0x0020/info) - Host driver is loaded and operational mfi0: 1857 (390306581s/0x0002/info) - Unexpected sense: PD 00(e0x20/s0) Path 5000c500413a3069, CDB: 1b 00 00 00 10 00, Sense: 5/24/00 mfi0: 1858 (390306581s/0x0002/info) - Unexpected sense: PD 00(e0x20/s0) Path 5000c500413a3069, CDB: 1b 00 00 00 10 00, Sense: 5/24/00 mfi0: 1859 (390306581s/0x0002/info) - Unexpected sense: PD 00(e0x20/s0) Path 5000c500413a3069, CDB: 1b 00 00 00 10 00, Sense: 5/24/00 mfi0: 1860 (390306581s/0x0002/info) - Unexpected sense: PD 00(e0x20/s0) Path 5000c500413a3069, CDB: 1b 00 00 00 10 00, Sense: 5/24/00 mfi0: 1861 (390306582s/0x0002/info) - Unexpected sense: PD 01(e0x20/s1) Path 5000c500413a4acd, CDB: 1b 00 00 00 10 00, Sense: 5/24/00 mfi0: 1862 (390306582s/0x0002/info) - Unexpected sense: PD 01(e0x20/s1) Path 5000c500413a4acd, CDB: 1b 00 00 00 10 00, Sense: 5/24/00 mfi0: 1863 (390306582s/0x0002/info) - Unexpected sense: PD 01(e0x20/s1) Path 5000c500413a4acd, CDB: 1b 00 00 00 10 00, Sense: 5/24/00 mfi0: 1864 (390306582s/0x0002/info) - Unexpected sense: PD 01(e0x20/s1) Path 5000c500413a4acd, CDB: 1b 00 00 00 10 00, Sense: 5/24/00 mfi0: 1865 (390306652s/0x0002/info) - Unexpected sense: PD 00(e0x20/s0) Path 5000c500413a3069, CDB: 1b 00 00 00 10 00, Sense: 5/24/00 mfi0: 1866 (390306652s/0x0002/info) - Unexpected sense: PD 01(e0x20/s1) Path 5000c500413a4acd, CDB: 1b 00 00 00 10 00, Sense: 5/24/00 mfi0: 1867 (390306783s/0x0002/info) - Unexpected sense: PD 00(e0x20/s0) Path 5000c500413a3069, CDB: 1b 00 00 00 10 00, Sense: 5/24/00 mfi0: 1868 (390306783s/0x0002/info) - Unexpected sense: PD 00(e0x20/s0) Path 5000c500413a3069, CDB: 1b 00 00 00 10 00, Sense: 5/24/00 mfi0: 1869 (390306783s/0x0002/info) - Unexpected sense: PD 00(e0x20/s0) Path 5000c500413a3069, CDB: 1b 00 00 00 10 00, Sense: 5/24/00 mfi0: 1870 (390306783s/0x0002/info) - Unexpected sense: PD 00(e0x20/s0) Path 5000c500413a3069, CDB: 1b 00 00 00 10 00, Sense: 5/24/00 mfi0: 1871 (390306783s/0x0002/info) - Unexpected sense: PD 00(e0x20/s0) Path 5000c500413a3069, CDB: 1b 00 00 00 10 00, Sense: 5/24/00 mfi0: 1872 (390306784s/0x0002/info) - Unexpected sense: PD 00(e0x20/s0) Path 5000c500413a3069, CDB: 1b 00 00 00 10 00, Sense: 5/24/00 mfi0: 1873 (390306784s/0x0002/info) - Unexpected sense: PD 00(e0x20/s0) Path 5000c500413a3069, CDB: 1b 00 00 00 10 00, Sense: 5/24/00 mfi0: 1874 (390306784s/0x0002/info) - Unexpected sense: PD 01(e0x20/s1) Path 5000c500413a4acd, CDB: 1b 00 00 00 10 00, Sense: 5/24/00 mfi0: 1875 (390306784s/0x0002/info) - Unexpected sense: PD 01(e0x20/s1) Path 5000c500413a4acd, CDB: 1b 00 00 00 10 00, Sense: 5/24/00 mfi0: 1876 (390306784s/0x0002/info) - Unexpected sense: PD 01(e0x20/s1) Path 5000c500413a4acd, CDB: 1b 00 00 00 10 00, Sense: 5/24/00 mfi0: 1877 (390306784s/0x0002/info) - Unexpected sense: PD 01(e0x20/s1) Path 5000c500413a4acd, CDB: 1b 00 00 00 10 00, Sense: 5/24/00 mfi0: 1878 (390306784s/0x0002/info) - Unexpected sense: PD 01(e0x20/s1) Path 5000c500413a4acd, CDB: 1b 00 00 00 10 00, Sense: 5/24/00 mfi0: 1879 (390306784s/0x0002/info) - Unexpected sense: PD 01(e0x20/s1) Path 5000c500413a4acd, CDB: 1b 00 00 00 10 00, Sense: 5/24/00 mfi0: 1880 (390306784s/0x0002/info) - Unexpected sense: PD 01(e0x20/s1) Path 5000c500413a4acd, CDB: 1b 00 00 00 10 00, Sense: 5/24/00 mfi0: 1881 (390307083s/0x0002/info) - Unexpected sense: PD 00(e0x20/s0) Path 5000c500413a3069, CDB: 1b 00 00 00 10 00, Sense: 5/24/00 mfi0: 1882 (390307083s/0x0002/info) - Unexpected sense: PD 01(e0x20/s1) Path 5000c500413a4acd, CDB: 1b 00 00 00 10 00, Sense: 5/24/00 mfi0: 1883 (390307114s/0x0002/info) - Unexpected sense: PD 00(e0x20/s0) Path 5000c500413a3069, CDB: 1b 00 00 00 10 00, Sense: 5/24/00 mfi0: 1884 (390307114s/0x0002/info) - Unexpected sense: PD 00(e0x20/s0) Path 5000c500413a3069, CDB: 1b 00 00 00 10 00, Sense: 5/24/00 mfi0: 1885 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1886 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1887 (boot + 6s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1888 (boot + 6s/0x0020/info) - Board Revision A00 mfi0: 1889 (boot + 29s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5e4ae02084308b00, CDB: 1c 01 00 00 20 00, Sense: 6/29/00 mfi0: 1890 (boot + 31s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1891 (boot + 31s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1892 (boot + 31s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1893 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1894 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1895 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1896 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1897 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1898 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1899 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1900 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1901 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1902 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1903 (boot + 30s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1904 (boot + 30s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1905 (boot + 30s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1906 (boot + 30s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1907 (boot + 30s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1908 (boot + 30s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1909 (boot + 30s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1910 (boot + 30s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1911 (boot + 30s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1912 (390389655s/0x0020/info) - Time established as 05/15/12 9:34:15; (76 seconds since power on) mfi0: 1913 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1914 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1915 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1916 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1917 (boot + 29s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5e4ae02084308b00, CDB: 1c 01 00 00 20 00, Sense: 6/29/00 mfi0: 1918 (boot + 31s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1919 (boot + 31s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1920 (boot + 31s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1921 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1922 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1923 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1924 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1925 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1926 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1927 (390389798s/0x0020/info) - Time established as 05/15/12 9:36:38; (76 seconds since power on) mfi0: 1928 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1929 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1930 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1931 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1932 (boot + 30s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1933 (boot + 30s/0x0002/info) - Inserted: Encl PD 20 mfi0: 1934 (boot + 30s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1935 (boot + 30s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1936 (boot + 30s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1937 (boot + 30s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1938 (boot + 30s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1939 (boot + 30s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1940 (boot + 30s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1941 (390407692s/0x0020/info) - Time established as 05/15/12 14:34:52; (76 seconds since power on) mfi0: 1942 (390407855s/0x0020/info) - Host driver is loaded and operational mfi0: 1943 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/1f51/1028) mfi0: 1944 (boot + 4s/0x0020/info) - Firmware version 2.120.14-1504 mfi0: 1945 (boot + 5s/0x0020/info) - Package version 20.10.1-0084 mfi0: 1946 (boot + 5s/0x0020/info) - Board Revision A00 mfi0: 1947 (boot + 29s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5e4ae02084308b00, CDB: 1c 01 00 00 20 00, Sense: 6/29/00 mfi0: 1948 (boot + 31s/0x0004/info) - Enclosure PD 20(c None/p1) communication restored mfi0: 1949 (boot + 31s/0x0002/info) - Inserted: Encl PD 20 usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered mfisyspd0 on mfi0 mfisyspd0: 476940MB (976773168 sectors) SYSPD volume mfisyspd0: SYSPD volume attached mfisyspd1 on mfi0 mfisyspd1: 476940MB (976773168 sectors) SYSPD volume mfisyspd1: SYSPD volume attached mfi0: 1950 (boot + 31s/0x0002/info) - Inserted: PD 20(c None/p1) Info: enclPd=20, scsiType=d, portMap=00, sasAddr=5e4ae02084308b00,0000000000000000 mfi0: 1951 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 1952 (boot + 31s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a3069,0000000000000000 mfi0: 1953 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 1954 (boot + 31s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=5000c500413a4acd,0000000000000000 mfi0: 1955 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) mfi0: 1956 (boot + 31s/0x0002/info) - Inserted: PD 21(e0x00/s0) Info: enclPd=00, scsiType=7f, portMap=00, sasAddr=500056b37789abfd,0000000000000000 mfi0: 1957 (390408291s/0x0020/info) - Time established as 05/15/12 14:44:51; (96 seconds since power on) mfi0: 1958 (390408447s/0x0020/info) - Host driver is loaded and operational After this point, nothing else about mfi in dmesg and they "seem" to work... any ideas on how to resolve? I'd be more than willing to test updated code that fixes the issue, or helps to debug it. Thanks, Jason. From owner-freebsd-current@FreeBSD.ORG Wed May 16 02:31:34 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B9371065673; Wed, 16 May 2012 02:31:34 +0000 (UTC) (envelope-from iwasaki@jp.FreeBSD.org) Received: from locore.org (ns01.locore.org [218.45.21.227]) by mx1.freebsd.org (Postfix) with ESMTP id C17378FC08; Wed, 16 May 2012 02:31:32 +0000 (UTC) Received: from localhost (celeron.v4.locore.org [192.168.0.10]) by locore.org (8.14.5/8.14.5/iwasaki) with ESMTP/inet id q4G2VH4a093543; Wed, 16 May 2012 11:31:17 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) Date: Wed, 16 May 2012 11:31:17 +0900 (JST) Message-Id: <20120516.113117.66055741.iwasaki@jp.FreeBSD.org> To: jkim@freebsd.org From: Mitsuru IWASAKI In-Reply-To: <4FB146F8.9090901@FreeBSD.org> References: <9E61BC2D-2654-40D9-936F-A99CD7AC1354@entel.upc.edu> <20120514.131617.129792413.iwasaki@jp.FreeBSD.org> <4FB146F8.9090901@FreeBSD.org> X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, gperez@entel.upc.edu, freebsd-current@freebsd.org Subject: Re: [CFT] SMP/i386 suspend/resume X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 02:31:34 -0000 Hi, > First of all, thank you very much for your work! I wanted to do it > for very long time but I had no time to actually implement it. :-) Welcome! I also wanted to do this for very long time but I had no time and test machines ;) Recently I got Core Duo (Thinkpad X60) and Core 2 Duo (X61) machines. I have some more ideas on wakecode but I'm not sure whether it is possible for now. I'll propose it when it is ready. > I know for sure it is not related to your patches. In fact, we cannot > resume most NVIDIA controllers without NVIDIA kernel driver + binary > X.org driver + VT switching hack (i.e., Hmm, my knowledge on recent hardware is very poor, so your comments are very helpful to catch up. Thanks. > > We can improve video initialization on another opportunity. Linux > > have many video hacks while we have only hw.acpi.reset_video ;) > > FYI, we don't need hw.acpi.reset_video any more (and it is even > harmful). It is done from vesa.ko now. Yeah, I thought that we need INT10 to set video mode again in realmode, but found it can be done in protected mode with x86bios_intr(), great! Anyway, thanks for many things! From owner-freebsd-current@FreeBSD.ORG Wed May 16 03:12:51 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1071B106566C for ; Wed, 16 May 2012 03:12:51 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id D52F98FC1C for ; Wed, 16 May 2012 03:12:50 +0000 (UTC) Received: by dadv36 with SMTP id v36so383196dad.13 for ; Tue, 15 May 2012 20:12:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:x-gm-message-state; bh=wDCUKpmfUOUv+Kl3v38sMEBHDS7HBuiJ4gbduftFXlM=; b=n7ha/iHHeaeyEsgoGym/Eqn+82WS+m2jGJMkion3VFYMgtgygWTR5nYxY/j1myS0xT QPNWzk3bjkrp/d2xdO5Z4Kgee6JuBzAy3aGaCaJP4KpO/y6AFD/abD/1QEqwryIBH8wm ECENQuJX44VavfnGiFp+ludsbNsbsBpJ0FgeZ2wL1GOzc+RBSO1R7fdihTetSAgAXYMI j5ONSJ9GX96IQpH5G5mJXFVU925eaMnM8WhU7xeyiavmCFK63Iez32JVYFp91+iNm10I TfhY5jgYjLeqY+04Eeq/Y+WlPjhHoBPbw3Z24hKZVjk+fUK+hf/zYMxXb2j/QFScE5lG Z5Lg== MIME-Version: 1.0 Received: by 10.68.226.5 with SMTP id ro5mr11970804pbc.74.1337137970426; Tue, 15 May 2012 20:12:50 -0700 (PDT) Sender: andy@fud.org.nz Received: by 10.68.49.97 with HTTP; Tue, 15 May 2012 20:12:50 -0700 (PDT) Date: Wed, 16 May 2012 15:12:50 +1200 X-Google-Sender-Auth: U5XpRY9oNknuJt7_uPvt2wQoXGU Message-ID: From: Andrew Thompson To: "current@freebsd.org Current" Content-Type: multipart/mixed; boundary=047d7b2e0961be32ec04c01eb168 X-Gm-Message-State: ALoCoQkY5PqF0dtri4ycx5q9su1OKut+U2uVEH1FeTLImCP8v02MdScaZ7FvNGd+hwtqB2oCjIA9 Cc: Subject: sockstat & jid patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 03:12:51 -0000 --047d7b2e0961be32ec04c01eb168 Content-Type: text/plain; charset=ISO-8859-1 Hi, Here is a quick patch to limit the sockstat output to a specific jail id, this is useful to verify which sockets a jail has open. A jid of 0 will show the host system. This will result in an extra syscall per socket when -j is set but I do not think warrants a process cache. Any objections? Andrew --047d7b2e0961be32ec04c01eb168 Content-Type: application/octet-stream; name="sockstat_jid.diff" Content-Disposition: attachment; filename="sockstat_jid.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h29tf1dv0 SW5kZXg6IHNvY2tzdGF0LjEKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc29ja3N0YXQuMQkocmV2aXNpb24gMjM1 NDUzKQorKysgc29ja3N0YXQuMQkod29ya2luZyBjb3B5KQpAQCAtMjcsNyArMjcsNyBAQAogLlwi CiAuXCIgJEZyZWVCU0QkCiAuXCIKLS5EZCBKYW51YXJ5IDI0LCAyMDEyCisuRGQgTWF5IDE2LCAy MDEyCiAuRHQgU09DS1NUQVQgMQogLk9zCiAuU2ggTkFNRQpAQCAtMzYsNiArMzYsNyBAQAogLlNo IFNZTk9QU0lTCiAuTm0KIC5PcCBGbCA0NmNMbHUKKy5PcCBGbCBqIEFyIGppZAogLk9wIEZsIHAg QXIgcG9ydHMKIC5PcCBGbCBQIEFyIHByb3RvY29scwogLlNoIERFU0NSSVBUSU9OCkBAIC01Nyw2 ICs1OCw4IEBAIFNob3cKIChJUHY2KSBzb2NrZXRzLgogLkl0IEZsIGMKIFNob3cgY29ubmVjdGVk IHNvY2tldHMuCisuSXQgRmwgaiBBciBqaWQKK1Nob3cgb25seSBzb2NrZXRzIGJlbG9uZ2luZyB0 byB0aGUgc3BlY2lmaWVkIGphaWwgSUQuCiAuSXQgRmwgTAogT25seSBzaG93IEludGVybmV0IHNv Y2tldHMgaWYgdGhlIGxvY2FsIG9yIGZvcmVpZ24gYWRkcmVzc2VzIGFyZSBub3QKIGluIHRoZSBs b29wYmFjayBuZXR3b3JrIHByZWZpeApJbmRleDogc29ja3N0YXQuYwo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBz b2Nrc3RhdC5jCShyZXZpc2lvbiAyMzU0NTMpCisrKyBzb2Nrc3RhdC5jCSh3b3JraW5nIGNvcHkp CkBAIC02Miw2ICs2Miw3IEBAIF9fRkJTRElEKCIkRnJlZUJTRCQiKTsKIHN0YXRpYyBpbnQJIG9w dF80OwkJLyogU2hvdyBJUHY0IHNvY2tldHMgKi8KIHN0YXRpYyBpbnQJIG9wdF82OwkJLyogU2hv dyBJUHY2IHNvY2tldHMgKi8KIHN0YXRpYyBpbnQJIG9wdF9jOwkJLyogU2hvdyBjb25uZWN0ZWQg c29ja2V0cyAqLworc3RhdGljIGludAkgb3B0X2o7CQkvKiBTaG93IHNwZWNpZmllZCBqYWlsICov CiBzdGF0aWMgaW50CSBvcHRfTDsJCS8qIERvbid0IHNob3cgSVB2NCBvciBJUHY2IGxvb3BiYWNr IHNvY2tldHMgKi8KIHN0YXRpYyBpbnQJIG9wdF9sOwkJLyogU2hvdyBsaXN0ZW5pbmcgc29ja2V0 cyAqLwogc3RhdGljIGludAkgb3B0X3U7CQkvKiBTaG93IFVuaXggZG9tYWluIHNvY2tldHMgKi8K QEAgLTU0OSw2ICs1NTAsMjcgQEAgZ2V0cHJvY25hbWUocGlkX3QgcGlkKQogfQogCiBzdGF0aWMg aW50CitnZXRwcm9jamlkKHBpZF90IHBpZCkKK3sKKwlzdGF0aWMgc3RydWN0IGtpbmZvX3Byb2Mg cHJvYzsKKwlzaXplX3QgbGVuOworCWludCBtaWJbNF07CisKKwltaWJbMF0gPSBDVExfS0VSTjsK KwltaWJbMV0gPSBLRVJOX1BST0M7CisJbWliWzJdID0gS0VSTl9QUk9DX1BJRDsKKwltaWJbM10g PSAoaW50KXBpZDsKKwlsZW4gPSBzaXplb2YgcHJvYzsKKwlpZiAoc3lzY3RsKG1pYiwgNCwgJnBy b2MsICZsZW4sIE5VTEwsIDApID09IC0xKSB7CisJCS8qIERvIG5vdCB3YXJuIGlmIHRoZSBwcm9j ZXNzIGV4aXRzIGJlZm9yZSB3ZSBnZXQgaXRzIGppZC4gKi8KKwkJaWYgKGVycm5vICE9IEVTUkNI KQorCQkJd2Fybigic3lzY3RsKCkiKTsKKwkJcmV0dXJuICgtMSk7CisJfQorCXJldHVybiAocHJv Yy5raV9qaWQpOworfQorCitzdGF0aWMgaW50CiBjaGVja19wb3J0cyhzdHJ1Y3Qgc29jayAqcykK IHsKIAlpbnQgcG9ydDsKQEAgLTY0Myw2ICs2NjUsOCBAQCBkaXNwbGF5KHZvaWQpCiAJZm9yICh4 ZiA9IHhmaWxlcywgbiA9IDA7IG4gPCBueGZpbGVzOyArK24sICsreGYpIHsKIAkJaWYgKHhmLT54 Zl9kYXRhID09IE5VTEwpCiAJCQljb250aW51ZTsKKwkJaWYgKG9wdF9qID49IDAgJiYgb3B0X2og IT0gZ2V0cHJvY2ppZCh4Zi0+eGZfcGlkKSkKKwkJCWNvbnRpbnVlOwogCQloYXNoID0gKGludCko KHVpbnRwdHJfdCl4Zi0+eGZfZGF0YSAlIEhBU0hTSVpFKTsKIAkJZm9yIChzID0gc29ja2hhc2hb aGFzaF07IHMgIT0gTlVMTDsgcyA9IHMtPm5leHQpCiAJCQlpZiAoKHZvaWQgKilzLT5zb2NrZXQg PT0geGYtPnhmX2RhdGEpCkBAIC02NjgsNiArNjkyLDggQEAgZGlzcGxheSh2b2lkKQogCQlwb3Mg Kz0geHByaW50ZigiJWQgIiwgeGYtPnhmX2ZkKTsKIAkJZGlzcGxheXNvY2socywgcG9zKTsKIAl9 CisJaWYgKG9wdF9qID49IDApCisJCXJldHVybjsKIAlmb3IgKGhhc2ggPSAwOyBoYXNoIDwgSEFT SFNJWkU7IGhhc2grKykgewogCQlmb3IgKHMgPSBzb2NraGFzaFtoYXNoXTsgcyAhPSBOVUxMOyBz ID0gcy0+bmV4dCkgewogCQkJaWYgKHMtPnNob3duKQpAQCAtNzE2LDcgKzc0Miw4IEBAIG1haW4o aW50IGFyZ2MsIGNoYXIgKmFyZ3ZbXSkKIAlpbnQgcHJvdG9zX2RlZmluZWQgPSAtMTsKIAlpbnQg bywgaTsKIAotCXdoaWxlICgobyA9IGdldG9wdChhcmdjLCBhcmd2LCAiNDZjTGxwOlA6dXYiKSkg IT0gLTEpCisJb3B0X2ogPSAtMTsKKwl3aGlsZSAoKG8gPSBnZXRvcHQoYXJnYywgYXJndiwgIjQ2 Y2o6TGxwOlA6dXYiKSkgIT0gLTEpCiAJCXN3aXRjaCAobykgewogCQljYXNlICc0JzoKIAkJCW9w dF80ID0gMTsKQEAgLTcyNyw2ICs3NTQsOSBAQCBtYWluKGludCBhcmdjLCBjaGFyICphcmd2W10p CiAJCWNhc2UgJ2MnOgogCQkJb3B0X2MgPSAxOwogCQkJYnJlYWs7CisJCWNhc2UgJ2onOgorCQkJ b3B0X2ogPSBhdG9pKG9wdGFyZyk7CisJCQlicmVhazsKIAkJY2FzZSAnTCc6CiAJCQlvcHRfTCA9 IDE7CiAJCQlicmVhazsK --047d7b2e0961be32ec04c01eb168-- From owner-freebsd-current@FreeBSD.ORG Wed May 16 05:41:02 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86ECE1065670 for ; Wed, 16 May 2012 05:41:02 +0000 (UTC) (envelope-from sergey.dyatko@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 F223E8FC1C for ; Wed, 16 May 2012 05:41:01 +0000 (UTC) Received: by laai10 with SMTP id i10so325989laa.13 for ; Tue, 15 May 2012 22:41:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=mNaQi4viHKhpzZYyXbddu7Y46P2ykNPVu0gBPM0coN0=; b=xeBXgAeqQS+DzGtOJejtwAJGBNOqv5whvx2kkmGvFWiE3xbQ/7Bf9mJVtimK2wVccm vIHISwyzIUNVLjBPkD8MVC2ViWCOFSJpYJTcIaifWriIXT2SOdtX2zZ8pHgngtPd4mo0 RUUFVNfyU48SczoxQy0rA0tbR9aEdX7mj2KPWcZuHVahUcV7gNPKUp89ca8vDRyFxAEo gfIPvevQqxeRLVHxvjb7MZuljCZ7kMAz0dqBEHgzz7NIZGa7pSrQuzbXWRpc0knGfWdA Ir+VuHWSP7hWStIo0BcEV278H8qx/nHhfpT2m1fyNXH4yIxWehWsu/NWLXibuMtL7ZN4 EjkQ== Received: by 10.152.46.6 with SMTP id r6mr1753065lam.7.1337146860618; Tue, 15 May 2012 22:41:00 -0700 (PDT) Received: from laptop (m-s.agava.net. [195.222.84.203]) by mx.google.com with ESMTPS id gd9sm2010940lbb.15.2012.05.15.22.40.58 (version=SSLv3 cipher=OTHER); Tue, 15 May 2012 22:40:59 -0700 (PDT) Date: Wed, 16 May 2012 08:41:38 +0300 From: "Sergey V. Dyatko" To: "current@freebsd.org Current" Message-ID: <20120516084138.68aa3076@laptop> In-Reply-To: References: X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: Re: sockstat & jid patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 05:41:02 -0000 On Wed, 16 May 2012 15:12:50 +1200 Andrew Thompson wrote: > Hi, > > > Here is a quick patch to limit the sockstat output to a specific jail > id, this is useful to verify which sockets a jail has open. A jid of 0 > will show the host system. > > This will result in an extra syscall per socket when -j is set but I > do not think warrants a process cache. > > Any objections? > Necessary thing for me, thanks. Only one question: that patch and releng_[78].. will it work? > > Andrew -- wbr, tiger From owner-freebsd-current@FreeBSD.ORG Wed May 16 06:52:37 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 42947106564A; Wed, 16 May 2012 06:52:37 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from springbank.echomania.com (andric.com [IPv6:2001:888:2003:1001:230:48ff:fe51:76b6]) by mx1.freebsd.org (Postfix) with ESMTP id CB2778FC17; Wed, 16 May 2012 06:52:36 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at springbank.echomania.com Received: from [192.168.1.100] (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by springbank.echomania.com (Postfix) with ESMTPSA id 37178A7071; Wed, 16 May 2012 08:52:15 +0200 (CEST) Message-ID: <4FB34EAE.4040704@FreeBSD.org> Date: Wed, 16 May 2012 08:52:30 +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: Outback Dingo References: In-Reply-To: X-Enigmail-Version: 1.5a1pre Content-Type: multipart/mixed; boundary="------------090802070502000504000505" Cc: freebsd-current , freebsd-ports@freebsd.org Subject: Re: FYI clang fails to build ports argp-standalone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 06:52:37 -0000 This is a multi-part message in MIME format. --------------090802070502000504000505 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 2012-05-14 22:03, Outback Dingo wrote:> build on CURRENT Not sure if its appropriate here, but when trying to > get through a new glusterfs FYI clang fails to build ports > argp-standalone on CURRENT This is easy to fix, patch attached. --------------090802070502000504000505 Content-Type: text/x-diff; name="clangports-devel-argp-standalone-1.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="clangports-devel-argp-standalone-1.diff" Index: devel/argp-standalone/Makefile =================================================================== RCS file: /home/pcvs/ports/devel/argp-standalone/Makefile,v retrieving revision 1.12 diff -u -r1.12 Makefile --- devel/argp-standalone/Makefile 4 Dec 2010 07:31:00 -0000 1.12 +++ devel/argp-standalone/Makefile 15 May 2012 12:20:47 -0000 @@ -21,6 +21,7 @@ AUTOMAKE_ARGS= -c -a ACLOCAL_ARGS= --acdir=${ACLOCAL_DIR} -I ${LOCALBASE}/share/aclocal USE_LDCONFIG= yes +USE_CSTD= c89 PLIST_FILES= lib/libargp.la lib/libargp.a \ lib/libargp.so lib/libargp.so.0 \ --------------090802070502000504000505-- From owner-freebsd-current@FreeBSD.ORG Wed May 16 08:45:55 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B543E106566B; Wed, 16 May 2012 08:45:55 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id DA1CD8FC08; Wed, 16 May 2012 08:45:54 +0000 (UTC) Received: from ncsc.bris.ac.uk ([137.222.10.41]) by dirg.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1SUZrl-0000EB-3c; Wed, 16 May 2012 09:45:54 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncsc.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SUZrj-0000OT-Qs; Wed, 16 May 2012 09:45:52 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5) with ESMTP id q4G8jpLM049071; Wed, 16 May 2012 09:45:51 +0100 (BST) (envelope-from mexas@bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5/Submit) id q4G8jpbI049070; Wed, 16 May 2012 09:45:51 +0100 (BST) (envelope-from mexas@bris.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bris.ac.uk using -f Date: Wed, 16 May 2012 09:45:51 +0100 From: Anton Shterenlikht To: John Baldwin Message-ID: <20120516084551.GA49037@mech-cluster241.men.bris.ac.uk> Mail-Followup-To: John Baldwin , Anton Shterenlikht , freebsd-current@freebsd.org References: <20120426224215.GA79891@mech-cluster241.men.bris.ac.uk> <201205071039.51737.jhb@freebsd.org> <20120507212502.GA8936@mech-cluster241.men.bris.ac.uk> <201205151211.09161.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201205151211.09161.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org, Anton Shterenlikht Subject: Re: updating from r231158 to 234465: mounting from ufs:/dev/ad4s1a failed with error 19 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 08:45:55 -0000 On Tue, May 15, 2012 at 12:11:09PM -0400, John Baldwin wrote: > On Monday, May 07, 2012 5:25:02 pm Anton Shterenlikht wrote: > > On Mon, May 07, 2012 at 10:39:51AM -0400, John Baldwin wrote: > > > On Friday, May 04, 2012 4:07:24 pm Anton Shterenlikht wrote: > > > > On Fri, May 04, 2012 at 11:07:59AM -0400, John Baldwin wrote: > > > > > On Friday, May 04, 2012 7:51:33 am Anton Shterenlikht wrote: > > > > > > On Thu, May 03, 2012 at 02:46:18PM -0400, John Baldwin wrote: > > > > > > > On Thursday, May 03, 2012 11:35:19 am Anton Shterenlikht wrote: > > > > > > > > On Tue, May 01, 2012 at 12:35:26PM +0100, Anton Shterenlikht wrote: > > > > > > > > > On Mon, Apr 30, 2012 at 08:43:14AM -0400, John Baldwin wrote: > > > > > > > > > > > > > > > > > > > > > > I also see: > > > > > > > > > > > > > > > > > > > > > > ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0exb > > > > > > > > > > > ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 > > > > > > > > > > > ata0: reset tp2 stat0=00 stat1=00 devices=0x10000 > > > > > > > > > > > > > > > > > > > > Hmmm, I don't know how to grok these lines, but does your disk work > > > > > at > > > > > > > all now > > > > > > > > > > with any kernel? It may be that your disk has died (or a cable, > > > > > etc.) > > > > > > > and it > > > > > > > > > > just happened to coincide with your upgrade? > > > > > > > > > > > > > > > > > > I reverted back to r231158, built world and generic > > > > > > > > > kernel (minus all modules, i.e. "option MODULES_OVERRIDE="). > > > > > > > > > This works, see the verbose boot dmesg at the end. > > > > > > > > > > > > > > > > > > I think I'll just do a binary search. > > > > > > > > > > > > > > > > I traced it to r233677. > > > > > > > > The only change from 233676 to 233677 is > > > > > > > > in /sys/dev/pci/pci.c > > > > > > > > > > > > > > > > My kernel is GENERIC with no modules > > > > > > > > and with various bits removed, e.g. all raid devices > > > > > > > > and PCI network devices, which I definitely > > > > > > > > haven't got on this laptop. > > > > > > > > > > > > > > > > Below is the verbose boot with r233676. > > > > > > > > Apparently at the beginning there's also > > > > > > > > the previous unsuccessful boot with r233677. > > > > > > > > Is this a new feature? I didn't know the > > > > > > > > previous dmesg is preserved after a reboot. > > > > > > > > Anyway, you can see clearly the error with r233677. > > > > > > > > > > > > > > > > I guess this is something to do with > > > > > > > > ata -> ada change? > > > > > > > > > > > > > > I don't think so. > > > > > > > > > > > > > > Please try just this change: > > > > > > > > > > > > > > Index: pci.c > > > > > > > =================================================================== > > > > > > > --- pci.c (revision 234928) > > > > > > > +++ pci.c (working copy) > > > > > > > @@ -2822,10 +2822,14 @@ pci_add_map(device_t bus, device_t dev, int reg, s > > > > > > > * from the parent. > > > > > > > */ > > > > > > > resource_list_delete(rl, type, reg); > > > > > > > - } else { > > > > > > > + start = 0; > > > > > > > + device_printf(bus, > > > > > > > + "pci%d:%d:%d:%d bar %#x failed to allocate", > > > > > > > + pci_get_domain(dev), pci_get_bus(dev), pci_get_slot(dev), > > > > > > > + pci_get_function(dev), reg); > > > > > > > + } else > > > > > > > start = rman_get_start(res); > > > > > > > - pci_write_bar(dev, pm, start); > > > > > > > - } > > > > > > > + pci_write_bar(dev, pm, start); > > > > > > > return (barlen); > > > > > > > } > > > > > > > > > > > > > > > > > > > That helped, thank you. > > > > > > > > > > Bizarre, can you get a regular dmesg with that change applied? > > > > > > > > > > Hmm, I missed a newline at the end. :) Looks like this happened twice. > > > I've added the relevant verbose boot messages from your earlier kernel > > > below each one: > > > > > > > pci0: on pcib0 > > > > pci0: pci0:0:20:2 bar 0x10 failed to allocate > > > > pcib1: at device 1.0 on pci0 > > > > > > found-> vendor=0x1002, dev=0x4383, revid=0x00 > > > domain=0, bus=0, slot=20, func=2 > > > class=04-03-00, hdrtype=0x00, mfdev=0 > > > cmdreg=0x0006, statreg=0x0410, cachelnsz=16 (dwords) > > > lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > > intpin=a, irq=10 > > > powerspec 2 supports D0 D3 current D0 > > > map[10]: type Memory, range 64, base 0xcc408000, size 14, enabled > > > pcib0: matched entry for 0.20.INTA > > > pcib0: slot 20 INTA hardwired to IRQ 16 > > > > > > > pcib4: at device 20.4 on pci0 > > > > pcib4: failed to allocate initial memory window: 0xcc100000-0xcc1fffff > > > > pci2: on pcib4 > > > > pci2: pci0:2:4:0 bar 0x10 failed to allocate > > > > cbb0: irq 20 at device 4.0 on pci2 > > > > > > found-> vendor=0x1180, dev=0x0476, revid=0xb6 > > > domain=0, bus=2, slot=4, func=0 > > > class=06-07-00, hdrtype=0x02, mfdev=1 > > > cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) > > > lattimer=0x40 (1920 ns), mingnt=0x80 (32000 ns), maxlat=0x07 (1750 ns) > > > intpin=a, irq=10 > > > powerspec 2 supports D0 D1 D2 D3 current D0 > > > map[10]: type Memory, range 32, base 0xcc100000, size 12, enabled > > > pcib4: failed to allocate initial memory window (0xcc100000-0xcc1fffff,0x100000) > > > pcib4: matched entry for 2.4.INTA > > > pcib4: slot 4 INTA hardwired to IRQ 20 > > > cbb0: irq 20 at device 4.0 on pci2 > > > pcib0: allocated type 3 (0xcc500000-0xcc5fffff) for rid 20 of pcib4 > > > pcib4: allocated initial memory window of 0xcc500000-0xcc5fffff > > > pcib4: allocated memory range (0xcc500000-0xcc500fff) for rid 10 of cbb0 > > > cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xcc500000 > > > > > > So the second case actually recovers and allocates a different range. > > > > > > Can you try booting with 'debug.acpi.disabled=sysres' set in the loader? > > > > You mean without the patch? > > Either way. > > > > Also, can you get the output of 'devinfo -rv' from a working kernel? > > Oops, I meant to ask for devinfo -u, sorry. :( > > Oh, I see it now. Your BIOS is broken. > > The hdac0 device is assigned a resource that conflicts with pcib4, though > that is the one we recover from: > > > hdac0 pnpinfo vendor=0x1002 device=0x4383 subvendor=0x103c subdevice=0x30c2 class=0x040300 at slot=20 function=2 handle=\_SB_.C08B.C0FD > > Interrupt request lines: > > 16 > > I/O memory addresses: > > 0xcc100000-0xcc103fff > > For the CardBus Bridge, the issue is this device: > > > ahci0 pnpinfo vendor=0x1002 device=0x4380 subvendor=0x1002 subdevice=0x4380 class=0x01018f at slot=18 function=0 handle=\_SB_.C08B.C275 > > Interrupt request lines: > > 16 > > I/O ports: > > 0x5018-0x501b > > 0x5020-0x502f > > 0x9000-0x9007 > > 0x9008-0x900b > > 0x9010-0x9017 > > I/O memory addresses: > > 0xcc409000-0xcc4093ff > > That last memory BAR conflicts with the desired range of 0xcc408000-0xcc40c000. > > I'm not sure why BIOS writers are so grossly incompetent, but such is life. > > Try this: > > Index: pci.c > =================================================================== > --- pci.c (revision 235475) > +++ pci.c (working copy) > @@ -2815,13 +2815,36 @@ pci_add_map(device_t bus, device_t dev, int reg, s > */ > res = resource_list_reserve(rl, bus, dev, type, ®, start, end, count, > prefetch ? RF_PREFETCHABLE : 0); > + if (res == NULL && (start != 0 || end != ~0ul)) { > + /* > + * If the allocation fails, try to allocate a resource for > + * this BAR using any available range. The firmware felt > + * it was important enough to assign a resource, so don't > + * disable decoding if we can help it. > + */ > + resource_list_delete(rl, type, reg); > + start = 0; > + end = ~0ul; > + resource_list_add(rl, type, reg, 0, ~0ul, count); > + resource_list_add(rl, type, reg, start, end, count); > + res = resource_list_reserve(rl, bus, dev, type, ®, 0, ~0ul, > + count, prefetch ? RF_PREFETCHABLE : 0); > + } > if (res == NULL) { > /* > * If the allocation fails, delete the resource list entry > - * to force pci_alloc_resource() to allocate resources > - * from the parent. > + * and disable decoding for this device. > + * > + * If the driver requests this resource in the future, > + * pci_reserve_map() will try to allocate fresh resources. > */ > resource_list_delete(rl, type, reg); > + pci_disable_io(dev, type); > + start = 0; > + device_printf(bus, > + "pci%d:%d:%d:%d bar %#x failed to allocate", > + pci_get_domain(dev), pci_get_bus(dev), pci_get_slot(dev), > + pci_get_function(dev), reg); > } else { > start = rman_get_start(res); > pci_write_bar(dev, pm, start); > > > -- > John Baldwin Below are (1) verbose boot dmesg and (2) devinfo -u, with your patch and with 'debug.acpi.disabled=sysres' set in the loader. Thank you # dmesg Table 'FACP' at 0xb7fc8084 Table 'SLIC' at 0xb7fc8220 Table 'EPTH' at 0xb7fc8398 Table 'APIC' at 0xb7fc83d0 APIC: Found table at 0xb7fc83d0 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 2: enabled SMP: Added CPU 1 (AP) Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.9-CURRENT #1 r234928M: Tue May 8 16:10:50 BST 2012 root@mech-aslap239.men.bris.ac.uk:/usr/obj/usr/src/sys/GEN8 amd64 WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80f07000. Preloaded elf obj module "/boot/modules/bwn_v4_ucode.ko" at 0xffffffff80f07210. Calibrating TSC clock ... TSC clock: 1995044869 Hz CPU: AMD Turion(tm) 64 X2 Mobile Technology TL-60 (1995.04-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x60f82 Family = f Model = 68 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f L1 2MB data TLB: 8 entries, fully associative L1 2MB instruction TLB: 8 entries, fully associative L1 4KB data TLB: 32 entries, fully associative L1 4KB instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 2MB unified TLB: 0 entries, disabled/not present L2 4KB data TLB: 512 entries, 4-way associative L2 4KB instruction TLB: 512 entries, 4-way associative L2 unified cache: 512 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative real memory = 3221225472 (3072 MB) Physical memory chunk(s): 0x0000000000010000 - 0x000000000009bfff, 573440 bytes (140 pages) 0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) 0x0000000000f36000 - 0x00000000b28ecfff, 2979753984 bytes (727479 pages) avail memory = 2958528512 (2821 MB) INTR: Adding local APIC 0 as a target Event timer "LAPIC" quality 400 ACPI APIC Table: INTR: Adding local APIC 0 as a target INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 x86bios: IVT 0x000000-0x0004ff at 0xfffffe0000000000 x86bios: SSEG 0x098000-0x098fff at 0xffffff8000210000 x86bios: EBDA 0x09f000-0x09ffff at 0xfffffe000009f000 x86bios: ROM 0x0a0000-0x0fefff at 0xfffffe00000a0000 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 ULE: setup cpu 0 ULE: setup cpu 1 ACPI: RSDP 0xfe0b0 00024 (v02 HP ) ACPI: XSDT 0xb7fc81bc 00064 (v01 HPQOEM SLIC-MPC 00000001 HP 00000001) ACPI: FACP 0xb7fc8084 000F4 (v04 HP 0944 00000003 HP 00000001) ACPI Error: 32/64X address mismatch in Pm2ControlBlock: 0x00008800/0x0000000000008100, using 32 (20120420/tbfadt-474) ACPI: DSDT 0xb7fc84a4 11437 (v01 HP SB400 00010000 MSFT 03000001) ACPI: FACS 0xb7fe7d80 00040 ACPI: SLIC 0xb7fc8220 00176 (v01 HPQOEM SLIC-MPC 00000001 HP 00000001) ACPI: EPTH 0xb7fc8398 00038 (v01 HP 0944 00000001 HP 00000001) ACPI: APIC 0xb7fc83d0 00062 (v01 HP 0944 00000001 HP 00000001) ACPI: MCFG 0xb7fc8434 0003C (v01 HP 0944 00000001 HP 00000001) ACPI: TCPA 0xb7fc8470 00032 (v02 HP 0944 00000001 HP 00000001) ACPI: SSDT 0xb7fd98db 00059 (v01 HP HPQNLP 00000001 MSFT 03000001) ACPI: SSDT 0xb7fd9934 00206 (v01 HP PSSTBLID 00000001 HP 00000001) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 2 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: low lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 wlan: <802.11 Link Layer> firmware: 'bwn_v4_ucode' version 0: 0 bytes loaded at 0xffffffff80eda890 firmware: 'bwn_v4_ucode5' version 0: 22384 bytes loaded at 0xffffffff80eda890 firmware: 'bwn_v4_ucode11' version 0: 29864 bytes loaded at 0xffffffff80ee0000 firmware: 'bwn_v4_ucode13' version 0: 32232 bytes loaded at 0xffffffff80ee74a8 firmware: 'bwn_v4_ucode14' version 0: 31384 bytes loaded at 0xffffffff80eef290 firmware: 'bwn_v4_ucode15' version 0: 30488 bytes loaded at 0xffffffff80ef6d28 firmware: 'bwn_v4_pcm5' version 0: 1320 bytes loaded at 0xffffffff80efe440 firmware: 'bwn_v4_a0g1initvals5' version 0: 1840 bytes loaded at 0xffffffff80efe968 firmware: 'bwn_v4_a0g0initvals5' version 0: 1840 bytes loaded at 0xffffffff80eff098 firmware: 'bwn_v4_b0g0initvals5' version 0: 1840 bytes loaded at 0xffffffff80eff7c8 firmware: 'bwn_v4_b0g0initvals13' version 0: 2080 bytes loaded at 0xffffffff80effef8 firmware: 'bwn_v4_a0g1bsinitvals5' version 0: 158 bytes loaded at 0xffffffff80f00718 firmware: 'bwn_v4_a0g0bsinitvals5' version 0: 158 bytes loaded at 0xffffffff80f007b6 firmware: 'bwn_v4_b0g0bsinitvals5' version 0: 158 bytes loaded at 0xffffffff80f00854 firmware: 'bwn_v4_lp0initvals13' version 0: 3618 bytes loaded at 0xffffffff80f008f2 firmware: 'bwn_v4_lp0initvals14' version 0: 2064 bytes loaded at 0xffffffff80f01714 firmware: 'bwn_v4_lp0initvals15' version 0: 2052 bytes loaded at 0xffffffff80f01f24 firmware: 'bwn_v4_lp0bsinitvals13' version 0: 158 bytes loaded at 0xffffffff80f02728 firmware: 'bwn_v4_lp0bsinitvals14' version 0: 158 bytes loaded at 0xffffffff80f027c6 firmware: 'bwn_v4_lp0bsinitvals15' version 0: 158 bytes loaded at 0xffffffff80f02864 firmware: 'bwn_v4_n0bsinitvals11' version 0: 158 bytes loaded at 0xffffffff80f02902 kbd: new array size 4 kbd1 at kbdmux0 mem: null: io: random: acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xe0000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: Power Button (fixed) unknown: I/O range not supported cpu0: on acpi0 cpu0: switching to generic Cx mode cpu1: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 49 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71,0x72-0x73 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 50 Event timer "RTC" frequency 32768 Hz quality 0 ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 10 11 Validation 0 255 N 0 10 11 After Disable 0 255 N 0 10 11 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 10 11 Validation 0 255 N 0 10 11 After Disable 0 255 N 0 10 11 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 10 11 Validation 0 255 N 0 10 11 After Disable 0 255 N 0 10 11 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 10 11 Validation 0 255 N 0 10 11 After Disable 0 255 N 0 10 11 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 10 11 Validation 0 255 N 0 10 11 After Disable 0 255 N 0 10 11 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 9 Validation 0 255 N 0 9 After Disable 0 255 N 0 9 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 10 11 Validation 0 255 N 0 10 11 After Disable 0 255 N 0 10 11 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 10 11 Validation 0 255 N 0 10 11 After Disable 0 255 N 0 10 11 pcib0: port 0xcf8-0xcff on acpi0 pcib0: decoding 4 range 0-0xcf7 pcib0: decoding 4 range 0xd00-0xffff pcib0: decoding 3 range 0xa0000-0xbffff pcib0: decoding 3 range 0xc0000000-0xfedfffff pcib0: Length mismatch for 3 range: 11ff000 vs 11fefff pcib0: decoding 3 range 0xfee01000-0xffffffff pcib0: decoding 3 range 0xd3000-0xdffff pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x1002, dev=0x7910, revid=0x00 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2220, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x7912, revid=0x00 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x7914, revid=0x00 domain=0, bus=0, slot=4, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 1 message found-> vendor=0x1002, dev=0x7915, revid=0x00 domain=0, bus=0, slot=5, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 1 message found-> vendor=0x1002, dev=0x7916, revid=0x00 domain=0, bus=0, slot=6, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 1 message found-> vendor=0x1002, dev=0x4380, revid=0x00 domain=0, bus=0, slot=18, func=0 class=01-01-8f, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0230, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0x9000, size 3, enabled pcib0: allocated type 4 (0x9000-0x9007) for rid 10 of pci0:0:18:0 map[14]: type I/O Port, range 32, base 0x9008, size 2, enabled pcib0: allocated type 4 (0x9008-0x900b) for rid 14 of pci0:0:18:0 map[18]: type I/O Port, range 32, base 0x9010, size 3, enabled pcib0: allocated type 4 (0x9010-0x9017) for rid 18 of pci0:0:18:0 map[1c]: type I/O Port, range 32, base 0x5018, size 2, enabled pcib0: allocated type 4 (0x5018-0x501b) for rid 1c of pci0:0:18:0 map[20]: type I/O Port, range 32, base 0x5020, size 4, enabled pcib0: allocated type 4 (0x5020-0x502f) for rid 20 of pci0:0:18:0 map[24]: type Memory, range 32, base 0xd0409000, size 10, enabled pcib0: allocated type 3 (0xd0409000-0xd04093ff) for rid 24 of pci0:0:18:0 pcib0: matched entry for 0.18.INTA pcib0: slot 18 INTA hardwired to IRQ 16 found-> vendor=0x1002, dev=0x4387, revid=0x00 domain=0, bus=0, slot=19, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x02a0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[10]: type Memory, range 32, base 0xd0401000, size 12, enabled pcib0: allocated type 3 (0xd0401000-0xd0401fff) for rid 10 of pci0:0:19:0 pcib0: matched entry for 0.19.INTA pcib0: slot 19 INTA hardwired to IRQ 23 found-> vendor=0x1002, dev=0x4388, revid=0x00 domain=0, bus=0, slot=19, func=1 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02a0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 map[10]: type Memory, range 32, base 0xd0402000, size 12, enabled pcib0: allocated type 3 (0xd0402000-0xd0402fff) for rid 10 of pci0:0:19:1 pcib0: matched entry for 0.19.INTB pcib0: slot 19 INTB hardwired to IRQ 17 found-> vendor=0x1002, dev=0x4389, revid=0x00 domain=0, bus=0, slot=19, func=2 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02a0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=5 map[10]: type Memory, range 32, base 0xd0403000, size 12, enabled pcib0: allocated type 3 (0xd0403000-0xd0403fff) for rid 10 of pci0:0:19:2 pcib0: matched entry for 0.19.INTC pcib0: slot 19 INTC hardwired to IRQ 17 found-> vendor=0x1002, dev=0x438a, revid=0x00 domain=0, bus=0, slot=19, func=3 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02a0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 map[10]: type Memory, range 32, base 0xd0404000, size 12, enabled pcib0: allocated type 3 (0xd0404000-0xd0404fff) for rid 10 of pci0:0:19:3 pcib0: matched entry for 0.19.INTB pcib0: slot 19 INTB hardwired to IRQ 17 found-> vendor=0x1002, dev=0x438b, revid=0x00 domain=0, bus=0, slot=19, func=4 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02a0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=5 map[10]: type Memory, range 32, base 0xd0405000, size 12, enabled pcib0: allocated type 3 (0xd0405000-0xd0405fff) for rid 10 of pci0:0:19:4 pcib0: matched entry for 0.19.INTC pcib0: slot 19 INTC hardwired to IRQ 17 found-> vendor=0x1002, dev=0x4386, revid=0x00 domain=0, bus=0, slot=19, func=5 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xd0406000, size 8, enabled pcib0: allocated type 3 (0xd0406000-0xd04060ff) for rid 10 of pci0:0:19:5 pcib0: matched entry for 0.19.INTD pcib0: slot 19 INTD hardwired to IRQ 23 found-> vendor=0x1002, dev=0x4385, revid=0x14 domain=0, bus=0, slot=20, func=0 class=0c-05-00, hdrtype=0x00, mfdev=1 cmdreg=0x0003, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type I/O Port, range 32, base 0x8200, size 4, enabled pcib0: allocated type 4 (0x8200-0x820f) for rid 10 of pci0:0:20:0 found-> vendor=0x1002, dev=0x438c, revid=0x00 domain=0, bus=0, slot=20, func=1 class=01-01-82, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0220, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 pcib0: allocated type 4 (0x1f0-0x1f7) for rid 10 of pci0:0:20:1 pcib0: allocated type 4 (0x3f6-0x3f6) for rid 14 of pci0:0:20:1 pcib0: allocated type 4 (0x170-0x177) for rid 18 of pci0:0:20:1 pcib0: allocated type 4 (0x376-0x376) for rid 1c of pci0:0:20:1 map[20]: type I/O Port, range 32, base 0x5040, size 4, enabled pcib0: allocated type 4 (0x5040-0x504f) for rid 20 of pci0:0:20:1 pcib0: matched entry for 0.20.INTA pcib0: slot 20 INTA hardwired to IRQ 16 found-> vendor=0x1002, dev=0x4383, revid=0x00 domain=0, bus=0, slot=20, func=2 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0410, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 64, base 0xd0408000, size 14, enabled pci0: pci0:0:20:2 bar 0x10 failed to allocatepcib0: matched entry for 0.20.INTA pcib0: slot 20 INTA hardwired to IRQ 16 found-> vendor=0x1002, dev=0x438d, revid=0x00 domain=0, bus=0, slot=20, func=3 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x4384, revid=0x00 domain=0, bus=0, slot=20, func=4 class=06-04-01, hdrtype=0x01, mfdev=1 cmdreg=0x0027, statreg=0x02a0, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1100, revid=0x00 domain=0, bus=0, slot=24, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1101, revid=0x00 domain=0, bus=0, slot=24, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1102, revid=0x00 domain=0, bus=0, slot=24, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1103, revid=0x00 domain=0, bus=0, slot=24, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pcib1: at device 1.0 on pci0 pcib0: allocated type 4 (0x4000-0x4fff) for rid 1c of pcib1 pcib0: allocated type 3 (0xd0200000-0xd03fffff) for rid 20 of pcib1 pcib0: allocated type 3 (0xc0000000-0xc7ffffff) for rid 24 of pcib1 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x4000-0x4fff pcib1: memory decode 0xd0200000-0xd03fffff pcib1: prefetched decode 0xc0000000-0xc7ffffff pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x1002, dev=0x791f, revid=0x00 domain=0, bus=1, slot=5, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Prefetchable Memory, range 64, base 0xc0000000, size 27, enabled pcib1: allocated prefetch range (0xc0000000-0xc7ffffff) for rid 10 of pci0:1:5:0 map[18]: type Memory, range 64, base 0xd0200000, size 16, enabled pcib1: allocated memory range (0xd0200000-0xd020ffff) for rid 18 of pci0:1:5:0 map[20]: type I/O Port, range 32, base 0x4000, size 8, enabled pcib1: allocated I/O port range (0x4000-0x40ff) for rid 20 of pci0:1:5:0 map[24]: type Memory, range 32, base 0xd0300000, size 20, enabled pcib1: allocated memory range (0xd0300000-0xd03fffff) for rid 24 of pci0:1:5:0 pcib1: matched entry for 1.5.INTB pcib1: slot 5 INTB hardwired to IRQ 19 vgapci0: port 0x4000-0x40ff mem 0xc0000000-0xc7ffffff,0xd0200000-0xd020ffff,0xd0300000-0xd03fffff irq 19 at device 5.0 on pci1 pcib2: at device 4.0 on pci0 pcib0: allocated type 3 (0xd0000000-0xd00fffff) for rid 20 of pcib2 pcib2: domain 0 pcib2: secondary bus 16 pcib2: subordinate bus 16 pcib2: memory decode 0xd0000000-0xd00fffff pcib2: no prefetched decode pcib2: could not get PCI interrupt routing table for \\_SB_.C08B.C24F - AE_NOT_FOUND pci16: on pcib2 pci16: domain=0, physical bus=16 found-> vendor=0x14e4, dev=0x1713, revid=0x02 domain=0, bus=16, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xd0000000, size 16, enabled pcib2: allocated memory range (0xd0000000-0xd000ffff) for rid 10 of pci0:16:0:0 pcib0: matched entry for 0.4.INTA pcib0: slot 4 INTA hardwired to IRQ 16 pcib2: slot 0 INTA is routed to irq 16 bge0: mem 0xd0000000-0xd000ffff irq 16 at device 0.0 on pci16 bge0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 51 bge0: using IRQ 256 for MSI bge0: CHIP ID 0x0000c002; ASIC REV 0x0c; CHIP REV 0xc0; PCI-E miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: OUI 0x0050ef, model 0x0004, rev. 0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow bge0: bpf attached bge0: Ethernet address: 00:1a:4b:89:4b:4e pcib3: at device 5.0 on pci0 pcib0: allocated type 4 (0x2000-0x3fff) for rid 1c of pcib3 pcib0: allocated type 3 (0xcc000000-0xcfffffff) for rid 20 of pcib3 pcib3: domain 0 pcib3: secondary bus 32 pcib3: subordinate bus 32 pcib3: I/O decode 0x2000-0x3fff pcib3: memory decode 0xcc000000-0xcfffffff pcib3: no prefetched decode pcib3: could not get PCI interrupt routing table for \\_SB_.C08B.C254 - AE_NOT_FOUND pci32: on pcib3 pci32: domain=0, physical bus=32 pcib4: at device 6.0 on pci0 pcib0: allocated type 3 (0xc8000000-0xc80fffff) for rid 20 of pcib4 pcib4: domain 0 pcib4: secondary bus 48 pcib4: subordinate bus 48 pcib4: memory decode 0xc8000000-0xc80fffff pcib4: no prefetched decode pcib4: could not get PCI interrupt routing table for \\_SB_.C08B.C25E - AE_NOT_FOUND pci48: on pcib4 pci48: domain=0, physical bus=48 found-> vendor=0x14e4, dev=0x4312, revid=0x02 domain=0, bus=48, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xc8000000, size 14, enabled pcib4: allocated memory range (0xc8000000-0xc8003fff) for rid 10 of pci0:48:0:0 pcib0: matched entry for 0.6.INTA pcib0: slot 6 INTA hardwired to IRQ 18 pcib4: slot 0 INTA is routed to irq 18 siba_bwn0: mem 0xc8000000-0xc8003fff irq 18 at device 0.0 on pci48 siba_bwn0: unsupported coreid (USB 1.1 Host) bwn0 on siba_bwn0 bwn0: WLAN (chipid 0x4311 rev 13) PHY (analog 4 type 2 rev 9) RADIO (manuf 0x17f ver 0x2050 rev 2) bwn0: DMA (64 bits) bwn0: MSI count : 1 siba_bwn0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 257 to local APIC 0 vector 52 siba_bwn0: using IRQ 257 for MSI bwn0: Using 1 MSI messages bwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps bwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ahci0: port 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f mem 0xd0409000-0xd04093ff irq 16 at device 18.0 on pci0 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 53 ahci0: AHCI v1.10 with 4 3Gbps ports, Port Multiplier not supported ahci0: Caps: 64bit NCQ SNTF MPS ALP AL CLO 3Gbps PMD SSC PSC 32cmd CCC 4ports ahci0: Caps2: ahcich0: at channel 0 on ahci0 ahcich0: Caps: ahcich1: not probed (disabled) ahcich2: not probed (disabled) ahcich3: not probed (disabled) ohci0: mem 0xd0401000-0xd0401fff irq 23 at device 19.0 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 54 usbus0 on ohci0 usbus0: bpf attached ohci0: usbpf: Attached ohci1: mem 0xd0402000-0xd0402fff irq 17 at device 19.1 on pci0 ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 0 vector 55 usbus1 on ohci1 usbus1: bpf attached ohci1: usbpf: Attached ohci2: mem 0xd0403000-0xd0403fff irq 17 at device 19.2 on pci0 usbus2 on ohci2 usbus2: bpf attached ohci2: usbpf: Attached ohci3: mem 0xd0404000-0xd0404fff irq 17 at device 19.3 on pci0 usbus3 on ohci3 usbus3: bpf attached ohci3: usbpf: Attached ohci4: mem 0xd0405000-0xd0405fff irq 17 at device 19.4 on pci0 usbus4 on ohci4 usbus4: bpf attached ohci4: usbpf: Attached ehci0: mem 0xd0406000-0xd04060ff irq 23 at device 19.5 on pci0 ehci0: AMD SB600/700 quirk applied ehci0: Dropped interrupts workaround enabled usbus5: EHCI version 1.0 usbus5 on ehci0 usbus5: bpf attached ehci0: usbpf: Attached pci0: at device 20.0 (no driver attached) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x5040-0x504f irq 16 at device 20.1 on pci0 ata0: at channel 0 on atapci0 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 56 hdac0: irq 16 at device 20.2 on pci0 hdac0: HDA Driver Revision: 20120126_0002 hdac0: Config options: on=0x00000000 off=0x00000000 pcib0: allocated type 3 (0xc8100000-0xc8103fff) for rid 10 of hdac0 hdac0: Lazy allocation of 0x4000 bytes rid 0x10 type 3 at 0xc8100000 hdac0: Caps: OSS 4, ISS 4, BSS 0, NSDO 1, 64bit, CORB 256, RIRB 256 isab0: at device 20.3 on pci0 isa0: on isab0 pcib5: at device 20.4 on pci0 pcib0: allocated type 3 (0xd0100000-0xd01fffff) for rid 20 of pcib5 pcib5: domain 0 pcib5: secondary bus 2 pcib5: subordinate bus 3 pcib5: memory decode 0xd0100000-0xd01fffff pcib5: no prefetched decode pcib5: Subtractively decoded bridge. pci2: on pcib5 pci2: domain=0, physical bus=2 found-> vendor=0x1180, dev=0x0476, revid=0xb6 domain=0, bus=2, slot=4, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x80 (32000 ns), maxlat=0x07 (1750 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xd0100000, size 12, enabled pcib5: allocated memory range (0xd0100000-0xd0100fff) for rid 10 of pci0:2:4:0 pcib5: matched entry for 2.4.INTA pcib5: slot 4 INTA hardwired to IRQ 20 cbb0: mem 0xd0100000-0xd0100fff irq 20 at device 4.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 0 vector 57 cbb0: PCI Configuration space: 0x00: 0x04761180 0x02100007 0x060700b6 0x00824000 0x10: 0xd0100000 0x020000dc 0x20030302 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x07000114 0x40: 0x30c2103c 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x30a00001 0x00000000 0x04630463 0x00000000 0x90: 0x00000000 0x00000000 0x00000000 0x00000000 0xa0: 0x00000008 0x00000000 0x00000000 0x00000000 0xb0: 0x00000000 0xbe000000 0x00003000 0x00000000 0xc0: 0x30c2103c 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0xfe0a0001 0xe0: 0x24c04000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 battery0: on acpi0 battery1: on acpi0 acpi_acad0: on acpi0 acpi_button0: on acpi0 acpi_lid0: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 58 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0065 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 59 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3-00, 3 buttons psm0: config:00004000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 acpi0: wakeup code va 0xffffff80cdb77000 pa 0x90000 pcib0: allocated type 3 (0xa0000-0xa07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa0800-0xa0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1000-0xa17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1800-0xa1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2000-0xa27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2800-0xa2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3000-0xa37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3800-0xa3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4000-0xa47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4800-0xa4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5000-0xa57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5800-0xa5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6000-0xa67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6800-0xa6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7000-0xa77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7800-0xa7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8000-0xa87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8800-0xa8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9000-0xa97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9800-0xa9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa000-0xaa7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa800-0xaafff) for rid 0 of orm0 pcib0: allocated type 3 (0xab000-0xab7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xab800-0xabfff) for rid 0 of orm0 pcib0: allocated type 3 (0xac000-0xac7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xac800-0xacfff) for rid 0 of orm0 pcib0: allocated type 3 (0xad000-0xad7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xad800-0xadfff) for rid 0 of orm0 pcib0: allocated type 3 (0xae000-0xae7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xae800-0xaefff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf000-0xaf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf800-0xaffff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1000-0xb17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1800-0xb1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2000-0xb27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2800-0xb2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3000-0xb37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3800-0xb3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4000-0xb47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4800-0xb4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5000-0xb57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5800-0xb5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6000-0xb67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6800-0xb6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7000-0xb77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7800-0xb7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8000-0xb87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8800-0xb8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9000-0xb97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9800-0xb9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xba000-0xba7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xba800-0xbafff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb000-0xbb7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb800-0xbbfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc000-0xbc7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc800-0xbcfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd000-0xbd7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd800-0xbdfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe000-0xbe7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe800-0xbefff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf000-0xbf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf800-0xbffff) for rid 0 of orm0 pcib0: allocated type 3 (0xd3000-0xd37ff) for rid 1 of orm0 pcib0: allocated type 3 (0xd3800-0xd3fff) for rid 1 of orm0 pcib0: allocated type 3 (0xd4000-0xd47ff) for rid 1 of orm0 pcib0: allocated type 3 (0xd4800-0xd4fff) for rid 1 of orm0 pcib0: allocated type 3 (0xd5000-0xd57ff) for rid 1 of orm0 pcib0: allocated type 3 (0xd5800-0xd5fff) for rid 1 of orm0 pcib0: allocated type 3 (0xd6000-0xd67ff) for rid 1 of orm0 pcib0: allocated type 3 (0xd6800-0xd6fff) for rid 1 of orm0 pcib0: allocated type 3 (0xd7000-0xd77ff) for rid 1 of orm0 pcib0: allocated type 3 (0xd7800-0xd7fff) for rid 1 of orm0 pcib0: allocated type 3 (0xd8000-0xd87ff) for rid 1 of orm0 pcib0: allocated type 3 (0xd8800-0xd8fff) for rid 1 of orm0 pcib0: allocated type 3 (0xd9000-0xd97ff) for rid 1 of orm0 pcib0: allocated type 3 (0xd9800-0xd9fff) for rid 1 of orm0 pcib0: allocated type 3 (0xda000-0xda7ff) for rid 1 of orm0 pcib0: allocated type 3 (0xda800-0xdafff) for rid 1 of orm0 pcib0: allocated type 3 (0xdb000-0xdb7ff) for rid 1 of orm0 pcib0: allocated type 3 (0xdb800-0xdbfff) for rid 1 of orm0 pcib0: allocated type 3 (0xdc000-0xdc7ff) for rid 1 of orm0 pcib0: allocated type 3 (0xdc800-0xdcfff) for rid 1 of orm0 pcib0: allocated type 3 (0xdd000-0xdd7ff) for rid 1 of orm0 pcib0: allocated type 3 (0xdd800-0xddfff) for rid 1 of orm0 pcib0: allocated type 3 (0xde000-0xde7ff) for rid 1 of orm0 pcib0: allocated type 3 (0xde800-0xdefff) for rid 1 of orm0 pcib0: allocated type 3 (0xdf000-0xdf7ff) for rid 1 of orm0 pcib0: allocated type 3 (0xdf800-0xdffff) for rid 1 of orm0 isa_probe_children: disabling PnP devices atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it sc: sc0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xd0000-0xd0fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 pcib0: allocated type 4 (0x3c0-0x3df) for rid 0 of vga0 pcib0: allocated type 3 (0xa0000-0xbffff) for rid 0 of vga0 fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 ppc0 failed to probe at irq 7 on isa0 uart0 failed to probe at port 0x3f8 irq 4 on isa0 uart1 failed to probe at port 0x2f8 irq 3 on isa0 wbwd0 failed to probe on isa0 isa_probe_children: probing PnP devices ctl: CAM Target Layer loaded powernow0: on cpu0 powernow1: on cpu1 Device configuration finished. procfs registered lapic: Divisor 2, Frequency 99750271 Hz Timecounters tick every 1.000 msec vlan: initialized, using hash tables with chaining Linux ELF exec handler installed IP Filter: v4.1.28 initialized. Default = block all, Logging = enabled lo0: bpf attached hdacc0: at cad 0 on hdac0 hdacc0: Root Node at nid=0: 1 subnodes 1-1 hdaa0: at nid 1 on hdacc0 hdaa0: Audio Function Group at nid=1: 30 subnodes 2-31 hdaa0: NumGPIO=4 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1 hdaa0: GPIO0: disabled hdaa0: GPIO1: disabled hdaa0: GPIO2: disabled hdaa0: GPIO3: disabled hdaa0: WARNING: nid=2 has cnid outside of the AFG range j=0 entnum=4 index=0 res=0x00000401 hdaa0: Original pins configuration: hdaa0: nid 0x as seq device conn jack loc color misc hdaa0: 5 92174110 1 0 Speaker Fixed Analog 0x12 Green 1 hdaa0: 6 0421201f 1 15 Headphones Jack 1/8 Right Grey 0 hdaa0: 7 410710f0 15 0 Line-out None Analog Rear Black 0 hdaa0: 8 04a12020 2 0 Mic Jack 1/8 Right Grey 0 hdaa0: 9 0181302e 2 14 Line-in Jack 1/8 Rear Blue 0 hdaa0: 10 4145f0f0 15 0 SPDIF-out None Optical Rear Other 0 hdaa0: 22 995711f0 15 0 Digital-out Fixed Analog Onboard Black 1 hdaa0: 23 5993e0f0 15 0 AUX None ATAPI Onboard White 0 hdaa0: 24 f0a79159 5 9 Mic Both Analog Other Pink 1 hdaa0: 25 593310f0 15 0 CD None ATAPI Onboard Black 0 hdaa0: Patched pins configuration: hdaa0: nid 0x as seq device conn jack loc color misc hdaa0: 5 92174110 1 0 Speaker Fixed Analog 0x12 Green 1 hdaa0: 6 0421201f 1 15 Headphones Jack 1/8 Right Grey 0 hdaa0: 7 410710f0 15 0 Line-out None Analog Rear Black 0 DISA hdaa0: 8 04a12020 2 0 Mic Jack 1/8 Right Grey 0 hdaa0: 9 0181302e 2 14 Line-in Jack 1/8 Rear Blue 0 hdaa0: 10 4145f0f0 15 0 SPDIF-out None Optical Rear Other 0 DISA hdaa0: 22 995711f0 15 0 Digital-out Fixed Analog Onboard Black 1 hdaa0: 23 5993e0f0 15 0 AUX None ATAPI Onboard White 0 DISA hdaa0: 24 f0a79159 5 9 Mic Both Analog Other Pink 1 hdaa0: 25 593310f0 15 0 CD None ATAPI Onboard Black 0 DISA hdaa0: 4 associations found: hdaa0: Association 0 (1) out: hdaa0: Pin nid=5 seq=0 hdaa0: Pin nid=6 seq=15 hdaa0: Association 1 (2) in: hdaa0: Pin nid=8 seq=0 hdaa0: Pin nid=9 seq=14 hdaa0: Association 2 (5) in: hdaa0: Pin nid=24 seq=9 hdaa0: Association 3 (15) out: hdaa0: Pin nid=22 seq=0 hdaa0: Tracing association 0 (1) hdaa0: Pin 5 traced to DAC 3 hdaa0: Pin 6 traced to DAC 3 and hpredir 0 hdaa0: Association 0 (1) trace succeeded hdaa0: Tracing association 1 (2) hdaa0: Pin 8 traced to ADC 4 hdaa0: Pin 9 traced to ADC 4 hdaa0: Association 1 (2) trace succeeded hdaa0: Tracing association 2 (5) hdaa0: Association 2 (5) trace failed hdaa0: Tracing association 3 (15) hdaa0: Unable to trace pin 22 seq 0 with min nid 0 hdaa0: Association 3 (15) trace failed hdaa0: Looking for additional DAC for association 0 (1) hdaa0: Looking for additional ADC for association 1 (2) hdaa0: Tracing input monitor hdaa0: Tracing nid 12 to out hdaa0: Tracing other input monitors hdaa0: Tracing nid 8 to out hdaa0: nid 8 is input monitor hdaa0: Tracing nid 9 to out hdaa0: nid 9 is input monitor hdaa0: Tracing beeper hdaa0: nid 16 traced to out hdaa0: Headphones redirection for association 0 nid=6 using unsolicited responses. hdaa0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref hdaa0: hdaa0: +-------------------+ hdaa0: | DUMPING HDA NODES | hdaa0: +-------------------+ hdaa0: hdaa0: Default Parameter hdaa0: ----------------- hdaa0: Stream cap: 0x00000001 hdaa0: PCM hdaa0: PCM cap: 0x000e007f hdaa0: 16 20 24 bits, 8 11 16 22 32 44 48 KHz hdaa0: IN amp: 0x00270300 hdaa0: OUT amp: 0x80053f3d hdaa0: hdaa0: nid: 2 [DISABLED] hdaa0: Name: audio output hdaa0: Widget cap: 0x00030311 hdaa0: DIGITAL STEREO hdaa0: Stream cap: 0x00000005 hdaa0: AC3 PCM hdaa0: PCM cap: 0x00020060 hdaa0: 16 bits, 44 48 KHz hdaa0: connections: 2 hdaa0: | hdaa0: + [DISABLED] <- nid=1 [GHOST!] [UNKNOWN] (selected) hdaa0: + <- nid=4 [audio input] hdaa0: hdaa0: nid: 3 hdaa0: Name: audio output hdaa0: Widget cap: 0x00000441 hdaa0: PWR PROC STEREO hdaa0: Association: 0 (0x00008001) hdaa0: OSS: pcm (pcm) hdaa0: Stream cap: 0x00000001 hdaa0: PCM hdaa0: PCM cap: 0x000e007f hdaa0: 16 20 24 bits, 8 11 16 22 32 44 48 KHz hdaa0: hdaa0: nid: 4 hdaa0: Name: audio input hdaa0: Widget cap: 0x00100511 hdaa0: PWR STEREO hdaa0: Association: 1 (0x00004001) hdaa0: Stream cap: 0x00000001 hdaa0: PCM hdaa0: PCM cap: 0x0006007f hdaa0: 16 20 bits, 8 11 16 22 32 44 48 KHz hdaa0: connections: 1 hdaa0: | hdaa0: + <- nid=21 [audio selector] hdaa0: hdaa0: nid: 5 hdaa0: Name: pin: Speaker (Fixed) hdaa0: Widget cap: 0x00400187 hdaa0: UNSOL STEREO hdaa0: Association: 0 (0x00000001) hdaa0: Pin cap: 0x0001173f hdaa0: ISC TRQD PDC HP OUT IN VREF[ 50 80 GROUND HIZ ] EAPD hdaa0: Pin config: 0x92174110 hdaa0: Pin control: 0x00000040 OUT hdaa0: EAPD: 0x00000002 hdaa0: Output amp: 0x80053f3d hdaa0: mute=1 step=63 size=5 offset=61 hdaa0: Input amp: 0x00270300 hdaa0: mute=0 step=3 size=39 offset=0 hdaa0: connections: 2 hdaa0: | hdaa0: + [DISABLED] <- nid=3 [audio output] hdaa0: + <- nid=14 [audio mixer] (selected) hdaa0: hdaa0: nid: 6 hdaa0: Name: pin: Headphones (Grey Jack) hdaa0: Widget cap: 0x00400185 hdaa0: UNSOL STEREO hdaa0: Association: 0 (0x00008000) hdaa0: Pin cap: 0x0000001f hdaa0: ISC TRQD PDC HP OUT hdaa0: Pin config: 0x0421201f hdaa0: Pin control: 0x000000c0 HP OUT hdaa0: Output amp: 0x80053f3d hdaa0: mute=1 step=63 size=5 offset=61 hdaa0: connections: 2 hdaa0: | hdaa0: + [DISABLED] <- nid=3 [audio output] hdaa0: + <- nid=14 [audio mixer] (selected) hdaa0: hdaa0: nid: 7 [DISABLED] hdaa0: Name: pin: Line-out (None) hdaa0: Widget cap: 0x00400104 hdaa0: Pin cap: 0x00000010 hdaa0: OUT hdaa0: Pin config: 0x410710f0 hdaa0: Pin control: 0x00000000 hdaa0: Output amp: 0x80053f3d hdaa0: mute=1 step=63 size=5 offset=61 hdaa0: connections: 1 hdaa0: | hdaa0: + [DISABLED] <- nid=15 [audio mixer] [DISABLED] hdaa0: hdaa0: nid: 8 hdaa0: Name: pin: Mic (Grey Jack) hdaa0: Widget cap: 0x00400083 hdaa0: UNSOL STEREO hdaa0: Association: 1 (0x00000001) hdaa0: OSS: mic (mic) hdaa0: Pin cap: 0x00001727 hdaa0: ISC TRQD PDC IN VREF[ 50 80 GROUND HIZ ] hdaa0: Pin config: 0x04a12020 hdaa0: Pin control: 0x00000024 IN VREFs hdaa0: Input amp: 0x00270300 hdaa0: mute=0 step=3 size=39 offset=0 hdaa0: hdaa0: nid: 9 hdaa0: Name: pin: Line-in (Blue Jack) hdaa0: Widget cap: 0x00400187 hdaa0: UNSOL STEREO hdaa0: Association: 1 (0x00004000) hdaa0: OSS: line (line) hdaa0: Pin cap: 0x00001737 hdaa0: ISC TRQD PDC OUT IN VREF[ 50 80 GROUND HIZ ] hdaa0: Pin config: 0x0181302e hdaa0: Pin control: 0x00000024 IN VREFs hdaa0: Output amp: 0x80053f3d hdaa0: mute=1 step=63 size=5 offset=61 hdaa0: Input amp: 0x00270300 hdaa0: mute=0 step=3 size=39 offset=0 hdaa0: connections: 2 hdaa0: | hdaa0: + [DISABLED] <- nid=3 [audio output] (selected) hdaa0: + [DISABLED] <- nid=14 [audio mixer] hdaa0: hdaa0: nid: 10 [DISABLED] hdaa0: Name: pin: SPDIF-out (None) hdaa0: Widget cap: 0x00400301 hdaa0: DIGITAL STEREO hdaa0: Pin cap: 0x00000010 hdaa0: OUT hdaa0: Pin config: 0x4145f0f0 hdaa0: Pin control: 0x00000000 hdaa0: connections: 1 hdaa0: | hdaa0: + <- nid=2 [audio output] [DISABLED] hdaa0: hdaa0: nid: 11 [DISABLED] hdaa0: Name: audio selector hdaa0: Widget cap: 0x00300101 hdaa0: STEREO hdaa0: connections: 6 hdaa0: | hdaa0: + <- nid=3 [audio output] (selected) hdaa0: + <- nid=12 [audio mixer] hdaa0: + <- nid=9 [pin: Line-in (Blue Jack)] hdaa0: + <- nid=14 [audio mixer] hdaa0: + <- nid=5 [pin: Speaker (Fixed)] hdaa0: + <- nid=24 [pin: Mic (Both)] [DISABLED] hdaa0: hdaa0: nid: 12 hdaa0: Name: audio mixer hdaa0: Widget cap: 0x00200101 hdaa0: STEREO hdaa0: Association: 1 (0x00000001) hdaa0: OSS: mic hdaa0: connections: 2 hdaa0: | hdaa0: + <- nid=30 [audio selector] hdaa0: + [DISABLED] <- nid=31 [audio selector] [DISABLED] hdaa0: hdaa0: nid: 13 hdaa0: Name: audio selector hdaa0: Widget cap: 0x0030010c hdaa0: Association: -2 (0x00000000) hdaa0: OSS: speaker hdaa0: Output amp: 0x800b0f0f hdaa0: mute=1 step=15 size=11 offset=15 hdaa0: connections: 2 hdaa0: | hdaa0: + <- nid=16 [beep widget] (selected) hdaa0: + [DISABLED] <- nid=22 [pin: Digital-out (Fixed)] [DISABLED] hdaa0: hdaa0: nid: 14 hdaa0: Name: audio mixer hdaa0: Widget cap: 0x00200101 hdaa0: STEREO hdaa0: Association: 0 (0x00008001) hdaa0: OSS: pcm, speaker, line, mic hdaa0: connections: 8 hdaa0: | hdaa0: + <- nid=13 [audio selector] hdaa0: + <- nid=17 [audio selector] hdaa0: + <- nid=18 [audio selector] hdaa0: + <- nid=19 [audio selector] hdaa0: + [DISABLED] <- nid=26 [audio selector] [DISABLED] hdaa0: + [DISABLED] <- nid=27 [audio selector] [DISABLED] hdaa0: + [DISABLED] <- nid=28 [audio selector] [DISABLED] hdaa0: + [DISABLED] <- nid=29 [audio selector] [DISABLED] hdaa0: hdaa0: nid: 15 [DISABLED] hdaa0: Name: audio mixer hdaa0: Widget cap: 0x00200100 hdaa0: connections: 1 hdaa0: | hdaa0: + <- nid=11 [audio selector] [DISABLED] hdaa0: hdaa0: nid: 16 hdaa0: Name: beep widget hdaa0: Widget cap: 0x00700000 hdaa0: Association: -2 (0x00000000) hdaa0: OSS: speaker (speaker) hdaa0: hdaa0: nid: 17 hdaa0: Name: audio selector hdaa0: Widget cap: 0x0030010d hdaa0: STEREO hdaa0: Association: 0 (0x00008001) hdaa0: OSS: pcm hdaa0: Output amp: 0x80051f17 hdaa0: mute=1 step=31 size=5 offset=23 hdaa0: connections: 1 hdaa0: | hdaa0: + <- nid=3 [audio output] hdaa0: hdaa0: nid: 18 hdaa0: Name: audio selector hdaa0: Widget cap: 0x0030010d hdaa0: STEREO hdaa0: Association: -2 (0x00000000) hdaa0: OSS: mic hdaa0: Output amp: 0x80051f17 hdaa0: mute=1 step=31 size=5 offset=23 hdaa0: connections: 1 hdaa0: | hdaa0: + <- nid=8 [pin: Mic (Grey Jack)] hdaa0: hdaa0: nid: 19 hdaa0: Name: audio selector hdaa0: Widget cap: 0x0030010d hdaa0: STEREO hdaa0: Association: -2 (0x00000000) hdaa0: OSS: line hdaa0: Output amp: 0x80051f17 hdaa0: mute=1 step=31 size=5 offset=23 hdaa0: connections: 1 hdaa0: | hdaa0: + <- nid=9 [pin: Line-in (Blue Jack)] hdaa0: hdaa0: nid: 20 [DISABLED] hdaa0: Name: power widget hdaa0: Widget cap: 0x00500500 hdaa0: PWR hdaa0: connections: 13 hdaa0: | hdaa0: + <- nid=13 [audio selector] (selected) hdaa0: + <- nid=14 [audio mixer] hdaa0: + <- nid=15 [audio mixer] [DISABLED] hdaa0: + <- nid=16 [beep widget] hdaa0: + <- nid=19 [audio selector] hdaa0: + <- nid=20 [power widget] [DISABLED] hdaa0: + <- nid=21 [audio selector] hdaa0: + <- nid=22 [pin: Digital-out (Fixed)] [DISABLED] hdaa0: + <- nid=23 [pin: AUX (None)] [DISABLED] hdaa0: + <- nid=24 [pin: Mic (Both)] [DISABLED] hdaa0: + <- nid=25 [pin: CD (None)] [DISABLED] hdaa0: + <- nid=26 [audio selector] [DISABLED] hdaa0: + <- nid=29 [audio selector] [DISABLED] hdaa0: hdaa0: nid: 21 hdaa0: Name: audio selector hdaa0: Widget cap: 0x0030010d hdaa0: STEREO hdaa0: Association: 1 (0x00004001) hdaa0: OSS: line, mic hdaa0: Output amp: 0x80050f00 hdaa0: mute=1 step=15 size=5 offset=0 hdaa0: connections: 8 hdaa0: | hdaa0: + <- nid=12 [audio mixer] hdaa0: + <- nid=9 [pin: Line-in (Blue Jack)] (selected) hdaa0: + [DISABLED] <- nid=14 [audio mixer] hdaa0: + [DISABLED] <- nid=15 [audio mixer] [DISABLED] hdaa0: + [DISABLED] <- nid=25 [pin: CD (None)] [DISABLED] hdaa0: + [DISABLED] <- nid=5 [pin: Speaker (Fixed)] hdaa0: + [DISABLED] <- nid=24 [pin: Mic (Both)] [DISABLED] hdaa0: + [DISABLED] <- nid=23 [pin: AUX (None)] [DISABLED] hdaa0: hdaa0: nid: 22 [DISABLED] hdaa0: Name: pin: Digital-out (Fixed) hdaa0: Widget cap: 0x00400000 hdaa0: Pin cap: 0x00000020 hdaa0: IN hdaa0: Pin config: 0x995711f0 hdaa0: Pin control: 0x00000000 hdaa0: hdaa0: nid: 23 [DISABLED] hdaa0: Name: pin: AUX (None) hdaa0: Widget cap: 0x00400081 hdaa0: UNSOL STEREO hdaa0: Pin cap: 0x00000027 hdaa0: ISC TRQD PDC IN hdaa0: Pin config: 0x5993e0f0 hdaa0: Pin control: 0x00000000 hdaa0: hdaa0: nid: 24 [DISABLED] hdaa0: Name: pin: Mic (Both) hdaa0: Widget cap: 0x00400187 hdaa0: UNSOL STEREO hdaa0: Pin cap: 0x00001737 hdaa0: ISC TRQD PDC OUT IN VREF[ 50 80 GROUND HIZ ] hdaa0: Pin config: 0xf0a79159 hdaa0: Pin control: 0x00000000 hdaa0: Output amp: 0x80053f3d hdaa0: mute=1 step=63 size=5 offset=61 hdaa0: Input amp: 0x00270300 hdaa0: mute=0 step=3 size=39 offset=0 hdaa0: connections: 2 hdaa0: | hdaa0: + [DISABLED] <- nid=3 [audio output] (selected) hdaa0: + <- nid=14 [audio mixer] hdaa0: hdaa0: nid: 25 [DISABLED] hdaa0: Name: pin: CD (None) hdaa0: Widget cap: 0x00400001 hdaa0: STEREO hdaa0: Pin cap: 0x00000020 hdaa0: IN hdaa0: Pin config: 0x593310f0 hdaa0: Pin control: 0x00000000 hdaa0: hdaa0: nid: 26 [DISABLED] hdaa0: Name: audio selector hdaa0: Widget cap: 0x0030010d hdaa0: STEREO hdaa0: Output amp: 0x80051f17 hdaa0: mute=1 step=31 size=5 offset=23 hdaa0: connections: 1 hdaa0: | hdaa0: + <- nid=5 [pin: Speaker (Fixed)] hdaa0: hdaa0: nid: 27 [DISABLED] hdaa0: Name: audio selector hdaa0: Widget cap: 0x0030010d hdaa0: STEREO hdaa0: Output amp: 0x80051f17 hdaa0: mute=1 step=31 size=5 offset=23 hdaa0: connections: 1 hdaa0: | hdaa0: + [DISABLED] <- nid=23 [pin: AUX (None)] [DISABLED] hdaa0: hdaa0: nid: 28 [DISABLED] hdaa0: Name: audio selector hdaa0: Widget cap: 0x0030010d hdaa0: STEREO hdaa0: Output amp: 0x80051f17 hdaa0: mute=1 step=31 size=5 offset=23 hdaa0: connections: 1 hdaa0: | hdaa0: + <- nid=24 [pin: Mic (Both)] [DISABLED] hdaa0: hdaa0: nid: 29 [DISABLED] hdaa0: Name: audio selector hdaa0: Widget cap: 0x0030010d hdaa0: STEREO hdaa0: Output amp: 0x80051f17 hdaa0: mute=1 step=31 size=5 offset=23 hdaa0: connections: 1 hdaa0: | hdaa0: + [DISABLED] <- nid=25 [pin: CD (None)] [DISABLED] hdaa0: hdaa0: nid: 30 hdaa0: Name: audio selector hdaa0: Widget cap: 0x0030010d hdaa0: STEREO hdaa0: Association: 1 (0x00000001) hdaa0: OSS: mic hdaa0: Output amp: 0x80000000 hdaa0: mute=1 step=0 size=0 offset=0 hdaa0: connections: 1 hdaa0: | hdaa0: + <- nid=8 [pin: Mic (Grey Jack)] hdaa0: hdaa0: nid: 31 [DISABLED] hdaa0: Name: audio selector hdaa0: Widget cap: 0x0030010d hdaa0: STEREO hdaa0: Output amp: 0x80000000 hdaa0: mute=1 step=0 size=0 offset=0 hdaa0: connections: 1 hdaa0: | hdaa0: + <- nid=24 [pin: Mic (Both)] [DISABLED] hdaa0: pcm0: at nid 5,6 and 8,9 on hdaa0 pcm0: +--------------------------------------+ pcm0: | DUMPING PCM Playback/Record Channels | pcm0: +--------------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: Stream cap: 0x00000001 pcm0: PCM pcm0: PCM cap: 0x000e007f pcm0: 16 20 24 bits, 8 11 16 22 32 44 48 KHz pcm0: DAC: 3 pcm0: pcm0: Record: pcm0: pcm0: Stream cap: 0x00000001 pcm0: PCM pcm0: PCM cap: 0x0006007f pcm0: 16 20 bits, 8 11 16 22 32 44 48 KHz pcm0: DAC: 4 pcm0: pcm0: +-------------------------------+ pcm0: | DUMPING Playback/Record Paths | pcm0: +-------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: nid=5 [pin: Speaker (Fixed)] pcm0: | pcm0: + <- nid=14 [audio mixer] [src: pcm, speaker, line, mic] pcm0: | pcm0: + <- nid=13 [audio selector] [src: speaker] pcm0: | pcm0: + <- nid=16 [beep widget] [src: speaker] pcm0: + <- nid=17 [audio selector] [src: pcm] pcm0: | pcm0: + <- nid=3 [audio output] [src: pcm] pcm0: + <- nid=18 [audio selector] [src: mic] pcm0: | pcm0: + <- nid=8 [pin: Mic (Grey Jack)] [src: mic] pcm0: + <- nid=19 [audio selector] [src: line] pcm0: | pcm0: + <- nid=9 [pin: Line-in (Blue Jack)] [src: line] pcm0: pcm0: nid=6 [pin: Headphones (Grey Jack)] pcm0: | pcm0: + <- nid=14 [audio mixer] [src: pcm, speaker, line, mic] pcm0: | pcm0: + <- nid=13 [audio selector] [src: speaker] pcm0: | pcm0: + <- nid=16 [beep widget] [src: speaker] pcm0: + <- nid=17 [audio selector] [src: pcm] pcm0: | pcm0: + <- nid=3 [audio output] [src: pcm] pcm0: + <- nid=18 [audio selector] [src: mic] pcm0: | pcm0: + <- nid=8 [pin: Mic (Grey Jack)] [src: mic] pcm0: + <- nid=19 [audio selector] [src: line] pcm0: | pcm0: + <- nid=9 [pin: Line-in (Blue Jack)] [src: line] pcm0: pcm0: Record: pcm0: pcm0: nid=4 [audio input] pcm0: | pcm0: + <- nid=21 [audio selector] [src: line, mic] pcm0: | pcm0: + <- nid=12 [audio mixer] [src: mic] pcm0: | pcm0: + <- nid=30 [audio selector] [src: mic] pcm0: | pcm0: + <- nid=8 [pin: Mic (Grey Jack)] [src: mic] pcm0: + <- nid=9 [pin: Line-in (Blue Jack)] [src: line] pcm0: pcm0: +-------------------------+ pcm0: | DUMPING Volume Controls | pcm0: +-------------------------+ pcm0: pcm0: Master Volume (OSS: vol): -91/3dB pcm0: | pcm0: +- ctl 1 (nid 5 in ): -91/3dB (64 steps) + mute pcm0: +- ctl 3 (nid 6 in ): -91/3dB (64 steps) + mute pcm0: +- ctl 8 (nid 13 out): -45/0dB (16 steps) + mute pcm0: +- ctl 9 (nid 17 out): -34/12dB (32 steps) + mute pcm0: +- ctl 10 (nid 18 out): -34/12dB (32 steps) + mute pcm0: +- ctl 11 (nid 19 out): -34/12dB (32 steps) + mute pcm0: pcm0: PCM Volume (OSS: pcm): -34/12dB pcm0: | pcm0: +- ctl 9 (nid 17 out): -34/12dB (32 steps) + mute pcm0: pcm0: Microphone Volume (OSS: mic): 0/30dB pcm0: | pcm0: +- ctl 5 (nid 8 out): 0/30dB (4 steps) pcm0: +- ctl 10 (nid 18 out): -34/12dB (32 steps) + mute pcm0: +- ctl 12 (nid 21 out): 0/22dB (16 steps) + mute pcm0: +- ctl 19 (nid 30 out): mute pcm0: pcm0: Line-in Volume (OSS: line): 0/30dB pcm0: | pcm0: +- ctl 7 (nid 9 out): 0/30dB (4 steps) pcm0: +- ctl 11 (nid 19 out): -34/12dB (32 steps) + mute pcm0: +- ctl 12 (nid 21 out): 0/22dB (16 steps) + mute pcm0: pcm0: Speaker/Beep Volume (OSS: speaker): -45/0dB pcm0: | pcm0: +- ctl 8 (nid 13 out): -45/0dB (16 steps) + mute pcm0: pcm0: Recording Level (OSS: rec): 0/22dB pcm0: | pcm0: +- ctl 12 (nid 21 out): 0/22dB (16 steps) + mute pcm0: +- ctl 19 (nid 30 out): mute pcm0: pcm0: Input Monitoring Level (OSS: igain): -34/0dB pcm0: | pcm0: +- ctl 8 (nid 13 out): -45/0dB (16 steps) + mute pcm0: +- ctl 10 (nid 18 out): -34/12dB (32 steps) + mute pcm0: +- ctl 11 (nid 19 out): -34/12dB (32 steps) + mute pcm0: pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "line": pcm0: Mixer "mic": pcm0: Mixer "rec": pcm0: Mixer "igain": pcm0: Mixer "ogain": pcm0: clone manager: deadline=750ms flags=0x8000001e pcm0: sndbuf_setmap 4ac0000, 10000; 0xffffff80cdb94000 -> 4ac0000 pcm0: sndbuf_setmap 6b80000, 10000; 0xffffff80cdbd4000 -> 6b80000 hdacc1: at cad 1 on hdac0 hdacc1: Root Node at nid=0: 1 subnodes 1-1 unknown: at nid 1 on hdacc1 (no driver attached) usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 480Mbps High Speed USB v2.0 acpi_tz0: _AC3: temperature 56.0 >= setpoint 40.0 acpi_tz0: _AC2: temperature 56.0 >= setpoint 50.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 acpi_tz0: switched from NONE to _AC2: 56.0C ahcich0: AHCI reset... ahcich0: SATA connect time=1800us status=00000113 ahcich0: AHCI reset: device found ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ahcich0: AHCI reset: device ready after 100ms (aprobe0:ahcich0:0:0:0): SIGNATURE: 0000 ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=00 stat1=00 devices=0x10000 (aprobe1:ata0:0:0:0): SIGNATURE: eb14 battery0: battery initialization start battery1: battery initialization start acpi_acad0: acline initialization start acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times acpi_tz0: _AC3: temperature 56.0 >= setpoint 40.0 acpi_tz0: _AC3: temperature 56.0 >= setpoint 40.0 battery0: battery initialization done, tried 1 times uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered (probe0:ctl2cam0:0:1:0): Error 6, Unretryable error ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 GEOM: new disk cd0 GEOM: new disk ada0 ada0: ATA-7 SATA 1.x device ada0: Serial Number 5MA83WKD ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) (cd0:ata0:0:0:0): Error 6, Unretryable error cd0 at ata0 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: Serial Number HE58 101390 cd0: 16.700MB/s transfers (WDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed PIO 8192bytes) ada0: 152627MB (312581808 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 pass0: ATA-7 SATA 1.x device pass0: Serial Number 5MA83WKD pass0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) pass1 at ata0 bus 0 scbus1 target 0 lun 0 pass1: Removable CD-ROM SCSI-0 device pass1: Serial Number HE58 101390 pass1: 16.700MB/s transfers (WDMA2, ATAPI 12bytes, PIO 65534bytes) (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) (cd0:ata0:0:0:0): Error 6, Unretryable error SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 1 vector 48 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 1 vector 49 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 1 vector 50 ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 1 vector 51 msi: Assigning MSI IRQ 256 to local APIC 1 vector 52 TSC timecounter discards lower 7 bit(s) Timecounter "TSC-low" frequency 15586288 Hz quality -100 WARNING: WITNESS option enabled, expect reduced performance. (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) (cd0:ata0:0:0:0): Error 6, Unretryable error (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) (cd0:ata0:0:0:0): Error 6, Unretryable error Root mount waiting for: usbus5 Root mount waiting for: usbus5 Root mount waiting for: usbus5 Root mount waiting for: usbus5 uhub5: 10 ports with 10 removable, self powered Root mount waiting for: usbus5 Trying to mount root from ufs:/dev/ada0s1a [rw]... start_init: trying /sbin/init ugen0.2: at usbus0 ugen1.2: at usbus1 ums0: on usbus1 ums0: 3 buttons and [XY] coordinates ID=0 acpi_tz0: _AC3: temperature 51.0 >= setpoint 40.0 wlan0: bpf attached wlan0: bpf attached wlan0: Ethernet address: 00:1a:73:e1:46:79 bwn0: firmware version (rev 410 patch 2160 date 0x751a time 0x7c0a) bwn0: status of RF switch is changed to OFF bwn0: please turn on the RF switch bwn0: need multicast update callback bwn0: RX decryption attempted (old 0 keyidx 0x2) bwn0: need multicast update callback bwn0: need multicast update callback bwn0: RX decryption attempted (old 0 keyidx 0x2) # devinfo -u Interrupt request lines: 0 (attimer0) 1 (atkbdc0) 3-7 (root0) 8 (atrtc0) 9 (acpi0) 10-11 (root0) 12 (psm0) 13 (root0) 14 (ata0) 15 (root0) 16 (hdac0) 16 (ahci0) 17 (ohci4) 17 (ohci3) 17 (ohci2) 17 (ohci1) 18-19 (root0) 20 (cbb0) 21-22 (root0) 23 (ehci0) 23 (ohci0) 256 (bge0) 257 (siba_bwn0) DMA request lines: 0-3 (root0) 4 (atdma0) 5-7 (root0) I/O ports: 0x0-0xf (atdma0) 0x10-0x1f (root0) 0x20-0x21 ---- 0x22-0x3f (root0) 0x40-0x43 (attimer0) 0x44-0x5f (root0) 0x60 (atkbdc0) 0x61 ---- 0x62 (acpi_ec0) 0x63 (root0) 0x64 (atkbdc0) 0x65 (root0) 0x66 (acpi_ec0) 0x67-0x6f (root0) 0x70-0x71 (atrtc0) 0x72-0x73 (atrtc0) 0x74-0x7f (root0) 0x80-0x8f (atdma0) 0x90-0x9f (root0) 0xa0-0xa1 ---- 0xa2-0xbf (root0) 0xc0-0xdf (atdma0) 0xe0-0xef (root0) 0xf0-0xff (fpupnp0) 0x100-0x16f (root0) 0x170-0x177 (atapci0) 0x178-0x1ef (root0) 0x1f0-0x1f7 (atapci0) 0x1f8-0x375 (root0) 0x376 (atapci0) 0x377-0x3bf (root0) 0x3c0-0x3df (vga0) 0x3e0-0x3f5 (root0) 0x3f6 (atapci0) 0x3f7-0xcf7 (root0) 0xcf8-0xcff (pcib0) 0xd00-0x1fff (root0) 0x2000-0x3fff (pcib3) 0x4000-0x4fff (pcib1) 0x5000-0x5017 (root0) 0x5018-0x501b (ahci0) 0x501c-0x501f (root0) 0x5020-0x502f (ahci0) 0x5030-0x503f (root0) 0x5040-0x504f (atapci0) 0x5050-0x8007 (root0) 0x8008-0x800b (acpi_timer0) 0x800c-0x81ff (root0) 0x8200-0x820f ---- 0x8210-0x8fff (root0) 0x9000-0x9007 (ahci0) 0x9008-0x900b (ahci0) 0x900c-0x900f (root0) 0x9010-0x9017 (ahci0) 0x9018-0xffff (root0) I/O memory addresses: 0x0-0x9fbff (ram0) 0x9fc00-0x9ffff (root0) 0xa0000-0xbffff (vga0) 0xc0000-0xcffff (root0) 0xd0000-0xd0fff (orm0) 0xd1000-0xfffff (root0) 0x100000-0xb7faffff (ram0) 0xb7fb0000-0xbfffffff (root0) 0xc0000000-0xc7ffffff (pcib1) 0xc8000000-0xc80fffff (pcib4) 0xc8100000-0xc8103fff (hdac0) 0xc8104000-0xcbffffff (root0) 0xcc000000-0xcfffffff (pcib3) 0xd0000000-0xd00fffff (pcib2) 0xd0100000-0xd01fffff (pcib5) 0xd0200000-0xd03fffff (pcib1) 0xd0400000-0xd0400fff (root0) 0xd0401000-0xd0401fff (ohci0) 0xd0402000-0xd0402fff (ohci1) 0xd0403000-0xd0403fff (ohci2) 0xd0404000-0xd0404fff (ohci3) 0xd0405000-0xd0405fff (ohci4) 0xd0406000-0xd04060ff (ehci0) 0xd0406100-0xd0408fff (root0) 0xd0409000-0xd04093ff (ahci0) 0xd0409400-0xfebfffff (root0) 0xfec00000-0xfec0001f (apic0) 0xfec00020-0xfedfffff (root0) 0xfee00000-0xfee003ff (apic0) 0xfee00400-0xffffffffffffffff (root0) ACPI I/O ports: ACPI I/O memory addresses: pcib1 I/O port window: 0x4000-0x40ff (vgapci0) 0x4100-0x4fff (root0) pcib1 memory window: 0xd0200000-0xd020ffff (vgapci0) 0xd0210000-0xd02fffff (root0) 0xd0300000-0xd03fffff (vgapci0) pcib1 prefetch window: 0xc0000000-0xc7ffffff (vgapci0) pcib2 I/O port window: pcib2 memory window: 0xd0000000-0xd000ffff (bge0) 0xd0010000-0xd00fffff (root0) pcib2 prefetch window: pcib3 I/O port window: 0x2000-0x3fff (root0) pcib3 memory window: 0xcc000000-0xcfffffff (root0) pcib3 prefetch window: pcib4 I/O port window: pcib4 memory window: 0xc8000000-0xc8003fff (siba_bwn0) 0xc8004000-0xc80fffff (root0) pcib4 prefetch window: I/O memory addresses: 0xd0409000-0xd04090ff (root0) 0xd0409100-0xd040917f (ahcich0) 0xd0409180-0xd04093ff (root0) pcib5 I/O port window: pcib5 memory window: 0xd0100000-0xd0100fff (cbb0) 0xd0101000-0xd01fffff (root0) pcib5 prefetch window: -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Wed May 16 09:11:33 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2AB1106566B for ; Wed, 16 May 2012 09:11:32 +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 2A1DA8FC12 for ; Wed, 16 May 2012 09:11:31 +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 MAA21846 for ; Wed, 16 May 2012 12:11:30 +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 1SUaGY-000O1n-9J for freebsd-current@FreeBSD.org; Wed, 16 May 2012 12:11:30 +0300 Message-ID: <4FB36F41.9070101@FreeBSD.org> Date: Wed, 16 May 2012 12:11: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: FreeBSD-Current X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: Subject: wdog_kern_pat: liberate from SW_WATCHDOG X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 09:11:33 -0000 I would like to commit something like the following patch. I think that in-kernel watchdog patting during crash dump is useful with hardware watchdogs too. The code seems to work fine here. In fact, I am not sure why wdog_kern_pat was originally tied to SW_WATCHDOG. commit 59329ca52f5e25266772f157e0640628b223d305 Author: Andriy Gapon Date: Fri Nov 25 09:59:53 2011 +0200 [test] kernel watchdog patting makes sense with hardware watchdogs too diff --git a/sys/amd64/amd64/minidump_machdep.c b/sys/amd64/amd64/minidump_machdep.c index 057d81d..9be642e 100644 --- a/sys/amd64/amd64/minidump_machdep.c +++ b/sys/amd64/amd64/minidump_machdep.c @@ -37,9 +37,7 @@ __FBSDID("$FreeBSD$"); #include #include #include -#ifdef SW_WATCHDOG #include -#endif #include #include #include @@ -177,9 +175,9 @@ blk_write report_progress(progress, dumpsize); counter &= (1<<24) - 1; } -#ifdef SW_WATCHDOG + wdog_kern_pat(WD_LASTVAL); -#endif + if (ptr) { error = dump_write(di, ptr, 0, dumplo, len); if (error) diff --git a/sys/i386/i386/minidump_machdep.c b/sys/i386/i386/minidump_machdep.c index d57de3a..e0cd1ff 100644 --- a/sys/i386/i386/minidump_machdep.c +++ b/sys/i386/i386/minidump_machdep.c @@ -36,9 +36,7 @@ __FBSDID("$FreeBSD$"); #include #include #include -#ifdef SW_WATCHDOG #include -#endif #include #include #include @@ -143,9 +141,9 @@ blk_write printf(" %lld", PG2MB(progress >> PAGE_SHIFT)); counter &= (1<<24) - 1; } -#ifdef SW_WATCHDOG + wdog_kern_pat(WD_LASTVAL); -#endif + if (ptr) { error = dump_write(di, ptr, 0, dumplo, len); if (error) diff --git a/sys/kern/kern_shutdown.c b/sys/kern/kern_shutdown.c index 2f7a391..54eca2a 100644 --- a/sys/kern/kern_shutdown.c +++ b/sys/kern/kern_shutdown.c @@ -66,9 +66,7 @@ __FBSDID("$FreeBSD$"); #include #include #include -#ifdef SW_WATCHDOG #include -#endif #include @@ -334,9 +332,7 @@ kern_reboot(int howto) waittime = 0; -#ifdef SW_WATCHDOG wdog_kern_pat(WD_LASTVAL); -#endif sys_sync(curthread, NULL); /* @@ -362,9 +358,8 @@ kern_reboot(int howto) if (nbusy < pbusy) iter = 0; pbusy = nbusy; -#ifdef SW_WATCHDOG + wdog_kern_pat(WD_LASTVAL); -#endif sys_sync(curthread, NULL); #ifdef PREEMPTION diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c index a06ba31..6e1333b 100644 --- a/sys/kern/vfs_subr.c +++ b/sys/kern/vfs_subr.c @@ -73,9 +73,7 @@ __FBSDID("$FreeBSD$"); #include #include #include -#ifdef SW_WATCHDOG #include -#endif #include @@ -1868,10 +1866,10 @@ sched_sync(void) LIST_INSERT_HEAD(next, bo, bo_synclist); continue; } -#ifdef SW_WATCHDOG + if (first_printf == 0) wdog_kern_pat(WD_LASTVAL); -#endif + } if (!LIST_EMPTY(gslp)) { mtx_unlock(&sync_mtx); diff --git a/sys/x86/x86/dump_machdep.c b/sys/x86/x86/dump_machdep.c index 4e6546d..5c874f4 100644 --- a/sys/x86/x86/dump_machdep.c +++ b/sys/x86/x86/dump_machdep.c @@ -36,9 +36,7 @@ __FBSDID("$FreeBSD$"); #include #include #include -#ifdef SW_WATCHDOG #include -#endif #include #include #include @@ -198,9 +196,9 @@ cb_dumpdata(struct md_pa *mdp, int seqnr, void *arg) a = pa + i * PAGE_SIZE; va = pmap_kenter_temporary(trunc_page(a), i); } -#ifdef SW_WATCHDOG + wdog_kern_pat(WD_LASTVAL); -#endif + error = dump_write(di, va, 0, dumplo, sz); if (error) break; -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed May 16 09:59:19 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26389106566B; Wed, 16 May 2012 09:59:19 +0000 (UTC) (envelope-from mjguzik@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 836CE8FC0A; Wed, 16 May 2012 09:59:18 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so519210wgb.31 for ; Wed, 16 May 2012 02:59:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=VIqbjbQtbYJcXbfOgVUkPcfC19tkFL9Dxv0TB5CVj1M=; b=tijoNqKJ3TZaSGoZjWzQmZNPLNf1PjDnjmao1a7WGzRWg7I+eiA71ffwu8GdgTN60d SYUkd9ODZUP3/BlLunNbm9GVzXkJx/ZTTQZBZTEm4pSnZ6DzBIrTC6XavABUgsNPNGo/ V9t6bfk3V87jQx7YWuiv63jqTwq1DzKqApOzTNqoq6fYUAlvjABDjDfLD924DUNsUx6p CrG0nbluIlIiBX0DTA3O3jRAXpdvUuALeh6SnoN9UgMqvwGqrRcrtlqS4uANt8jMLNLf 06xpEEGweyPyAr7NSP/+LCMHI1qim/ms5ScM4ILQqiKFzIEGGz5B76eJHHQBu6CtjEHi h7pQ== Received: by 10.180.91.225 with SMTP id ch1mr6365694wib.18.1337162356829; Wed, 16 May 2012 02:59:16 -0700 (PDT) Received: from dft-labs.eu (dft-labs.eu. [80.87.128.179]) by mx.google.com with ESMTPS id o9sm7579152wia.3.2012.05.16.02.59.14 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 May 2012 02:59:15 -0700 (PDT) Date: Wed, 16 May 2012 11:59:09 +0200 From: Mateusz Guzik To: Andrew Thompson Message-ID: <20120516095908.GA2470@dft-labs.eu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "current@freebsd.org Current" Subject: Re: sockstat & jid patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 09:59:19 -0000 On Wed, May 16, 2012 at 03:12:50PM +1200, Andrew Thompson wrote: > Hi, > > > Here is a quick patch to limit the sockstat output to a specific jail > id, this is useful to verify which sockets a jail has open. A jid of 0 > will show the host system. > > This will result in an extra syscall per socket when -j is set but I > do not think warrants a process cache. > > Any objections? I think you should extend struct xsocket with jid. Unfortunately this breaks ABI so MFC is not possible. That being said, IMHO this patch can be committed to -STABLE if this feature is that important, but -CURRENT should get implementation mentioned earlier. I can try to write a patch in a couple of days (or this evening if I find the time). -- Mateusz Guzik From owner-freebsd-current@FreeBSD.ORG Wed May 16 11:18:20 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EB14D1065673; Wed, 16 May 2012 11:18:20 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id A89848FC14; Wed, 16 May 2012 11:18:20 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 1C1A16526; Wed, 16 May 2012 11:18:14 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id CA3AB8ABF; Wed, 16 May 2012 13:18:13 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Vance Siemens References: <4FA2434F.1020802@unsane.co.uk> <864nrxh5zf.fsf@ds4.des.no> Date: Wed, 16 May 2012 13:18:13 +0200 In-Reply-To: (Vance Siemens's message of "Sat, 12 May 2012 09:25:04 -0400") Message-ID: <868vgsv0ga.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-chat@freebsd.org, Vincent Hoffman Subject: Re: FreeBSD 10 prognostication... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 11:18:21 -0000 Vance Siemens writes: > Can you share a brief overview of what's wrong with it? Umm, it's about as factual as The Onion, except not as funny. FreeBSD never had to "jettison two thirds of its code base and start from scratch". Apple is not involved in FreeBSD development. No Mac OS X or Darwin version "includes" FreeBSD. FreeBSD and Mac OS X will never merge. FreeBSD was never acquired by WinDriver Systems or by anyone else, although a company named WindRiver Systems (makers of the embedded operating system VxWorks, not of Windows video drivers) did at one point acquire BSDI, which had previously acquired Walnut Creek CD-ROM, which was heavily involved in the early history of both FreeBSD and Slackware Linux. The remains of Walnut Creek CD-ROM and BSDI are now known as FreeBSD Mall and iXsystems (of PC-BSD and FreeNAS fame). DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Wed May 16 11:37:04 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BEAC6106564A for ; Wed, 16 May 2012 11:37:04 +0000 (UTC) (envelope-from jwd@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A6B028FC16; Wed, 16 May 2012 11:37:04 +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 q4GBb4FF048141; Wed, 16 May 2012 11:37:04 GMT (envelope-from jwd@freefall.freebsd.org) Received: (from jwd@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q4GBb3iY048140; Wed, 16 May 2012 11:37:03 GMT (envelope-from jwd) Date: Wed, 16 May 2012 11:37:03 +0000 From: John To: Hans Petter Selasky Message-ID: <20120516113703.GA37604@FreeBSD.org> References: <20120511005419.GA5643@FreeBSD.org> <201205110741.41137.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201205110741.41137.hselasky@c2i.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: usb problems on HP DL980G7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 11:37:04 -0000 ----- Hans Petter Selasky's Original Message ----- > On Friday 11 May 2012 02:54:19 John wrote: > > Hi Folks, > > > > We've been trying to bring freebsd up on a hp dl980g7 for awhile. > > Due to usb issues, we finally installed onto a revo card and > > installed it into the 980. The system consistently puts out the > > following messages: > > > > usbd_ctrl_transfer_setup: could not setup default USB transfer > > usb_alloc_device: set address 2 failed (USB_ERR_NOMEM, ignored) > > usbd_ctrl_transfer_setup: could not setup default USB transfer > > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > > USB_ERR_NOMEM usbd_ctrl_transfer_setup: could not setup default USB > > transfer > > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_NOMEM, ignored) > > usbd_ctrl_transfer_setup: could not setup default USB transfer > > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > > USB_ERR_NOMEM usbd_ctrl_transfer_setup: could not setup default USB > > transfer > > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_NOMEM, ignored) > > usbd_ctrl_transfer_setup: could not setup default USB transfer > > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > > USB_ERR_NOMEM ugen0.2: at usbus0 (disconnected) > > uhub_reattach_port: could not allocate new device > > > > From dmesg: > > > > pci0: at device 20.0 (no driver > > attached) pcib12: at device 28.0 on pci0 > > pci3: on pcib12 > > pcib13: at device 28.4 on pci0 > > pci2: on pcib13 > > pci2: at device 0.0 (no driver attached) > > pci2: at device 0.2 (no driver attached) > > uhci0: port 0x3c00-0x3c1f irq 17 at device > > 0.4 on pci2 usbus0 on uhci0 > > uhci1: port 0x1000-0x101f irq > > 20 at device 29.0 on pci0 device_attach: uhci1 attach returned 12 > > uhci1: port 0x1020-0x103f irq > > 23 at device 29.1 on pci0 device_attach: uhci1 attach returned 12 > > uhci1: port 0x1040-0x105f irq > > 22 at device 29.2 on pci0 device_attach: uhci1 attach returned 12 > > uhci1: port 0x1060-0x107f irq > > 23 at device 29.3 on pci0 device_attach: uhci1 attach returned 12 > > ehci0: mem > > 0xa0300000-0xa03003ff irq 20 at device 29.7 on pci0 device_attach: ehci0 > > attach returned 12 > > > > Current - 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r235137M > > > > Nothing connected to usb on this systems works. > > > > Full dmesg is here: > > http://people.freebsd.org/~jwd/dl980g7/dmesg.boot.html > > > > Any help is appreciated. > > Hi, > > If you compile a kernel with options USB_DEBUG, there are some tunables under > hw.usb which can set various USB related delays. Try to double all USB sysctls > having the keyword "delay". > > --HPS Hi, It turns out USB_DEBUG is already enabled in the GENERIC kernel config. # sysctl -a | grep usb | grep delay hw.usb.pr_recovery_delay: 250 hw.usb.pr_poll_delay: 50 Increased these to 500 and 100 respectively in /etc/sysctl.conf. After rebooting, the error still comes up regularly on the console. Is there anything else we should turn on/try? (and a usb keyboard still doesn't work) I didn't notice this near the top of the dmesg output previously. Could it be related? ACPI Warning: Invalid length for Pm1aControlBlock: 32, using default 16 (20120420/tbfadt-662) Thanks, John From owner-freebsd-current@FreeBSD.ORG Wed May 16 12:37:32 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 50C3B1065673; Wed, 16 May 2012 12:37:32 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 97E808FC16; Wed, 16 May 2012 12:37:31 +0000 (UTC) Received: by lbon10 with SMTP id n10so650211lbo.13 for ; Wed, 16 May 2012 05:37:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=r8Mo/GbxecmhzECok7ZyTMRsFsjb+Qh3nPFlWpearnk=; b=FehLmSpQXf8T8tZ/QRrLiM/X+Tv1gc5xzvto7K1X7BuJLhkE4j01QOjhNf1YiQqXg3 8hW3Hx5C0WikjFFvx0Nq/Qb4GZ8tuTLkrejj3MBvOrpr4NqEnHYz+g/Q7Lzd+LeW3FKd IwNeh9snmaH2NeG94GhU/d1vMejC4W4ZnBA+6WgPX4jvtgu88RbDxzSpqiLj4mnPILN6 sbntn4KLAbc2RVGr9hjRVwA3W6YWJ6DTEgZcYXS40iGCLWaU0W3rxATQEpcSnO+MDTOx VLipHikXfKr8XAIsBHbovjUhTSL9joDas7p/HXy3h2tcEBkdXLLFEDVTBendSGZTLSLC SX/g== MIME-Version: 1.0 Received: by 10.152.144.234 with SMTP id sp10mr1140559lab.51.1337171849661; Wed, 16 May 2012 05:37:29 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.27.65 with HTTP; Wed, 16 May 2012 05:37:29 -0700 (PDT) In-Reply-To: <4FB36F41.9070101@FreeBSD.org> References: <4FB36F41.9070101@FreeBSD.org> Date: Wed, 16 May 2012 13:37:29 +0100 X-Google-Sender-Auth: g9Vl1EDvh0abcXPq2jWQADKtcy0 Message-ID: From: Attilio Rao To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD-Current Subject: Re: wdog_kern_pat: liberate from SW_WATCHDOG X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 12:37:32 -0000 2012/5/16, Andriy Gapon : > > I would like to commit something like the following patch. > I think that in-kernel watchdog patting during crash dump is useful with > hardware watchdogs too. The code seems to work fine here. > In fact, I am not sure why wdog_kern_pat was originally tied to > SW_WATCHDOG. I didn't think I tested this with any hw watchdog. Which one you are using for tests? BTW, can you please skip adding the white lines? Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Wed May 16 12:51:43 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B4A14106566B; Wed, 16 May 2012 12:51:43 +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 CEAC78FC0C; Wed, 16 May 2012 12:51:42 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA25469; Wed, 16 May 2012 15:51:41 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4FB3A2DB.5000805@FreeBSD.org> Date: Wed, 16 May 2012 15:51:39 +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: Attilio Rao References: <4FB36F41.9070101@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current Subject: Re: wdog_kern_pat: liberate from SW_WATCHDOG X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 12:51:43 -0000 on 16/05/2012 15:37 Attilio Rao said the following: > 2012/5/16, Andriy Gapon : >> >> I would like to commit something like the following patch. >> I think that in-kernel watchdog patting during crash dump is useful with >> hardware watchdogs too. The code seems to work fine here. >> In fact, I am not sure why wdog_kern_pat was originally tied to >> SW_WATCHDOG. > > I didn't think I tested this with any hw watchdog. > Which one you are using for tests? amdsbwd and ichwd > BTW, can you please skip adding the white lines? I thought that those calls were quite significant to be emphasized by spacing. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed May 16 13:02:22 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41220106566B; Wed, 16 May 2012 13:02:22 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8757F8FC0A; Wed, 16 May 2012 13:02:21 +0000 (UTC) Received: by lbon10 with SMTP id n10so674331lbo.13 for ; Wed, 16 May 2012 06:02:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=gMFOjk6FAP9U0VtUQq/VG3rCaSvSAn4RbEUgrEddVZ8=; b=DmCQ375A1C0557oIfB71L8wbSPa65UkjtaydkBk62EF4VRANfsltTGzi8YHS8w9oux bjvIOiQMj6jjjE/S7BKG/8QoAfgAu9esa1IK1LT6WHRek+i3AtiYHWnxo7m7GwHJbA5E 8TKjuAtfWj3iurZHYgHBx75agro37aOf3JTNUxlPSUttpo8gHsVHrgpnFL6Na1WxpKjs Z6k8M9eO6IIs7WCBCy/UohrvgRxcGat1bfkaQ2I64Rbd4+BRyvbI1lClj9LkTbGOC4BA zpmWFaututIxx8wcW/s/gwd9hRw+JAFU6D9WJiR8IFMOVPwcsB96fxKWGnFDcG8DS9UX eAAw== MIME-Version: 1.0 Received: by 10.152.132.166 with SMTP id ov6mr3081336lab.35.1337173340337; Wed, 16 May 2012 06:02:20 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.27.65 with HTTP; Wed, 16 May 2012 06:02:20 -0700 (PDT) In-Reply-To: <4FB3A2DB.5000805@FreeBSD.org> References: <4FB36F41.9070101@FreeBSD.org> <4FB3A2DB.5000805@FreeBSD.org> Date: Wed, 16 May 2012 14:02:20 +0100 X-Google-Sender-Auth: y_sacABeQt5TG-IFKsW4iCJCDZo Message-ID: From: Attilio Rao To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD-Current Subject: Re: wdog_kern_pat: liberate from SW_WATCHDOG X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 13:02:22 -0000 2012/5/16, Andriy Gapon : > on 16/05/2012 15:37 Attilio Rao said the following: >> 2012/5/16, Andriy Gapon : >>> >>> I would like to commit something like the following patch. >>> I think that in-kernel watchdog patting during crash dump is useful with >>> hardware watchdogs too. The code seems to work fine here. >>> In fact, I am not sure why wdog_kern_pat was originally tied to >>> SW_WATCHDOG. >> >> I didn't think I tested this with any hw watchdog. >> Which one you are using for tests? > > amdsbwd and ichwd > >> BTW, can you please skip adding the white lines? > > I thought that those calls were quite significant to be emphasized by > spacing. I don't think this is the right thing to do style-wise. But it is up to you. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Wed May 16 15:09:10 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3A6AA1065672; Wed, 16 May 2012 15:09:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id E95628FC16; Wed, 16 May 2012 15:09:09 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5DED8B922; Wed, 16 May 2012 11:09:09 -0400 (EDT) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Wed, 16 May 2012 10:50:35 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <4FAF7343.8010808@cran.org.uk> <201205151034.13994.jhb@freebsd.org> <4FB285C0.1090905@FreeBSD.org> In-Reply-To: <4FB285C0.1090905@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201205161050.35759.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 16 May 2012 11:09:09 -0400 (EDT) Cc: Bruce Cran , freebsd-current , Jung-uk Kim , Andriy Gapon Subject: Re: ACPI 'driver bug: Unable to set devclass' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 15:09:10 -0000 On Tuesday, May 15, 2012 12:35:12 pm Andriy Gapon wrote: > on 15/05/2012 17:34 John Baldwin said the following: > > On Monday, May 14, 2012 12:41:37 pm Andriy Gapon wrote: > >> on 14/05/2012 01:43 Bruce Cran said the following: > >>> On 13/05/2012 21:06, Andriy Gapon wrote: > >>>> Can you produce an equivalent snippet with verbose logging enabled? I have a > >>>> suspicion that these messages are a byproduct from r231161. > >>> > >>> acpi0: reservation of fee00000, 1000 (3) failed > >>> acpi0: reservation of 0, a0000 (3) failed > >>> acpi0: reservation of 100000, bbf00000 (3) failed > >>> acpi_sysresource: acpi_sysresource0 already exists; skipping it > >>> driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > >>> acpi_timer: acpi_timer0 already exists; skipping it > >>> driver bug: Unable to set devclass (class: acpi_timer devname: (unknown)) > >>> cpu0: on acpi0 > >>> ACPI Warning: Incorrect checksum in table [OEMB] - 0x45, should be 0x44 > >>> (20120420/tbutils-293) > >>> ACPI: SSDT 0xbb7900f0 01340 (v01 DpgPmm P001Ist 00000011 INTL 20051117) > >>> ACPI: Dynamic OEM Table Load: > >>> ACPI: SSDT 0 01340 (v01 DpgPmm P001Ist 00000011 INTL 20051117) > >>> ACPI: SSDT 0xbb791430 004F4 (v01 PmRef P001Cst 00003001 INTL 20051117) > >>> ACPI: Dynamic OEM Table Load: > >>> ACPI: SSDT 0 004F4 (v01 PmRef P001Cst 00003001 INTL 20051117) > >>> acpi_sysresource: acpi_sysresource2 already exists; skipping it > >>> driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > >>> cpu2: on acpi0 > >>> acpi_sysresource: acpi_sysresource1 already exists; skipping it > >>> driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > >>> cpu1: on acpi0 > >>> acpi_sysresource: acpi_sysresource3 already exists; skipping it > >>> driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > >>> > >> > >> I think that the following is what happens here in the acpi_timer case. > >> Previously one acpi_timer device_t was added with an order of zero and a fixed > >> unit number of zero in acpi_timer_identify(). Then, another acpi_timer device_t > >> could be added when walking the ACPI device tree, that device would always have a > >> later order and a wildcard unit number (-1). > >> Now both the "hardwired" device and "auto-probed" device are added with the same > >> order of 2 and it also so happens that the hardwired device is after the > >> auto-probed in the device list. So first the auto-probed device just takes the > >> unit number of zero because it is free and then the hardwired device fails to > >> claim the same unit number. > > > > Eh. This should not be true. The unit 0 is reserved when device_add_child() > > is called in the acpi_timer identify routine. The wildcard device will not be > > assigned a unit number until device_probe_child time. > > Not sure what you disagree with... > First, the wildcard device is added to the child list during the walk. > Then, the unit 0 device is added to the list when acpi_timer identify is executed. > Then, the wildcard device is probed and gets unit number of zero. > Then, the fixed device is being probed and the unit number conflict arises. > > Am I misunderstanding something? Yes. The third step will see that unit 0 is already in use and shouldn't reuse unit 0. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed May 16 15:09:12 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A7BD2106567A for ; Wed, 16 May 2012 15:09:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 69D9F8FC17 for ; Wed, 16 May 2012 15:09:12 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BDE95B9A6; Wed, 16 May 2012 11:09:11 -0400 (EDT) From: John Baldwin To: Anton Shterenlikht Date: Wed, 16 May 2012 11:08:05 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <20120426224215.GA79891@mech-cluster241.men.bris.ac.uk> <201205151211.09161.jhb@freebsd.org> <20120516084551.GA49037@mech-cluster241.men.bris.ac.uk> In-Reply-To: <20120516084551.GA49037@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201205161108.05809.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 16 May 2012 11:09:11 -0400 (EDT) Cc: freebsd-current@freebsd.org Subject: Re: updating from r231158 to 234465: mounting from ufs:/dev/ad4s1a failed with error 19 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 15:09:12 -0000 On Wednesday, May 16, 2012 4:45:51 am Anton Shterenlikht wrote: > On Tue, May 15, 2012 at 12:11:09PM -0400, John Baldwin wrote: > > On Monday, May 07, 2012 5:25:02 pm Anton Shterenlikht wrote: > > > On Mon, May 07, 2012 at 10:39:51AM -0400, John Baldwin wrote: > > > > On Friday, May 04, 2012 4:07:24 pm Anton Shterenlikht wrote: > > > > > On Fri, May 04, 2012 at 11:07:59AM -0400, John Baldwin wrote: > > > > > > On Friday, May 04, 2012 7:51:33 am Anton Shterenlikht wrote: > > > > > > > On Thu, May 03, 2012 at 02:46:18PM -0400, John Baldwin wrote: > > > > > > > > On Thursday, May 03, 2012 11:35:19 am Anton Shterenlikht wrote: > > > > > > > > > On Tue, May 01, 2012 at 12:35:26PM +0100, Anton Shterenlikht wrote: > > > > > > > > > > On Mon, Apr 30, 2012 at 08:43:14AM -0400, John Baldwin wrote: > > > > > > > > > > > > > > > > > > > > > > > > I also see: > > > > > > > > > > > > > > > > > > > > > > > > ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0exb > > > > > > > > > > > > ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 > > > > > > > > > > > > ata0: reset tp2 stat0=00 stat1=00 devices=0x10000 > > > > > > > > > > > > > > > > > > > > > > Hmmm, I don't know how to grok these lines, but does your disk work > > > > > > at > > > > > > > > all now > > > > > > > > > > > with any kernel? It may be that your disk has died (or a cable, > > > > > > etc.) > > > > > > > > and it > > > > > > > > > > > just happened to coincide with your upgrade? > > > > > > > > > > > > > > > > > > > > I reverted back to r231158, built world and generic > > > > > > > > > > kernel (minus all modules, i.e. "option MODULES_OVERRIDE="). > > > > > > > > > > This works, see the verbose boot dmesg at the end. > > > > > > > > > > > > > > > > > > > > I think I'll just do a binary search. > > > > > > > > > > > > > > > > > > I traced it to r233677. > > > > > > > > > The only change from 233676 to 233677 is > > > > > > > > > in /sys/dev/pci/pci.c > > > > > > > > > > > > > > > > > > My kernel is GENERIC with no modules > > > > > > > > > and with various bits removed, e.g. all raid devices > > > > > > > > > and PCI network devices, which I definitely > > > > > > > > > haven't got on this laptop. > > > > > > > > > > > > > > > > > > Below is the verbose boot with r233676. > > > > > > > > > Apparently at the beginning there's also > > > > > > > > > the previous unsuccessful boot with r233677. > > > > > > > > > Is this a new feature? I didn't know the > > > > > > > > > previous dmesg is preserved after a reboot. > > > > > > > > > Anyway, you can see clearly the error with r233677. > > > > > > > > > > > > > > > > > > I guess this is something to do with > > > > > > > > > ata -> ada change? > > > > > > > > > > > > > > > > I don't think so. > > > > > > > > > > > > > > > > Please try just this change: > > > > > > > > > > > > > > > > Index: pci.c > > > > > > > > =================================================================== > > > > > > > > --- pci.c (revision 234928) > > > > > > > > +++ pci.c (working copy) > > > > > > > > @@ -2822,10 +2822,14 @@ pci_add_map(device_t bus, device_t dev, int reg, s > > > > > > > > * from the parent. > > > > > > > > */ > > > > > > > > resource_list_delete(rl, type, reg); > > > > > > > > - } else { > > > > > > > > + start = 0; > > > > > > > > + device_printf(bus, > > > > > > > > + "pci%d:%d:%d:%d bar %#x failed to allocate", > > > > > > > > + pci_get_domain(dev), pci_get_bus(dev), pci_get_slot(dev), > > > > > > > > + pci_get_function(dev), reg); > > > > > > > > + } else > > > > > > > > start = rman_get_start(res); > > > > > > > > - pci_write_bar(dev, pm, start); > > > > > > > > - } > > > > > > > > + pci_write_bar(dev, pm, start); > > > > > > > > return (barlen); > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > That helped, thank you. > > > > > > > > > > > > Bizarre, can you get a regular dmesg with that change applied? > > > > > > > > > > > > > Hmm, I missed a newline at the end. :) Looks like this happened twice. > > > > I've added the relevant verbose boot messages from your earlier kernel > > > > below each one: > > > > > > > > > pci0: on pcib0 > > > > > pci0: pci0:0:20:2 bar 0x10 failed to allocate > > > > > pcib1: at device 1.0 on pci0 > > > > > > > > found-> vendor=0x1002, dev=0x4383, revid=0x00 > > > > domain=0, bus=0, slot=20, func=2 > > > > class=04-03-00, hdrtype=0x00, mfdev=0 > > > > cmdreg=0x0006, statreg=0x0410, cachelnsz=16 (dwords) > > > > lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > > > intpin=a, irq=10 > > > > powerspec 2 supports D0 D3 current D0 > > > > map[10]: type Memory, range 64, base 0xcc408000, size 14, enabled > > > > pcib0: matched entry for 0.20.INTA > > > > pcib0: slot 20 INTA hardwired to IRQ 16 > > > > > > > > > pcib4: at device 20.4 on pci0 > > > > > pcib4: failed to allocate initial memory window: 0xcc100000-0xcc1fffff > > > > > pci2: on pcib4 > > > > > pci2: pci0:2:4:0 bar 0x10 failed to allocate > > > > > cbb0: irq 20 at device 4.0 on pci2 > > > > > > > > found-> vendor=0x1180, dev=0x0476, revid=0xb6 > > > > domain=0, bus=2, slot=4, func=0 > > > > class=06-07-00, hdrtype=0x02, mfdev=1 > > > > cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) > > > > lattimer=0x40 (1920 ns), mingnt=0x80 (32000 ns), maxlat=0x07 (1750 ns) > > > > intpin=a, irq=10 > > > > powerspec 2 supports D0 D1 D2 D3 current D0 > > > > map[10]: type Memory, range 32, base 0xcc100000, size 12, enabled > > > > pcib4: failed to allocate initial memory window (0xcc100000-0xcc1fffff,0x100000) > > > > pcib4: matched entry for 2.4.INTA > > > > pcib4: slot 4 INTA hardwired to IRQ 20 > > > > cbb0: irq 20 at device 4.0 on pci2 > > > > pcib0: allocated type 3 (0xcc500000-0xcc5fffff) for rid 20 of pcib4 > > > > pcib4: allocated initial memory window of 0xcc500000-0xcc5fffff > > > > pcib4: allocated memory range (0xcc500000-0xcc500fff) for rid 10 of cbb0 > > > > cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xcc500000 > > > > > > > > So the second case actually recovers and allocates a different range. > > > > > > > > Can you try booting with 'debug.acpi.disabled=sysres' set in the loader? > > > > > > You mean without the patch? > > > > Either way. > > > > > > Also, can you get the output of 'devinfo -rv' from a working kernel? > > > > Oops, I meant to ask for devinfo -u, sorry. :( > > > > Oh, I see it now. Your BIOS is broken. > > > > The hdac0 device is assigned a resource that conflicts with pcib4, though > > that is the one we recover from: > > > > > hdac0 pnpinfo vendor=0x1002 device=0x4383 subvendor=0x103c subdevice=0x30c2 class=0x040300 at slot=20 function=2 handle=\_SB_.C08B.C0FD > > > Interrupt request lines: > > > 16 > > > I/O memory addresses: > > > 0xcc100000-0xcc103fff > > > > For the CardBus Bridge, the issue is this device: > > > > > ahci0 pnpinfo vendor=0x1002 device=0x4380 subvendor=0x1002 subdevice=0x4380 class=0x01018f at slot=18 function=0 handle=\_SB_.C08B.C275 > > > Interrupt request lines: > > > 16 > > > I/O ports: > > > 0x5018-0x501b > > > 0x5020-0x502f > > > 0x9000-0x9007 > > > 0x9008-0x900b > > > 0x9010-0x9017 > > > I/O memory addresses: > > > 0xcc409000-0xcc4093ff > > > > That last memory BAR conflicts with the desired range of 0xcc408000-0xcc40c000. > > > > I'm not sure why BIOS writers are so grossly incompetent, but such is life. > > > > Try this: > > > > Index: pci.c > > =================================================================== > > --- pci.c (revision 235475) > > +++ pci.c (working copy) > > @@ -2815,13 +2815,36 @@ pci_add_map(device_t bus, device_t dev, int reg, s > > */ > > res = resource_list_reserve(rl, bus, dev, type, ®, start, end, count, > > prefetch ? RF_PREFETCHABLE : 0); > > + if (res == NULL && (start != 0 || end != ~0ul)) { > > + /* > > + * If the allocation fails, try to allocate a resource for > > + * this BAR using any available range. The firmware felt > > + * it was important enough to assign a resource, so don't > > + * disable decoding if we can help it. > > + */ > > + resource_list_delete(rl, type, reg); > > + start = 0; > > + end = ~0ul; > > + resource_list_add(rl, type, reg, 0, ~0ul, count); > > + resource_list_add(rl, type, reg, start, end, count); > > + res = resource_list_reserve(rl, bus, dev, type, ®, 0, ~0ul, > > + count, prefetch ? RF_PREFETCHABLE : 0); > > + } > > if (res == NULL) { > > /* > > * If the allocation fails, delete the resource list entry > > - * to force pci_alloc_resource() to allocate resources > > - * from the parent. > > + * and disable decoding for this device. > > + * > > + * If the driver requests this resource in the future, > > + * pci_reserve_map() will try to allocate fresh resources. > > */ > > resource_list_delete(rl, type, reg); > > + pci_disable_io(dev, type); > > + start = 0; > > + device_printf(bus, > > + "pci%d:%d:%d:%d bar %#x failed to allocate", > > + pci_get_domain(dev), pci_get_bus(dev), pci_get_slot(dev), > > + pci_get_function(dev), reg); > > } else { > > start = rman_get_start(res); > > pci_write_bar(dev, pm, start); > > > > > > -- > > John Baldwin > > Below are (1) verbose boot dmesg and > (2) devinfo -u, with your patch > and with 'debug.acpi.disabled=sysres' > set in the loader. Humm, so did the patch help at all? (Wasn't clear from your e-mail.) It seems to have not helped given that the BAR still failed to allocate? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed May 16 15:18:13 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1205410656D3 for ; Wed, 16 May 2012 15:18:13 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (mail.farley.org [IPv6:2001:470:1f07:14d3:2::11]) by mx1.freebsd.org (Postfix) with ESMTP id 98B5F8FC17 for ; Wed, 16 May 2012 15:18:12 +0000 (UTC) Received: from thor.farley.org (HPooka@thor.farley.org [IPv6:2001:470:1f07:14d3:1::5]) by mail.farley.org (8.14.5/8.14.5) with ESMTP id q4GFIA9i035532; Wed, 16 May 2012 11:18:11 -0400 (EDT) (envelope-from scf@FreeBSD.org) Date: Wed, 16 May 2012 11:18:10 -0400 (EDT) From: "Sean C. Farley" To: "O. Hartmann" In-Reply-To: <4F82A3AF.3050207@zedat.fu-berlin.de> Message-ID: References: <4F8176A0.807@zedat.fu-berlin.de> <20120408152915.GU1420@albert.catwhisker.org> <4F82A3AF.3050207@zedat.fu-berlin.de> User-Agent: Alpine 2.02 (BSF 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-2.9 required=4.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.farley.org Cc: Current FreeBSD Subject: Re: xdm failing to start on FBSD 10.0 r2340030 erratically X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 15:18:13 -0000 On Mon, 9 Apr 2012, O. Hartmann wrote: > Am 04/08/12 17:29, schrieb David Wolfskill: *snip* >> * I don't know that this is different, but it may well be: my >> xorg.conf >> includes a stanza: >> >> Section "ServerFlags" >> Option "AutoAddDevices" "False" >> EndSection >> > I should go with this and try. But as far as I know, since I have USB > devices (mouse, keyboard), unpluggin and pluggin them is then, without > hal and dbus, not recognized anymore, isn't it? > > There was a discussion once going one for this subject. For posterity's sake, I wanted to mention that I use AutoAddDevices on my desktop, but for my laptop, I do not. However, I do not use HAL with either. Here are bits of my laptop's configuration to get it to use an external mouse without HAL. sysmouse(4) handles the mouse being added before or after the X server is running. Section "ServerLayout" ... InputDevice "Keyboard0" "CoreKeyboard" InputDevice "Synaptics Mouse" "CorePointer" InputDevice "SysMouse" "SendCoreEvents" ... EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" EndSection Section "InputDevice" Identifier "Synaptics Mouse" Driver "synaptics" Option "Protocol" "psm" Option "Device" "/dev/psm0" EndSection Section "InputDevice" Identifier "SysMouse" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" EndSection Sean -- scf@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed May 16 15:30:28 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17B401065677; Wed, 16 May 2012 15:30:28 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id B73D48FC18; Wed, 16 May 2012 15:30:27 +0000 (UTC) Received: from ncsd.bris.ac.uk ([137.222.10.59] helo=ncs.bris.ac.uk) by dirg.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1SUgBA-0004Vy-Gc; Wed, 16 May 2012 16:30:21 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SUgBA-0002Zc-A6; Wed, 16 May 2012 16:30:20 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5) with ESMTP id q4GFUK1R009116; Wed, 16 May 2012 16:30:20 +0100 (BST) (envelope-from mexas@bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5/Submit) id q4GFUKN1009115; Wed, 16 May 2012 16:30:20 +0100 (BST) (envelope-from mexas@bris.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bris.ac.uk using -f Date: Wed, 16 May 2012 16:30:19 +0100 From: Anton Shterenlikht To: John Baldwin Message-ID: <20120516153019.GB9070@mech-cluster241.men.bris.ac.uk> Mail-Followup-To: John Baldwin , Anton Shterenlikht , freebsd-current@freebsd.org References: <20120426224215.GA79891@mech-cluster241.men.bris.ac.uk> <201205151211.09161.jhb@freebsd.org> <20120516084551.GA49037@mech-cluster241.men.bris.ac.uk> <201205161108.05809.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201205161108.05809.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org, Anton Shterenlikht Subject: Re: updating from r231158 to 234465: mounting from ufs:/dev/ad4s1a failed with error 19 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 15:30:28 -0000 On Wed, May 16, 2012 at 11:08:05AM -0400, John Baldwin wrote: > On Wednesday, May 16, 2012 4:45:51 am Anton Shterenlikht wrote: > > On Tue, May 15, 2012 at 12:11:09PM -0400, John Baldwin wrote: > > > On Monday, May 07, 2012 5:25:02 pm Anton Shterenlikht wrote: > > > > On Mon, May 07, 2012 at 10:39:51AM -0400, John Baldwin wrote: > > > > > On Friday, May 04, 2012 4:07:24 pm Anton Shterenlikht wrote: > > > > > > On Fri, May 04, 2012 at 11:07:59AM -0400, John Baldwin wrote: > > > > > > > On Friday, May 04, 2012 7:51:33 am Anton Shterenlikht wrote: > > > > > > > > On Thu, May 03, 2012 at 02:46:18PM -0400, John Baldwin wrote: > > > > > > > > > On Thursday, May 03, 2012 11:35:19 am Anton Shterenlikht wrote: > > > > > > > > > > On Tue, May 01, 2012 at 12:35:26PM +0100, Anton Shterenlikht wrote: > > > > > > > > > > > On Mon, Apr 30, 2012 at 08:43:14AM -0400, John Baldwin wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > I also see: > > > > > > > > > > > > > > > > > > > > > > > > > > ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0exb > > > > > > > > > > > > > ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 > > > > > > > > > > > > > ata0: reset tp2 stat0=00 stat1=00 devices=0x10000 > > > > > > > > > > > > > > > > > > > > > > > > Hmmm, I don't know how to grok these lines, but does your disk work > > > > > > > at > > > > > > > > > all now > > > > > > > > > > > > with any kernel? It may be that your disk has died (or a cable, > > > > > > > etc.) > > > > > > > > > and it > > > > > > > > > > > > just happened to coincide with your upgrade? > > > > > > > > > > > > > > > > > > > > > > I reverted back to r231158, built world and generic > > > > > > > > > > > kernel (minus all modules, i.e. "option MODULES_OVERRIDE="). > > > > > > > > > > > This works, see the verbose boot dmesg at the end. > > > > > > > > > > > > > > > > > > > > > > I think I'll just do a binary search. > > > > > > > > > > > > > > > > > > > > I traced it to r233677. > > > > > > > > > > The only change from 233676 to 233677 is > > > > > > > > > > in /sys/dev/pci/pci.c > > > > > > > > > > > > > > > > > > > > My kernel is GENERIC with no modules > > > > > > > > > > and with various bits removed, e.g. all raid devices > > > > > > > > > > and PCI network devices, which I definitely > > > > > > > > > > haven't got on this laptop. > > > > > > > > > > > > > > > > > > > > Below is the verbose boot with r233676. > > > > > > > > > > Apparently at the beginning there's also > > > > > > > > > > the previous unsuccessful boot with r233677. > > > > > > > > > > Is this a new feature? I didn't know the > > > > > > > > > > previous dmesg is preserved after a reboot. > > > > > > > > > > Anyway, you can see clearly the error with r233677. > > > > > > > > > > > > > > > > > > > > I guess this is something to do with > > > > > > > > > > ata -> ada change? > > > > > > > > > > > > > > > > > > I don't think so. > > > > > > > > > > > > > > > > > > Please try just this change: > > > > > > > > > > > > > > > > > > Index: pci.c > > > > > > > > > =================================================================== > > > > > > > > > --- pci.c (revision 234928) > > > > > > > > > +++ pci.c (working copy) > > > > > > > > > @@ -2822,10 +2822,14 @@ pci_add_map(device_t bus, device_t dev, int reg, s > > > > > > > > > * from the parent. > > > > > > > > > */ > > > > > > > > > resource_list_delete(rl, type, reg); > > > > > > > > > - } else { > > > > > > > > > + start = 0; > > > > > > > > > + device_printf(bus, > > > > > > > > > + "pci%d:%d:%d:%d bar %#x failed to allocate", > > > > > > > > > + pci_get_domain(dev), pci_get_bus(dev), pci_get_slot(dev), > > > > > > > > > + pci_get_function(dev), reg); > > > > > > > > > + } else > > > > > > > > > start = rman_get_start(res); > > > > > > > > > - pci_write_bar(dev, pm, start); > > > > > > > > > - } > > > > > > > > > + pci_write_bar(dev, pm, start); > > > > > > > > > return (barlen); > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > That helped, thank you. > > > > > > > > > > > > > > Bizarre, can you get a regular dmesg with that change applied? > > > > > > > > > > > > > > > > Hmm, I missed a newline at the end. :) Looks like this happened twice. > > > > > I've added the relevant verbose boot messages from your earlier kernel > > > > > below each one: > > > > > > > > > > > pci0: on pcib0 > > > > > > pci0: pci0:0:20:2 bar 0x10 failed to allocate > > > > > > pcib1: at device 1.0 on pci0 > > > > > > > > > > found-> vendor=0x1002, dev=0x4383, revid=0x00 > > > > > domain=0, bus=0, slot=20, func=2 > > > > > class=04-03-00, hdrtype=0x00, mfdev=0 > > > > > cmdreg=0x0006, statreg=0x0410, cachelnsz=16 (dwords) > > > > > lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > > > > intpin=a, irq=10 > > > > > powerspec 2 supports D0 D3 current D0 > > > > > map[10]: type Memory, range 64, base 0xcc408000, size 14, enabled > > > > > pcib0: matched entry for 0.20.INTA > > > > > pcib0: slot 20 INTA hardwired to IRQ 16 > > > > > > > > > > > pcib4: at device 20.4 on pci0 > > > > > > pcib4: failed to allocate initial memory window: 0xcc100000-0xcc1fffff > > > > > > pci2: on pcib4 > > > > > > pci2: pci0:2:4:0 bar 0x10 failed to allocate > > > > > > cbb0: irq 20 at device 4.0 on pci2 > > > > > > > > > > found-> vendor=0x1180, dev=0x0476, revid=0xb6 > > > > > domain=0, bus=2, slot=4, func=0 > > > > > class=06-07-00, hdrtype=0x02, mfdev=1 > > > > > cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) > > > > > lattimer=0x40 (1920 ns), mingnt=0x80 (32000 ns), maxlat=0x07 (1750 ns) > > > > > intpin=a, irq=10 > > > > > powerspec 2 supports D0 D1 D2 D3 current D0 > > > > > map[10]: type Memory, range 32, base 0xcc100000, size 12, enabled > > > > > pcib4: failed to allocate initial memory window (0xcc100000-0xcc1fffff,0x100000) > > > > > pcib4: matched entry for 2.4.INTA > > > > > pcib4: slot 4 INTA hardwired to IRQ 20 > > > > > cbb0: irq 20 at device 4.0 on pci2 > > > > > pcib0: allocated type 3 (0xcc500000-0xcc5fffff) for rid 20 of pcib4 > > > > > pcib4: allocated initial memory window of 0xcc500000-0xcc5fffff > > > > > pcib4: allocated memory range (0xcc500000-0xcc500fff) for rid 10 of cbb0 > > > > > cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xcc500000 > > > > > > > > > > So the second case actually recovers and allocates a different range. > > > > > > > > > > Can you try booting with 'debug.acpi.disabled=sysres' set in the loader? > > > > > > > > You mean without the patch? > > > > > > Either way. > > > > > > > > Also, can you get the output of 'devinfo -rv' from a working kernel? > > > > > > Oops, I meant to ask for devinfo -u, sorry. :( > > > > > > Oh, I see it now. Your BIOS is broken. > > > > > > The hdac0 device is assigned a resource that conflicts with pcib4, though > > > that is the one we recover from: > > > > > > > hdac0 pnpinfo vendor=0x1002 device=0x4383 subvendor=0x103c subdevice=0x30c2 class=0x040300 at slot=20 function=2 > handle=\_SB_.C08B.C0FD > > > > Interrupt request lines: > > > > 16 > > > > I/O memory addresses: > > > > 0xcc100000-0xcc103fff > > > > > > For the CardBus Bridge, the issue is this device: > > > > > > > ahci0 pnpinfo vendor=0x1002 device=0x4380 subvendor=0x1002 subdevice=0x4380 class=0x01018f at slot=18 function=0 > handle=\_SB_.C08B.C275 > > > > Interrupt request lines: > > > > 16 > > > > I/O ports: > > > > 0x5018-0x501b > > > > 0x5020-0x502f > > > > 0x9000-0x9007 > > > > 0x9008-0x900b > > > > 0x9010-0x9017 > > > > I/O memory addresses: > > > > 0xcc409000-0xcc4093ff > > > > > > That last memory BAR conflicts with the desired range of 0xcc408000-0xcc40c000. > > > > > > I'm not sure why BIOS writers are so grossly incompetent, but such is life. > > > > > > Try this: > > > > > > Index: pci.c > > > =================================================================== > > > --- pci.c (revision 235475) > > > +++ pci.c (working copy) > > > @@ -2815,13 +2815,36 @@ pci_add_map(device_t bus, device_t dev, int reg, s > > > */ > > > res = resource_list_reserve(rl, bus, dev, type, ®, start, end, count, > > > prefetch ? RF_PREFETCHABLE : 0); > > > + if (res == NULL && (start != 0 || end != ~0ul)) { > > > + /* > > > + * If the allocation fails, try to allocate a resource for > > > + * this BAR using any available range. The firmware felt > > > + * it was important enough to assign a resource, so don't > > > + * disable decoding if we can help it. > > > + */ > > > + resource_list_delete(rl, type, reg); > > > + start = 0; > > > + end = ~0ul; > > > + resource_list_add(rl, type, reg, 0, ~0ul, count); > > > + resource_list_add(rl, type, reg, start, end, count); > > > + res = resource_list_reserve(rl, bus, dev, type, ®, 0, ~0ul, > > > + count, prefetch ? RF_PREFETCHABLE : 0); > > > + } > > > if (res == NULL) { > > > /* > > > * If the allocation fails, delete the resource list entry > > > - * to force pci_alloc_resource() to allocate resources > > > - * from the parent. > > > + * and disable decoding for this device. > > > + * > > > + * If the driver requests this resource in the future, > > > + * pci_reserve_map() will try to allocate fresh resources. > > > */ > > > resource_list_delete(rl, type, reg); > > > + pci_disable_io(dev, type); > > > + start = 0; > > > + device_printf(bus, > > > + "pci%d:%d:%d:%d bar %#x failed to allocate", > > > + pci_get_domain(dev), pci_get_bus(dev), pci_get_slot(dev), > > > + pci_get_function(dev), reg); > > > } else { > > > start = rman_get_start(res); > > > pci_write_bar(dev, pm, start); > > > > > > > > > -- > > > John Baldwin > > > > Below are (1) verbose boot dmesg and > > (2) devinfo -u, with your patch > > and with 'debug.acpi.disabled=sysres' > > set in the loader. > > Humm, so did the patch help at all? (Wasn't clear from your e-mail.) > > It seems to have not helped given that the BAR still failed to allocate? er.. yes, of course it helped. My problem was that I couldn't boot. So, I presumed the very existence of dmesg.boot showed that your patches (both of them) work fine. But, sorry, I could've been more explicit. All seems to work, including sound and wireless. Thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Wed May 16 15:58:11 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A3328106566B for ; Wed, 16 May 2012 15:58:11 +0000 (UTC) (envelope-from pfg@freebsd.org) Received: from nm19-vm0.bullet.mail.bf1.yahoo.com (nm19-vm0.bullet.mail.bf1.yahoo.com [98.139.213.162]) by mx1.freebsd.org (Postfix) with SMTP id 506048FC0C for ; Wed, 16 May 2012 15:58:11 +0000 (UTC) Received: from [98.139.212.148] by nm19.bullet.mail.bf1.yahoo.com with NNFMP; 16 May 2012 15:58:10 -0000 Received: from [98.139.211.193] by tm5.bullet.mail.bf1.yahoo.com with NNFMP; 16 May 2012 15:58:10 -0000 Received: from [127.0.0.1] by smtp202.mail.bf1.yahoo.com with NNFMP; 16 May 2012 15:58:10 -0000 X-Yahoo-Newman-Id: 660404.64989.bm@smtp202.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ciDVJg0VM1lA.azkQ6qziMtvDYMnOBw66.rWkNKf2io2LE9 _MGCd.t_b2RRaQX3_CvstRCr.xe0kRcGEBB2BKX8cyTZDOajTIf4hB1Tlq3z bQx1fw2sQ_kJfzuLGn9lcHPJJgQT8A_Q9hfjrbrRDgDbMoVsWayP.aRcSp5q 5EZKfxf4JANCyrO676q8roUOcVjNpsWF7auLydaNuRt9ukfWy7RmLmqll._I XGj3ye5Y9haehU4kqXtr1YgtPKeIHsZtk9nYGD_pKImm232H2mb56hsk.G2M LQETLlybxdg6nkrlGJRMs82KOHWBWk3m0t8ergQ09GaA4l6u8Eg0rddkP5KW eOdD9Pch2GP6c4Ns_thrxXZKYUkio8fWatZO19iaXpzpaOFa43BhHY2Nijh. p5vTlsDlFfRnaGh_OE.i.2Pxfq2nV852pKBPJ8sHI9o8LnZ7E63w.KMD77_4 lYIf2bddaUjeXH59_eEqEYN_iQ5zRXGWC1WPYw0GLtczkXmsB9zsR34qzP.J BR5GAa9Eu9uCftmS5oxMEJlhzGpBF2KFZoM6deo8Qroyue9Vh.rWesmcWPbS dBJburGL1XuC4Jbbab05yizSCBMd7CmnTkiS8eJnttqLGeEoDpj4S5b7iyIV ZyK0E75S.Rxpg2pmkg1K7HM4- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Received: from [192.168.10.103] (pfg@200.118.157.7 with plain) by smtp202.mail.bf1.yahoo.com with SMTP; 16 May 2012 08:58:10 -0700 PDT Message-ID: <4FB3CE90.8050004@FreeBSD.org> Date: Wed, 16 May 2012 10:58:08 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120328 Thunderbird/10.0.3 MIME-Version: 1.0 To: Mateusz Guzik , freebsd-current@FreeBSD.org References: <4FA6F324.4080107@FreeBSD.org> <4FA82269.6080406@FreeBSD.org> <20120507201153.GA19942@dft-labs.eu> <20120508194514.GA10688@x2.osted.lan> <20120510102118.GA26472@dft-labs.eu> <20120510103900.GA77554@x2.osted.lan> <20120512224938.GA1322@dft-labs.eu> In-Reply-To: <20120512224938.GA1322@dft-labs.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: panic, seems related to r234386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 15:58:11 -0000 Hello; On 05/12/12 17:49, Mateusz Guzik wrote: >>>> >>>> Gave this a spin and found what looks like a deadlock: >>>> >>>> http://people.freebsd.org/~pho/stress/log/ext2fs.txt >>>> >>>> Not a new problem, it would seem. Same issue with 8.3-PRERELEASE r232656M. >>>> >>> pid 2680 (fts) holds lock for vnode cb4be414 and tries to lock cc0ac15c >>> pid 2581 (openat) holds lock for vnode cc0ac15c and tries to lock cb4be414 >>> >>> openat calls rmdir foo/bar and ext2_rmdir unlocks and tries to lock >>> again foo's vnode. >>> >>> This is fairly easly reproducible with concurrently running mkdir and fts >>> testcase programs that are provided by stress2. >>> >>> I'll try to come up with a patch by the end of the week. >>> > Easier way to reproduce: mkdir from stress2 and "while true; do find /mnt> > /dev/null; done" on another terminal. > > Assuming foo/bar directory tree, deadlock happens during removal of bar > with simultaneous lookup of .. in bar. > > Proposed trivial patch: > http://student.agh.edu.pl/~mjguzik/patches/ext2fs_rmdir-deadlock.patch > > If the lock cannot be acquired immediately unlocks 'bar' vnode and then > locks both vnodes in order. > > After patching this I ran into another issue - wrong vnode type panics > from cache_enter_time after calls by ext2_lookup. (It takes some time to > reproduce this, testcase as before.) > > It looks like ext2_lookup is actually adapted version of ufs_lookup and > lacks some bugfixes present in current ufs_lookup. I believe those > bugfixes address this bug. > > Here is my attempt to fix the problem (based on ufs_lookup changes): > http://student.agh.edu.pl/~mjguzik/patches/ext2fs_lookup-relookup.patch > It is indeed extremely useful that UFS and ext2fs are so similar. The two bugfixes were committed as revision 235508, thanks! Pedro. From owner-freebsd-current@FreeBSD.ORG Wed May 16 16:18:29 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CC4801065670; Wed, 16 May 2012 16:18: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 870808FC12; Wed, 16 May 2012 16:18:28 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA27762; Wed, 16 May 2012 19:18:26 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4FB3D351.6030804@FreeBSD.org> Date: Wed, 16 May 2012 19:18: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: John Baldwin References: <4FAF7343.8010808@cran.org.uk> <201205151034.13994.jhb@freebsd.org> <4FB285C0.1090905@FreeBSD.org> <201205161050.35759.jhb@freebsd.org> In-Reply-To: <201205161050.35759.jhb@freebsd.org> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Bruce Cran , freebsd-acpi@FreeBSD.org, freebsd-current , Jung-uk Kim Subject: Re: ACPI 'driver bug: Unable to set devclass' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 16:18:29 -0000 on 16/05/2012 17:50 John Baldwin said the following: > On Tuesday, May 15, 2012 12:35:12 pm Andriy Gapon wrote: >> Not sure what you disagree with... >> First, the wildcard device is added to the child list during the walk. >> Then, the unit 0 device is added to the list when acpi_timer identify is executed. >> Then, the wildcard device is probed and gets unit number of zero. >> Then, the fixed device is being probed and the unit number conflict arises. >> >> Am I misunderstanding something? > > Yes. The third step will see that unit 0 is already in use and shouldn't > reuse unit 0. > Looks like I missed the call to devclass_add_device() in make_device(). Your guess: > I wonder if this is related to the recent changes to set the unit number for CPUs? seems to be true. The device_t-s created for CPUs have NULL driver name / devclass, but a non-wildcard unit number. So when such a device with unit number 0 is probed by acpi_timer we get a unit number conflict with acpi_timer0 pre-created via the identify. Similarly we get conflicts for acpi_sysresource driver, because we do an early probe-and-attach for this driver and the attached devices get some unit numbers (0, 1, etc). So when during the normal probe pass the "CPU" devices with matching unit numbers are passed to the driver the conflict results. I guess that it is an unorthodox use of newbus to specify a unit number without specifying a driver name... It's like saying "this device must be unit N whatever driver claims it (be it kbdN or diskN) just because I say so". Not sure if this ever makes sense and maybe we should prohibit such a combination (reject it earlier). I guess that in this particular case we already know that the devices are really CPU devices and are going to be claimed by acpi cpu driver. So we should pass "cpu" as the name. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed May 16 18:38:14 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9F4021065670; Wed, 16 May 2012 18:38:14 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 533178FC15; Wed, 16 May 2012 18:38:14 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q4GIc8Fb041625; Wed, 16 May 2012 14:38:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q4GIc7CI041612; Wed, 16 May 2012 18:38:07 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 16 May 2012 18:38:07 GMT Message-Id: <201205161838.q4GIc7CI041612@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 18:38:14 -0000 TB --- 2012-05-16 17:10:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-05-16 17:10:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-05-16 17:10:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-05-16 17:10:00 - cleaning the object tree TB --- 2012-05-16 17:10:00 - cvsupping the source tree TB --- 2012-05-16 17:10:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-05-16 17:12:09 - building world TB --- 2012-05-16 17:12:09 - CROSS_BUILD_TESTING=YES TB --- 2012-05-16 17:12:09 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-16 17:12:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-16 17:12:09 - SRCCONF=/dev/null TB --- 2012-05-16 17:12:09 - TARGET=i386 TB --- 2012-05-16 17:12:09 - TARGET_ARCH=i386 TB --- 2012-05-16 17:12:09 - TZ=UTC TB --- 2012-05-16 17:12:09 - __MAKE_CONF=/dev/null TB --- 2012-05-16 17:12:09 - cd /src TB --- 2012-05-16 17:12:09 - /usr/bin/make -B buildworld >>> World build started on Wed May 16 17:12:11 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 [...] c++ -O2 -pipe -I/src/lib/clang/libllvminstrumentation/../../../contrib/llvm/include -I/src/lib/clang/libllvminstrumentation/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvminstrumentation/../../../contrib/llvm/lib/Transforms/Instrumentation -I. -I/src/lib/clang/libllvminstrumentation/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libllvminstrumentation/../../../contrib/llvm/lib/Transforms/Instrumentation/GCOVProfiling.cpp c++ -O2 -pipe -I/src/lib/clang/libllvminstrumentation/../../../contrib/llvm/include -I/src/lib/clang/libllvminstrumentation/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvminstrumentation/../../../contrib/llvm/lib/Transforms/Instrumentation -I. -I/src/lib/clang/libllvminstrumentation/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libllvminstrumentation/../../../contrib/llvm/lib/Transforms/Instrumentation/Instrumentation.cpp c++ -O2 -pipe -I/src/lib/clang/libllvminstrumentation/../../../contrib/llvm/include -I/src/lib/clang/libllvminstrumentation/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvminstrumentation/../../../contrib/llvm/lib/Transforms/Instrumentation -I. -I/src/lib/clang/libllvminstrumentation/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libllvminstrumentation/../../../contrib/llvm/lib/Transforms/Instrumentation/OptimalEdgeProfiling.cpp /obj/i386.i386/src/tmp/usr/include/c++/4.2/bits/stl_algo.h: In function 'void std::__merge_without_buffer(_BidirectionalIterator, _BidirectionalIterator, _BidirectionalIterator, _Distance, _Distance, _Compare) [with _BidirectionalIterator = __gnu_cxx::__normal_iterator, double>*, std::vector, double>, std::allocator, double> > > >, _Distance = int, _Compare = llvm::MaximumSpanningTree::EdgeWeightCompare]': /obj/i386.i386/src/tmp/usr/include/c++/4.2/bits/stl_algo.h:3125: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop in /src/lib/clang/libllvminstrumentation. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-05-16 18:38:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-05-16 18:38:07 - ERROR: failed to build world TB --- 2012-05-16 18:38:07 - 4024.52 user 532.12 system 5287.05 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed May 16 18:48:17 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E82BF1065670 for ; Wed, 16 May 2012 18:48:17 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 889618FC14 for ; Wed, 16 May 2012 18:48:17 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtp (envelope-from ) id <1SUjGd-0002kz-6y>; Wed, 16 May 2012 20:48:11 +0200 Received: from e178027084.adsl.alicedsl.de ([85.178.27.84] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtpsa (envelope-from ) id <1SUjGc-0008Sl-Vf>; Wed, 16 May 2012 20:48:11 +0200 Message-ID: <4FB3F663.8090308@zedat.fu-berlin.de> Date: Wed, 16 May 2012 20:48:03 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120502 Thunderbird/12.0.1 MIME-Version: 1.0 To: Current FreeBSD X-Enigmail-Version: 1.5pre Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig06A33F2ADA38B6A28850E566" X-Originating-IP: 85.178.27.84 Cc: Subject: r235510: recent buildworld fail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 18:48:18 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig06A33F2ADA38B6A28850E566 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable When compiling world (make buildworld) I receive the bewlo error, which seems very strange! The error occured out of the blue on a FreeBSD 10.0-CURRENT/amd64 box. The line /usr/obj/usr/src/tmp/usr/bin/ld: Warning: size of symbol `_ZNSi6ignoreEv@GLIBCXX_3.4' changed from 243 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so to 211 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so looks like a "mixed up" between CLANG and legacy GCC 4.2.1, as far as I remember this error was typical for a mismatch. I can not imagine how this could be introduced on one of my systems. By the way, all FreeBSD 10.0-CURRENT boxes I have compiling under CLANG refuse compiling world - neither with make "-jXX buildworld" nor "make buildworl". This is my /etc/src.conf: WITH_CLANG=3D YES WITH_CLANG_EXTRAS=3D YES # WITH_BIND_LARGE_FILE=3D YES WITH_BIND_SIGCHASE=3D YES WITH_BIND_LIBS=3D YES # WITH_IDEA=3D YES WITH_HESIOD=3D YES # WITH_BSD_SORT=3D YES #WITH_BSD_GREP=3D YES #WITH_ICONV=3D YES # WITH_LIBCPLUSPLUS=3D YES # #WITH_OFED=3D YES # PORTS_MODULES=3D x11/nvidia-driver # MALLOC_PRODUCTION=3D YES What can I do to repair the system? Regards, Oliver [...] clang++ -O2 -pipe -O2 -fno-strict-aliasing -pipe -O3 -pipe -fno-strict-aliasing -march=3Dnative -Qunused-arguments -fstack-protector= -Wsystem-headers -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-parentheses -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -o gperf bool-array.o hash-table.o input.o keyword-list.o keyword.o main.o options.o output.o positions.o search.o version.o getline.o hash.o /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_ifstream >::is_open() const' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_string, std::allocator >::_Rep::_M_set_length_and_sharable(unsigned long= )' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_string, std::allocator >::_M_check_length(unsigned long, unsigned long, char const*) const' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_fstream >::is_open() const' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_istream >::ignore()' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_string, std::allocator >::_M_copy(wchar_t*, wchar_t const*, unsigned lon= g)' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::string::_M_assign(char*, unsigned long, char)' /usr/obj/usr/src/tmp/usr/bin/ld: Warning: size of symbol `_ZNSt13basic_istreamIwSt11char_traitsIwEE6ignoreEv@GLIBCXX_3.4' changed from 243 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so to 211 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_fstream >::is_open() const' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_string, std::allocator >::_M_move(wchar_t*, wchar_t const*, unsigned lon= g)' /usr/obj/usr/src/tmp/usr/bin/ld: Warning: size of symbol `_ZNSbIwSt11char_traitsIwESaIwEE4_Rep26_M_set_length_and_sharableEm@GLIBC= XX_3.4' changed from 19 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so to 24 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::string::_M_move(char*, char const*, unsigned long)' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::istream::ignore()' /usr/obj/usr/src/tmp/usr/bin/ld: Warning: size of symbol `_ZNKSs15_M_check_lengthEmmPKc@GLIBCXX_3.4' changed from 39 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so to 36 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_ofstream >::is_open() const' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_string, std::allocator >::_M_assign(wchar_t*, unsigned long, wchar_t)' /usr/obj/usr/src/tmp/usr/bin/ld: Warning: size of symbol `_ZNKSbIwSt11char_traitsIwESaIwEE15_M_check_lengthEmmPKc@GLIBCXX_3.4' changed from 39 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so to 36 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so /usr/obj/usr/src/tmp/usr/bin/ld: Warning: size of symbol `_ZNSi6ignoreEv@GLIBCXX_3.4' changed from 243 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so to 211 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_ifstream >::is_open() const' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::string::_M_copy(char*, char const*, unsigned long)' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_ofstream >::is_open() const' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::string::_M_check_length(unsigned long, unsigned long, char const*) const' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::string::_Rep::_M_set_length_and_sharable(unsigned lon= g)' clang++: error: linker command failed with exit code 1 (use -v to see invocation) *** [gperf] Error code 1 Stop in /usr/src/gnu/usr.bin/gperf. *** [all] Error code 1 Stop in /usr/src/gnu/usr.bin. *** [all] Error code 1 Stop in /usr/src/gnu. *** [gnu.all__D] Error code 1 Stop in /usr/src. *** [everything] Error code 1 Stop in /usr/src. *** [buildworld] Error code 1 Stop in /usr/src. --------------enig06A33F2ADA38B6A28850E566 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJPs/ZqAAoJEOgBcD7A/5N8bjMIAJHpnykFPlR1Oaf95uc73pAy IqA3aOm1h70RiiH44K+xtOdw2BmXrrH4l8kL+gFZeMKRwG0Ng6e1ZN/JUjKf06Px eDjMamoWpVJN03F+oUlQGufdVGIoWZlYFGo1JPON6+e6eHpTTEd23VB2Rk05cSsg wDT28sBPJ1QJ7KKK3cpUdmnMiXOMy+vsiMQYJz/G1ZJ5dyu/tHUPzfObNpon+GaB EL4XMRldeklzxvzhCsOhbSHTRpNwpuoT9vAlDlWlUigjROl+5VX8xfOhOQE/vyed SNNwVSOcQs55mi7MSEIfQuHOkJpr9RJPeMY5YUnUboGMzTz6fhhOCVsQ/eanElA= =N+yh -----END PGP SIGNATURE----- --------------enig06A33F2ADA38B6A28850E566-- From owner-freebsd-current@FreeBSD.ORG Wed May 16 18:56:45 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6BBF106566C; Wed, 16 May 2012 18:56:45 +0000 (UTC) (envelope-from david.somayajulu@qlogic.com) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by mx1.freebsd.org (Postfix) with ESMTP id 33A4F8FC15; Wed, 16 May 2012 18:56:44 +0000 (UTC) Received: from mail70-db3-R.bigfish.com (10.3.81.249) by DB3EHSOBE004.bigfish.com (10.3.84.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 16 May 2012 18:41:25 +0000 Received: from mail70-db3 (localhost [127.0.0.1]) by mail70-db3-R.bigfish.com (Postfix) with ESMTP id 6FE041E04AC; Wed, 16 May 2012 18:41:25 +0000 (UTC) X-SpamScore: -1 X-BigFish: VPS-1(zzc85fh14ffIzz1202hzz8275bh8275dhz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:198.70.193.61; KIP:(null); UIP:(null); IPV:NLI; H:avexcashub1.qlogic.com; RD:avexcashub1.qlogic.com; EFVD:NLI Received-SPF: pass (mail70-db3: domain of qlogic.com designates 198.70.193.61 as permitted sender) client-ip=198.70.193.61; envelope-from=david.somayajulu@qlogic.com; helo=avexcashub1.qlogic.com ; 1.qlogic.com ; Received: from mail70-db3 (localhost.localdomain [127.0.0.1]) by mail70-db3 (MessageSwitch) id 1337193683554175_9568; Wed, 16 May 2012 18:41:23 +0000 (UTC) Received: from DB3EHSMHS006.bigfish.com (unknown [10.3.81.249]) by mail70-db3.bigfish.com (Postfix) with ESMTP id 82CFB10026E; Wed, 16 May 2012 18:41:23 +0000 (UTC) Received: from avexcashub1.qlogic.com (198.70.193.61) by DB3EHSMHS006.bigfish.com (10.3.87.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 16 May 2012 18:41:22 +0000 Received: from avexmb1.qlogic.org ([fe80::9545:3a4f:c131:467d]) by avexcashub1.qlogic.org ([::1]) with mapi; Wed, 16 May 2012 11:41:26 -0700 From: David Somayajulu To: "freebsd-net@freebsd.org" , "freebsd-current@freebsd.org (freebsd-current@FreeBSD.org)" , "freebsd-drivers@freebsd.org" Date: Wed, 16 May 2012 11:41:25 -0700 Thread-Topic: Ethernet Drivers: Question on ifp->if_ioctl invocation for SIOCADDMULTI and SIOCDELMULTI Thread-Index: Ac0zkCqD5TmECMzeQBqgnK1AAFmspg== Message-ID: <75E1A2A7D185F841A975979B0906BBA67C7A229F49@AVEXMB1.qlogic.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginatorOrg: qlogic.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "davidcs@FreeBSD.org" Subject: Ethernet Drivers: Question on ifp->if_ioctl invocation for SIOCADDMULTI and SIOCDELMULTI X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 18:56:46 -0000 Hi All, When ifp->if_ioctl() is invoked for the ioctl cmd SIOCADDMULTI, IN_MULTI_LOCK() is called in one of the functions in_joingroup() in the ca= ller stack. >From netinet/in_var.h, line 357 : #define IN_MULTI_LOCK() mtx_lock= (&in_multi_mtx) >From netinet/in_mcast.c 1098 in_joingroup(struct ifnet *ifp, const struct in_addr *gina, 1099 /*const*/ struct in_mfilter *imf, struct in_multi **pinm) 1100 { 1101 int error; 1102 1103 IN_MULTI_LOCK(); 1104 error =3D in_joingroup_locked(ifp, gina, imf, pinm); 1105 IN_MULTI_UNLOCK(); 1106 This is also the case for SIOCDELMULTI, where the function holding "in_mul= ti_mtx" lock is in_leavegroup() This poses a problem in the driver in that the hardware dependent function = performing it, is not allowed to sleep() in case it needs to poll some sta= te. Question: 1. If I want to implement any delays - for the above case - in the dr= iver using DELAY(usec) macro, is there a maximum amount of time that the dr= iver is allowed to complete this function? I am concerned that if it takes = to too long I might run into a soft_lockup() situation. 2. Is it o.k to defer the processing in a separate in a separate thre= ad which can sleep() ? Thanks David S. ________________________________ This message and any attached documents contain information from QLogic Cor= poration or its wholly-owned subsidiaries that may be confidential. If you = are not the intended recipient, you may not read, copy, distribute, or use = this information. If you have received this transmission in error, please n= otify the sender immediately by reply e-mail and then delete this message. From owner-freebsd-current@FreeBSD.ORG Wed May 16 20:07:47 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0ED31065673; Wed, 16 May 2012 20:07:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id B2C7D8FC16; Wed, 16 May 2012 20:07:47 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 86D1DB948; Wed, 16 May 2012 16:07:46 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Wed, 16 May 2012 16:07:43 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <4FAF7343.8010808@cran.org.uk> <201205161050.35759.jhb@freebsd.org> <4FB3D351.6030804@FreeBSD.org> In-Reply-To: <4FB3D351.6030804@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201205161607.43286.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 16 May 2012 16:07:47 -0400 (EDT) Cc: Bruce Cran , freebsd-acpi@freebsd.org, freebsd-current , Jung-uk Kim Subject: Re: ACPI 'driver bug: Unable to set devclass' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 20:07:48 -0000 On Wednesday, May 16, 2012 12:18:25 pm Andriy Gapon wrote: > on 16/05/2012 17:50 John Baldwin said the following: > > On Tuesday, May 15, 2012 12:35:12 pm Andriy Gapon wrote: > >> Not sure what you disagree with... > >> First, the wildcard device is added to the child list during the walk. > >> Then, the unit 0 device is added to the list when acpi_timer identify is executed. > >> Then, the wildcard device is probed and gets unit number of zero. > >> Then, the fixed device is being probed and the unit number conflict arises. > >> > >> Am I misunderstanding something? > > > > Yes. The third step will see that unit 0 is already in use and shouldn't > > reuse unit 0. > > > > Looks like I missed the call to devclass_add_device() in make_device(). > > Your guess: > > I wonder if this is related to the recent changes to set the unit number for CPUs? > > seems to be true. > > The device_t-s created for CPUs have NULL driver name / devclass, but a > non-wildcard unit number. So when such a device with unit number 0 is probed by > acpi_timer we get a unit number conflict with acpi_timer0 pre-created via the > identify. > Similarly we get conflicts for acpi_sysresource driver, because we do an early > probe-and-attach for this driver and the attached devices get some unit numbers > (0, 1, etc). So when during the normal probe pass the "CPU" devices with matching > unit numbers are passed to the driver the conflict results. > > I guess that it is an unorthodox use of newbus to specify a unit number without > specifying a driver name... It's like saying "this device must be unit N whatever > driver claims it (be it kbdN or diskN) just because I say so". Not sure if this > ever makes sense and maybe we should prohibit such a combination (reject it earlier). > I guess that in this particular case we already know that the devices are really > CPU devices and are going to be claimed by acpi cpu driver. So we should pass > "cpu" as the name. Oh, whoops. Actually, the right way to do this I think is bus_hint_device_unit() (and/or, not make the unit number in cpuX mean anything at all, but use a separate ivar to track what PCPU_GET(cpuid) a given cpuX device corresponds to). I think the last approach is really the right way to fix this. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed May 16 21:18:37 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5CA71065673 for ; Wed, 16 May 2012 21:18:37 +0000 (UTC) (envelope-from joel@vnode.se) Received: from mail.vnode.se (mail.vnode.se [62.119.52.80]) by mx1.freebsd.org (Postfix) with ESMTP id 5E1928FC15 for ; Wed, 16 May 2012 21:18:37 +0000 (UTC) Received: from mail.vnode.se (localhost [127.0.0.1]) by mail.vnode.se (Postfix) with ESMTP id 53978E3F07B for ; Wed, 16 May 2012 23:18:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at vnode.se Received: from mail.vnode.se ([127.0.0.1]) by mail.vnode.se (mail.vnode.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIUcEsTFQigc for ; Wed, 16 May 2012 23:18:28 +0200 (CEST) Received: from goofy01.vnodelab.local (jd.benders.se [212.247.52.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.vnode.se (Postfix) with ESMTPSA id 15B65E3F079 for ; Wed, 16 May 2012 23:18:28 +0200 (CEST) Date: Wed, 16 May 2012 23:18:26 +0200 From: Joel Dahl To: current@freebsd.org Message-ID: <20120516211826.GI6475@goofy01.vnodelab.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: buildkernel fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 21:18:37 -0000 Hi, I did a buildworld+buildkernel on my workstation today and buildkernel fails with: cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/usr/src/sys -I/usr/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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror /usr/src/sys/dev/et/if_et.c Bus error (core dumped) *** [isci.ko.debug] Error code 138 1 error *** [all] Error code 2 1 error *** [modules-all] Error code 2 ctfconvert -L VERSION -g if_et.o 1 error *** [buildkernel] Error code 2 1 error *** [buildkernel] Error code 2 1 error My src tree is at the latest rev. No /usr/obj. I'm currently running CURRENT from May, 5th. Any ideas? -- Joel From owner-freebsd-current@FreeBSD.ORG Wed May 16 21:27:29 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A2A3E106564A for ; Wed, 16 May 2012 21:27:29 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from glenbarber.us (onyx.glenbarber.us [199.48.134.227]) by mx1.freebsd.org (Postfix) with SMTP id 4F97C8FC12 for ; Wed, 16 May 2012 21:27:29 +0000 (UTC) Received: (qmail 66218 invoked by uid 0); 16 May 2012 17:27:27 -0400 Received: from unknown (HELO glenbarber.us) (75.146.225.65) by 0 with SMTP; 16 May 2012 17:27:27 -0400 Date: Wed, 16 May 2012 17:27:25 -0400 From: Glen Barber To: Joel Dahl Message-ID: <20120516212725.GC1778@glenbarber.us> References: <20120516211826.GI6475@goofy01.vnodelab.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120516211826.GI6475@goofy01.vnodelab.local> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org Subject: Re: buildkernel fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 21:27:29 -0000 On Wed, May 16, 2012 at 11:18:26PM +0200, Joel Dahl wrote: > Hi, > > I did a buildworld+buildkernel on my workstation today and buildkernel fails with: > > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign > -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option > -nostdinc -I. -I/usr/src/sys -I/usr/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 -fno-omit-frame-pointer -mcmodel=kernel > -mno-red-zone -mno-mmx -mno-sse -msoft-float > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror > /usr/src/sys/dev/et/if_et.c > Bus error (core dumped) > *** [isci.ko.debug] Error code 138 > 1 error > *** [all] Error code 2 > 1 error > *** [modules-all] Error code 2 > ctfconvert -L VERSION -g if_et.o > 1 error > *** [buildkernel] Error code 2 > 1 error > *** [buildkernel] Error code 2 > 1 error > > My src tree is at the latest rev. No /usr/obj. I'm currently running > CURRENT from May, 5th. > > Any ideas? > Is this a GENERIC kernel? if_et requires miibus, so I'm curious if you have that device enabled in the kernel config. Glen From owner-freebsd-current@FreeBSD.ORG Wed May 16 21:41:11 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A41BA1065673 for ; Wed, 16 May 2012 21:41:11 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from springbank.echomania.com (andric.com [IPv6:2001:888:2003:1001:230:48ff:fe51:76b6]) by mx1.freebsd.org (Postfix) with ESMTP id 3D6B28FC15 for ; Wed, 16 May 2012 21:41:11 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at springbank.echomania.com Received: from [192.168.1.6] (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by springbank.echomania.com (Postfix) with ESMTPSA id 90179A7071; Wed, 16 May 2012 23:40:53 +0200 (CEST) Message-ID: <4FB41EF1.2010900@FreeBSD.org> Date: Wed, 16 May 2012 23:41:05 +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: Joel Dahl References: <20120516211826.GI6475@goofy01.vnodelab.local> In-Reply-To: <20120516211826.GI6475@goofy01.vnodelab.local> X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: buildkernel fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 21:41:11 -0000 On 2012-05-16 23:18, Joel Dahl wrote:> Hi, > I did a buildworld+buildkernel on my workstation today and buildkernel fails with: > > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign > -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option > -nostdinc -I. -I/usr/src/sys -I/usr/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 -fno-omit-frame-pointer -mcmodel=kernel > -mno-red-zone -mno-mmx -mno-sse -msoft-float > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror > /usr/src/sys/dev/et/if_et.c > Bus error (core dumped) > *** [isci.ko.debug] Error code 138 > 1 error > *** [all] Error code 2 > 1 error > *** [modules-all] Error code 2 > ctfconvert -L VERSION -g if_et.o > 1 error > *** [buildkernel] Error code 2 > 1 error > *** [buildkernel] Error code 2 > 1 error > > My src tree is at the latest rev. No /usr/obj. I'm currently running > CURRENT from May, 5th. I think you may be hitting the libthr issue that was introduced in r234947 (Thu May 3 09:17:31 2012 UTC) and fixed in r235068 (Sat May 5 23:51:24 2012 UTC). This caused some programs to randomly bomb out with bus errors or other weirdness. Please try building and installing lib/libthr (from your updated source tree) before running the rest of the world/kernel build. From owner-freebsd-current@FreeBSD.ORG Wed May 16 21:44:08 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5681B1065677 for ; Wed, 16 May 2012 21:44:08 +0000 (UTC) (envelope-from mueller23@insightbb.com) Received: from mail.insightbb.com (smtp2.insight.synacor.com [208.47.185.24]) by mx1.freebsd.org (Postfix) with ESMTP id 0C0348FC0A for ; Wed, 16 May 2012 21:44:07 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=1.1 cv=rkgxjMBYhgowM3sfH/RQsg+jECNF8WDRFC1Y2qIyHaM= c=1 sm=0 a=LG3yoKeVwxgA:10 a=jLN7EqiLvroA:10 a=MJqbyNkXAAAA:8 a=-l8puTzKIuh6iKCaa08A:9 a=8I2Wgc3K0f5_KlROYPoA:7 a=nmC91KWBhlNMp-H0:21 a=eEm4QFCvf5C5ZpgU:21 a=Q/oqmR4JO1zR3vNQamCQeQ==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp01.insight.synacor.com smtp.mail=mueller23@insightbb.com; spf=softfail; sender-id=softfail Authentication-Results: smtp01.insight.synacor.com header.from=mueller23@insightbb.com; sender-id=softfail Received-SPF: softfail (smtp01.insight.synacor.com: transitional domain insightbb.com does not designate 74.134.26.53 as permitted sender) Received: from [74.134.26.53] ([74.134.26.53:37091] helo=localhost) by mail.insightbb.com (envelope-from ) (ecelerity 2.2.2.40 r(29895/29896)) with ESMTP id C6/6A-21955-6AF14BF4; Wed, 16 May 2012 17:44:07 -0400 Date: Wed, 16 May 2012 17:44:06 -0400 Message-ID: From: "Thomas Mueller" To: freebsd-current@freebsd.org Subject: Re: FreeBSD 10 prognostication... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 21:44:08 -0000 Umm, it's about as factual as The Onion, except not as funny. FreeBSD never had to "jettison two thirds of its code base and start from scratch". Apple is not involved in FreeBSD development. No Mac OS X or Darwin version "includes" FreeBSD. FreeBSD and Mac OS X will never merge. FreeBSD was never acquired by WinDriver Systems or by anyone else, although a company named WindRiver Systems (makers of the embedded operating system VxWorks, not of Windows video drivers) did at one point acquire BSDI, which had previously acquired Walnut Creek CD-ROM, which was heavily involved in the early history of both FreeBSD and Slackware Linux. The remains of Walnut Creek CD-ROM and BSDI are now known as FreeBSD Mall and iXsystems (of PC-BSD and FreeNAS fame). DES -- Dag-Erling Smørgrav - des@des.no I was a long-time subscriber to Slackware going back to Walnut Creek CDROM days (Slackware 96 to the best of my memory, but < 3.0). I believe FreeBSD Mall and Slackware (store.slackware.com) are connected. I had a difficult time terminating my Slackware subscription, customer service ignoring me, thought I was going to have to have my credit card number changed to jilt Slackware. I noticed the similarity in subscription arrangement between FreeBSD Mall and store.slackware.com. Slackware package system is geared to binary packages rather than building from source, and there is no tracking of dependencies. A package can be installed even if dependencies are missing, and that even happened in Slackware releases, as I found when I tried unsuccessfully to run gnumeric many releases ago, got the message of missing library. Seeing the better package managers in FreeBSD (ports), NetBSD (pkgsrc, and ported to other (quasi-)Unix OSes), and several Linux distributions is what made me not want to go further with Slackware. Multimedia files failing to play may have been due to lack of proper package management. Tom From owner-freebsd-current@FreeBSD.ORG Wed May 16 22:24:45 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 517A4106566C for ; Wed, 16 May 2012 22:24:45 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from springbank.echomania.com (andric.com [IPv6:2001:888:2003:1001:230:48ff:fe51:76b6]) by mx1.freebsd.org (Postfix) with ESMTP id DDE928FC16 for ; Wed, 16 May 2012 22:24:44 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at springbank.echomania.com Received: from [192.168.1.6] (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by springbank.echomania.com (Postfix) with ESMTPSA id A8650A7071; Thu, 17 May 2012 00:24:26 +0200 (CEST) Message-ID: <4FB42926.1040103@FreeBSD.org> Date: Thu, 17 May 2012 00:24:38 +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: "O. Hartmann" References: <4FB3F663.8090308@zedat.fu-berlin.de> In-Reply-To: <4FB3F663.8090308@zedat.fu-berlin.de> X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Current FreeBSD Subject: Re: r235510: recent buildworld fail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 22:24:45 -0000 On 2012-05-16 20:48, O. Hartmann wrote:> When compiling world (make buildworld) I receive the bewlo error, which > seems very strange! > The error occured out of the blue on a FreeBSD 10.0-CURRENT/amd64 box. ... > /usr/obj/usr/src/tmp/usr/bin/ld: Warning: size of symbol > `_ZNSi6ignoreEv@GLIBCXX_3.4' changed from 243 in > /usr/obj/usr/src/tmp/usr/lib/libstdc++.so to 211 in > /usr/obj/usr/src/tmp/usr/lib/libstdc++.so > > looks like a "mixed up" between CLANG and legacy GCC 4.2.1, as far as I > remember this error was typical for a mismatch. Where did you read that? In any case, I think this may be a problem with one of the settings in your make.conf, not those in src.conf, specifically CFLAGS or CXXFLAGS. Can you please post those? From owner-freebsd-current@FreeBSD.ORG Wed May 16 23:02:17 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E247D106566B for ; Wed, 16 May 2012 23:02:16 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 69BAA8FC14 for ; Wed, 16 May 2012 23:02:16 +0000 (UTC) Received: by bkvi18 with SMTP id i18so1427545bkv.13 for ; Wed, 16 May 2012 16:02:15 -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:content-transfer-encoding; bh=DF5Pv4vzMqYoyWkvEEx3ssyrgPrwo69TZW5BQgudHqY=; b=okGYsoJQbxF1trBZ//gmp2yKkxlYV0wG1wnAc2t/YFLD0B9Nbr6cRwp/GSboMiggGr vFpz/I+lBYww2SnR7STKz7/uLxfdwBHPH8HP2kvAAnQlLUlZWIJ3in4olyITRhPXg/eJ y4TJyDJ66JKeKS0qnip7Tf3J4uXRdUwHH+aq31tm6DVmO47NE1haRCIzhpLvmq0YE11T 3wsls3vOhwbE/YY1u9uLZ9GigWRGPlu0mGKqZybCwe05TMws2n87LyUeIQqit6BYJTlJ VZmFrQopAZ1nCiPsVArDCIXIHb+JmsCCSPpRpetWZIZw/OAIaGG4rkwH52Dlqxcqi+f1 K8Rw== MIME-Version: 1.0 Received: by 10.204.151.199 with SMTP id d7mr1830047bkw.73.1337209335117; Wed, 16 May 2012 16:02:15 -0700 (PDT) Received: by 10.204.157.11 with HTTP; Wed, 16 May 2012 16:02:15 -0700 (PDT) In-Reply-To: References: Date: Wed, 16 May 2012 19:02:15 -0400 Message-ID: From: Outback Dingo To: Thomas Mueller Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 10 prognostication... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 23:02:17 -0000 On Wed, May 16, 2012 at 5:44 PM, Thomas Mueller w= rote: > Umm, it's about as factual as The Onion, except not as funny. =A0FreeBSD > never had to "jettison two thirds of its code base and start from > scratch". =A0Apple is not involved in FreeBSD development. =A0No Mac OS X= or > Darwin version "includes" FreeBSD. =A0FreeBSD and Mac OS X will never > merge. =A0FreeBSD was never acquired by WinDriver Systems or by anyone > else, although a company named WindRiver Systems (makers of the embedded > operating system VxWorks, not of Windows video drivers) did at one point > acquire BSDI, which had previously acquired Walnut Creek CD-ROM, which > was heavily involved in the early history of both FreeBSD and Slackware > Linux. =A0The remains of Walnut Creek CD-ROM and BSDI are now known as > FreeBSD Mall and iXsystems (of PC-BSD and FreeNAS fame). > > DES > -- > Dag-Erling Sm=F8rgrav - des@des.no > > I was a long-time subscriber to Slackware going back to Walnut Creek CDRO= M days (Slackware 96 to the best of my memory, but < 3.0). > > I believe FreeBSD Mall and Slackware (store.slackware.com) are connected.= =A0I had a difficult time terminating my Slackware subscription, customer = service ignoring me, thought I was going to have to have my credit card num= ber changed to jilt Slackware. =A0I noticed the similarity in subscription = arrangement between FreeBSD Mall and store.slackware.com. > > Slackware package system is geared to binary packages rather than buildin= g from source, and there is no tracking of dependencies. =A0A package can b= e installed even if dependencies are missing, and that even happened in Sla= ckware releases, as I found when I tried unsuccessfully to run gnumeric man= y releases ago, got the message of missing library. =A0Seeing the better pa= ckage managers in FreeBSD (ports), NetBSD (pkgsrc, and ported to other (qua= si-)Unix OSes), and several Linux distributions is what made me not want to= go further with Slackware. =A0Multimedia files failing to play may have be= en due to lack of proper package management. > > Tom Guess his next claim will be that the kernel was forked from minix, and userland came from QNX........... some people are just plain.... (biting my tongue) > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-current@FreeBSD.ORG Wed May 16 23:06:25 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 431C4106564A for ; Wed, 16 May 2012 23:06:25 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from mail28.syd.optusnet.com.au (mail28.syd.optusnet.com.au [211.29.133.169]) by mx1.freebsd.org (Postfix) with ESMTP id C8CE38FC0A for ; Wed, 16 May 2012 23:06:24 +0000 (UTC) Received: from server.rulingia.com (c220-239-254-65.belrs5.nsw.optusnet.com.au [220.239.254.65]) by mail28.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q4GN6Gnm012282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 17 May 2012 09:06:17 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q4GN6FpQ024752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 May 2012 09:06:15 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q4GN6FPC024751 for freebsd-current@freebsd.org; Thu, 17 May 2012 09:06:15 +1000 (EST) (envelope-from peter) Date: Thu, 17 May 2012 09:06:15 +1000 From: Peter Jeremy To: freebsd-current@freebsd.org Message-ID: <20120516230615.GC84284@server.rulingia.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hQiwHBbRI9kgIhsi" Content-Disposition: inline X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Subject: "make delete-old" performance. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 23:06:25 -0000 --hQiwHBbRI9kgIhsi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I recently ran "make delete-old" on a -current box and felt it was rather slow. That prompted me to do some more careful experiments. On one box where I have both 8-stable and 9-stable available, there was a ~30x slowdown (based on 5 runs, ignoring the first). I don't have a -current world on that box so I can't directly compare but on another pair of fairly similar boxes, I get a ~180x slowdown between 8-stable and -current (and that figure is probably optimistic since the -current box was idle whereas the 8-stable box was fairly busy). I realise that "make delete-old" isn't something you nede to do every day but going from sub-second to multi-minute duration is quite noticable. Can anyone suggest what has caused the change? --=20 Peter Jeremy --hQiwHBbRI9kgIhsi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk+0MucACgkQ/opHv/APuIeudgCfcizw5gqvdpbLmDYa/Dv3uhfV rnkAoIHZjs2Y8gB5q5iElLTBlqTjxAPE =ZttN -----END PGP SIGNATURE----- --hQiwHBbRI9kgIhsi-- From owner-freebsd-current@FreeBSD.ORG Thu May 17 01:11:41 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BCD2106567E for ; Thu, 17 May 2012 01:11:41 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 61E1A8FC18 for ; Thu, 17 May 2012 01:11:41 +0000 (UTC) Received: from pps.filterd (ltcfislmsgpa01 [127.0.0.1]) by ltcfislmsgpa01.fnfis.com (8.14.4/8.14.4) with SMTP id q4H0QOwq003552; Wed, 16 May 2012 20:11:35 -0500 Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa01.fnfis.com with ESMTP id 14vnxb07fp-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 16 May 2012 20:11:34 -0500 Received: from [10.0.0.105] (10.14.152.61) by smtp.fisglobal.com (10.132.206.17) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 16 May 2012 20:11:33 -0500 MIME-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset="us-ascii" From: Devin Teske In-Reply-To: <20120516230615.GC84284@server.rulingia.com> Date: Wed, 16 May 2012 18:11:32 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20120516230615.GC84284@server.rulingia.com> To: Peter Jeremy X-Mailer: Apple Mail (2.1257) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7580, 1.0.260, 0.0.0000 definitions=2012-05-16_10:2012-05-16, 2012-05-16, 1970-01-01 signatures=0 Cc: freebsd-current@freebsd.org Subject: Re: "make delete-old" performance. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 01:11:41 -0000 On May 16, 2012, at 4:06 PM, Peter Jeremy wrote: > I recently ran "make delete-old" on a -current box and felt it was > rather slow. That prompted me to do some more careful experiments. >=20 > On one box where I have both 8-stable and 9-stable available, there > was a ~30x slowdown (based on 5 runs, ignoring the first). I don't > have a -current world on that box so I can't directly compare but on > another pair of fairly similar boxes, I get a ~180x slowdown between > 8-stable and -current (and that figure is probably optimistic since > the -current box was idle whereas the 8-stable box was fairly busy). >=20 > I realise that "make delete-old" isn't something you nede to do every > day but going from sub-second to multi-minute duration is quite > noticable. Can anyone suggest what has caused the change? >=20 > --=20 > Peter Jeremy Right now, I believe the most useful comparison between systems is (assumin= g UFS is in play) the output of "tunefs -p" for the filesystem that the slo= wness is appearing on. SoftUpdates (and whether it's enabled or disabled) can play a huge differen= ce in how fast file-deletions are. Also note that SU+J may be interesting if-set in 9 (while not available in = 8). --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Thu May 17 02:39:06 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 920FD106566B; Thu, 17 May 2012 02:39:06 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from mail15.syd.optusnet.com.au (mail15.syd.optusnet.com.au [211.29.132.196]) by mx1.freebsd.org (Postfix) with ESMTP id 215F78FC1F; Thu, 17 May 2012 02:39:05 +0000 (UTC) Received: from server.rulingia.com (c220-239-254-65.belrs5.nsw.optusnet.com.au [220.239.254.65]) by mail15.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q4H2cvws014862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 May 2012 12:38:58 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q4H2cvZv026754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 May 2012 12:38:57 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q4H2cvWw026753; Thu, 17 May 2012 12:38:57 +1000 (EST) (envelope-from peter) Date: Thu, 17 May 2012 12:38:57 +1000 From: Peter Jeremy To: Devin Teske Message-ID: <20120517023857.GE84284@server.rulingia.com> References: <20120516230615.GC84284@server.rulingia.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5QAgd0e35j3NYeGe" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: Re: "make delete-old" performance. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 02:39:06 -0000 --5QAgd0e35j3NYeGe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-May-16 18:11:32 -0700, Devin Teske wrot= e: >Right now, I believe the most useful comparison between systems is >(assuming UFS is in play) the output of "tunefs -p" for the >filesystem that the slowness is appearing on. These systems all run ZFS and apart from the first run, there doesn't seem to be any disk activity at all. It looks like the kernel is the bottleneck. >SoftUpdates (and whether it's enabled or disabled) can play a huge >difference in how fast file-deletions are. I've already successfully run "make delete-old" so there are no actual file deletions. This is all just looking for files that aren't present. --=20 Peter Jeremy --5QAgd0e35j3NYeGe Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk+0ZMEACgkQ/opHv/APuIdBAACgvKuCI0Sh2SbX88ZMlQ/I1uHh qcUAoLZoa5Edo7BytFvSgq7HtUgaIQX+ =JNIk -----END PGP SIGNATURE----- --5QAgd0e35j3NYeGe-- From owner-freebsd-current@FreeBSD.ORG Thu May 17 02:57:21 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 916C81065670 for ; Thu, 17 May 2012 02:57:21 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 478548FC0C for ; Thu, 17 May 2012 02:57:20 +0000 (UTC) Received: by yenl8 with SMTP id l8so1761550yen.13 for ; Wed, 16 May 2012 19:57:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=/orYMFtMxMPUaTTlzrKek+hulkPGOddP/sbKDENqLr4=; b=FBvUF1dElhCPm8wS94LWBRireSdVJnJJg2dMAvrqwqMNnVBahlrWZynT7TZWmC2I/E cbWuQqvulgY6pMSGB6gJmgzuB6XMAFEnYG+l6aZJqEwYZyq7UXamJ5vKJcSOnPsS97YR h+ELoQGorwgMF2kmlN0psHBl4XSzc9+sbyW8Ja0qHecbdc5Jw0Pfx69the78X8puo6DC hebmzXu+jVEONaPg5M+H4QVzuupZQsVoMXWyMBWULFOcrw+6METexhgJgm5xTiDy3kOF ryE2I9G32gU3kwSJWxh4pegLouODCM4U57DFRLPpeKj8aRQhjtOFRCfi24Qb0FJJDBrD u6dw== Received: by 10.236.161.3 with SMTP id v3mr1980753yhk.128.1337223440512; Wed, 16 May 2012 19:57:20 -0700 (PDT) Received: from [192.168.0.2] (173-17-108-234.client.mchsi.com. [173.17.108.234]) by mx.google.com with ESMTPS id b58sm13958656yhh.16.2012.05.16.19.57.19 (version=SSLv3 cipher=OTHER); Wed, 16 May 2012 19:57:19 -0700 (PDT) Message-ID: <4FB4692D.6070304@gmail.com> Date: Wed, 16 May 2012 21:57:49 -0500 From: Chuck Burns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: FreeBSD 10 prognostication... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 02:57:21 -0000 On 5/16/2012 6:02 PM, Outback Dingo wrote: > > Guess his next claim will be that the kernel was forked from minix, > and userland came from QNX........... some people are just plain.... > (biting my tongue) > You guys DO realize that's a troll website, right? And you're being seriously trolled.. right? *shakes head and walks away* Chuck Burns From owner-freebsd-current@FreeBSD.ORG Thu May 17 03:18:47 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D795B106566C for ; Thu, 17 May 2012 03:18:47 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6C7698FC0C for ; Thu, 17 May 2012 03:18:47 +0000 (UTC) Received: by werg1 with SMTP id g1so1147750wer.13 for ; Wed, 16 May 2012 20:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; bh=mPX1aKP4Yyz5OISsUxiD6cRSKiTw/0OjvGYz/D3/gAg=; b=oLTjE4fFE+uTxBQMCkL76izqvoEtkAh6mzEpcTTfq7bmtXUd1DNzq3crckIeAidERx cUKqygsgKQMZZ2jDEcXuX0seUev0PMaPcPRxTUPc2lC+415awS5xgKPQvliGPqVhvKuo N62L4VowwN8CDC4UY7Ia4O0fCwkt1S72ttH9nle+r7Y+zAZj79hOq2TQFSu/GuzP7xNM mUmqalnAr6rsrNwJSqXNL3u89X7bJYDqb9GGlA7EJZ3jt7UEsLb8tYNlLk+um2olBw0e GxYeOqZDXpH/UVLAIRN2iWRHMqlkLe9pZBKq8LXdFrnDDOCyquCrTEf01c+KU+O/FhoZ mSUw== MIME-Version: 1.0 Received: by 10.180.82.136 with SMTP id i8mr13786224wiy.19.1337224726232; Wed, 16 May 2012 20:18:46 -0700 (PDT) Received: by 10.180.24.5 with HTTP; Wed, 16 May 2012 20:18:46 -0700 (PDT) Date: Wed, 16 May 2012 23:18:46 -0400 Message-ID: From: "b. f." To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Peter Jeremy Subject: Re: "make delete-old" performance. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 03:18:47 -0000 > I recently ran "make delete-old" on a -current box and felt it was > rather slow. That prompted me to do some more careful experiments. > > On one box where I have both 8-stable and 9-stable available, there > was a ~30x slowdown (based on 5 runs, ignoring the first). I don't > have a -current world on that box so I can't directly compare but on > another pair of fairly similar boxes, I get a ~180x slowdown between > 8-stable and -current (and that figure is probably optimistic since > the -current box was idle whereas the 8-stable box was fairly busy). > > I realise that "make delete-old" isn't something you nede to do every > day but going from sub-second to multi-minute duration is quite > noticable. Can anyone suggest what has caused the change? The slowdown is probably due - at least in part - to two factors: - the list of files to be checked for removal has grown substantially, because missing entries for old knobs and new entries for new knobs have been added; and - a new (and slower) method of checking was added in: http://svnweb.FreeBSD.org/base?view=revision&revision=220255 because the old method broke down with the size of the new lists of files. Some changes could be made to lessen the affect of the latter. b. From owner-freebsd-current@FreeBSD.ORG Thu May 17 06:16:08 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3CEA1065674; Thu, 17 May 2012 06:16:07 +0000 (UTC) (envelope-from conrads@cox.net) Received: from eastrmfepo103.cox.net (eastrmfepo103.cox.net [68.230.241.215]) by mx1.freebsd.org (Postfix) with ESMTP id 74D7C8FC17; Thu, 17 May 2012 06:16:07 +0000 (UTC) Received: from eastrmimpo306.cox.net ([68.230.241.238]) by eastrmfepo103.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20120517061601.TXGP8874.eastrmfepo103.cox.net@eastrmimpo306.cox.net>; Thu, 17 May 2012 02:16:01 -0400 Received: from serene.no-ip.org ([98.164.83.188]) by eastrmimpo306.cox.net with bizsmtp id AuG01j00A43nm9e02uG1AJ; Thu, 17 May 2012 02:16:01 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020207.4FB497A1.0032,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=1.1 cv=oNsJgJ5cAGpTaXJztO+k5aVuruDCBvmbzOAslSMJ7bY= c=1 sm=1 a=7qPX-ydv6MoA:10 a=G8Uczd0VNMoA:10 a=kj9zAlcOel0A:10 a=F4D4Y6gUi4XSUMrqnG4xkg==:17 a=kviXuzpPAAAA:8 a=nwSUVsnSYRXeURJCeeMA:9 a=CjuIK1q_8ugA:10 a=4vB-4DCPJfMA:10 a=F4D4Y6gUi4XSUMrqnG4xkg==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Received: from serene.no-ip.org (localhost [127.0.0.1]) by serene.no-ip.org (8.14.5/8.14.5) with ESMTP id q4H6FxbZ014581; Thu, 17 May 2012 01:16:00 -0500 (CDT) (envelope-from conrads@cox.net) Date: Thu, 17 May 2012 01:15:54 -0500 From: "Conrad J. Sabatier" To: freebsd-chromium@freebsd.org Message-ID: <20120517011554.5d16067e@serene.no-ip.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Chrome crashing system (amd64-10.0-CURRENT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 06:16:08 -0000 For the last week or so, I've been unable to run chrome. Any attempt to start it up will cause the system either to freeze up or reboot. To make matters worse, no trace of what's happening is anywhere to be found. Nothing in any log files. The system doesn't drop into the kernel debugger, either. It's either a hard freeze or sudden reboot. I've tried rebuilding the chromium port, with both clang and gcc 4.6, to no avail. I've also updated the system sources several times this week and remade world/kernel. Nothing seems to help. I'm totally stumped as to how to determine what's going on here. Any suggestions as to how to obtain some useful info? Thanks! -- Conrad J. Sabatier conrads@cox.net From owner-freebsd-current@FreeBSD.ORG Thu May 17 07:15:50 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 877EE1065670; Thu, 17 May 2012 07:15:50 +0000 (UTC) (envelope-from john@ixsystems.com) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) by mx1.freebsd.org (Postfix) with ESMTP id 68DCE8FC20; Thu, 17 May 2012 07:15:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.iXsystems.com (Postfix) with ESMTP id 6190C1C43; Thu, 17 May 2012 00:15:48 -0700 (PDT) Received: from mail.iXsystems.com ([127.0.0.1]) by localhost (mail.ixsystems.com [127.0.0.1]) (maiad, port 10024) with ESMTP id 75803-04-4; Thu, 17 May 2012 00:15:40 -0700 (PDT) Received: from thinkbsd.divinix.org (unknown [10.8.0.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id C75C81C28; Thu, 17 May 2012 00:11:43 -0700 (PDT) Date: Thu, 17 May 2012 00:11:42 -0700 From: John Hixson To: "Conrad J. Sabatier" Message-ID: <20120517071141.GL2701@thinkbsd.divinix.org> References: <20120517011554.5d16067e@serene.no-ip.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120517011554.5d16067e@serene.no-ip.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-chromium@freebsd.org, freebsd-current@freebsd.org Subject: Re: Chrome crashing system (amd64-10.0-CURRENT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 07:15:50 -0000 On Thu, May 17, 2012 at 01:15:54AM -0500, Conrad J. Sabatier wrote: > For the last week or so, I've been unable to run chrome. Any attempt > to start it up will cause the system either to freeze up or reboot. > > To make matters worse, no trace of what's happening is anywhere to be > found. Nothing in any log files. The system doesn't drop into the > kernel debugger, either. It's either a hard freeze or sudden reboot. > > I've tried rebuilding the chromium port, with both clang and gcc 4.6, > to no avail. I've also updated the system sources several times this > week and remade world/kernel. Nothing seems to help. > > I'm totally stumped as to how to determine what's going on here. Any > suggestions as to how to obtain some useful info? > To add to this, I've had the same problem on 10-CURRENT for several months now. -John From owner-freebsd-current@FreeBSD.ORG Thu May 17 08:55:35 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5DB77106566B; Thu, 17 May 2012 08:55:35 +0000 (UTC) (envelope-from joel@vnode.se) Received: from mail.vnode.se (mail.vnode.se [62.119.52.80]) by mx1.freebsd.org (Postfix) with ESMTP id 13E7F8FC12; Thu, 17 May 2012 08:55:35 +0000 (UTC) Received: from mail.vnode.se (localhost [127.0.0.1]) by mail.vnode.se (Postfix) with ESMTP id 1288CE3F07B; Thu, 17 May 2012 10:55:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at vnode.se Received: from mail.vnode.se ([127.0.0.1]) by mail.vnode.se (mail.vnode.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJsslbdQuYS4; Thu, 17 May 2012 10:55:30 +0200 (CEST) Received: from goofy01.vnodelab.local (jd.benders.se [212.247.52.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.vnode.se (Postfix) with ESMTPSA id C5DDEE3F079; Thu, 17 May 2012 10:55:30 +0200 (CEST) Date: Thu, 17 May 2012 10:55:29 +0200 From: Joel Dahl To: Dimitry Andric Message-ID: <20120517085529.GJ6475@goofy01.vnodelab.local> References: <20120516211826.GI6475@goofy01.vnodelab.local> <4FB41EF1.2010900@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FB41EF1.2010900@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org Subject: Re: buildkernel fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 08:55:35 -0000 On 16-05-2012 23:41, Dimitry Andric wrote: > On 2012-05-16 23:18, Joel Dahl wrote:> Hi, > > I did a buildworld+buildkernel on my workstation today and buildkernel fails with: > > > > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall > > -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes > > -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign > > -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option > > -nostdinc -I. -I/usr/src/sys -I/usr/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 -fno-omit-frame-pointer -mcmodel=kernel > > -mno-red-zone -mno-mmx -mno-sse -msoft-float > > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror > > /usr/src/sys/dev/et/if_et.c > > Bus error (core dumped) > > *** [isci.ko.debug] Error code 138 > > 1 error > > *** [all] Error code 2 > > 1 error > > *** [modules-all] Error code 2 > > ctfconvert -L VERSION -g if_et.o > > 1 error > > *** [buildkernel] Error code 2 > > 1 error > > *** [buildkernel] Error code 2 > > 1 error > > > > My src tree is at the latest rev. No /usr/obj. I'm currently running > > CURRENT from May, 5th. > > I think you may be hitting the libthr issue that was introduced in > r234947 (Thu May 3 09:17:31 2012 UTC) and fixed in r235068 (Sat May 5 > 23:51:24 2012 UTC). This caused some programs to randomly bomb out with > bus errors or other weirdness. > > Please try building and installing lib/libthr (from your updated source > tree) before running the rest of the world/kernel build. That fixed it. Thanks! -- Joel From owner-freebsd-current@FreeBSD.ORG Thu May 17 09:49:54 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F8EA1065670 for ; Thu, 17 May 2012 09:49:54 +0000 (UTC) (envelope-from joel@vnode.se) Received: from mail.vnode.se (mail.vnode.se [62.119.52.80]) by mx1.freebsd.org (Postfix) with ESMTP id 251E28FC12 for ; Thu, 17 May 2012 09:49:54 +0000 (UTC) Received: from mail.vnode.se (localhost [127.0.0.1]) by mail.vnode.se (Postfix) with ESMTP id 39A3CE3F07B for ; Thu, 17 May 2012 11:49:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at vnode.se Received: from mail.vnode.se ([127.0.0.1]) by mail.vnode.se (mail.vnode.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qlr3gyK1mzFk for ; Thu, 17 May 2012 11:49:50 +0200 (CEST) Received: from goofy01.vnodelab.local (jd.benders.se [212.247.52.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.vnode.se (Postfix) with ESMTPSA id CCC46E3F079 for ; Thu, 17 May 2012 11:49:50 +0200 (CEST) Date: Thu, 17 May 2012 11:49:49 +0200 From: Joel Dahl To: current@freebsd.org Message-ID: <20120517094949.GK6475@goofy01.vnodelab.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: FreeBSD and LDAP users, bug or feature? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 09:49:54 -0000 Hi, I have a machine running FreeBSD and openldap24-server, and several client machines running FreeBSD and openldap24-client and I'm experiencing a weird behaviour with adduser/pw. I create my LDAP users on the LDAP server, with UIDs starting at 5001. Local users on the server and clients should start at UID 1001, but this does not really work. If I use adduser to create a new local user on one of the client machines, it'll automatically be assigned with UID 5002 - which I find very confusing. This also breaks my LDAP setup, because when I add an LDAP user on the server, it'll also get UID 5002. Running pw usernext on one of the client machines confirms this behaviour: root@crashbox [~] pw usernext 5002:5002 But looking inside my /etc/passwd on the same machine reveals that the next free UID should be 1002. So pw is obviously getting information from LDAP and tries to be friendly and automatically gives me the next free UID from LDAP - which would make sense if pw could create LDAP users in addition to local users, but it can't. So right now I'm forced to check /etc/passwd on my machines each time I add a new local user and manually use that UID whenever I run adduser or pw. It works, but it's easy to shoot myself in the foot. Is this intended behaviour, or a bug? Or perhaps a misconfiguration on my part? I can provide configuration examples from my environment, but there really isn't much to see - I haven't made many changes besides installing the required applications from ports (openldap,nss_ldap,pam_ldap), changed my nsswitch.conf and a couple of files in /etc/pam.d/. -- Joel From owner-freebsd-current@FreeBSD.ORG Thu May 17 11:39:45 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 53CAD106564A; Thu, 17 May 2012 11:39:45 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 195A28FC08; Thu, 17 May 2012 11:39:43 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA10166; Thu, 17 May 2012 14:39:36 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4FB4E377.8050805@FreeBSD.org> Date: Thu, 17 May 2012 14:39:35 +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: Gleb Smirnoff , current@FreeBSD.org References: <4F1D18A5.8010006@FreeBSD.org> <20120123130743.GI16676@glebius.int.ru> <4F1D6830.60602@FreeBSD.org> <20120123162410.GN16676@glebius.int.ru> <20120123162606.GO16676@FreeBSD.org> <4F1D8E2B.30800@FreeBSD.org> <20120123164659.GQ16676@glebius.int.ru> <4F1D9128.3030501@FreeBSD.org> <20120124115424.GX16676@glebius.int.ru> <4F1E9F5F.8080209@FreeBSD.org> <20120124123245.GZ16676@glebius.int.ru> <4F2079B3.80305@FreeBSD.org> In-Reply-To: <4F2079B3.80305@FreeBSD.org> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: hackers@FreeBSD.org Subject: Re: new panic in cpu_reset() with WITNESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 11:39:45 -0000 on 25/01/2012 23:52 Andriy Gapon said the following: > on 24/01/2012 14:32 Gleb Smirnoff said the following: >> Yes, now: >> >> Rebooting... >> lock order reversal: >> 1st 0xffffffff80937140 smp rendezvous (smp rendezvous) @ /usr/src/head/sys/kern/kern_shutdown.c:542 >> 2nd 0xfffffe0001f5d838 uart_hwmtx (uart_hwmtx) @ /usr/src/head/sys/dev/uart/uart_cpu.h:92 >> panic: mtx_lock_spin: recursed on non-recursive mutex cnputs_mtx @ /usr/src/head/sys/kern/kern_cons.c:500 > > OK, so it's just a plain LOR between smp rendezvous and uart_hwmtx, no new > details... > > It's still intriguing to me why the LOR *doesn't* happen [*] with > stop_scheduler_on_panic=0. But I don't see a productive way to pursue this > investigation further. Salve Glebius! After your recent nudging I took yet another look at this issue and it seems that I have some findings. For those who might get interested here is a convenience reference to the whole thread on gmane: http://thread.gmane.org/gmane.os.freebsd.current/139307 A short summary. Prerequisites: an SMP x86 system, its kernel is configured with WITNESS && !WITNESS_SKIPSPIN (this is important) and a system uses serial console via uart. Then, if stop_scheduler_on_panic is set to zero the system can be rebooted without a problem. On the other hand, if stop_scheduler_on_panic is enabled, then the system first runs into a LOR when calling printf() in cpu_reset() and then it runs into a panic when printf is recursively called from witness(9) to report the LOR. The panic happens because of the recursion on cnputs_mtx, which should ensure that cnputs() output is not intermingled and which is not flagged to support recursion. There are two things about this report that greatly confused and puzzled me: 1. stop_scheduler_on_panic variable is used _only_ in panic(9). So how could it be possible that changing its value affects behavior of the system when panic(9) is not called?! 2. The LOR in question happens between "smp rendezvous" (smp_ipi_mtx) and "uart_hwmtx" (sc_hwmtx_s in uart core) spin locks. The order of these locks is actually predefined in witness order_lists[] such that uart_hwmtx must come before smp_ipi_mtx. But in the reboot path we first take smp_ipi_mtx in shutdown_reset(), then we call cpu_reset, then it calls printf and from there we get to uart_hwmtx for serial console output. So the order between these spinlocks is always violated in the x86 SMP reboot path. How come witness(9) doesn't _always_ detect this LOR? How come it didn't detect this LOR before any "stop scheduler" commits?! [Spoiler alert :-)] Turns out that the two puzzles above are closely related. Let's first list all the things that change when stop_scheduler_on_panic is enabled and a panic happens: - other CPUs are stopped (forced to spin) - interrupts on current CPU are disabled - by virtue of the above the current thread should be the only thread running (unless it executes a voluntary switch) - all locks are "busted", they are completely ignored / bypassed - by virtue of the above no lock invariants and witness checks are performed, so no lock order checking, no recursion checking, etc So, what I observe is this: when stop_scheduler_on_panic is disabled, the LOR is actually detected as it should be. witness(9) works properly here. Once the LOR is detected witness(9) wants to report it using printf(9). That's where we run into the cnputs_mtx recursion panic. It's all exactly as with stop_scheduler_on_panic enabled. Then panic(9) wants to report the panic using printf(9), which goes to cnputs() again, where _mtx_lock_spin_flags() detects locks recursion again (this is independent of witness(9)) and calls panic(9) again. Then panic(9) wants to report the panic using printf(9)... I assume that when the stack is exhausted we run into a double fault and dblfault_handler wants to print something again... Likely we eventually run into a triple fault which resets the machine. Although, I recall some old reports of machines hanging during reboot in a place suspiciously close to where the described ordeal happens... But if the machine doesn't hang we get a full appearance of the reset successfully happening (modulo some last messages missing). With stop_scheduler_on_panic enabled and all the locks being ignored we, of course, do not run into any secondary lock recursions and resulting panics. So the system is able to at least panic "gracefully" (still we should have just reported the LOR gracefully, no panic is required). Some obvious conclusions: - the "smp rendezvous" and "uart_hwmtx" LOR is real and it is the true cause of the problem; it should be fixed one way or other - either by correcting witness order_lists[] or by avoiding the LOR in shutdown_reset/cpu_reset; - because witness(9) uses printf(9) to report problems, it is very fragile to use witness with any locks that can be acquired under printf(9) - stop_scheduler_on_panic just uncovers the true bug There are probably other conclusions that can be made. I welcome any suggestions on how to fix the problems discovered. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu May 17 12:13:47 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21CF1106566B for ; Thu, 17 May 2012 12:13:47 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from springbank.echomania.com (andric.com [IPv6:2001:888:2003:1001:230:48ff:fe51:76b6]) by mx1.freebsd.org (Postfix) with ESMTP id AAFA18FC0C for ; Thu, 17 May 2012 12:13:46 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at springbank.echomania.com Received: from [192.168.1.6] (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by springbank.echomania.com (Postfix) with ESMTPSA id E2A9AA7071; Thu, 17 May 2012 14:13:24 +0200 (CEST) Message-ID: <4FB4EB74.5040009@FreeBSD.org> Date: Thu, 17 May 2012 14:13:40 +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: bf1783@gmail.com References: In-Reply-To: X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Peter Jeremy , "b. f." Subject: Re: "make delete-old" performance. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 12:13:47 -0000 On 2012-05-17 05:18, b. f. wrote:... > The slowdown is probably due - at least in part - to two factors: > > - the list of files to be checked for removal has grown substantially, > because missing entries for old knobs and new entries for new knobs > have been added; and > > - a new (and slower) method of checking was added in: > http://svnweb.FreeBSD.org/base?view=revision&revision=220255 > because the old method broke down with the size of the new lists of files. Hm, maybe it would have been better to fix make, so it can accept arbitrarily long lists, without segfaulting? There's such a thing as malloc(), and I simply don't believe any of those lists could be larger than a few hundred kilobytes. From owner-freebsd-current@FreeBSD.ORG Thu May 17 12:20:20 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECE47106564A for ; Thu, 17 May 2012 12:20:20 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id A46EE8FC12 for ; Thu, 17 May 2012 12:20:20 +0000 (UTC) Received: by yenl8 with SMTP id l8so2145192yen.13 for ; Thu, 17 May 2012 05:20:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=aRCEFEuKocSxjuJ2wACXAc7d5PsKGZ+Xha1WXmrARmY=; b=NEaEU9CTjOvFUg2o1CcXUAGl2L3cei3vKoYbBqCWlCvZ9KRYbFBcLv+BE5/8v+FLVD GYDoUa40/wzky7TfdUytYzn4nsOI2TqdD+QJIicbY7P8kTrxvgyjaomQh2ajzpciyPMw 68hChE7lvI6fXrJ5IQZz7BNQoI6j3fhA76cDh6yaJQrP6nVLtRcbmNrTojVCCLfR18of Z/rH//6nvSffRMX1flVyGs+uF4NGzLFfXVRO0/CQd1O4SOHNk/1OZCb9q47HdDoF5Pke pPqqJg4wJhRA8FYL6ZaCr3dFO6AT3FyL37nUVBjFhyr7IjPvEPvgFZs04cfOiuCGcP9V kNng== Received: by 10.236.185.10 with SMTP id t10mr7681652yhm.112.1337257219745; Thu, 17 May 2012 05:20:19 -0700 (PDT) Received: from [192.168.0.2] (173-17-108-234.client.mchsi.com. [173.17.108.234]) by mx.google.com with ESMTPS id u2sm23163189yhe.8.2012.05.17.05.20.18 (version=SSLv3 cipher=OTHER); Thu, 17 May 2012 05:20:19 -0700 (PDT) Message-ID: <4FB4ED23.2040603@gmail.com> Date: Thu, 17 May 2012 07:20:51 -0500 From: Chuck Burns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20120517011554.5d16067e@serene.no-ip.org> <20120517071141.GL2701@thinkbsd.divinix.org> In-Reply-To: <20120517071141.GL2701@thinkbsd.divinix.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Chrome crashing system (amd64-10.0-CURRENT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 12:20:21 -0000 On 5/17/2012 2:11 AM, John Hixson wrote: > On Thu, May 17, 2012 at 01:15:54AM -0500, Conrad J. Sabatier wrote: >> For the last week or so, I've been unable to run chrome. Any attempt >> to start it up will cause the system either to freeze up or reboot. > > To add to this, I've had the same problem on 10-CURRENT for several months > now. Are you guys building ports with clang? There's a known bug with google-perftools, when it's built with clang, chrome will crash upon launch. chrome itself can be built with any compiler, but if google-perftools is built with clang, crash! http://code.google.com/p/gperftools/issues/detail?id=394 -- Chuck Burns From owner-freebsd-current@FreeBSD.ORG Thu May 17 13:24:37 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B29FA106564A for ; Thu, 17 May 2012 13:24:37 +0000 (UTC) (envelope-from feld@feld.me) Received: from feld.me (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7AB9E8FC0C for ; Thu, 17 May 2012 13:24:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=In-Reply-To:Message-Id:From:Mime-Version:Date:References:Subject:To:Content-Type; bh=stx3MLhIL5ih+OrtUVQGEj98T4s98kstGJg5FxZofQI=; b=UTlcg1oosLm2hMBMJf14H5D1mQcp3J4Her5FBeS9rkeFXWQC0pJMOzntZONXJlKECKEFV6FTxtJ0fzZmk+6iweNE4EpvjDcs9D5duinLGPQqpXm4ep6AtzuRk+bwFQsD; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by feld.me with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SV0gx-000Bwr-6k for current@freebsd.org; Thu, 17 May 2012 08:24:37 -0500 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpa id 1337261064-3288-3287/5/11; Thu, 17 May 2012 13:24:24 +0000 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: current@freebsd.org References: <20120517094949.GK6475@goofy01.vnodelab.local> Date: Thu, 17 May 2012 08:24:24 -0500 Mime-Version: 1.0 From: Mark Felder Message-Id: In-Reply-To: <20120517094949.GK6475@goofy01.vnodelab.local> User-Agent: Opera Mail/11.64 (FreeBSD) X-SA-Score: -1.5 Cc: Subject: Re: FreeBSD and LDAP users, bug or feature? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 13:24:37 -0000 Check man adduser.conf(5) There is an option for "uidstart" which should do what you want. If you set it to 1000 every time you run "adduser" it will show: # adduser Username: foo Full name: bar Uid [1000]: Don't worry -- it's just showing you the starting range. If there is already a UID of 1000 in use it will choose the next available. It's pretty nice because it even fills in holes if you remove users and then add new ones. However, that might be undesirable if you happen to leave files around from previous users and the new user gets the owning UID of those files.... hth From owner-freebsd-current@FreeBSD.ORG Thu May 17 14:07:40 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 446D91065670; Thu, 17 May 2012 14:07:40 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 266D78FC15; Thu, 17 May 2012 14:07:38 +0000 (UTC) Received: by lbon10 with SMTP id n10so1846079lbo.13 for ; Thu, 17 May 2012 07:07:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=FVoHhCR4eLsHfe96Y2UqH2+D56DRqpTAsa8JIpwIPGM=; b=03+fJiwLCRGYfprZtXPDiXZ9MGQmAardCi16C9/Zlyk7iicOGCohj4DeBbK+OWrlZp R0mvxjSDLTD1gYEU89CHa2gpXJjClIfVIrucipj9T/8y+5Sg4/GDb1hKDO+D6NDzN5bN Lz9sw8gFMJ4tFFAedN86Chrh7z2dubPVYG5Qu6AG1cVpFWA1JMevoMrgUITX7kqODc0b JD9zwl+bxTHZAyNy17phW8VNMM73AVwInrlDxyNDw7K7f85wfEb7GSil3Z6JyCthvm8s W4ZqiqDyDlw34SdJrNEBIGyKVDRYO7jLEzZS6O9FFtPbcccLkIGL41zXlVN+EsbBkIKd E17g== MIME-Version: 1.0 Received: by 10.152.135.105 with SMTP id pr9mr7242041lab.37.1337263657727; Thu, 17 May 2012 07:07:37 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.27.65 with HTTP; Thu, 17 May 2012 07:07:37 -0700 (PDT) In-Reply-To: <4FB4E377.8050805@FreeBSD.org> References: <4F1D18A5.8010006@FreeBSD.org> <20120123130743.GI16676@glebius.int.ru> <4F1D6830.60602@FreeBSD.org> <20120123162410.GN16676@glebius.int.ru> <20120123162606.GO16676@FreeBSD.org> <4F1D8E2B.30800@FreeBSD.org> <20120123164659.GQ16676@glebius.int.ru> <4F1D9128.3030501@FreeBSD.org> <20120124115424.GX16676@glebius.int.ru> <4F1E9F5F.8080209@FreeBSD.org> <20120124123245.GZ16676@glebius.int.ru> <4F2079B3.80305@FreeBSD.org> <4FB4E377.8050805@FreeBSD.org> Date: Thu, 17 May 2012 15:07:37 +0100 X-Google-Sender-Auth: xeySoIxqn6F6IL_1txyq-7se1RA Message-ID: From: Attilio Rao To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: hackers@freebsd.org, Gleb Smirnoff , current@freebsd.org Subject: Re: new panic in cpu_reset() with WITNESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 14:07:40 -0000 2012/5/17, Andriy Gapon : > on 25/01/2012 23:52 Andriy Gapon said the following: >> on 24/01/2012 14:32 Gleb Smirnoff said the following: >>> Yes, now: >>> >>> Rebooting... >>> lock order reversal: >>> 1st 0xffffffff80937140 smp rendezvous (smp rendezvous) @ >>> /usr/src/head/sys/kern/kern_shutdown.c:542 >>> 2nd 0xfffffe0001f5d838 uart_hwmtx (uart_hwmtx) @ >>> /usr/src/head/sys/dev/uart/uart_cpu.h:92 >>> panic: mtx_lock_spin: recursed on non-recursive mutex cnputs_mtx @ >>> /usr/src/head/sys/kern/kern_cons.c:500 >> >> OK, so it's just a plain LOR between smp rendezvous and uart_hwmtx, no >> new >> details... >> >> It's still intriguing to me why the LOR *doesn't* happen [*] with >> stop_scheduler_on_panic=0. But I don't see a productive way to pursue >> this >> investigation further. > > Salve Glebius! > After your recent nudging I took yet another look at this issue and it seems > that > I have some findings. > > For those who might get interested here is a convenience reference to the > whole > thread on gmane: http://thread.gmane.org/gmane.os.freebsd.current/139307 > > A short summary. > Prerequisites: an SMP x86 system, its kernel is configured with WITNESS && > !WITNESS_SKIPSPIN (this is important) and a system uses serial console via > uart. > Then, if stop_scheduler_on_panic is set to zero the system can be rebooted > without > a problem. On the other hand, if stop_scheduler_on_panic is enabled, then > the > system first runs into a LOR when calling printf() in cpu_reset() and then > it runs > into a panic when printf is recursively called from witness(9) to report the > LOR. > The panic happens because of the recursion on cnputs_mtx, which should > ensure > that cnputs() output is not intermingled and which is not flagged to > support > recursion. > > There are two things about this report that greatly confused and puzzled > me: > 1. stop_scheduler_on_panic variable is used _only_ in panic(9). So how > could it > be possible that changing its value affects behavior of the system when > panic(9) > is not called?! > > 2. The LOR in question happens between "smp rendezvous" (smp_ipi_mtx) and > "uart_hwmtx" (sc_hwmtx_s in uart core) spin locks. The order of these locks > is > actually predefined in witness order_lists[] such that uart_hwmtx must come > before > smp_ipi_mtx. But in the reboot path we first take smp_ipi_mtx in > shutdown_reset(), then we call cpu_reset, then it calls printf and from > there we > get to uart_hwmtx for serial console output. So the order between these > spinlocks > is always violated in the x86 SMP reboot path. > How come witness(9) doesn't _always_ detect this LOR? > How come it didn't detect this LOR before any "stop scheduler" commits?! > > [Spoiler alert :-)] > > Turns out that the two puzzles above are closely related. > Let's first list all the things that change when stop_scheduler_on_panic is > enabled and a panic happens: > - other CPUs are stopped (forced to spin) > - interrupts on current CPU are disabled > - by virtue of the above the current thread should be the only thread > running > (unless it executes a voluntary switch) > - all locks are "busted", they are completely ignored / bypassed > - by virtue of the above no lock invariants and witness checks are > performed, so > no lock order checking, no recursion checking, etc > > So, what I observe is this: when stop_scheduler_on_panic is disabled, the > LOR is > actually detected as it should be. witness(9) works properly here. Once > the LOR > is detected witness(9) wants to report it using printf(9). That's where we > run > into the cnputs_mtx recursion panic. It's all exactly as with > stop_scheduler_on_panic enabled. Then panic(9) wants to report the panic > using > printf(9), which goes to cnputs() again, where _mtx_lock_spin_flags() > detects > locks recursion again (this is independent of witness(9)) and calls > panic(9) > again. Then panic(9) wants to report the panic using printf(9)... > I assume that when the stack is exhausted we run into a double fault and > dblfault_handler wants to print something again... Likely we eventually run > into > a triple fault which resets the machine. Although, I recall some old > reports of > machines hanging during reboot in a place suspiciously close to where the > described ordeal happens... > But if the machine doesn't hang we get a full appearance of the reset > successfully > happening (modulo some last messages missing). > > With stop_scheduler_on_panic enabled and all the locks being ignored we, of > course, do not run into any secondary lock recursions and resulting panics. > So > the system is able to at least panic "gracefully" (still we should have > just > reported the LOR gracefully, no panic is required). > > Some obvious conclusions: > - the "smp rendezvous" and "uart_hwmtx" LOR is real and it is the true cause > of > the problem; it should be fixed one way or other - either by correcting > witness > order_lists[] or by avoiding the LOR in shutdown_reset/cpu_reset; > - because witness(9) uses printf(9) to report problems, it is very fragile > to use > witness with any locks that can be acquired under printf(9) > - stop_scheduler_on_panic just uncovers the true bug Thanks for working on this. My thoughts on the matter: - We should not printf() in cpu_reset() which is supposed to be a very low level primitives, usable by any context. Acquiring console spinlocks there is not really a wise choice. - I'd like to see witness being based on an alternative approach, but we may find something that doesn't wrap up (thus a bufring ala KTR is not appropriate) and can work also in SMP context (thus a lockfree algorithm is not appropriate). I don't have any good solution for this on the top of my idea, but of course, relying on a path acquiring locks for a lock protector is not a great idea. The only other thing we may do is marking locks involved in the printf() path with NO_WITNESS, but that of course won't solve the deadlock problem itself. - On a related note, I once had a patch that was having BSP recovering from deadlock in the reset code and panic/print informations, under DIAGNOSTIC. I may find it again and post here. Definitively, I think that we need to make cpu_reset() locks agnostic and if you agree I can make a patch for that. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Thu May 17 15:00:38 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 503D0106566B; Thu, 17 May 2012 15:00:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1CE318FC0C; Thu, 17 May 2012 15:00:38 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 86E24B948; Thu, 17 May 2012 11:00:37 -0400 (EDT) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Thu, 17 May 2012 10:05:19 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <4FAF7343.8010808@cran.org.uk> <4FB3D351.6030804@FreeBSD.org> <201205161607.43286.jhb@freebsd.org> In-Reply-To: <201205161607.43286.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201205171005.19736.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 17 May 2012 11:00:37 -0400 (EDT) Cc: Bruce Cran , freebsd-current , Jung-uk Kim , Andriy Gapon Subject: Re: ACPI 'driver bug: Unable to set devclass' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 15:00:38 -0000 On Wednesday, May 16, 2012 4:07:43 pm John Baldwin wrote: > On Wednesday, May 16, 2012 12:18:25 pm Andriy Gapon wrote: > > on 16/05/2012 17:50 John Baldwin said the following: > > > On Tuesday, May 15, 2012 12:35:12 pm Andriy Gapon wrote: > > >> Not sure what you disagree with... > > >> First, the wildcard device is added to the child list during the walk. > > >> Then, the unit 0 device is added to the list when acpi_timer identify is executed. > > >> Then, the wildcard device is probed and gets unit number of zero. > > >> Then, the fixed device is being probed and the unit number conflict arises. > > >> > > >> Am I misunderstanding something? > > > > > > Yes. The third step will see that unit 0 is already in use and shouldn't > > > reuse unit 0. > > > > > > > Looks like I missed the call to devclass_add_device() in make_device(). > > > > Your guess: > > > I wonder if this is related to the recent changes to set the unit number for CPUs? > > > > seems to be true. > > > > The device_t-s created for CPUs have NULL driver name / devclass, but a > > non-wildcard unit number. So when such a device with unit number 0 is probed by > > acpi_timer we get a unit number conflict with acpi_timer0 pre-created via the > > identify. > > Similarly we get conflicts for acpi_sysresource driver, because we do an early > > probe-and-attach for this driver and the attached devices get some unit numbers > > (0, 1, etc). So when during the normal probe pass the "CPU" devices with matching > > unit numbers are passed to the driver the conflict results. > > > > I guess that it is an unorthodox use of newbus to specify a unit number without > > specifying a driver name... It's like saying "this device must be unit N whatever > > driver claims it (be it kbdN or diskN) just because I say so". Not sure if this > > ever makes sense and maybe we should prohibit such a combination (reject it earlier). > > I guess that in this particular case we already know that the devices are really > > CPU devices and are going to be claimed by acpi cpu driver. So we should pass > > "cpu" as the name. > > Oh, whoops. Actually, the right way to do this I think is bus_hint_device_unit() > (and/or, not make the unit number in cpuX mean anything at all, but use a separate > ivar to track what PCPU_GET(cpuid) a given cpuX device corresponds to). I think > the last approach is really the right way to fix this. I haven't been able to try this yet, but I have a first cut at www.freebsd.org/~jhb/patches/acpi_cpu.patch -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu May 17 15:00:42 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2DDE4106564A; Thu, 17 May 2012 15:00:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id F32708FC18; Thu, 17 May 2012 15:00:38 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3FB1EB94E; Thu, 17 May 2012 11:00:38 -0400 (EDT) From: John Baldwin To: freebsd-drivers@freebsd.org Date: Thu, 17 May 2012 10:33:37 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <75E1A2A7D185F841A975979B0906BBA67C7A229F49@AVEXMB1.qlogic.org> In-Reply-To: <75E1A2A7D185F841A975979B0906BBA67C7A229F49@AVEXMB1.qlogic.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201205171033.37636.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 17 May 2012 11:00:38 -0400 (EDT) Cc: "freebsd-net@freebsd.org" , "freebsd-current@freebsd.org \(freebsd-current@FreeBSD.org\)" , "davidcs@FreeBSD.org" , David Somayajulu Subject: Re: Ethernet Drivers: Question on ifp->if_ioctl invocation for SIOCADDMULTI and SIOCDELMULTI X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 15:00:42 -0000 On Wednesday, May 16, 2012 2:41:25 pm David Somayajulu wrote: > Hi All, > When ifp->if_ioctl() is invoked for the ioctl cmd SIOCADDMULTI, > > > > IN_MULTI_LOCK() is called in one of the functions in_joingroup() in the caller stack. > > > > >From netinet/in_var.h, line 357 : #define IN_MULTI_LOCK() mtx_lock(&in_multi_mtx) > > > > >From netinet/in_mcast.c > 1098 in_joingroup(struct ifnet *ifp, const struct in_addr *gina, > 1099 /*const*/ struct in_mfilter *imf, struct in_multi **pinm) > 1100 { > 1101 int error; > 1102 > 1103 IN_MULTI_LOCK(); > 1104 error = in_joingroup_locked(ifp, gina, imf, pinm); > 1105 IN_MULTI_UNLOCK(); > 1106 > > This is also the case for SIOCDELMULTI, where the function holding "in_multi_mtx" lock is in_leavegroup() > > This poses a problem in the driver in that the hardware dependent function performing it, is not allowed to sleep() in case it needs to poll some state. > > Question: > > 1. If I want to implement any delays - for the above case - in the driver using DELAY(usec) macro, is there a maximum amount of time that the driver is allowed to complete this function? I am concerned that if it takes to too long I might run into a soft_lockup() situation. > > 2. Is it o.k to defer the processing in a separate in a separate thread which can sleep() ? You can always queue a task to update the MAC table if you need to use a sleep. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu May 17 15:10:00 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AD1A1065673 for ; Thu, 17 May 2012 15:10:00 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from springbank.echomania.com (andric.com [IPv6:2001:888:2003:1001:230:48ff:fe51:76b6]) by mx1.freebsd.org (Postfix) with ESMTP id AC2C78FC19 for ; Thu, 17 May 2012 15:09:59 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at springbank.echomania.com Received: from [192.168.1.6] (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by springbank.echomania.com (Postfix) with ESMTPSA id E4234A7071; Thu, 17 May 2012 17:09:40 +0200 (CEST) Message-ID: <4FB514C3.5020908@FreeBSD.org> Date: Thu, 17 May 2012 17:09:55 +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: Chuck Burns References: <20120517011554.5d16067e@serene.no-ip.org> <20120517071141.GL2701@thinkbsd.divinix.org> <4FB4ED23.2040603@gmail.com> In-Reply-To: <4FB4ED23.2040603@gmail.com> X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Chrome crashing system (amd64-10.0-CURRENT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 15:10:00 -0000 On 2012-05-17 14:20, Chuck Burns wrote:> On 5/17/2012 2:11 AM, John Hixson wrote: >> On Thu, May 17, 2012 at 01:15:54AM -0500, Conrad J. Sabatier wrote: >>> For the last week or so, I've been unable to run chrome. Any attempt >>> to start it up will cause the system either to freeze up or reboot. >> >> To add to this, I've had the same problem on 10-CURRENT for several months >> now. > > Are you guys building ports with clang? There's a known bug with > google-perftools, when it's built with clang, chrome will crash upon launch. Please note the OP is talking about a complete system crash and/or restart, not just chrome itself crashing. > chrome itself can be built with any compiler, but if google-perftools is > built with clang, crash! > > http://code.google.com/p/gperftools/issues/detail?id=394 There seem to be several problems with gperftools; compiled with gcc 4.2.1, there are at least 3 failures in its test suite (of 40 tests). Compiled with gcc 4.7 it doesn't even compile, since it erroneously tries to use backtrace_symbols(), which we don't provide. Compiled with clang 3.1, there are 12 failures. I assume this is because it is doing all kinds of tricky things with threads and re-implementing Yet Another Malloc, which seems to be very hard, as recent experience with head has shown. :) In any case, a good start would be to attempt to diagnose all the test failures that occur with clang only, to see if they indicate a problem in gperftools or clang itself. From owner-freebsd-current@FreeBSD.ORG Thu May 17 15:34:01 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 977871065676; Thu, 17 May 2012 15:34:01 +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 5441A8FC1E; Thu, 17 May 2012 15:34:00 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA12182; Thu, 17 May 2012 18:33:57 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4FB51A64.6090906@FreeBSD.org> Date: Thu, 17 May 2012 18:33:56 +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: John Baldwin References: <4FAF7343.8010808@cran.org.uk> <4FB3D351.6030804@FreeBSD.org> <201205161607.43286.jhb@freebsd.org> <201205171005.19736.jhb@freebsd.org> In-Reply-To: <201205171005.19736.jhb@freebsd.org> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Bruce Cran , freebsd-acpi@FreeBSD.org, freebsd-current , Jung-uk Kim Subject: Re: ACPI 'driver bug: Unable to set devclass' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 15:34:01 -0000 on 17/05/2012 17:05 John Baldwin said the following: > On Wednesday, May 16, 2012 4:07:43 pm John Baldwin wrote: >> Oh, whoops. Actually, the right way to do this I think is bus_hint_device_unit() >> (and/or, not make the unit number in cpuX mean anything at all, but use a separate >> ivar to track what PCPU_GET(cpuid) a given cpuX device corresponds to). I think >> the last approach is really the right way to fix this. > > I haven't been able to try this yet, but I have a first cut at > www.freebsd.org/~jhb/patches/acpi_cpu.patch > The patch has not been compile-tested? :) -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu May 17 15:49:58 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3188106564A; Thu, 17 May 2012 15:49:58 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id 7DDA98FC19; Thu, 17 May 2012 15:49:58 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id D38551DD4FB; Thu, 17 May 2012 17:49:56 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id BAC782847A; Thu, 17 May 2012 17:49:56 +0200 (CEST) Date: Thu, 17 May 2012 17:49:56 +0200 From: Jilles Tjoelker To: Dimitry Andric Message-ID: <20120517154956.GA63826@stack.nl> References: <4FB4EB74.5040009@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FB4EB74.5040009@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: bf1783@gmail.com, freebsd-current@FreeBSD.org, Peter Jeremy , "b. f." Subject: Re: "make delete-old" performance. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 15:49:59 -0000 On Thu, May 17, 2012 at 02:13:40PM +0200, Dimitry Andric wrote: > On 2012-05-17 05:18, b. f. wrote:... > > The slowdown is probably due - at least in part - to two factors: > > - the list of files to be checked for removal has grown substantially, > > because missing entries for old knobs and new entries for new knobs > > have been added; and > > - a new (and slower) method of checking was added in: > > http://svnweb.FreeBSD.org/base?view=revision&revision=220255 > > because the old method broke down with the size of the new lists of files. > Hm, maybe it would have been better to fix make, so it can accept > arbitrarily long lists, without segfaulting? There's such a thing as > malloc(), and I simply don't believe any of those lists could be larger > than a few hundred kilobytes. Alternatively, make could be fixed so that the original code works. Although an invocation like sh -c 'for file in VERY_LONG_LIST; do something; done' will bump into {ARG_MAX}, the shell itself does not have a fixed limitation so longer command lines can be written to a temporary file and passed to sh that way. In some cases (such as with -j), make always uses a temporary file, slowing things down and obscuring ps output. At the cost of needing the temporary file named a bit longer, it is better to pass the pathname to sh rather than feeding the script on standard input: this avoids interfering with terminal input and is potentially faster. The code currently in Makefile.inc1 can probably be sped up by passing the output of the make -V command to something like xargs sh -c 'for file do rm -i "${DESTDIR}/${file}"; done' sh instead of the xargs -n1 | while read file; do ...; done loop. (Note the second "sh" at the end, which serves as a value for $0 so all strings from xargs become positional parameters.) -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Thu May 17 15:51:29 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3B801065674 for ; Thu, 17 May 2012 15:51:29 +0000 (UTC) (envelope-from pfg@freebsd.org) Received: from nm3-vm2.bullet.mail.ne1.yahoo.com (nm3-vm2.bullet.mail.ne1.yahoo.com [98.138.91.19]) by mx1.freebsd.org (Postfix) with SMTP id 870A38FC12 for ; Thu, 17 May 2012 15:51:29 +0000 (UTC) Received: from [98.138.90.52] by nm3.bullet.mail.ne1.yahoo.com with NNFMP; 17 May 2012 15:44:34 -0000 Received: from [98.138.226.63] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 17 May 2012 15:44:34 -0000 Received: from [127.0.0.1] by smtp214.mail.ne1.yahoo.com with NNFMP; 17 May 2012 15:44:33 -0000 X-Yahoo-Newman-Id: 974815.37195.bm@smtp214.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 9S.klaEVM1mz9Tf8XNLidcKpoJdz4c2WpBpjM.rr0YmMGc_ c8ROE3uKHvOtSw6f.ajgKUbqTf5ejBYgIuPOSZh_KP23vZFr_2jb9uydfE4_ hD7RGvGL8aboU1l9IsO8cImP4emSHvVjWbojf22UJFtlTK_p2jcBeih3xPW1 _ppvzf2cjO.AzBXtOMupkPL5_idLvO8WG9RYaT9Lqwt8ezkWrAv.ZGzzxXja FBiA94phwP.xeRiAw2tMRr9YFNdYQpGbR81OxAMi_wT6t8s0h0rq6F_Ad7mn LU03kuM145FDT_HPnTBQBzOxC8cQR6aoVsr0Gp6EOeuPpk7Lixwmp0HmwNen MwmL0LlaNR63gBx3fkoDOl.DIpLjS5rx23a41JqnAaYm4m5bRNyeLRHYQmc5 spOykESWpo_1QIUakE66CBCDIUSfBjo43o6Bf8lxsUeMsqP4WqACRIUuWCEz 65wJhiDkQ8e_id8Q0IaTF3TfhZ6hSC4rGkTE8mb9guurJZsyrZTn2QSAm.6K VqmNzSA-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Received: from [192.168.10.103] (pfg@200.118.157.7 with plain) by smtp214.mail.ne1.yahoo.com with SMTP; 17 May 2012 08:44:33 -0700 PDT Message-ID: <4FB51CDF.3040306@FreeBSD.org> Date: Thu, 17 May 2012 10:44:31 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120328 Thunderbird/10.0.3 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org, freebsd-toolchain@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: GCC update for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 15:51:30 -0000 Hi; I took a bunch of patches that were merged into the GCC 4.1 branch (under GPLv2) and prepared a patch for merging them into our base gcc. These are supposed to be bug fixes only. You can get the patch here: http://people.freebsd.org/~pfg/patches/patch-contrib-gcc And, for those really interested, the log is here: http://people.freebsd.org/~pfg/patches/gcc41-pr-log It may be my imagination but the patch seems to be causing more warnings than usual and it breaks the kernel here: ____ $ make cc -c -O2 -Os -pipe -fno-strict-aliasing -march=athlon64 -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I../../.. -I../../../contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror ../../../cam/scsi/scsi_sa.c cc1: warnings being treated as errors ../../../cam/scsi/scsi_sa.c: In function 'samount': ../../../cam/scsi/scsi_sa.c:1887: warning: 'comp_supported' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:1888: warning: 'write_protect' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:1887: warning: 'comp_enabled' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:2728: warning: 'current_speed' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:2728: note: 'current_speed' was declared here ../../../cam/scsi/scsi_sa.c:2727: warning: 'current_density' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:2727: note: 'current_density' was declared here ../../../cam/scsi/scsi_sa.c:2725: warning: 'current_blocksize' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:2725: note: 'current_blocksize' was declared here ../../../cam/scsi/scsi_sa.c:2728: warning: 'current_speed' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:2728: note: 'current_speed' was declared here ../../../cam/scsi/scsi_sa.c:2725: warning: 'current_blocksize' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:2725: note: 'current_blocksize' was declared here ../../../cam/scsi/scsi_sa.c:2728: warning: 'current_speed' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:2728: note: 'current_speed' was declared here ../../../cam/scsi/scsi_sa.c:2725: warning: 'current_blocksize' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:2725: note: 'current_blocksize' was declared here ../../../cam/scsi/scsi_sa.c:2728: warning: 'current_speed' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:2728: note: 'current_speed' was declared here ../../../cam/scsi/scsi_sa.c:2725: warning: 'current_blocksize' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:2725: note: 'current_blocksize' was declared here *** Error code 1 ... ____ Other stuff I tested (Apache OpenOffice) builds fine. cheers, Pedro. From owner-freebsd-current@FreeBSD.ORG Thu May 17 15:55:51 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25E531065674 for ; Thu, 17 May 2012 15:55:51 +0000 (UTC) (envelope-from evanm@google.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id C1E7B8FC0A for ; Thu, 17 May 2012 15:55:50 +0000 (UTC) Received: by ggnm2 with SMTP id m2so2449735ggn.13 for ; Thu, 17 May 2012 08:55:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-system-of-record; bh=Jq9sS4phQMpUx+Yf9kxsBqJiYU93L+te6GTn2UbMUFA=; b=Pjmjn4umC2UFhvhDDonawrZ4fSVx3ddr5WUUPUiKONZcmesvRu592rG4pZC/kHSQXE zmeiQ+Lr9Z2gA3WCg63g+P7gZ02kqOaz85S9v3LmaO7F6O1rORKfb+kaa5AwJdNOKK3k rV60nleadwqTznGFGCa4+R83jLVa7+dMUcefuPGHIMTNvs1ovyi5g/CJduXsTzSwCdLy wgcGwZ7NGFHCvxgb3FzDGcWb6VO/GiSF2XnSO4qR/j7/RZNqHAMbfu9yRtw+BVmnA3o2 2Au1urcK6clazG3VSU+uTi0YPTjLd6Y/5Vpy5f6JDi73ugJzrYqa649sOEVB07Bjmme6 GNMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-system-of-record:x-gm-message-state; bh=Jq9sS4phQMpUx+Yf9kxsBqJiYU93L+te6GTn2UbMUFA=; b=PeDMRWNMxqANQzbCRs14AaTqNyEghLR8cwJuNGLJTJMSdLMLSYCU/PifERtKLOVWlg nyQ6jSM8aDef75f04UinCQ77jMOCu88V1H3AZH/DaOfwaTOiHwGsWJhIRZGACjqnjImu 4ljHpCXUFDYtonV1PAgg05o8/98qJnyqox7EbmAZz6w0OT2Ca5ZT/998kirbBMN0b9oK x2magx/1mcLVRd3xv/jaZLTzaugKXINWg2+w5rierdNN/V+G1LVMsauTnMvfG25/zS2z 9ZRyi+YShpJOQZuFKxGXDhn2p5r5r+eDdGUxlWPklq/C8McIuqVojIpgTDgWkZhWIWDw kOSg== Received: by 10.236.114.161 with SMTP id c21mr8711191yhh.51.1337270150100; Thu, 17 May 2012 08:55:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.114.161 with SMTP id c21mr8711163yhh.51.1337270149848; Thu, 17 May 2012 08:55:49 -0700 (PDT) Sender: evanm@google.com Received: by 10.101.156.21 with HTTP; Thu, 17 May 2012 08:55:49 -0700 (PDT) In-Reply-To: <20120517011554.5d16067e@serene.no-ip.org> References: <20120517011554.5d16067e@serene.no-ip.org> Date: Thu, 17 May 2012 08:55:49 -0700 X-Google-Sender-Auth: XfLA5WyS5Ad7RuYOFBeleNv3m6o Message-ID: From: Evan Martin To: "Conrad J. Sabatier" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQlzwnfhJab8NeNhymrQyifxAWeFiDqoBPLGPtyd34nhSc1VYHzUCa3+N5JDulvKTYca0+ces4GyRxRvKUjTJJxB67ukYcfmP/KkwrmXncCjKWDGIelyonZuJbpWLpNxhyJChi9kCJ7ZksoARu2Oj0AhykDLyw== X-Mailman-Approved-At: Thu, 17 May 2012 16:24:21 +0000 Cc: freebsd-chromium@freebsd.org, freebsd-current@freebsd.org Subject: Re: Chrome crashing system (amd64-10.0-CURRENT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 15:55:51 -0000 These kinds of hard locks often point at graphics driver problems, but normally Chrome relies on a driver whitelist that likely doesn't include any FreeBSD drivers. Did you perhaps set a flag somewhere to bypass a blacklist? You could try some command line flags like --blacklist-accelerated-compositing --blacklist-webgl to see if they help. (I found those on http://peter.sh/experiments/chromium-command-line-switches/ , not certain if they do what you need.) Another idea is to use strace/ktrace/truss into a log file to see what it was doing around the time of dying. On Wed, May 16, 2012 at 11:15 PM, Conrad J. Sabatier wrot= e: > For the last week or so, I've been unable to run chrome. =A0Any attempt > to start it up will cause the system either to freeze up or reboot. > > To make matters worse, no trace of what's happening is anywhere to be > found. =A0Nothing in any log files. =A0The system doesn't drop into the > kernel debugger, either. =A0It's either a hard freeze or sudden reboot. > > I've tried rebuilding the chromium port, with both clang and gcc 4.6, > to no avail. =A0I've also updated the system sources several times this > week and remade world/kernel. =A0Nothing seems to help. > > I'm totally stumped as to how to determine what's going on here. =A0Any > suggestions as to how to obtain some useful info? > > Thanks! > > -- > Conrad J. Sabatier > conrads@cox.net > _______________________________________________ > freebsd-chromium@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-chromium > To unsubscribe, send any mail to "freebsd-chromium-unsubscribe@freebsd.or= g" From owner-freebsd-current@FreeBSD.ORG Thu May 17 16:44:53 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 099451065674; Thu, 17 May 2012 16:44:53 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from springbank.echomania.com (andric.com [IPv6:2001:888:2003:1001:230:48ff:fe51:76b6]) by mx1.freebsd.org (Postfix) with ESMTP id 762D78FC0A; Thu, 17 May 2012 16:44:49 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at springbank.echomania.com Received: from [192.168.1.6] (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by springbank.echomania.com (Postfix) with ESMTPSA id CCD50A7071; Thu, 17 May 2012 18:44:26 +0200 (CEST) Message-ID: <4FB52AF9.1010306@andric.com> Date: Thu, 17 May 2012 18:44:41 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120425 Thunderbird/13.0 MIME-Version: 1.0 To: Pedro Giffuni References: <4FB51CDF.3040306@FreeBSD.org> In-Reply-To: <4FB51CDF.3040306@FreeBSD.org> X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-toolchain@FreeBSD.org Subject: Re: GCC update for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 16:44:53 -0000 On 2012-05-17 17:44, Pedro Giffuni wrote:> Hi; > I took a bunch of patches that were merged into the GCC 4.1 branch > (under GPLv2) and prepared a patch for merging them into our base > gcc. These are supposed to be bug fixes only. > > You can get the patch here: > http://people.freebsd.org/~pfg/patches/patch-contrib-gcc > And, for those really interested, the log is here: > http://people.freebsd.org/~pfg/patches/gcc41-pr-log > > It may be my imagination but the patch seems to be causing more > warnings than usual and it breaks the kernel here: ... > ../../../cam/scsi/scsi_sa.c: In function 'samount': > ../../../cam/scsi/scsi_sa.c:1887: warning: 'comp_supported' may be used > uninitialized in this function > ../../../cam/scsi/scsi_sa.c:1888: warning: 'write_protect' may be used > uninitialized in this function These warnings seem wrong, upon casual inspection of the code. In any case, if you compile the same file with gcc 4.7, they don't appear. :) Any idea which particular gcc fix is responsible for them? As a workaround, we could set all those variable to some reasonable value, but that feels like a cheap trick to me... But I'd rather just not import the fix that causes those warnings. From owner-freebsd-current@FreeBSD.ORG Thu May 17 18:41:24 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D29E8106566C for ; Thu, 17 May 2012 18:41:24 +0000 (UTC) (envelope-from joel@vnode.se) Received: from mail.vnode.se (mail.vnode.se [62.119.52.80]) by mx1.freebsd.org (Postfix) with ESMTP id 87F1E8FC12 for ; Thu, 17 May 2012 18:41:24 +0000 (UTC) Received: from mail.vnode.se (localhost [127.0.0.1]) by mail.vnode.se (Postfix) with ESMTP id 3277CE3F07B; Thu, 17 May 2012 20:41:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at vnode.se Received: from mail.vnode.se ([127.0.0.1]) by mail.vnode.se (mail.vnode.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s02E07Y0eZ2D; Thu, 17 May 2012 20:41:21 +0200 (CEST) Received: from goofy01.vnodelab.local (jd.benders.se [212.247.52.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.vnode.se (Postfix) with ESMTPSA id 00C36E3F079; Thu, 17 May 2012 20:41:20 +0200 (CEST) Date: Thu, 17 May 2012 20:41:19 +0200 From: Joel Dahl To: Mark Felder Message-ID: <20120517184118.GA60874@goofy01.vnodelab.local> References: <20120517094949.GK6475@goofy01.vnodelab.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org Subject: Re: FreeBSD and LDAP users, bug or feature? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 18:41:24 -0000 On 17-05-2012 8:24, Mark Felder wrote: > Check man adduser.conf(5) > > There is an option for "uidstart" which should do what you want. If you > set it to 1000 every time you run "adduser" it will show: Thanks, setting uidstart to 1000 indeed works around the problem. :) However, I would still like to know if this is intended behaviour. -- Joel From owner-freebsd-current@FreeBSD.ORG Thu May 17 18:42:02 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 935741065677 for ; Thu, 17 May 2012 18:42:02 +0000 (UTC) (envelope-from krisik28@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 599C18FC1D for ; Thu, 17 May 2012 18:42:02 +0000 (UTC) Received: by obcni5 with SMTP id ni5so3784974obc.13 for ; Thu, 17 May 2012 11:42:01 -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=HYe1J39TGDglRzGi/069XS3cmfNXWgZYAadvk/V/GCw=; b=eRfHq5nRwC6lymK/ViSYjLr9GI4N3OufxAVi75v2ash3axfrsluB8949Pq20KwprQT J0GTyBuIvEsu4MKFNcBLNgDE9LQMSvfzUkxO0y5ORmMieOV6in54fWdhewhe/fkkTbkS uSFSdnf6+V9ofdaAoAZJj2Yx+t/q6lQfm1LSYSDMhWT8vtUoNZE8Vq+07x/aJb33y6vS SluxQAIM1ovULJn85QZ0D+5KdqBLLYE/YEK19gCUfHVUZZXi1fUVCYL4blO2/TYYg2L+ GxJCZJmj1ASarELHAoRRNrDI8/3E3dMh21hooCZtj4oqzMV4tj3zG5t+Hq1Koi+Cf4GL jEag== MIME-Version: 1.0 Received: by 10.60.24.7 with SMTP id q7mr7558034oef.50.1337280121623; Thu, 17 May 2012 11:42:01 -0700 (PDT) Received: by 10.76.172.69 with HTTP; Thu, 17 May 2012 11:42:01 -0700 (PDT) Date: Thu, 17 May 2012 20:42:01 +0200 Message-ID: From: Krzysztof Kowalski To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: VNET jails freebsd 9.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 18:42:02 -0000 Hi, i was trying to make jail, under VB 4.1.14r77440 WINDOWS7 as host, using this: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails-build.html http://wiki.polymorf.fr/index.php/Howto:FreeBSD_jail_vnet I set everything like wiki says, recompiled kernel and patched /etc/rc.d/jail, but when i try to do: /etc/rc.d/netif cloneup i get: ifconfig: create: bad value At startup i get: Starting jails:epair0a: Ethernet address: 02:c0:84:00:05:0a epair0b: Ethernet address: 02:c0:84:00:06:0b epair0a cannot start jail "misc" tail: /tmp/jail.qqSQ0EB4/jail.17: No such file or directory . /etc/rc: WARNING: Ignoring scratch file /etc/rc.d/jail.orig Sorry if some information are missing but i don't know what to attach /etc/rc.conf: http://wklej.to/VUy3l /etc/jails/misc.conf: http://wklej.to/vQVxW dmesg: http://wklej.to/jJiqO Can someone tell me whats wrong? Best regards, Krzysztof K. From owner-freebsd-current@FreeBSD.ORG Thu May 17 19:23:41 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D6D8106564A for ; Thu, 17 May 2012 19:23:41 +0000 (UTC) (envelope-from pfg@freebsd.org) Received: from nm27-vm2.bullet.mail.ne1.yahoo.com (nm27-vm2.bullet.mail.ne1.yahoo.com [98.138.91.215]) by mx1.freebsd.org (Postfix) with SMTP id 23E118FC08 for ; Thu, 17 May 2012 19:23:41 +0000 (UTC) Received: from [98.138.90.48] by nm27.bullet.mail.ne1.yahoo.com with NNFMP; 17 May 2012 19:23:35 -0000 Received: from [98.138.84.47] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 17 May 2012 19:23:35 -0000 Received: from [127.0.0.1] by smtp115.mail.ne1.yahoo.com with NNFMP; 17 May 2012 19:23:35 -0000 X-Yahoo-Newman-Id: 599928.26148.bm@smtp115.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Vhm8ZTEVM1klTadLKjcbXxAvzbtcV0iCtTFuoME_9AqYcqP iHcUBmF3BFByfD7FnP.cWD_d0y4WxmwplM5VR4KzgH53dAPgBQQSajBavkl2 Pk_ySUS_Jf19RpbTqc1Ya2FhIxkOb3sb632dWvvJIbnm5GiIDSsfPtVl.Jz8 p_tnn5g0imsB2lGcJl42Js_NmLRNE4IERU6ilrQetQDuU.GVxYF2V7miQDhE 4gi905.qcBcy1l3.I0FkYVL9_5E83kuKwJX1McuHun1bEzgd70qCR5LcCg5p lVu_tj8XLKrjp.Jy6h8sMZDwqYznJA1gBp5Y_Dz.unHBOHue0eMZGPqsbR7n uvVmUbn67OR.njI6g9tXshNa83wGLxLZzJ2tBiYKs7BofA4ZEWHIxPXX8YiV dUmFEuz835cOSewIfnhHi_UmjAznWzE5T6_7dXiNqyyHwsD4Vm2jmN5Z389x U3BKVP5e18B5_EiiVkmOFjbRIIivycax7scZOiNNY7l.Vv0TumUurzFTPhCb irzHTqQ-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Received: from [192.168.10.103] (pfg@200.118.157.7 with plain) by smtp115.mail.ne1.yahoo.com with SMTP; 17 May 2012 12:23:35 -0700 PDT Message-ID: <4FB55034.2080404@FreeBSD.org> Date: Thu, 17 May 2012 14:23:32 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120328 Thunderbird/10.0.3 MIME-Version: 1.0 To: Dimitry Andric References: <4FB51CDF.3040306@FreeBSD.org> <4FB52AF9.1010306@andric.com> In-Reply-To: <4FB52AF9.1010306@andric.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-toolchain@FreeBSD.org Subject: Re: GCC update for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 19:23:41 -0000 Hi Dimitry; On 05/17/12 11:44, Dimitry Andric wrote: > On 2012-05-17 17:44, Pedro Giffuni wrote:> Hi; >> I took a bunch of patches that were merged into the GCC 4.1 branch >> (under GPLv2) and prepared a patch for merging them into our base >> gcc. These are supposed to be bug fixes only. >> >> You can get the patch here: >> http://people.freebsd.org/~pfg/patches/patch-contrib-gcc >> And, for those really interested, the log is here: >> http://people.freebsd.org/~pfg/patches/gcc41-pr-log >> >> It may be my imagination but the patch seems to be causing more >> warnings than usual and it breaks the kernel here: > ... >> ../../../cam/scsi/scsi_sa.c: In function 'samount': >> ../../../cam/scsi/scsi_sa.c:1887: warning: 'comp_supported' may be used >> uninitialized in this function >> ../../../cam/scsi/scsi_sa.c:1888: warning: 'write_protect' may be used >> uninitialized in this function > These warnings seem wrong, upon casual inspection of the code. In any > case, if you compile the same file with gcc 4.7, they don't appear. :) > > Any idea which particular gcc fix is responsible for them? > > As a workaround, we could set all those variable to some reasonable > value, but that feels like a cheap trick to me... > > But I'd rather just not import the fix that causes those warnings. I will have to dig deeper into the changes to see what causes this. In any case I do agree and the patch will not be committed. Ultimately I can just leave the list around and we bring them in only as needed. Pedro. From owner-freebsd-current@FreeBSD.ORG Thu May 17 19:29:49 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44181106566B; Thu, 17 May 2012 19:29:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 16CB68FC16; Thu, 17 May 2012 19:29:49 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7E43CB94F; Thu, 17 May 2012 15:29:48 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Thu, 17 May 2012 13:50:53 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <4FAF7343.8010808@cran.org.uk> <201205171005.19736.jhb@freebsd.org> <4FB51A64.6090906@FreeBSD.org> In-Reply-To: <4FB51A64.6090906@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201205171350.53229.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 17 May 2012 15:29:48 -0400 (EDT) Cc: Bruce Cran , freebsd-acpi@freebsd.org, freebsd-current , Jung-uk Kim Subject: Re: ACPI 'driver bug: Unable to set devclass' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 19:29:49 -0000 On Thursday, May 17, 2012 11:33:56 am Andriy Gapon wrote: > on 17/05/2012 17:05 John Baldwin said the following: > > On Wednesday, May 16, 2012 4:07:43 pm John Baldwin wrote: > >> Oh, whoops. Actually, the right way to do this I think is bus_hint_device_unit() > >> (and/or, not make the unit number in cpuX mean anything at all, but use a separate > >> ivar to track what PCPU_GET(cpuid) a given cpuX device corresponds to). I think > >> the last approach is really the right way to fix this. > > > > I haven't been able to try this yet, but I have a first cut at > > www.freebsd.org/~jhb/patches/acpi_cpu.patch > > > > The patch has not been compile-tested? :) Not yet. I'll try to test it later today unless someone beats me to it. :-P -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu May 17 20:10:40 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A80561065691 for ; Thu, 17 May 2012 20:10:40 +0000 (UTC) (envelope-from christer.solskogen@gmail.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 618108FC15 for ; Thu, 17 May 2012 20:10:40 +0000 (UTC) Received: by ggnm2 with SMTP id m2so2798430ggn.13 for ; Thu, 17 May 2012 13:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=fTSBKlKcUXylyEBUilrsMRCrjgU739Bc/ov941zVuYA=; b=rnZgTO/Dm1TLENpDJoMpLWW4xSU63Y9eyvDZkZS+XiHxPq+Gp4ZOk6oyA1QkW/2pee HVyS+R8fjw84zfUipgd+ZsufB26qa3LXrl8zQh1r1KhSP4rkKaFTyV5UoLNXKpzepNDc q9VUPweTM1XPegeooqBowcbNKzarxRgZCwgteAqWxRuoj6xQQsm8eaBNFPTSATn+MuDr O1xGVFu6CisZULDyeLRuwJ0EI9NZdKiaj6heCFMRxbPOEYQO/akwR2ksqAH3O4YkURW6 bH0ux8Zw1IcVt5iiGf0FXcCvBBWDdcS2Fo4vPIiE+wupsMw9Xgc72vn6++Z6k9NRvrE/ ppfw== Received: by 10.42.10.73 with SMTP id p9mr1984663icp.43.1337285438514; Thu, 17 May 2012 13:10:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.67.233 with HTTP; Thu, 17 May 2012 13:10:17 -0700 (PDT) In-Reply-To: <4FB4692D.6070304@gmail.com> References: <4FB4692D.6070304@gmail.com> From: Christer Solskogen Date: Thu, 17 May 2012 22:10:17 +0200 Message-ID: To: Chuck Burns Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 10 prognostication... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 20:10:40 -0000 On Thu, May 17, 2012 at 4:57 AM, Chuck Burns wrote: > You guys DO realize that's a troll website, right? And you're being > seriously trolled.. right? > The URL is legit! This is noes trollz! -- chs, From owner-freebsd-current@FreeBSD.ORG Thu May 17 20:18:54 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 03975106566C for ; Thu, 17 May 2012 20:18:54 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from glenbarber.us (onyx.glenbarber.us [199.48.134.227]) by mx1.freebsd.org (Postfix) with SMTP id CCE388FC0A for ; Thu, 17 May 2012 20:18:53 +0000 (UTC) Received: (qmail 68781 invoked by uid 0); 17 May 2012 16:18:53 -0400 Received: from unknown (HELO glenbarber.us) (75.146.225.65) by 0 with SMTP; 17 May 2012 16:18:53 -0400 Date: Thu, 17 May 2012 16:18:51 -0400 From: Glen Barber To: freebsd-current@FreeBSD.org Message-ID: <20120517201851.GA1414@glenbarber.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: [panic] zfs_zget() panic during 'svn update' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 20:18:54 -0000 Hi, I'm running -CURRENT from a few weeks ago (r234559M), and during 'svn update', had the machine panic. I have kgdb output available here, and am happy to provide additional information if needed: http://people.freebsd.org/~gjb/zfs_zget-panic.kgdb.txt Regards, Glen From owner-freebsd-current@FreeBSD.ORG Thu May 17 20:38:29 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 860951065800; Thu, 17 May 2012 20:38: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 9D4B68FC20; Thu, 17 May 2012 20:38:28 +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 XAA14319; Thu, 17 May 2012 23:38:24 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SV7Sq-0002sc-LM; Thu, 17 May 2012 23:38:24 +0300 Message-ID: <4FB561BF.2090404@FreeBSD.org> Date: Thu, 17 May 2012 23:38:23 +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: Bruce Cran References: <4FB14C48.1030002@cran.org.uk> In-Reply-To: <4FB14C48.1030002@cran.org.uk> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current Subject: Re: "random device not loaded; using insecure entropy" during boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 20:38:29 -0000 on 14/05/2012 21:17 Bruce Cran said the following: > While booting -current I noticed a new warning introduced in r230230** > (though it's not > in 'dmesg' once booted): > > FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 4 > cpu3 (AP): APIC ID: 5 > random device not loaded; using insecure entropy > > I guess something's wanting random data before its been initialized? Once > booted kern.random shows that it is loaded and working. It seems that the message is triggered by __stack_chk_init. I am not sure if we really need a "secure" random value there. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu May 17 21:04:32 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C6BB106566C for ; Thu, 17 May 2012 21:04:32 +0000 (UTC) (envelope-from feld@feld.me) Received: from feld.me (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id E6A898FC08 for ; Thu, 17 May 2012 21:04:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=In-Reply-To:Message-Id:From:Mime-Version:Date:References:Subject:To:Content-Type; bh=fgmtyDMU5Wiz5O7K994L0dhBjpa6e9tDhf/Ye4dXKB0=; b=PNQ7OAGaO62HfpmH8otHqo3Nrd00wWk92Zalw6DBsGxLtZNnL8Ts9Vx5uDFgsvZN2Io3uO/11lGh8VlGWpdCnySTo73UN3mRZnXYDOJ7ytirVPa/s4nJHPj108dKT/i2; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by feld.me with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SV7s5-000P4g-Fs for current@freebsd.org; Thu, 17 May 2012 16:04:30 -0500 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpa id 1337288663-3288-3287/5/12; Thu, 17 May 2012 21:04:23 +0000 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: current@freebsd.org References: <20120517094949.GK6475@goofy01.vnodelab.local> <20120517184118.GA60874@goofy01.vnodelab.local> Date: Thu, 17 May 2012 16:04:22 -0500 Mime-Version: 1.0 From: Mark Felder Message-Id: In-Reply-To: <20120517184118.GA60874@goofy01.vnodelab.local> User-Agent: Opera Mail/11.64 (FreeBSD) X-SA-Score: -1.5 Cc: Subject: Re: FreeBSD and LDAP users, bug or feature? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 21:04:32 -0000 On Thu, 17 May 2012 13:41:19 -0500, Joel Dahl wrote: > > Thanks, setting uidstart to 1000 indeed works around the problem. :) > > However, I would still like to know if this is intended behaviour. > I'm not sure but hopefully someone here can answer that for you. From owner-freebsd-current@FreeBSD.ORG Thu May 17 21:37:17 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 7D7751065670 for ; Thu, 17 May 2012 21:37:17 +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 06A441A9048; Thu, 17 May 2012 21:37:16 +0000 (UTC) Message-ID: <4FB56F8C.2000304@FreeBSD.org> Date: Thu, 17 May 2012 14:37:16 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120506 Thunderbird/12.0.1 MIME-Version: 1.0 To: Bryan Drewery References: <4FAF291C.8090401@shatow.net> <4FB04084.5070202@FreeBSD.org> <4FB10A1B.7090102@shatow.net> In-Reply-To: <4FB10A1B.7090102@shatow.net> X-Enigmail-Version: 1.5pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: [review request] usr.sbin/service - make showing files configurable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 21:37:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 05/14/2012 06:35, Bryan Drewery wrote: > > > On 5/13/2012 6:15 PM, Doug Barton wrote: >> On 5/12/2012 8:23 PM, Bryan Drewery wrote: >>> Hi, >>> >>> I found service(8) to be inconsistent that it listed files with >>> `service -e`, but plain services with `service -l` > >> That behavior is by design. > > > > Could you please elaborate on the design decision? For services that are enabled (IOW, a tiny subset of the overall number) I thought it was useful to indicate to the user where those services come from. The -l option dumps everything in the directories, even if it's not a service. Users interested in differentiating /etc/rc.d from $local_startup can use ls. > I did of course look in base for uses of service -e and service > -l, before considering this patch. The only case I can find is in a > cshrc example, which my patch does not affect. That's not relevant, as you cannot possibly know what other uses service(1) is being put to. Also, it's bad form to change the default output of a tool (and/or the semantics of its command line options) years after its introduction. > I had expected service -e to behave like service -l, so I could > for example, put it into a loop and check all services, using the > service(8) script itself. > > for service_name in `service -e`; do service status $service_name > || service start $service_name; done for service in `service -e` ; do service ${##*/service} status || service ${##*/service} start done (Note, your syntax for the service command is wrong above.) hth, Doug - -- This .signature sanitized for your protection -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJPtW+MAAoJEFzGhvEaGryEpokH/RbWnJZN/RCQzidxoIbAx0+5 nAEX33e0Iazfqs/km7uFP8T/4SD2b0pOmr3dNBaKHqnpz005ACzhTcWD111ik/d2 ypRKdzh+vlq+Y9bDB4PozMjnalZrhkAUIinUIDDH6xMW46fIbN2bXPqz8AIe1Umo a8LaHW59ARJf197o7iyWNOYOcF6+S3haaSzu8UXL5MTDtKBpn5XY5Eg6ppc/ZD9J Mzaq1k7baCrGqCSsyZusmCv7WWDcOw7tOspUKzoNMm+wBMf7MrQyPUQsaA9vfGXZ cB39Byryvi9Rhbz/ACjgw44ZRVUcjWJaxkFVc5WwkLbCDTv4tny5q2KpIAHfhPk= =ykfV -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu May 17 21:51:59 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BADB31065672 for ; Thu, 17 May 2012 21:51:59 +0000 (UTC) (envelope-from bryan@shatow.net) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) by mx1.freebsd.org (Postfix) with ESMTP id 602E78FC12 for ; Thu, 17 May 2012 21:51:59 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sweb; b=FB3cVD YM7b5aaOsTCboTmcaCO5j/DNl7U5pgDtSnFW9r8bmxGiJQBQyQHAxXrVqIqmDDpd 5LYydgyDmMOzOMch2tbdmP/lPARYLkxPri3n8BNGDjZYppAE4+X72Y8SzSjr9XfY tV90mU+ESNjDOD+wsTSYfSLOlUL961yYgP+Bc= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sweb; bh=riauZD/K3pX1 BRkNTdF48NFUI82rMkWbMca8MwUfKTs=; b=GuAZ2R9ARuHXEmJg9RBeOanFyWVl sxkuZUqo9uywFgCdwBk2FyQNyeD5i5tWI19WCxU40+H0BQMYybY2/JF5WCdNJINB tjyGdDLaP335+x4gujfHjcSWJXvZgC/ze3FYRODXgPXtOR+o3hH7CMco3eWuZOTg lKjebSL85dRVVoU= Received: (qmail 55613 invoked from network); 17 May 2012 16:51:52 -0500 Received: from unknown (HELO ?10.10.1.87?) (bryan@shatow.net@10.10.1.87) by sweb.xzibition.com with ESMTPA; 17 May 2012 16:51:52 -0500 Message-ID: <4FB572F5.4070801@shatow.net> Date: Thu, 17 May 2012 16:51:49 -0500 From: Bryan Drewery User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Doug Barton References: <4FAF291C.8090401@shatow.net> <4FB04084.5070202@FreeBSD.org> <4FB10A1B.7090102@shatow.net> <4FB56F8C.2000304@FreeBSD.org> In-Reply-To: <4FB56F8C.2000304@FreeBSD.org> X-Enigmail-Version: 1.4.1 OpenPGP: id=3C9B0CF9; url=http://www.shatow.net/bryan/bryan.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: [review request] usr.sbin/service - make showing files configurable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 21:51:59 -0000 On 5/17/2012 4:37 PM, Doug Barton wrote: > On 05/14/2012 06:35, Bryan Drewery wrote: > > >> On 5/13/2012 6:15 PM, Doug Barton wrote: >>> On 5/12/2012 8:23 PM, Bryan Drewery wrote: >>>> Hi, >>>> >>>> I found service(8) to be inconsistent that it listed files with >>>> `service -e`, but plain services with `service -l` > >>> That behavior is by design. > > > >> Could you please elaborate on the design decision? > > For services that are enabled (IOW, a tiny subset of the overall > number) I thought it was useful to indicate to the user where those > services come from. The -l option dumps everything in the directories, > even if it's not a service. Users interested in differentiating > /etc/rc.d from $local_startup can use ls. Thanks for explaining. > >> I did of course look in base for uses of service -e and service >> -l, before considering this patch. The only case I can find is in a >> cshrc example, which my patch does not affect. > > That's not relevant, as you cannot possibly know what other uses > service(1) is being put to. Also, it's bad form to change the default > output of a tool (and/or the semantics of its command line options) > years after its introduction. True. > >> I had expected service -e to behave like service -l, so I could >> for example, put it into a loop and check all services, using the >> service(8) script itself. > >> for service_name in `service -e`; do service status $service_name >> || service start $service_name; done > > for service in `service -e` ; do > service ${##*/service} status || service ${##*/service} start > done Yes, I resorted to that before the patch. I just think consistency is better. > > (Note, your syntax for the service command is wrong above.) Yeah it's what I get for mashing a pseudo example up and not testing it! > > > hth, > > Doug > Thank you, Bryan Drewery From owner-freebsd-current@FreeBSD.ORG Thu May 17 22:16:05 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30A87106566C; Thu, 17 May 2012 22:16:05 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id CF9908FC0A; Thu, 17 May 2012 22:16:04 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q4HMFXuu053359; Thu, 17 May 2012 15:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1337292935; bh=zcAEacuHtKcOWxwHlIeJdT/p7FrL/1JQcud/F8T8O80=; h=Subject:From:Reply-To:To:Cc:In-Reply-To:References:Content-Type: Date:Message-ID:Mime-Version:Content-Transfer-Encoding; b=FetXTRK+HXFj5vUegVuUXKTcYXt9wnjtZ29TThbxifjxmm2fpcHvrUy6iXrPuk5+W 5agZSKp7pkZEQE89UmV7Gv/o+ZaXieykkP4UA+e1/tPuVhVspLCNlvlg83omvp3we8 Gp8Wb5L2ai7DvCsLK8iIh7MtJZHTdKW+kb/XIo+A= From: Sean Bruno To: "chet.ramey@case.edu" In-Reply-To: <4FABBB1B.4080108@case.edu> References: <1336599447.71431.2.camel@powernoodle-l7> <4FABBB1B.4080108@case.edu> Content-Type: text/plain; charset="UTF-8" Date: Thu, 17 May 2012 15:15:33 -0700 Message-ID: <1337292933.15253.6.camel@powernoodle-l7.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 292934000 Cc: Craig Rodrigues , Current FreeBSD Subject: Re: ports/bash4 --enable-static fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 22:16:05 -0000 On Thu, 2012-05-10 at 05:56 -0700, Chet Ramey wrote: > On 5/10/12 12:20 AM, Craig Rodrigues wrote: > > > Bash is trying to override the malloc() functions in libc with its own > > implementation in lib/malloc/malloc.c . > > I have seen this type of trick before 3rd party code that tries to > > override the libc implementation of malloc() / free() with its own. > > > > kan@ explained this to me before, but I don't know if I can explain it > > as well as him, because it has to do > > with how static linking works. :) > > > > Basically, the malloc.o object from bash, *must* have implementations of > > *all* the relevant functions in jemalloc_jemalloc.o in order for > > malloc.o to properly override jemalloc_jemalloc.o. > > > > If you have something like: > > jemalloc_jemalloc.o (libc) malloc.o (Bash) > > =============== ============= > > malloc() malloc() > > free() free() > > calloc() > > realloc() > > > > > > the static linker will not be able to replace jemalloc_jemalloc.o from > > libc with malloc.o from Bash, > > because calloc() and realloc() symbols in jemalloc_jemalloc.o (libc) > > do not exist malloc.o (Bash). > > > > Since the linker can only deal with whole objects (.o files), it will > > try to pull in both > > jemalloc_jemalloc.o and malloc.o when doing static linking. > > > > I may have got some of the details/explanation wrong, but I have fixed > > something similar > > to this in 3rd party code, when the layout of malloc() functions in > > libc changed between FreeBSD 4 and FreeBSD 6. > > This explanation is substantially correct. > > > > > What you need to do is: > > (1) run nm or readelf on jemalloc_jemalloc.o, then run nm or > > readelf on malloc.o > > (2) Look at the symbols in both > > (3) Add the missing symbols to malloc.c in Bash > > The bash malloc includes definitions for malloc/free/realloc/calloc/cfree/ > valloc/memalign. I'd be interested in knowing what other global symbols > jemalloc exports. I'd also be interested in seeing how someone managed to > compile the bash malloc and leave out realloc. > > Chet Just to kind of close the loop here, we went ahead and changed our local build of bash to do: ./configure --enable-static-link --without-bash-malloc This matches the ports implementation, so we have moved on here. Sean From owner-freebsd-current@FreeBSD.ORG Thu May 17 22:17:45 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 67B271065672 for ; Thu, 17 May 2012 22:17:45 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id B330317A6FC; Thu, 17 May 2012 22:17:00 +0000 (UTC) Message-ID: <4FB578DC.90608@FreeBSD.org> Date: Thu, 17 May 2012 15:17:00 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Bryan Drewery References: <4FAF291C.8090401@shatow.net> <4FB04084.5070202@FreeBSD.org> <4FB10A1B.7090102@shatow.net> <4FB56F8C.2000304@FreeBSD.org> <4FB572F5.4070801@shatow.net> In-Reply-To: <4FB572F5.4070801@shatow.net> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: [review request] usr.sbin/service - make showing files configurable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 22:17:45 -0000 On 05/17/2012 02:51 PM, Bryan Drewery wrote: > Yeah it's what I get for mashing a pseudo example up and not testing it! S'ok, I screwed up ${service##*/} in mine. :) From owner-freebsd-current@FreeBSD.ORG Thu May 17 23:08:57 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D84A3106566B; Thu, 17 May 2012 23:08:57 +0000 (UTC) (envelope-from conrads@cox.net) Received: from eastrmfepo201.cox.net (eastrmfepo201.cox.net [68.230.241.216]) by mx1.freebsd.org (Postfix) with ESMTP id 5C1678FC08; Thu, 17 May 2012 23:08:56 +0000 (UTC) Received: from eastrmimpo210.cox.net ([68.230.241.225]) by eastrmfepo201.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20120517230856.RSFX5450.eastrmfepo201.cox.net@eastrmimpo210.cox.net>; Thu, 17 May 2012 19:08:56 -0400 Received: from serene.no-ip.org ([98.164.83.188]) by eastrmimpo210.cox.net with bizsmtp id BB8v1j00543nm9e02B8v3C; Thu, 17 May 2012 19:08:55 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020207.4FB58508.000F,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=1.1 cv=zgrfwPxMZK8qZ92ObMQftE+CrxUcpQPkHWvi4UAp5mI= c=1 sm=1 a=swW3mUodPN4A:10 a=G8Uczd0VNMoA:10 a=kj9zAlcOel0A:10 a=F4D4Y6gUi4XSUMrqnG4xkg==:17 a=cm27Pg_UAAAA:8 a=jngkN49NAAAA:8 a=kviXuzpPAAAA:8 a=ye2Y2kOJyop1Br4zxMIA:9 a=CjuIK1q_8ugA:10 a=zv9_9hqRWm8A:10 a=4vB-4DCPJfMA:10 a=F4D4Y6gUi4XSUMrqnG4xkg==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Received: from serene.no-ip.org (localhost [127.0.0.1]) by serene.no-ip.org (8.14.5/8.14.5) with ESMTP id q4HN8s8Z001471; Thu, 17 May 2012 18:08:54 -0500 (CDT) (envelope-from conrads@cox.net) Date: Thu, 17 May 2012 18:08:49 -0500 From: "Conrad J. Sabatier" To: Evan Martin Message-ID: <20120517180849.72ac2664@serene.no-ip.org> In-Reply-To: References: <20120517011554.5d16067e@serene.no-ip.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-chromium@freebsd.org, John Hixson , freebsd-current@freebsd.org Subject: Re: Chrome crashing system (amd64-10.0-CURRENT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 23:08:57 -0000 On Thu, 17 May 2012 08:55:49 -0700 Evan Martin wrote: > These kinds of hard locks often point at graphics driver problems, but > normally Chrome relies on a driver whitelist that likely doesn't > include any FreeBSD drivers. Did you perhaps set a flag somewhere to > bypass a blacklist? > > You could try some command line flags like > --blacklist-accelerated-compositing > --blacklist-webgl > to see if they help. > > (I found those on > http://peter.sh/experiments/chromium-command-line-switches/ , not > certain if they do what you need.) > > Another idea is to use strace/ktrace/truss into a log file to see what > it was doing around the time of dying. Thanks. I tried those, and it still locked up. I finally just moved away ~/.config/chromium, and it started up OK. Luckily, I was able to restore pretty much everything from my synced data. Happy ending. :-) -- Conrad J. Sabatier conrads@cox.net From owner-freebsd-current@FreeBSD.ORG Thu May 17 23:26:45 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 253F5106566C; Thu, 17 May 2012 23:26:45 +0000 (UTC) (envelope-from conrads@cox.net) Received: from eastrmfepo102.cox.net (eastrmfepo102.cox.net [68.230.241.214]) by mx1.freebsd.org (Postfix) with ESMTP id 87A718FC08; Thu, 17 May 2012 23:26:44 +0000 (UTC) Received: from eastrmimpo210.cox.net ([68.230.241.225]) by eastrmfepo102.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20120517232637.PXJF26743.eastrmfepo102.cox.net@eastrmimpo210.cox.net>; Thu, 17 May 2012 19:26:37 -0400 Received: from serene.no-ip.org ([98.164.83.188]) by eastrmimpo210.cox.net with bizsmtp id BBSZ1j00B43nm9e02BSb3C; Thu, 17 May 2012 19:26:37 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020209.4FB5892D.0059,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=1.1 cv=zgrfwPxMZK8qZ92ObMQftE+CrxUcpQPkHWvi4UAp5mI= c=1 sm=1 a=swW3mUodPN4A:10 a=G8Uczd0VNMoA:10 a=8nJEP1OIZ-IA:10 a=F4D4Y6gUi4XSUMrqnG4xkg==:17 a=cm27Pg_UAAAA:8 a=kviXuzpPAAAA:8 a=oCjSQ2ZfFCm5Fb19x00A:9 a=lDoC0UDEdsZUMbiPfIEA:7 a=wPNLvfGTeEIA:10 a=zv9_9hqRWm8A:10 a=4vB-4DCPJfMA:10 a=F4D4Y6gUi4XSUMrqnG4xkg==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Received: from serene.no-ip.org (localhost [127.0.0.1]) by serene.no-ip.org (8.14.5/8.14.5) with ESMTP id q4HNQVA8001590; Thu, 17 May 2012 18:26:32 -0500 (CDT) (envelope-from conrads@cox.net) Date: Thu, 17 May 2012 18:26:26 -0500 From: "Conrad J. Sabatier" To: Evan Martin Message-ID: <20120517182626.17c27855@serene.no-ip.org> In-Reply-To: References: <20120517011554.5d16067e@serene.no-ip.org> <20120517180849.72ac2664@serene.no-ip.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-chromium@freebsd.org, John Hixson , freebsd-current@freebsd.org Subject: Re: Chrome crashing system (amd64-10.0-CURRENT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 23:26:45 -0000 On Thu, 17 May 2012 16:12:15 -0700 Evan Martin wrote: > On Thu, May 17, 2012 at 4:08 PM, Conrad J. Sabatier > wrote: > > Thanks. =A0I tried those, and it still locked up. > > > > I finally just moved away ~/.config/chromium, and it started up OK. > > Luckily, I was able to restore pretty much everything from my synced > > data. >=20 > It's a little surprising to me that a userspace app is able to nuke > your system, but perhaps the bug is just something mundane like out of > control memory allocations and it's just swapping. Yes, that *is* a little troubling. I'm always touting FreeBSD to people as being a rock-solid platform, so I was slightly embarrassed when this happened several times recently when I had a friend over. :-) I'm looking into some sysctl settings now that do seem to have the ability to trigger odd behavior with certain apps, e.g., kern.maxfiles, kern.maxfilesperproc, various shared mem settings, etc. Some apps will either mysteriously refuse to run, or crash just after startup, depending on the settings of these and similar. My chrome problem was no doubt related to my recently having tinkered with some chrome://flags settings. Conservatism and caution definitely seem to be called for with these! :-) --=20 Conrad J. Sabatier conrads@cox.net From owner-freebsd-current@FreeBSD.ORG Fri May 18 00:58:45 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8D59106566B for ; Fri, 18 May 2012 00:58:45 +0000 (UTC) (envelope-from conrads@cox.net) Received: from eastrmfepo102.cox.net (eastrmfepo102.cox.net [68.230.241.214]) by mx1.freebsd.org (Postfix) with ESMTP id 6212E8FC0A for ; Fri, 18 May 2012 00:58:45 +0000 (UTC) Received: from eastrmimpo210.cox.net ([68.230.241.225]) by eastrmfepo102.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20120518005844.SSIB26743.eastrmfepo102.cox.net@eastrmimpo210.cox.net>; Thu, 17 May 2012 20:58:44 -0400 Received: from serene.no-ip.org ([98.164.83.188]) by eastrmimpo210.cox.net with bizsmtp id BCyf1j00543nm9e02CyiTV; Thu, 17 May 2012 20:58:43 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A02020B.4FB59EC3.009F,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=1.1 cv=zgrfwPxMZK8qZ92ObMQftE+CrxUcpQPkHWvi4UAp5mI= c=1 sm=1 a=swW3mUodPN4A:10 a=G8Uczd0VNMoA:10 a=kj9zAlcOel0A:10 a=F4D4Y6gUi4XSUMrqnG4xkg==:17 a=pGLkceISAAAA:8 a=1XWaLZrsAAAA:8 a=kviXuzpPAAAA:8 a=CIq8-txELKwA7bRAcOQA:9 a=CjuIK1q_8ugA:10 a=MSl-tDqOz04A:10 a=4vB-4DCPJfMA:10 a=F4D4Y6gUi4XSUMrqnG4xkg==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Received: from serene.no-ip.org (localhost [127.0.0.1]) by serene.no-ip.org (8.14.5/8.14.5) with ESMTP id q4I0wc6w001983; Thu, 17 May 2012 19:58:38 -0500 (CDT) (envelope-from conrads@cox.net) Date: Thu, 17 May 2012 19:58:33 -0500 From: "Conrad J. Sabatier" To: Chuck Burns Message-ID: <20120517195833.382c95ee@serene.no-ip.org> In-Reply-To: <4FB4ED23.2040603@gmail.com> References: <20120517011554.5d16067e@serene.no-ip.org> <20120517071141.GL2701@thinkbsd.divinix.org> <4FB4ED23.2040603@gmail.com> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Chrome crashing system (amd64-10.0-CURRENT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 00:58:45 -0000 On Thu, 17 May 2012 07:20:51 -0500 Chuck Burns wrote: > On 5/17/2012 2:11 AM, John Hixson wrote: > > On Thu, May 17, 2012 at 01:15:54AM -0500, Conrad J. Sabatier wrote: > >> For the last week or so, I've been unable to run chrome. Any > >> attempt to start it up will cause the system either to freeze up > >> or reboot. > > > > To add to this, I've had the same problem on 10-CURRENT for several > > months now. > > Are you guys building ports with clang? There's a known bug with > google-perftools, when it's built with clang, chrome will crash upon > launch. > > > chrome itself can be built with any compiler, but if google-perftools > is built with clang, crash! > > http://code.google.com/p/gperftools/issues/detail?id=394 > Ah, yes, I remember you mentioning this a month or two ago (at least, I think it was you). Thanks for the reminder. I'm gonna make sure my /etc/make.conf specifies gcc for that port. -- Conrad J. Sabatier conrads@cox.net From owner-freebsd-current@FreeBSD.ORG Thu May 17 23:12:16 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C3071065673 for ; Thu, 17 May 2012 23:12:16 +0000 (UTC) (envelope-from evanm@google.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id D4AEC8FC17 for ; Thu, 17 May 2012 23:12:15 +0000 (UTC) Received: by yhgm50 with SMTP id m50so3012709yhg.13 for ; Thu, 17 May 2012 16:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-system-of-record; bh=ghFcL8uwcfxfnYgafDq++zBcoq3yJSuSPW8IPkKE09Y=; b=BDi4BymwBruY31EE7FYpsimhqSKk+8MW3AHf2pq9v0rrB/0xnKUmaxgPShBLd7SiDQ 8u55lw144GnvgZOwrMC2ntoLWTgiTuIo1rB61BhvPXYBgR49o3+v2B+AIOA1bQhL9X6A 2l3R9kjhuHA0hS6B3xwUMBSKAqWvfRjvuI2KY64RXK50mt0nE9X+pWlmG240/LGxPDGn Rr+wmnqGWnSHhr7YNZg9IzP4JmhOvQThTDeSrOmZrhI9aWZFO7vyKaSAY5efqPA/ta7e WR9KO7PgNz0IBuqFsQJbhTQyPLyd3GnwVRNX7dbOWM2nMuR8VjP55r/TlpojINNLktNw ytWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-system-of-record:x-gm-message-state; bh=ghFcL8uwcfxfnYgafDq++zBcoq3yJSuSPW8IPkKE09Y=; b=Rex/gcIiAwTO5JVaBJAIPRrac0c1o42ngJ4gHr/rbzOyZ7JRT7HNhpPC1jDaG23p6a 9oLmGmrABQ/hAKO4ck7e/Rec525bos64s98Rry+asI9qV2tdjUkXtUsfSKPFIkxDQ+uN HYi+hnT50mAC20EmUC6kEi3R6vmOddYYbAVn/iiZ86mWYBjwyEiGuXeUPJENnqkjnwAO 6Wxu9MwyYnBh/dC15ebbrO4cf32YaO0KVWOXIrcBzT8hLSCBQ4qzl6O9+BYrII3OTpXh zf4/R7CDT6QN30oiLBpfN99jJ/9bIkkSeabCSTjUuPPnFq75lYqXLKLcv4tkVmktfSdl fepw== Received: by 10.236.126.15 with SMTP id a15mr10103691yhi.14.1337296335240; Thu, 17 May 2012 16:12:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.126.15 with SMTP id a15mr10103679yhi.14.1337296335103; Thu, 17 May 2012 16:12:15 -0700 (PDT) Sender: evanm@google.com Received: by 10.101.156.21 with HTTP; Thu, 17 May 2012 16:12:15 -0700 (PDT) In-Reply-To: <20120517180849.72ac2664@serene.no-ip.org> References: <20120517011554.5d16067e@serene.no-ip.org> <20120517180849.72ac2664@serene.no-ip.org> Date: Thu, 17 May 2012 16:12:15 -0700 X-Google-Sender-Auth: yAEkk2mRFav6kIXxnbTa-cj8oHY Message-ID: From: Evan Martin To: "Conrad J. Sabatier" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQnKpeO0HxYcw8UFixnN+ugeacejTLynr7csuGuUDH9bBqziaRYhct3B6lgmoKQgomYGpw+Y3P4wieENOHvz3EmGreWJIWyl2wHJ96tAtovzesuZ2D/KRH2ldgBQLfwq/1r/4gd0iLZfaCyFjSa4DPCZIdNBSw== X-Mailman-Approved-At: Fri, 18 May 2012 02:36:12 +0000 Cc: freebsd-chromium@freebsd.org, John Hixson , freebsd-current@freebsd.org Subject: Re: Chrome crashing system (amd64-10.0-CURRENT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 23:12:16 -0000 On Thu, May 17, 2012 at 4:08 PM, Conrad J. Sabatier wrote= : > Thanks. =A0I tried those, and it still locked up. > > I finally just moved away ~/.config/chromium, and it started up OK. > Luckily, I was able to restore pretty much everything from my synced > data. It's a little surprising to me that a userspace app is able to nuke your system, but perhaps the bug is just something mundane like out of control memory allocations and it's just swapping. From owner-freebsd-current@FreeBSD.ORG Thu May 17 23:20:19 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BEE10106566B; Thu, 17 May 2012 23:20:19 +0000 (UTC) (envelope-from vance.siemens@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 89B928FC0C; Thu, 17 May 2012 23:20:19 +0000 (UTC) Received: by dadv36 with SMTP id v36so3356179dad.13 for ; Thu, 17 May 2012 16:20:19 -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:content-transfer-encoding; bh=0IAJVUnFPDmoQROydrYkUoE4xeShg5/PTq4WjuJKCfk=; b=FR/YXLFTg0XVdMlJuSYzVmvjSavTsMXXhQbhJdv0MQNoxxCz/3x/C2vdHA/A2IsdOr xp3y9YPcO0nMaCnJsTb8MvQxaKLPwfSgJ27mwfq2HGpJjiWHHgjrr5S/mGOCUDnJVDlQ uXtLivI9VzeUB1RUDeVDME5APIoH3+4//pNJOy6sYnIf9ejE5mu0YozoEajWo+koUohY +OBOLUkX/OP4oELt27r8bqe8Zq+EDoJPdh6c3jWDmyGPFyqN4SoVKQmwP2Cq/J1Hffpc /NjRjVnLtiEvPQamZcl13vTNCAoT4TzIFIelI286M1dcfgcM9QDyEzuvIWgbF2kd3m63 S3dQ== MIME-Version: 1.0 Received: by 10.68.191.196 with SMTP id ha4mr24444399pbc.146.1337296818970; Thu, 17 May 2012 16:20:18 -0700 (PDT) Received: by 10.68.25.138 with HTTP; Thu, 17 May 2012 16:20:18 -0700 (PDT) In-Reply-To: <868vgsv0ga.fsf@ds4.des.no> References: <4FA2434F.1020802@unsane.co.uk> <864nrxh5zf.fsf@ds4.des.no> <868vgsv0ga.fsf@ds4.des.no> Date: Thu, 17 May 2012 19:20:18 -0400 Message-ID: From: Vance Siemens To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 18 May 2012 02:36:32 +0000 Cc: freebsd-current@freebsd.org, freebsd-chat@freebsd.org, Vincent Hoffman Subject: Re: FreeBSD 10 prognostication... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 23:20:19 -0000 Eh, sorry. I got excited at the prospect of downloading FreeBSD from the App Store and having the installer "just work" in a modern GUI. You have to admit, FreeBSD is lacking in this area. It would be a boon. On Wed, May 16, 2012 at 7:18 AM, Dag-Erling Sm=C3=B8rgrav wrot= e: > Vance Siemens writes: >> Can you share a brief overview of what's wrong with it? > > Umm, it's about as factual as The Onion, except not as funny. =C2=A0FreeB= SD > never had to "jettison two thirds of its code base and start from > scratch". =C2=A0Apple is not involved in FreeBSD development. =C2=A0No Ma= c OS X or > Darwin version "includes" FreeBSD. =C2=A0FreeBSD and Mac OS X will never > merge. =C2=A0FreeBSD was never acquired by WinDriver Systems or by anyone > else, although a company named WindRiver Systems (makers of the embedded > operating system VxWorks, not of Windows video drivers) did at one point > acquire BSDI, which had previously acquired Walnut Creek CD-ROM, which > was heavily involved in the early history of both FreeBSD and Slackware > Linux. =C2=A0The remains of Walnut Creek CD-ROM and BSDI are now known as > FreeBSD Mall and iXsystems (of PC-BSD and FreeNAS fame). > > DES > -- > Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri May 18 03:24:33 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F7AA106566C; Fri, 18 May 2012 03:24:33 +0000 (UTC) (envelope-from Rick.Hamell@sparqtraining.com) Received: from mx1.nike.iphmx.com (esa8.nike.iphmx.com [68.232.135.86]) by mx1.freebsd.org (Postfix) with ESMTP id 49E068FC1B; Fri, 18 May 2012 03:24:33 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.75,614,1330934400"; d="scan'208";a="56741833" Received: from barrierb241.nike.com (HELO barrierL241.nike.com) ([146.197.27.90]) by mx1.nike.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 May 2012 20:23:24 -0700 Received: from beavertn-svr-j5.nike.com (beavertn-svr-j5.nike.com [146.197.9.146]) by nkewhqmsf05.nike.com with ESMTP id q4I3NMqP006770; Fri, 18 May 2012 03:23:24 GMT Received: from HILLSBOR-SVR-JN.nike.com ([146.197.64.200]) by beavertn-svr-j5.nike.com over TLS secured channel with Microsoft SMTPSVC(7.0.6002.18264); Thu, 17 May 2012 20:23:22 -0700 Received: from BEAVERTN-SVR-VE.nike.com ([146.197.89.82]) by HILLSBOR-SVR-JN.nike.com ([::1]) with mapi; Thu, 17 May 2012 20:23:21 -0700 From: "Hamell, Rick (SPARQ)" To: Vance Siemens Date: Thu, 17 May 2012 20:23:16 -0700 Thread-Topic: FreeBSD 10 prognostication... Thread-Index: Ac00pZM+FRhi2pkcShSDUNgEg3F7mw== Message-ID: References: <4FA2434F.1020802@unsane.co.uk> <864nrxh5zf.fsf@ds4.des.no> <868vgsv0ga.fsf@ds4.des.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 18 May 2012 03:23:22.0566 (UTC) FILETIME=[9448CE60:01CD34A5] X-Mailman-Approved-At: Fri, 18 May 2012 04:57:12 +0000 Cc: =?utf-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= , "freebsd-current@freebsd.org" , "freebsd-chat@freebsd.org" , Vincent Hoffman Subject: Re: FreeBSD 10 prognostication... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 03:24:33 -0000 V2hhdCwgOGJpdCBjb2xvciBBTlNJIGlzbid0IEdVSSBlbm91Z2g/DQoNCkJ1dCBzZXJpb3VzbHks IGl0IGZlZWxzIGxpa2UgaXQgd29ya3MgZXZlbiB3b3JzZSB0aGVuIGl0IGRpZCBhIGRlY2FkZSBh Z28uIA0KDQpSaWNrIEhhbWVsbA0KU2VudCBmcm9tIG15IGlQaG9uZQ0KDQpPbiBNYXkgMTcsIDIw MTIsIGF0IDQ6MjAgUE0sICJWYW5jZSBTaWVtZW5zIiA8dmFuY2Uuc2llbWVuc0BnbWFpbC5jb20+ IHdyb3RlOg0KDQo+IEVoLCBzb3JyeS4gSSBnb3QgZXhjaXRlZCBhdCB0aGUgcHJvc3BlY3Qgb2Yg ZG93bmxvYWRpbmcgRnJlZUJTRCBmcm9tDQo+IHRoZSBBcHAgU3RvcmUgYW5kIGhhdmluZyB0aGUg aW5zdGFsbGVyICJqdXN0IHdvcmsiIGluIGEgbW9kZXJuIEdVSS4NCj4gWW91IGhhdmUgdG8gYWRt aXQsIEZyZWVCU0QgaXMgbGFja2luZyBpbiB0aGlzIGFyZWEuIEl0IHdvdWxkIGJlIGENCj4gYm9v bi4NCj4gDQo+IE9uIFdlZCwgTWF5IDE2LCAyMDEyIGF0IDc6MTggQU0sIERhZy1FcmxpbmcgU23D uHJncmF2IDxkZXNAZGVzLm5vPiB3cm90ZToNCj4+IFZhbmNlIFNpZW1lbnMgPHZhbmNlLnNpZW1l bnNAZ21haWwuY29tPiB3cml0ZXM6DQo+Pj4gQ2FuIHlvdSBzaGFyZSBhIGJyaWVmIG92ZXJ2aWV3 IG9mIHdoYXQncyB3cm9uZyB3aXRoIGl0Pw0KPj4gDQo+PiBVbW0sIGl0J3MgYWJvdXQgYXMgZmFj dHVhbCBhcyBUaGUgT25pb24sIGV4Y2VwdCBub3QgYXMgZnVubnkuICBGcmVlQlNEDQo+PiBuZXZl ciBoYWQgdG8gImpldHRpc29uIHR3byB0aGlyZHMgb2YgaXRzIGNvZGUgYmFzZSBhbmQgc3RhcnQg ZnJvbQ0KPj4gc2NyYXRjaCIuICBBcHBsZSBpcyBub3QgaW52b2x2ZWQgaW4gRnJlZUJTRCBkZXZl bG9wbWVudC4gIE5vIE1hYyBPUyBYIG9yDQo+PiBEYXJ3aW4gdmVyc2lvbiAiaW5jbHVkZXMiIEZy ZWVCU0QuICBGcmVlQlNEIGFuZCBNYWMgT1MgWCB3aWxsIG5ldmVyDQo+PiBtZXJnZS4gIEZyZWVC U0Qgd2FzIG5ldmVyIGFjcXVpcmVkIGJ5IFdpbkRyaXZlciBTeXN0ZW1zIG9yIGJ5IGFueW9uZQ0K Pj4gZWxzZSwgYWx0aG91Z2ggYSBjb21wYW55IG5hbWVkIFdpbmRSaXZlciBTeXN0ZW1zIChtYWtl cnMgb2YgdGhlIGVtYmVkZGVkDQo+PiBvcGVyYXRpbmcgc3lzdGVtIFZ4V29ya3MsIG5vdCBvZiBX aW5kb3dzIHZpZGVvIGRyaXZlcnMpIGRpZCBhdCBvbmUgcG9pbnQNCj4+IGFjcXVpcmUgQlNESSwg d2hpY2ggaGFkIHByZXZpb3VzbHkgYWNxdWlyZWQgV2FsbnV0IENyZWVrIENELVJPTSwgd2hpY2gN Cj4+IHdhcyBoZWF2aWx5IGludm9sdmVkIGluIHRoZSBlYXJseSBoaXN0b3J5IG9mIGJvdGggRnJl ZUJTRCBhbmQgU2xhY2t3YXJlDQo+PiBMaW51eC4gIFRoZSByZW1haW5zIG9mIFdhbG51dCBDcmVl ayBDRC1ST00gYW5kIEJTREkgYXJlIG5vdyBrbm93biBhcw0KPj4gRnJlZUJTRCBNYWxsIGFuZCBp WHN5c3RlbXMgKG9mIFBDLUJTRCBhbmQgRnJlZU5BUyBmYW1lKS4NCj4+IA0KPj4gREVTDQo+PiAt LQ0KPj4gRGFnLUVybGluZyBTbcO4cmdyYXYgLSBkZXNAZGVzLm5vDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGZyZWVic2QtY2hhdEBmcmVlYnNk Lm9yZyBtYWlsaW5nIGxpc3QNCj4gaHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlz dGluZm8vZnJlZWJzZC1jaGF0DQo+IFRvIHVuc3Vic2NyaWJlLCBzZW5kIGFueSBtYWlsIHRvICJm cmVlYnNkLWNoYXQtdW5zdWJzY3JpYmVAZnJlZWJzZC5vcmciDQo= From owner-freebsd-current@FreeBSD.ORG Fri May 18 07:08:58 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AA27106566B; Fri, 18 May 2012 07:08:58 +0000 (UTC) (envelope-from gleb.kurtsou@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 39E8C8FC0A; Fri, 18 May 2012 07:08:57 +0000 (UTC) Received: by laai10 with SMTP id i10so2600169laa.13 for ; Fri, 18 May 2012 00:08:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=X8L9RH6HBQMnVRGOueaFjiU3nYL4QOrjNzzNCbtGdz0=; b=MG1O02tOInQuRcQBPTBnWZZaOACt6nuW47uM7M35AXzHqqU/oVmRCyamRuBESToCuU 0aQdEbByZSSDWbSs1NR+64i39eao1NLxy40ZBxyX29POo3SE9TENy2/ziWQyJElls3c1 fyG9/iqYYFNr+2tZuW/Y45wfRfSglINST2CokH3FBpT89qmLpP0TzI3QYMHnfu5AtJPI XovkK4TTfMZR1DVKcPprm+WiJMN3rVDsC6lP0W0ALbE+IyzMnggBCb+MIjASd+YH9k/1 8AuDwB4vhOih07mDs8n5l9pvgsVXIn1AGEdwmpSopnMnf+jb1rjU+Lrgsav9fvyv/21W BXIQ== Received: by 10.112.24.194 with SMTP id w2mr4262068lbf.75.1337324935801; Fri, 18 May 2012 00:08:55 -0700 (PDT) Received: from localhost ([78.157.92.5]) by mx.google.com with ESMTPS id gv8sm11154210lab.14.2012.05.18.00.08.46 (version=SSLv3 cipher=OTHER); Fri, 18 May 2012 00:08:54 -0700 (PDT) Date: Fri, 18 May 2012 10:08:46 +0300 From: Gleb Kurtsou To: Pedro Giffuni Message-ID: <20120518070846.GB1071@reks> References: <4FB51CDF.3040306@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4FB51CDF.3040306@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org, freebsd-toolchain@FreeBSD.org Subject: Re: GCC update for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 07:08:58 -0000 On (17/05/2012 10:44), Pedro Giffuni wrote: > Hi; > > I took a bunch of patches that were merged into the GCC 4.1 branch > (under GPLv2) and prepared a patch for merging them into our base > gcc. These are supposed to be bug fixes only. > > You can get the patch here: > http://people.freebsd.org/~pfg/patches/patch-contrib-gcc > And, for those really interested, the log is here: > http://people.freebsd.org/~pfg/patches/gcc41-pr-log Could you check if patch fixes this issue: http://marc.info/?l=freebsd-hackers&m=132348021530691&w=2 I've disabled gcc from base locally since discovering it. Thanks, Gleb. > It may be my imagination but the patch seems to be causing more > warnings than usual and it breaks the kernel here: > > ____ > $ make > cc -c -O2 -Os -pipe -fno-strict-aliasing -march=athlon64 -std=c99 -g > -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs > -fdiagnostics-show-option -nostdinc -I. -I../../.. > -I../../../contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include > opt_global.h -fno-common -finline-limit=8000 --param > inline-unit-growth=100 --param large-function-growth=1000 > -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse > -msoft-float -fno-asynchronous-unwind-tables -ffreestanding > -fstack-protector -Werror ../../../cam/scsi/scsi_sa.c > cc1: warnings being treated as errors > ../../../cam/scsi/scsi_sa.c: In function 'samount': > ../../../cam/scsi/scsi_sa.c:1887: warning: 'comp_supported' may be used > uninitialized in this function > ../../../cam/scsi/scsi_sa.c:1888: warning: 'write_protect' may be used > uninitialized in this function > ../../../cam/scsi/scsi_sa.c:1887: warning: 'comp_enabled' may be used > uninitialized in this function > ../../../cam/scsi/scsi_sa.c:2728: warning: 'current_speed' may be used > uninitialized in this function > ../../../cam/scsi/scsi_sa.c:2728: note: 'current_speed' was declared here > ../../../cam/scsi/scsi_sa.c:2727: warning: 'current_density' may be used > uninitialized in this function > ../../../cam/scsi/scsi_sa.c:2727: note: 'current_density' was declared here > ../../../cam/scsi/scsi_sa.c:2725: warning: 'current_blocksize' may be > used uninitialized in this function > ../../../cam/scsi/scsi_sa.c:2725: note: 'current_blocksize' was declared > here > ../../../cam/scsi/scsi_sa.c:2728: warning: 'current_speed' may be used > uninitialized in this function > ../../../cam/scsi/scsi_sa.c:2728: note: 'current_speed' was declared here > ../../../cam/scsi/scsi_sa.c:2725: warning: 'current_blocksize' may be > used uninitialized in this function > ../../../cam/scsi/scsi_sa.c:2725: note: 'current_blocksize' was declared > here > ../../../cam/scsi/scsi_sa.c:2728: warning: 'current_speed' may be used > uninitialized in this function > ../../../cam/scsi/scsi_sa.c:2728: note: 'current_speed' was declared here > ../../../cam/scsi/scsi_sa.c:2725: warning: 'current_blocksize' may be > used uninitialized in this function > ../../../cam/scsi/scsi_sa.c:2725: note: 'current_blocksize' was declared > here > ../../../cam/scsi/scsi_sa.c:2728: warning: 'current_speed' may be used > uninitialized in this function > ../../../cam/scsi/scsi_sa.c:2728: note: 'current_speed' was declared here > ../../../cam/scsi/scsi_sa.c:2725: warning: 'current_blocksize' may be > used uninitialized in this function > ../../../cam/scsi/scsi_sa.c:2725: note: 'current_blocksize' was declared > here > *** Error code 1 > ... > ____ > > Other stuff I tested (Apache OpenOffice) builds fine. > > cheers, > > Pedro. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri May 18 08:45:51 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 40535106564A; Fri, 18 May 2012 08:45:51 +0000 (UTC) (envelope-from conrads@serene.no-ip.org) Received: from eastrmfepo203.cox.net (eastrmfepo203.cox.net [68.230.241.218]) by mx1.freebsd.org (Postfix) with ESMTP id B543C8FC0C; Fri, 18 May 2012 08:45:50 +0000 (UTC) Received: from eastrmimpo209.cox.net ([68.230.241.224]) by eastrmfepo203.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20120518084550.LXUR18532.eastrmfepo203.cox.net@eastrmimpo209.cox.net>; Fri, 18 May 2012 04:45:50 -0400 Received: from serene.no-ip.org ([98.164.83.188]) by eastrmimpo209.cox.net with bizsmtp id BLlp1j00A43nm9e02LlpVL; Fri, 18 May 2012 04:45:49 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020207.4FB60C3D.00B0,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=1.1 cv=LKDkrRjixwgtmuXwrIwnijc/8ro9lGx9B3c+ChRocFo= c=1 sm=1 a=z1TLwsU0kBEA:10 a=swW3mUodPN4A:10 a=G8Uczd0VNMoA:10 a=8nJEP1OIZ-IA:10 a=F4D4Y6gUi4XSUMrqnG4xkg==:17 a=kviXuzpPAAAA:8 a=-_rlT6ndqfEwl-SpOPUA:9 a=wPNLvfGTeEIA:10 a=4vB-4DCPJfMA:10 a=F4D4Y6gUi4XSUMrqnG4xkg==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Received: from serene.no-ip.org (localhost [127.0.0.1]) by serene.no-ip.org (8.14.5/8.14.5) with ESMTP id q4I8jnmL004910; Fri, 18 May 2012 03:45:49 -0500 (CDT) (envelope-from conrads@serene.no-ip.org) Received: (from conrads@localhost) by serene.no-ip.org (8.14.5/8.14.5/Submit) id q4I8jh1J004909; Fri, 18 May 2012 03:45:43 -0500 (CDT) (envelope-from conrads) Date: Fri, 18 May 2012 03:45:43 -0500 From: "Conrad J. Sabatier" To: Evan Martin Message-ID: <20120518084543.GB1264@serene.no-ip.org> References: <20120517011554.5d16067e@serene.no-ip.org> <20120517180849.72ac2664@serene.no-ip.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "Conrad J. Sabatier" , freebsd-chromium@freebsd.org, John Hixson , freebsd-current@freebsd.org Subject: Re: Chrome crashing system (amd64-10.0-CURRENT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 08:45:51 -0000 On Thu, May 17, 2012 at 04:12:15PM -0700, Evan Martin wrote: > On Thu, May 17, 2012 at 4:08 PM, Conrad J. Sabatier wrote: > > Thanks.  I tried those, and it still locked up. > > > > I finally just moved away ~/.config/chromium, and it started up OK. > > Luckily, I was able to restore pretty much everything from my synced > > data. > > It's a little surprising to me that a userspace app is able to nuke > your system, but perhaps the bug is just something mundane like out of > control memory allocations and it's just swapping. I just discovered while poking around again under ~/.config that my old chromium directory (that is, the directory file itself) had somehow become corrupted. This was most likely what was causing chrome to go berserk before. I'm using SU+J here, and this problem wasn't detected by fsck before. I only discovered it this evening when, after having already deleted all of the files in the directory, rmdir failed with the error message "Directory not empty". After booting single-user and running fsck twice (to force it not to use the journal), looks like everything's back to normal now. -- Conrad J. Sabatier conrads@cox.net From owner-freebsd-current@FreeBSD.ORG Fri May 18 10:00:10 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F57F1065670; Fri, 18 May 2012 10:00:10 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 863BD8FC0A; Fri, 18 May 2012 10:00:09 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1SVJyc-0000W0-Mr>; Fri, 18 May 2012 12:00:02 +0200 Received: from munin.geoinf.fu-berlin.de ([130.133.86.110]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1SVJyc-0005Xa-JD>; Fri, 18 May 2012 12:00:02 +0200 Message-ID: <4FB61DA6.4010404@zedat.fu-berlin.de> Date: Fri, 18 May 2012 12:00:06 +0200 From: "Hartmann, O." Organization: FU Berlin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120504 Thunderbird/12.0.1 MIME-Version: 1.0 To: Dimitry Andric References: <4FB3F663.8090308@zedat.fu-berlin.de> <4FB42926.1040103@FreeBSD.org> In-Reply-To: <4FB42926.1040103@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------040201090504030201090508" X-Originating-IP: 130.133.86.110 Cc: Current FreeBSD Subject: Re: r235510: recent buildworld fail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 10:00:10 -0000 This is a multi-part message in MIME format. --------------040201090504030201090508 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 05/17/12 00:24, Dimitry Andric wrote: > On 2012-05-16 20:48, O. Hartmann wrote:> When compiling world (make buildworld) I receive the bewlo error, which >> seems very strange! >> The error occured out of the blue on a FreeBSD 10.0-CURRENT/amd64 box. > ... >> /usr/obj/usr/src/tmp/usr/bin/ld: Warning: size of symbol >> `_ZNSi6ignoreEv@GLIBCXX_3.4' changed from 243 in >> /usr/obj/usr/src/tmp/usr/lib/libstdc++.so to 211 in >> /usr/obj/usr/src/tmp/usr/lib/libstdc++.so >> >> looks like a "mixed up" between CLANG and legacy GCC 4.2.1, as far as I >> remember this error was typical for a mismatch. > > Where did you read that? In any case, I think this may be a problem > with one of the settings in your make.conf, not those in src.conf, > specifically CFLAGS or CXXFLAGS. Can you please post those? There is nothing special about the setting. I present to you the /etc/make.conf as used when it fails. Hope its shwoing something useful. I fear there has been something went wrong on one of the prior installations ... Regards, Oliver --------------040201090504030201090508 Content-Type: text/plain; charset=us-ascii; name="make.conf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="make.conf" # $FreeBSD: src/share/examples/etc/make.conf,v 1.279 2007/01/17 12:43:06 des Exp $ # # NOTE: Please would any committer updating this file also update the # make.conf(5) manual page, if necessary, which is located in # src/share/man/man5/make.conf.5. # # /etc/make.conf, if present, will be read by make (see # /usr/share/mk/sys.mk). It allows you to override macro definitions # to make without changing your source tree, or anything the source # tree installs. # # This file must be in valid Makefile syntax. # # There are additional things you can put into /etc/make.conf. # You have to find those in the Makefiles and documentation of # the source tree. # # Note, that you should not set MAKEOBJDIRPREFIX or MAKEOBJDIR # from make.conf (or as command line variables to make). # Both variables are environment variables for make and must be used as: # # env MAKEOBJDIRPREFIX=/big/directory make # # # The CPUTYPE variable controls which processor should be targeted for # generated code. This controls processor-specific optimizations in # certain code (currently only OpenSSL) as well as modifying the value # of CFLAGS to contain the appropriate optimization directive to gcc. # The automatic setting of CFLAGS may be overridden using the # NO_CPU_CFLAGS variable below. # Currently the following CPU types are recognized: # Intel x86 architecture: # (AMD CPUs) opteron athlon64 athlon-mp athlon-xp athlon-4 # athlon-tbird athlon k8 k6-3 k6-2 k6 k5 # (Intel CPUs) core2 core nocona pentium4m pentium4 prescott # pentium3m pentium3 pentium-m pentium2 # pentiumpro pentium-mmx pentium i486 i386 # (Via CPUs) c3 c3-2 # Alpha/AXP architecture: ev67 ev6 pca56 ev56 ev5 ev45 ev4 # AMD64 architecture: opteron, athlon64, nocona, prescott, core2 # Intel ia64 architecture: itanium2, itanium # # (?= allows to buildworld for a different CPUTYPE.) # #NO_CLANG=YES CPUTYPE?=native #NO_CPU_CFLAGS= # Don't add -march= to CFLAGS automatically #NO_CPU_COPTFLAGS= # Don't add -march= to COPTFLAGS automatically # # CFLAGS controls the compiler settings used when compiling C code. # Note that optimization settings other than -O and -O2 are not recommended # or supported for compiling the world or the kernel - please revert any # nonstandard optimization settings to "-O" or "-O2 -fno-strict-aliasing" # before submitting bug reports without patches to the developers. # # Compiling with -fstrict-aliasing optimization breaks some [notable] ports. # GCC turns on -fstrict-aliasing optimization at all levels above -O[1], so # explicitly turn it off when using compiling with the -O2 optimization level. # #CFLAGS= -O2 -fno-strict-aliasing -pipe CFLAGS+= -O2 -fno-strict-aliasing -pipe # # CXXFLAGS controls the compiler settings used when compiling C++ code. # Note that CXXFLAGS is initially set to the value of CFLAGS. If you wish # to add to CXXFLAGS value, "+=" must be used rather than "=". Using "=" # alone will remove the often needed contents of CFLAGS from CXXFLAGS. # #CXXFLAGS+= -fconserve-space # # MAKE_SHELL controls the shell used internally by make(1) to process the # command scripts in makefiles. Three shells are supported, sh, ksh, and # csh. Using sh is most common, and advised. Using ksh *may* work, but is # not guaranteed to. Using csh is absurd. The default is to use sh. # #MAKE_SHELL?=sh # # BDECFLAGS are a set of gcc warning settings that Bruce Evans has suggested # for use in developing FreeBSD and testing changes. They can be used by # putting "CFLAGS+=${BDECFLAGS}" in /etc/make.conf. -Wconversion is not # included here due to compiler bugs, e.g., mkdir()'s mode_t argument. # #BDECFLAGS= -W -Wall -ansi -pedantic -Wbad-function-cast -Wcast-align \ # -Wcast-qual -Wchar-subscripts -Winline \ # -Wmissing-prototypes -Wnested-externs -Wpointer-arith \ # -Wredundant-decls -Wshadow -Wstrict-prototypes -Wwrite-strings # # To compile just the kernel with special optimizations, you should use # this instead of CFLAGS (which is not applicable to kernel builds anyway). # There is very little to gain by using higher optimization levels, and doing # so can cause problems. # #COPTFLAGS= -O -pipe COPTFLAGS+= -O2 -pipe # # Compare before install #INSTALL=install -C # # Mtree will follow symlinks #MTREE_FOLLOWS_SYMLINKS= -L # # To enable installing ssh(1) with the setuid bit turned on #ENABLE_SUID_SSH= # # To enable installing newgrp(1) with the setuid bit turned on. # Without the setuid bit, newgrp cannot change users' groups. #ENABLE_SUID_NEWGRP= # # To avoid building various parts of the base system: #NO_MODULES= # do not build modules with the kernel #NO_SHARE= # do not go into the share subdir #NO_SHARED= # build /bin and /sbin statically linked (bad idea) # # Variables that control how ppp(8) is built. #PPP_NO_NAT= # do not build with NAT support (see make.conf(5)) #PPP_NO_NETGRAPH= # do not build with Netgraph support #PPP_NO_RADIUS= # do not build with RADIUS support #PPP_NO_SUID= # build with normal permissions # #TRACEROUTE_NO_IPSEC= # do not build traceroute(8) with IPSEC support # # To build sys/modules when building the world (our old way of doing things) #MODULES_WITH_WORLD= # do not build modules when building kernel # # The list of modules to build instead of all of them. #MODULES_OVERRIDE= linux ipfw # # The list of modules to never build, applied *after* MODULES_OVERRIDE. #WITHOUT_MODULES= bktr plip # # If you do not want unformatted manual pages to be compressed # when they are installed: # #NO_MANCOMPRESS= # # # Default format for system documentation, depends on your printer. # Set this to "ascii" for simple printers or screen # #PRINTERDEVICE= ps # # # How long to wait for a console keypress before booting the default kernel. # This value is approximately in milliseconds. Keypresses are accepted by the # BIOS before booting from disk, making it possible to give custom boot # parameters even when this is set to 0. # #BOOTWAIT=0 #BOOTWAIT=30000 # # By default, the system will always use the keyboard/video card as system # console. However, the boot blocks may be dynamically configured to use a # serial port in addition to or instead of the keyboard/video console. # # By default we use COM1 as our serial console port *if* we're going to use # a serial port as our console at all. Alter as necessary. # # COM1: = 0x3F8, COM2: = 0x2F8, COM3: = 0x3E8, COM4: = 0x2E8 # #BOOT_COMCONSOLE_PORT= 0x3F8 # # The default serial console speed is 9600. Set the speed to a larger value # for better interactive response. # #BOOT_COMCONSOLE_SPEED= 115200 # # By default the 'pxeboot' loader retrieves the kernel via NFS. Defining # this and recompiling /usr/src/sys/boot will cause it to retrieve the kernel # via TFTP. This allows pxeboot to load a custom BOOTP diskless kernel yet # still mount the server's '/' (i.e. rather than load the server's kernel). # #LOADER_TFTP_SUPPORT= YES # # # Kerberos 5 su (k5su) # If you want to use the k5su utility, define this to have it installed # set-user-ID. #ENABLE_SUID_K5SU= # # # CVSup update flags. Edit SUPFILE settings to reflect whichever distribution # file(s) you use on your site (see /usr/share/examples/cvsup/README for more # information on CVSup and these files). To use, do "make update" in /usr/src. # #SUP_UPDATE= YES # #SUP= /usr/bin/csup #SUPFLAGS= -g -L 2 #SUPHOST= cvsup.FreeBSD.org #SUPFILE= /usr/local/etc/system.cvs PORTSSUPFILE= /usr/share/examples/cvsup/ports-supfile DOCSUPFILE= /usr/local/etc/docs.cvs # # top(1) uses a hash table for the user names. The size of this hash # can be tuned to match the number of local users. The table size should # be a prime number approximately twice as large as the number of lines in # /etc/passwd. The default number is 20011. # #TOP_TABLE_SIZE= 101 # # Documentation # # The list of languages and encodings to build and install # DOC_LANG= en_US.ISO8859-1 de_DE.ISO8859-1 # # # sendmail # # The following sets the default m4 configuration file to use at # install time. Use with caution as a make install will overwrite # any existing /etc/mail/sendmail.cf. Note that SENDMAIL_CF is now # deprecated. The value should be a fully qualified path name. # #SENDMAIL_MC=/etc/mail/myconfig.mc # # The following sets the default m4 configuration file for mail # submission to use at install time. Use with caution as a make # install will overwrite any existing /etc/mail/submit.cf. The # value should be a fully qualified path name. # #SENDMAIL_SUBMIT_MC=/etc/mail/mysubmit.mc # # If you need to build additional .cf files during a make buildworld, # include the full paths to the .mc files in SENDMAIL_ADDITIONAL_MC. # #SENDMAIL_ADDITIONAL_MC=/etc/mail/foo.mc /etc/mail/bar.mc # # The following overrides the default location for the m4 configuration # files used to build a .cf file from a .mc file. # #SENDMAIL_CF_DIR=/usr/local/share/sendmail/cf # # Setting the following variable modifies the flags passed to m4 when # building a .cf file from a .mc file. It can be used to enable # features disabled by default. # #SENDMAIL_M4_FLAGS= # # Setting the following variables modifies the build environment for # sendmail and its related utilities. For example, SASL support can be # added with settings such as: # # with SASLv1: # SENDMAIL_CFLAGS=-I/usr/local/include/sasl1 -DSASL # SENDMAIL_LDFLAGS=-L/usr/local/lib # SENDMAIL_LDADD=-lsasl # # with SASLv2: # SENDMAIL_CFLAGS=-I/usr/local/include -DSASL=2 # SENDMAIL_LDFLAGS=-L/usr/local/lib # SENDMAIL_LDADD=-lsasl2 # # Note: If you are using Cyrus SASL with other applications which require # access to the sasldb file, you should add the following to your # sendmail.mc file: # # define(`confDONT_BLAME_SENDMAIL',`GroupReadableSASLDBFile') # SENDMAIL_CFLAGS=-I/usr/local/include -DSASL=2 SENDMAIL_LDFLAGS=-L/usr/local/lib SENDMAIL_LDADD=-lsasl2 #SENDMAIL_DPADD= # # Setting SENDMAIL_SET_USER_ID will install the sendmail binary as a # set-user-ID root binary instead of a set-group-ID smmsp binary and will # prevent the installation of /etc/mail/submit.cf. # This is a deprecated mode of operation. See etc/mail/README for more # information. # #SENDMAIL_SET_USER_ID= # # The permissions to use on alias and map databases generated using # /etc/mail/Makefile. Defaults to 0640. # #SENDMAIL_MAP_PERMS= # Set this to use svn(1) to update your src tree with make update SVN_UPDATE= YES # SVN= /usr/local/bin/svn SVN_FLAGS= -r HEAD # Set this to the list of ports you wish to rebuild every # time the kernel is built. PORTS_MODULES= "x11/nvidia-driver" # BUGFIX FreeBSD 10.0 #WITH_FBSD10_FIX= YES # Set this to disable assertions and statistics gathering in malloc(3). MALLOC_PRODUCTION= YES ## ## CLANG ## .if !defined(NO_CLANG) .if !defined(CC) || ${CC} == "cc" CC= clang .endif .if !defined(CXX) || ${CXX} == "c++" CXX= clang++ .endif .if !defined(CPP) || ${CPP} == "cpp" CPP= clang-cpp .endif ## Don't die on warnings #NO_WERROR= #WERROR= ## Don't forget this when using Jails! #NO_FSCHG= CFLAGS+= -O3 -pipe -fno-strict-aliasing COPTFLAGS+= -O3 -pipe .endif ## Host Name KERNCONF= TELESTO # Force registration of port even if it is already registered FORCE_PKG_REGISTER= YES # Could trigger problems WITH_OPTIMIZED_FLAGS= YES # Lokal fun WANT_OPENLDAP_SASL= YES # DB5 WITH_BDB_VER= 5 WITH_BDB_HIGHEST= YES # Disable parallel jobs in make (make -jX) DISABLE_MAKE_JOBS= YES # Fixate SAMBA Version SAMBA_PORT= samba36 # Ruby default RUBY_DEFAULT_VER= 1.9 # What PostgreSQL port should be set default WANT_PGSQL_VER= 91 # Build without noveau driver which breaks for new Mesa and DRI #WITHOUT_NOUVEAU= YES # Build with new Xorg stuff? FreeBSD isn't only slow, it is far behinf development ... WITH_NEW_XORG= YES WITH_KMS= YES ### ### ### .if ${.CURDIR:M/usr/ports/x11/nvidia-driver} DISTVERSION= 302.07 .endif # added by use.perl 2012-05-08 10:11:34 PERL_VERSION=5.14.2 --------------040201090504030201090508-- From owner-freebsd-current@FreeBSD.ORG Fri May 18 10:18:57 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3624F106566B for ; Fri, 18 May 2012 10:18:57 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id D83708FC12 for ; Fri, 18 May 2012 10:18:56 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 4225E25D3891; Fri, 18 May 2012 10:18:50 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 75D54BE733D; Fri, 18 May 2012 10:18:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 4Dd3a7mWkaBl; Fri, 18 May 2012 10:18:48 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 7340EBE733A; Fri, 18 May 2012 10:18:48 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <2103A722-43BF-4BCF-AEDE-2E0CB13DF620@kientzle.com> Date: Fri, 18 May 2012 10:18:47 +0000 Content-Transfer-Encoding: 7bit Message-Id: <20769DCB-D3EF-49C6-A791-E190A5CCECAE@lists.zabbadoz.net> References: <2103A722-43BF-4BCF-AEDE-2E0CB13DF620@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1084) Cc: freebsd-current FreeBSD Subject: Re: SUJ file system corruption. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 10:18:57 -0000 On 13. May 2012, at 22:35 , Tim Kientzle wrote: > FYI: Saw a crash due to filesystem corruption when running SUJ. > > This is on a ARM AM335x system (BeagleBone) that is > still pretty experimental, so I certainly cannot rule out other > problems, but in case it means something to > someone, here's the scenario: > > Reset the board to reboot (which is routine for these > small embedded boards) and when it came back up > it went through SUJ recovery, and then a little later > the kernel panicked with this stack trace: > > rm: /var/run/dmesg.boot: Bad file descriptor > panic: ffs_write: type 0xc1e86660 0 (0,1024) Can you tell us if this was HEAD, stable/9 or 9.0-RELEASE? -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-current@FreeBSD.ORG Fri May 18 10:37:33 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D87581065672 for ; Fri, 18 May 2012 10:37:33 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 975E88FC0A for ; Fri, 18 May 2012 10:37:32 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id BEC227300A; Fri, 18 May 2012 12:57:47 +0200 (CEST) Date: Fri, 18 May 2012 12:57:47 +0200 From: Luigi Rizzo To: "Bjoern A. Zeeb" Message-ID: <20120518105747.GB5494@onelab2.iet.unipi.it> References: <2103A722-43BF-4BCF-AEDE-2E0CB13DF620@kientzle.com> <20769DCB-D3EF-49C6-A791-E190A5CCECAE@lists.zabbadoz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20769DCB-D3EF-49C6-A791-E190A5CCECAE@lists.zabbadoz.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current FreeBSD Subject: Re: SUJ file system corruption. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 10:37:33 -0000 On Fri, May 18, 2012 at 10:18:47AM +0000, Bjoern A. Zeeb wrote: > > On 13. May 2012, at 22:35 , Tim Kientzle wrote: > > > FYI: Saw a crash due to filesystem corruption when running SUJ. > > > > This is on a ARM AM335x system (BeagleBone) that is > > still pretty experimental, so I certainly cannot rule out other > > problems, but in case it means something to > > someone, here's the scenario: > > > > Reset the board to reboot (which is routine for these > > small embedded boards) and when it came back up > > it went through SUJ recovery, and then a little later > > the kernel panicked with this stack trace: > > > > rm: /var/run/dmesg.boot: Bad file descriptor > > panic: ffs_write: type 0xc1e86660 0 (0,1024) > > > Can you tell us if this was HEAD, stable/9 or 9.0-RELEASE? on stable/9 and amd64 as of 2-3 months ago i am seeing these panics every time (fortunately very rare) the system needs to recover from a crash. On the subsequent reboot the system keeps crashing randomly as soon as i load disk-intensive applications (often browsers or most things that run under X11, but sometimes the crashes are even before that. I then need to reboot in single user and do a manual fsck. I tried to run fsck using the journal, but after it completes a subsequent non-journal fsck finds errors. In the end, i am not sure if it makes sense to keep the SU+J active on the disk, i am so afraid of crashes that i don't even dare anymore to run experimental kernels or modules on my main workstation! cheers luigi From owner-freebsd-current@FreeBSD.ORG Fri May 18 10:37:37 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BCAB106564A; Fri, 18 May 2012 10:37:37 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 142548FC0C; Fri, 18 May 2012 10:37:36 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1SVKYy-000744-7Z>; Fri, 18 May 2012 12:37:36 +0200 Received: from munin.geoinf.fu-berlin.de ([130.133.86.110]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1SVKYy-0007gx-4w>; Fri, 18 May 2012 12:37:36 +0200 Message-ID: <4FB62673.6050004@zedat.fu-berlin.de> Date: Fri, 18 May 2012 12:37:39 +0200 From: "Hartmann, O." Organization: FU Berlin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120504 Thunderbird/12.0.1 MIME-Version: 1.0 To: Dimitry Andric References: <4FB3F663.8090308@zedat.fu-berlin.de> <4FB42926.1040103@FreeBSD.org> In-Reply-To: <4FB42926.1040103@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.110 Cc: Current FreeBSD Subject: Re: r235510: recent buildworld fail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 10:37:37 -0000 On 05/17/12 00:24, Dimitry Andric wrote: > On 2012-05-16 20:48, O. Hartmann wrote:> When compiling world (make buildworld) I receive the bewlo error, which >> seems very strange! >> The error occured out of the blue on a FreeBSD 10.0-CURRENT/amd64 box. > ... >> /usr/obj/usr/src/tmp/usr/bin/ld: Warning: size of symbol >> `_ZNSi6ignoreEv@GLIBCXX_3.4' changed from 243 in >> /usr/obj/usr/src/tmp/usr/lib/libstdc++.so to 211 in >> /usr/obj/usr/src/tmp/usr/lib/libstdc++.so >> >> looks like a "mixed up" between CLANG and legacy GCC 4.2.1, as far as I >> remember this error was typical for a mismatch. > > Where did you read that? In any case, I think this may be a problem > with one of the settings in your make.conf, not those in src.conf, > specifically CFLAGS or CXXFLAGS. Can you please post those? I tried to build the system with the legacy gcc and it turns out to fail like this: mkdep -f .depend -a -I/usr/src/lib/libc++/../../contrib/libc++/include -I/usr/src/lib/libc++/../../contrib/libcxxrt -DLIBCXXRT -std=c++0x /usr/src/lib/libc++/../../contrib/libc++/src/algorithm.cpp /usr/src/lib/libc++/../../contrib/libc++/src/bind.cpp /usr/src/lib/libc++/../../contrib/libc++/src/chrono.cpp /usr/src/lib/libc++/../../contrib/libc++/src/condition_variable.cpp /usr/src/lib/libc++/../../contrib/libc++/src/debug.cpp /usr/src/lib/libc++/../../contrib/libc++/src/exception.cpp /usr/src/lib/libc++/../../contrib/libc++/src/future.cpp /usr/src/lib/libc++/../../contrib/libc++/src/hash.cpp /usr/src/lib/libc++/../../contrib/libc++/src/ios.cpp /usr/src/lib/libc++/../../contrib/libc++/src/iostream.cpp /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp /usr/src/lib/libc++/../../contrib/libc++/src/memory.cpp /usr/src/lib/libc++/../../contrib/libc++/src/mutex.cpp /usr/src/lib/libc++/../../contrib/libc++/src/new.cpp /usr/src/lib/libc++/../../contrib/libc++/src/random.cpp /usr/src/lib/libc++/../../contrib/libc++/src/regex.cpp /usr/src/lib/libc++/../../contrib/libc++/src/stdexcept.cpp /usr/src/lib/libc++/../../contrib/libc++/src/string.cpp /usr/src/lib/libc++/../../contrib/libc++/src/strstream.cpp /usr/src/lib/libc++/../../contrib/libc++/src/system_error.cpp /usr/src/lib/libc++/../../contrib/libc++/src/thread.cpp /usr/src/lib/libc++/../../contrib/libc++/src/typeinfo.cpp /usr/src/lib/libc++/../../contrib/libc++/src/utility.cpp /usr/src/lib/libc++/../../contrib/libc++/src/valarray.cpp cc1plus: error: unrecognized command line option "-std=c++0x" cc1plus: error: unrecognized command line option "-std=c++0x" cc1plus: error: unrecognized command line option "-std=c++0x" cc1plus: error: unrecognized command line option "-std=c++0x" cc1plus: error: unrecognized command line option "-std=c++0x" cc1plus: error: unrecognized command line option "-std=c++0x" cc1plus: error: unrecognized command line option "-std=c++0x" cc1plus: error: unrecognized command line option "-std=c++0x" cc1plus: error: unrecognized command line option "-std=c++0x" cc1plus: error: unrecognized command line option "-std=c++0x" cc1plus: error: unrecognized command line option "-std=c++0x" cc1plus: error: unrecognized command line option "-std=c++0x" cc1plus: error: unrecognized command line option "-std=c++0x" cc1plus: error: unrecognized command line option "-std=c++0x" cc1plus: error: unrecognized command line option "-std=c++0x" cc1plus: error: unrecognized command line option "-std=c++0x" cc1plus: error: unrecognized command line option "-std=c++0x" cc1plus: error: unrecognized command line option "-std=c++0x" cc1plus: error: unrecognized command line option "-std=c++0x" cc1plus: error: unrecognized command line option "-std=c++0x" cc1plus: error: unrecognized command line option "-std=c++0x" cc1plus: error: unrecognized command line option "-std=c++0x" cc1plus: error: unrecognized command line option "-std=c++0x" cc1plus: error: unrecognized command line option "-std=c++0x" mkdep: compile failed *** [.depend] Error code 1 Stop in /usr/src/lib/libc++. *** [depend] Error code 1 Stop in /usr/src/lib. *** [lib__L] Error code 1 Stop in /usr/src. *** [libraries] Error code 1 Stop in /usr/src. *** [_libraries] Error code 1 Stop in /usr/src. *** [buildworld] Error code 1 From owner-freebsd-current@FreeBSD.ORG Fri May 18 10:45:16 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5398E106564A for ; Fri, 18 May 2012 10:45:16 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 04B1F8FC15 for ; Fri, 18 May 2012 10:45:16 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 6C6EB25D3A82; Fri, 18 May 2012 10:45:14 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id A6589BE7342; Fri, 18 May 2012 10:45:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id DcTEX8vPi3kb; Fri, 18 May 2012 10:45:12 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 28619BE7340; Fri, 18 May 2012 10:45:11 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <20120518105747.GB5494@onelab2.iet.unipi.it> Date: Fri, 18 May 2012 10:45:10 +0000 Content-Transfer-Encoding: 7bit Message-Id: <4AC639B8-4AC4-44DC-929B-1077F4E486D9@lists.zabbadoz.net> References: <2103A722-43BF-4BCF-AEDE-2E0CB13DF620@kientzle.com> <20769DCB-D3EF-49C6-A791-E190A5CCECAE@lists.zabbadoz.net> <20120518105747.GB5494@onelab2.iet.unipi.it> To: Luigi Rizzo X-Mailer: Apple Mail (2.1084) Cc: freebsd-current FreeBSD Subject: Re: SUJ file system corruption. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 10:45:16 -0000 On 18. May 2012, at 10:57 , Luigi Rizzo wrote: > On Fri, May 18, 2012 at 10:18:47AM +0000, Bjoern A. Zeeb wrote: >> >> On 13. May 2012, at 22:35 , Tim Kientzle wrote: >> >>> FYI: Saw a crash due to filesystem corruption when running SUJ. >>> >>> This is on a ARM AM335x system (BeagleBone) that is >>> still pretty experimental, so I certainly cannot rule out other >>> problems, but in case it means something to >>> someone, here's the scenario: >>> >>> Reset the board to reboot (which is routine for these >>> small embedded boards) and when it came back up >>> it went through SUJ recovery, and then a little later >>> the kernel panicked with this stack trace: >>> >>> rm: /var/run/dmesg.boot: Bad file descriptor >>> panic: ffs_write: type 0xc1e86660 0 (0,1024) >> >> >> Can you tell us if this was HEAD, stable/9 or 9.0-RELEASE? > > on stable/9 and amd64 as of 2-3 months ago i am seeing these panics Hmm, if you are on a 2-3 month old stable/9 please update; there have been quite a few su+j bug fixes. If it means you have been seeing them for the 2-3 last months and are on an up-to-date stable/9 please get the attention of Kirk, Jeff and maybe Peter Holm and Kostik. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-current@FreeBSD.ORG Fri May 18 03:52:53 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 290511065673; Fri, 18 May 2012 03:52:53 +0000 (UTC) (envelope-from a@unnali.com) Received: from unnali.com (tsovinar.unnali.com [106.187.34.169]) by mx1.freebsd.org (Postfix) with ESMTP id DEE4A8FC1C; Fri, 18 May 2012 03:52:52 +0000 (UTC) Received: by unnali.com (Postfix, from userid 5001) id 4F5BFC051; Fri, 18 May 2012 03:44:03 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tsovinar.unnali.com X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=unavailable version=3.3.2 Received: from akari.internal.alliancesoftware.com.au (203-206-182-151.perm.iinet.net.au [203.206.182.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: a) by unnali.com (Postfix) with ESMTPSA id CF056C04C; Fri, 18 May 2012 03:43:57 +0000 (UTC) Date: Fri, 18 May 2012 13:43:54 +1000 From: Arlen Cuss To: "=?utf-8?Q?Hamell=2C_Rick_(SPARQ)?=" Message-ID: In-Reply-To: References: <4FA2434F.1020802@unsane.co.uk> <864nrxh5zf.fsf@ds4.des.no> <868vgsv0ga.fsf@ds4.des.no> X-Mailer: sparrow 1.5 (build 1043.1) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailman-Approved-At: Fri, 18 May 2012 11:04:58 +0000 Cc: Vincent Hoffman , =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= , Vance Siemens , "=?utf-8?Q?freebsd-chat=40freebsd.org?=" , "=?utf-8?Q?freebsd-current=40freebsd.org?=" Subject: Re: FreeBSD 10 prognostication... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 03:52:53 -0000 > > > =20 > > > Umm, it's about as factual as The Onion, except not as funny. =46re= eBSD > > > never had to =22jettison two thirds of its code base and start from= > > > scratch=22. Apple is not involved in =46reeBSD development. No Mac = OS X or > > > Darwin version =22includes=22 =46reeBSD. =46reeBSD and Mac OS X wil= l never > > > merge. =46reeBSD was never acquired by WinDriver Systems or by anyo= ne > > > else, although a company named WindRiver Systems (makers of the emb= edded > > > operating system VxWorks, not of Windows video drivers) did at one = point > > > acquire BSDI, which had previously acquired Walnut Creek CD-ROM, wh= ich > > > was heavily involved in the early history of both =46reeBSD and Sla= ckware > > > Linux. The remains of Walnut Creek CD-ROM and BSDI are now known as= > > > =46reeBSD Mall and iXsystems (of PC-BSD and =46reeNAS fame). > > =20 > =20 =22Troll=22 *is* right there in the name=21 =20 > > > =20 > > > DES > > > -- > > > Dag-Erling Sm=C3=B8rgrav - des=40des.no (mailto:des=40des.no) > > =20 > =20 From owner-freebsd-current@FreeBSD.ORG Fri May 18 08:16:09 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8DE9106564A for ; Fri, 18 May 2012 08:16:09 +0000 (UTC) (envelope-from mueller23@insightbb.com) Received: from mail.insightbb.com (smtp1.insight.synacor.com [208.47.185.23]) by mx1.freebsd.org (Postfix) with ESMTP id 9AB638FC0C for ; Fri, 18 May 2012 08:16:09 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=1.1 cv=W8bazBKbUPWRxPg5qvtqiKsGwQUK9pcsWEEZ0WuB1rk= c=1 sm=0 a=EOK2rGxD0pkA:10 a=DvSzqBOGy98A:10 a=6I5d2MoRAAAA:8 a=FtVFBvEzhNNAA0Smq28A:9 a=SV7veod9ZcQA:10 a=Q/oqmR4JO1zR3vNQamCQeQ==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp02.insight.synacor.com header.from=mueller6727@bellsouth.net; sender-id=neutral Authentication-Results: smtp02.insight.synacor.com smtp.mail=mueller23@insightbb.com; spf=softfail; sender-id=softfail Received-SPF: softfail (smtp02.insight.synacor.com: transitional domain insightbb.com does not designate 74.134.26.53 as permitted sender) Received: from [74.134.26.53] ([74.134.26.53:45794] helo=localhost) by mail.insightbb.com (envelope-from ) (ecelerity 2.2.2.40 r(29895/29896)) with ESMTP id 9C/6F-21342-34506BF4; Fri, 18 May 2012 04:16:03 -0400 Date: Fri, 18 May 2012 04:16:03 -0400 Message-ID: <9C.6F.21342.34506BF4@smtp02.insight.synacor.com> From: "Thomas Mueller" To: freebsd-current@freebsd.org References: <20111027102208.88BFB106564A@hub.freebsd.org> <4EAA85FD.1060805@infracaninophile.co.uk> <4EAB5823.5090804@FreeBSD.org> X-Mailman-Approved-At: Fri, 18 May 2012 11:27:29 +0000 Cc: Doug Barton , Matthew Seaman Subject: Re: Upgrade from source to RC1: problems with /etc : lost users and dbus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 08:16:10 -0000 > pwd_mkdb -p /etc/master.passwd Cheers, Matthew > Dr Matthew J Seaman MA, D.Phil. That did it! Now I can login as nonroot and startx. I found pwd_mkdb in my searching, but would not have known to use '-p'. I might have done pwd_mkdb /etc/master.passwd from Doug Barton : > Carefully? :) Seriously ... always use the -P option, and/or add > PRESERVE_FILES in your mergemaster rc file. Watch the changes carefully. > If you have to, do the updates in more than one pass using the -r option > for subsequent runs. Do the simple ones first, then go back and do the > ones that you have to think harder about. I recommend against using the > -U option. > It's not rocket science, it's just like any other system administration > task, it requires careful attention. > Doug That seems like a good idea, using -P option to be able to go back to something good if one screws up. >From 'man mergemaster': The mergemaster utility is a Bourne shell script which is designed to aid you in updating the various configuration and other files associated with FreeBSD. It is HIGHLY recommended that you back up your /etc directory before beginning this process. So I could make a second backup of /etc before the second mergemaster invocation, after installworld. There are lots of files to merge/edit, and one can easily become tired and make mistakes. We're only human and not infallible. Tom From owner-freebsd-current@FreeBSD.ORG Fri May 18 14:45:18 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12E9F1065674; Fri, 18 May 2012 14:45:18 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id D978A8FC14; Fri, 18 May 2012 14:45:17 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3ADF1B96C; Fri, 18 May 2012 10:45:17 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Fri, 18 May 2012 10:45:16 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <4FAF7343.8010808@cran.org.uk> <201205171005.19736.jhb@freebsd.org> <4FB51A64.6090906@FreeBSD.org> In-Reply-To: <4FB51A64.6090906@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201205181045.16675.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 18 May 2012 10:45:17 -0400 (EDT) Cc: Bruce Cran , freebsd-acpi@freebsd.org, freebsd-current , Jung-uk Kim Subject: Re: ACPI 'driver bug: Unable to set devclass' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 14:45:18 -0000 On Thursday, May 17, 2012 11:33:56 am Andriy Gapon wrote: > on 17/05/2012 17:05 John Baldwin said the following: > > On Wednesday, May 16, 2012 4:07:43 pm John Baldwin wrote: > >> Oh, whoops. Actually, the right way to do this I think is bus_hint_device_unit() > >> (and/or, not make the unit number in cpuX mean anything at all, but use a separate > >> ivar to track what PCPU_GET(cpuid) a given cpuX device corresponds to). I think > >> the last approach is really the right way to fix this. > > > > I haven't been able to try this yet, but I have a first cut at > > www.freebsd.org/~jhb/patches/acpi_cpu.patch > > > > The patch has not been compile-tested? :) I've updated it with a run-tested version. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri May 18 14:48:53 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B6AB71065672 for ; Fri, 18 May 2012 14:48:53 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8B3CF8FC0A for ; Fri, 18 May 2012 14:48:53 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0AD44B96C; Fri, 18 May 2012 10:48:53 -0400 (EDT) From: John Baldwin To: Anton Shterenlikht Date: Fri, 18 May 2012 10:48:52 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <20120426224215.GA79891@mech-cluster241.men.bris.ac.uk> <201205161108.05809.jhb@freebsd.org> <20120516153019.GB9070@mech-cluster241.men.bris.ac.uk> In-Reply-To: <20120516153019.GB9070@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201205181048.52391.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 18 May 2012 10:48:53 -0400 (EDT) Cc: freebsd-current@freebsd.org Subject: Re: updating from r231158 to 234465: mounting from ufs:/dev/ad4s1a failed with error 19 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 14:48:53 -0000 On Wednesday, May 16, 2012 11:30:19 am Anton Shterenlikht wrote: > er.. yes, of course it helped. > > My problem was that I couldn't boot. > So, I presumed the very existence of dmesg.boot > showed that your patches (both of them) work fine. > But, sorry, I could've been more explicit. > All seems to work, including sound and wireless. Hmm. Can you try one more thing. Can you boot an unmodified kernel (no patches) but set 'hw.pci.enable_io_modes=0' from the loader? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri May 18 15:58:41 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7BB0F1065782 for ; Fri, 18 May 2012 15:58:41 +0000 (UTC) (envelope-from pfg@freebsd.org) Received: from nm19-vm0.bullet.mail.sp2.yahoo.com (nm19-vm0.bullet.mail.sp2.yahoo.com [98.139.91.216]) by mx1.freebsd.org (Postfix) with SMTP id 55D038FC15 for ; Fri, 18 May 2012 15:58:41 +0000 (UTC) Received: from [98.139.91.63] by nm19.bullet.mail.sp2.yahoo.com with NNFMP; 18 May 2012 15:58:40 -0000 Received: from [208.71.42.201] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 18 May 2012 15:58:40 -0000 Received: from [127.0.0.1] by smtp212.mail.gq1.yahoo.com with NNFMP; 18 May 2012 15:58:40 -0000 X-Yahoo-Newman-Id: 859341.55624.bm@smtp212.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: MME.y.MVM1ktI5roD7EFMOMCrBusbz8xcpLbSRz66TOFGtd LpjAvUCc9lLC4DbZBYZhwexBi2O2dPUPSXt2.H4HseAqAOj6depN7NU8fWuC K8hoXVRDcGjq1JuRb2Klkh_Qs7aGTtZZ4y9EmknvInOCkTidwvdUpKHEM7Ny mL37ZVUKqmGgViE3pRUbj6A8dp.sQgqhBXrkCTK0L5riaalY6KGJXdVVvJUA Gmfdo50jbw3r3VhCRgg3wzjWrFJdS0Bm0f4C1GK8Ju_1a_rNgvuazyfwPzwT dLKBaLoC65hrNwVn5BxisthzinanST7zfVYaOVS4ZQ8bj0ZD98LXDRBFrKnB 2OWR5MB.imAQIbObXRb5tyB2B1_p3zwYzOtcbFjjF1Lnz8IhQsw_VdtRFG3a L.5rMlduBFpGqV6DlFoW9hjll3u3M.hQSuaOIqILJc0PJ6l1QotiNsh5CKuq GACkZvJnH_z6wr0EFk056.OjtDFT0bIeND2nmWr4HpWmUHZm_Xh8NlmvVVrc 9nj59y4Dp18fmjBxy5e.5OXKevqAfRQfgQsR4TqRVxss4BnCkzHx5g74lPmC e71gnTZBty2JN9Pb3D6t0qN_BoqQ6gbxmMPN2PgUESW9r2YjUlqj0EhM- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Received: from [192.168.10.103] (pfg@200.118.157.7 with plain) by smtp212.mail.gq1.yahoo.com with SMTP; 18 May 2012 08:58:40 -0700 PDT Message-ID: <4FB671AE.2080601@FreeBSD.org> Date: Fri, 18 May 2012 10:58:38 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120328 Thunderbird/10.0.3 MIME-Version: 1.0 To: Gleb Kurtsou References: <4FB51CDF.3040306@FreeBSD.org> <20120518070846.GB1071@reks> In-Reply-To: <20120518070846.GB1071@reks> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-toolchain@FreeBSD.org Subject: Re: GCC update for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 15:58:41 -0000 On 05/18/12 02:08, Gleb Kurtsou wrote: > On (17/05/2012 10:44), Pedro Giffuni wrote: >> Hi; >> >> I took a bunch of patches that were merged into the GCC 4.1 branch >> (under GPLv2) and prepared a patch for merging them into our base >> gcc. These are supposed to be bug fixes only. >> >> You can get the patch here: >> http://people.freebsd.org/~pfg/patches/patch-contrib-gcc >> And, for those really interested, the log is here: >> http://people.freebsd.org/~pfg/patches/gcc41-pr-log > Could you check if patch fixes this issue: > http://marc.info/?l=freebsd-hackers&m=132348021530691&w=2 > > I've disabled gcc from base locally since discovering it. > > Thanks, > Gleb. > No joy :(. Sorry: ./gcc-test1 src2.c:16:test_fail: Assertion failed: addr->sin_addr.s_addr == ntohl(INADDR_ANY) Abort From owner-freebsd-current@FreeBSD.ORG Fri May 18 17:01:48 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 255B3106566B; Fri, 18 May 2012 17:01:48 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by mx1.freebsd.org (Postfix) with ESMTP id 0BE2E8FC12; Fri, 18 May 2012 17:01:46 +0000 (UTC) Received: by wibhm6 with SMTP id hm6so1026216wib.1 for ; Fri, 18 May 2012 10:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=f0T6v1EFLfKO8drWizD12ckYt25lxlvUvjVN90Y9hhw=; b=wHRjaKTpw15rmjvYxuQ61uCfwzDcVzH0HjK9yY+YYWPw2C3sTCjj8OyPElPpKI99i5 Q1oO94pyEbrZ3/ZehAI6u9+mpo0/GIQXGdx8ia0U4wvWJsj0WFT33EJdrSnltTET/Z7/ WPg6c2w2q5vozbbTIWHNYL6UYD9WFk3qlFZRMothz70EtXCojTvMjTXZ56H6bPgrnTn5 KcEcE6dRPrz6JDW1/8dleRswP6toBx3DvKsxJgVIFvbrJgFVHS49EgFREUqy610q6s9q 3Vjp1pu2fa9JL1KY9JXfjcTURgdN/ooibzDZhPodMuMUZiRAK47sAGKE9qyJepycEvTc prFw== Received: by 10.180.24.193 with SMTP id w1mr3401373wif.5.1337360505769; Fri, 18 May 2012 10:01:45 -0700 (PDT) MIME-Version: 1.0 Sender: villa.alberto@gmail.com Received: by 10.227.112.132 with HTTP; Fri, 18 May 2012 10:01:25 -0700 (PDT) In-Reply-To: <4FA028D9.1010403@entel.upc.edu> References: <4F9E9E06.4070004@entel.upc.edu> <2D080258-652B-4EFA-8F6F-6ECA3CA4404B@freebsd.org> <4FA028D9.1010403@entel.upc.edu> From: Alberto Villa Date: Fri, 18 May 2012 19:01:25 +0200 X-Google-Sender-Auth: _t4w3vpq_zsPxJMG2p-Z-ROd0Es Message-ID: To: =?ISO-8859-1?Q?Gustau_P=E9rez_i_Querol?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Adrian Chadd , kan@freebsd.org, Jason Evans , Andriy Gapon , FreeBSD current , kib@freebsd.org Subject: Re: RFC: jemalloc: qdbus sigsegv in malloc_init X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 17:01:48 -0000 On Tue, May 1, 2012 at 8:18 PM, Gustau P=E9rez i Querol wrote: > =A0So the problem seems to be not related to jemalloc or malloc. As the > experimental 4.8.1 devel/dbus-qt4 port works fine in stable, the problem = has > do to with some differences between head and stable. When we get more hin= ts > where the problem is, I will post them in a new thread in freebsd-current= @. Gus has been away for a while, but before disappearing he found a workaround to be building devel/dbus-qt4 with -fno-use-cxa-atexit. So I had a look around, and found this NetBSD bug report: http://www.archivum.info/fa.netbsd.bugs/2007-12/00070/lib-37654-libc's-atex= it_mutex-should-be-fully-recursive.html Since qdbus crashes after exit(3) here too, that might be an explanation. Or, at least, something related. kib@ and kan@ are CCed as per avg@ suggestion. --=20 Alberto Villa, FreeBSD committer http://people.FreeBSD.org/~avilla From owner-freebsd-current@FreeBSD.ORG Fri May 18 18:08:43 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7F911065672 for ; Fri, 18 May 2012 18:08:43 +0000 (UTC) (envelope-from mueller23@insightbb.com) Received: from mail.insightbb.com (smtp3.insight.synacor.com [208.47.185.25]) by mx1.freebsd.org (Postfix) with ESMTP id 688748FC1F for ; Fri, 18 May 2012 18:08:43 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=1.1 cv=DeBjMhloPjCj2nBnrPIhcraNPq/+f8+IwpuGZ4QD/k4= c=1 sm=0 a=kauGeCijDccA:10 a=DvSzqBOGy98A:10 a=dRG0W-xSsrGNT0IvN0gA:9 a=Q/oqmR4JO1zR3vNQamCQeQ==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp01.insight.synacor.com header.from=mueller6727@bellsouth.net; sender-id=neutral Authentication-Results: smtp01.insight.synacor.com smtp.mail=mueller23@insightbb.com; spf=softfail; sender-id=softfail Received-SPF: softfail (smtp01.insight.synacor.com: transitional domain insightbb.com does not designate 74.134.26.53 as permitted sender) Received: from [74.134.26.53] ([74.134.26.53:48969] helo=localhost) by mail.insightbb.com (envelope-from ) (ecelerity 2.2.2.40 r(29895/29896)) with ESMTP id 7B/15-18646-A2096BF4; Fri, 18 May 2012 14:08:43 -0400 Date: Fri, 18 May 2012 14:08:42 -0400 Message-ID: <7B.15.18646.A2096BF4@smtp01.insight.synacor.com> From: "Thomas Mueller" To: freebsd-current@freebsd.org References: <20111027102208.88BFB106564A@hub.freebsd.org> <4EAA85FD.1060805@infracaninophile.co.uk> <4EAB5823.5090804@FreeBSD.org> X-Mailman-Approved-At: Fri, 18 May 2012 18:11:21 +0000 Cc: Doug Barton , Matthew Seaman Subject: Re: Upgrade from source to RC1: problems with /etc : lost users and dbus: resent by mistake X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 18:08:43 -0000 > > pwd_mkdb -p /etc/master.passwd > Cheers, > Matthew > > Dr Matthew J Seaman MA, D.Phil. > That did it! Now I can login as nonroot and startx. (snip) Sorry, I didn't mean to send this old message again! I changed this message to send to freebsd-stable list, saved under a different name, but accidentally sent the old message instead of the new one! Tom From owner-freebsd-current@FreeBSD.ORG Fri May 18 18:11:46 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA991106566C for ; Fri, 18 May 2012 18:11:46 +0000 (UTC) (envelope-from pfg@freebsd.org) Received: from nm10.bullet.mail.bf1.yahoo.com (nm10.bullet.mail.bf1.yahoo.com [98.139.212.169]) by mx1.freebsd.org (Postfix) with SMTP id 472D68FC08 for ; Fri, 18 May 2012 18:11:46 +0000 (UTC) Received: from [98.139.212.145] by nm10.bullet.mail.bf1.yahoo.com with NNFMP; 18 May 2012 18:11:40 -0000 Received: from [98.139.211.198] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 18 May 2012 18:11:40 -0000 Received: from [127.0.0.1] by smtp207.mail.bf1.yahoo.com with NNFMP; 18 May 2012 18:11:40 -0000 X-Yahoo-Newman-Id: 511778.84696.bm@smtp207.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 8R4xXCMVM1nII.uBiZw9JBuCAB20WzaEP7EPFmc4FhSHvuF Ps5yoU3bmDiMn4_Bs6JxJ96c1J.Qt6nHi1JzohryJCeJHrcYIAwboRMAf18J CtYQnk36reUek8Qh4rVopML.p_hywny4Ymv2wIGLwmTpYgdjQY8GISXr5wht EdtzuMYortuvIs.9HvGshOJtekqeDxR_K9Gu.2AiMvP4NZ9jA_dt1RaP0F6K 8OrSPx7qMwILmeAHzqti_LYJiOgssAtOJ3_Y.VMYmHoHJy4QrmwJJKNG0GQE b3VTXTXq8HrhxLXLEOFNGSkkePSJ3mdTtcw4OxkByxhGK7GTdvJh7kGrSef_ vVeVwYZc6ZbeT_akN9fL9smFN.8SDEvtsLyS4mHmks0Hgfpcdrfpp0xAfqUX N.J4fVu4AMibz3HB2rabaTUSJpvus4_Dyw3eoUti6CX7du3Vb8aTZP69XrN. T5LDWL3_IYsUEbzO7qTXfh6oGzkhKvfJnRjGjMMGuYWfiqAfRyPpMRR_GTZE 8g8cVoock5A0YZ1FZquAXdH_LNKgxp9i24w-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Received: from [192.168.10.103] (pfg@200.118.157.7 with plain) by smtp207.mail.bf1.yahoo.com with SMTP; 18 May 2012 11:11:40 -0700 PDT Message-ID: <4FB690DA.8060203@FreeBSD.org> Date: Fri, 18 May 2012 13:11:38 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120328 Thunderbird/10.0.3 MIME-Version: 1.0 To: Dimitry Andric References: <4FB51CDF.3040306@FreeBSD.org> <4FB52AF9.1010306@andric.com> In-Reply-To: <4FB52AF9.1010306@andric.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-toolchain@FreeBSD.org Subject: Re: GCC update for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 18:11:46 -0000 Hi again; On 05/17/12 11:44, Dimitry Andric wrote: > On 2012-05-17 17:44, Pedro Giffuni wrote:> Hi; >> I took a bunch of patches that were merged into the GCC 4.1 branch >> (under GPLv2) and prepared a patch for merging them into our base >> gcc. These are supposed to be bug fixes only. >> >> You can get the patch here: >> http://people.freebsd.org/~pfg/patches/patch-contrib-gcc >> And, for those really interested, the log is here: >> http://people.freebsd.org/~pfg/patches/gcc41-pr-log >> >> It may be my imagination but the patch seems to be causing more >> warnings than usual and it breaks the kernel here: > ... >> ../../../cam/scsi/scsi_sa.c: In function 'samount': >> ../../../cam/scsi/scsi_sa.c:1887: warning: 'comp_supported' may be used >> uninitialized in this function >> ../../../cam/scsi/scsi_sa.c:1888: warning: 'write_protect' may be used >> uninitialized in this function > These warnings seem wrong, upon casual inspection of the code. In any > case, if you compile the same file with gcc 4.7, they don't appear. :) > > Any idea which particular gcc fix is responsible for them? > > As a workaround, we could set all those variable to some reasonable > value, but that feels like a cheap trick to me... > > But I'd rather just not import the fix that causes those warnings. Ugh... It appears the patch was fine after all: the warnings were somehow triggered by optimizations in my /etc/make.conf file. I will test it further before committing. Pedro. From owner-freebsd-current@FreeBSD.ORG Fri May 18 20:21:02 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 352F9106564A; Fri, 18 May 2012 20:21:02 +0000 (UTC) (envelope-from oleg.moskalenko@citrix.com) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) by mx1.freebsd.org (Postfix) with ESMTP id 9D9088FC08; Fri, 18 May 2012 20:21:01 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.75,618,1330923600"; d="scan'208";a="195584275" Received: from sjcpmailmx01.citrite.net ([10.216.14.74]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 18 May 2012 16:19:52 -0400 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.73]) by SJCPMAILMX01.citrite.net ([10.216.14.74]) with mapi; Fri, 18 May 2012 13:19:50 -0700 From: Oleg Moskalenko To: "'Hamell, Rick (SPARQ)'" , Vance Siemens Date: Fri, 18 May 2012 13:19:50 -0700 Thread-Topic: FreeBSD 10 prognostication... Thread-Index: Ac00pZM+FRhi2pkcShSDUNgEg3F7mwAjbfrw Message-ID: <031222CBCF33214AB2EB4ABA279428A3011A2C2D1AE1@SJCPMAILBOX01.citrite.net> References: <4FA2434F.1020802@unsane.co.uk> <864nrxh5zf.fsf@ds4.des.no> <868vgsv0ga.fsf@ds4.des.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: =?utf-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= , "freebsd-current@freebsd.org" , "freebsd-chat@freebsd.org" , Vincent Hoffman Subject: RE: FreeBSD 10 prognostication... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 20:21:02 -0000 SXRzIG5vdCB0aGF0IGJhZC4gUENCU0QgKHdpdGggRnJlZUJTRCA5LjAgaW5zaWRlKSBoYXMgYSBy ZWxhdGl2ZWx5IGRlY2VudCBHVUkgc2V0dXAsIHdpdGggc2V2ZXJhbCB2aWFibGUgR1VJIGNob2lj ZXMuDQoNCk9sZWcNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG93bmVyLWZy ZWVic2QtY3VycmVudEBmcmVlYnNkLm9yZyBbbWFpbHRvOm93bmVyLWZyZWVic2QtY3VycmVudEBm cmVlYnNkLm9yZ10gT24gQmVoYWxmIE9mIEhhbWVsbCwgUmljayAoU1BBUlEpDQpTZW50OiBUaHVy c2RheSwgTWF5IDE3LCAyMDEyIDg6MjMgUE0NClRvOiBWYW5jZSBTaWVtZW5zDQpDYzogRGFnLUVy bGluZyBTbcO4cmdyYXY7IGZyZWVic2QtY3VycmVudEBmcmVlYnNkLm9yZzsgZnJlZWJzZC1jaGF0 QGZyZWVic2Qub3JnOyBWaW5jZW50IEhvZmZtYW4NClN1YmplY3Q6IFJlOiBGcmVlQlNEIDEwIHBy b2dub3N0aWNhdGlvbi4uLg0KDQpXaGF0LCA4Yml0IGNvbG9yIEFOU0kgaXNuJ3QgR1VJIGVub3Vn aD8NCg0KQnV0IHNlcmlvdXNseSwgaXQgZmVlbHMgbGlrZSBpdCB3b3JrcyBldmVuIHdvcnNlIHRo ZW4gaXQgZGlkIGEgZGVjYWRlIGFnby4gDQoNClJpY2sgSGFtZWxsDQpTZW50IGZyb20gbXkgaVBo b25lDQoNCk9uIE1heSAxNywgMjAxMiwgYXQgNDoyMCBQTSwgIlZhbmNlIFNpZW1lbnMiIDx2YW5j ZS5zaWVtZW5zQGdtYWlsLmNvbT4gd3JvdGU6DQoNCj4gRWgsIHNvcnJ5LiBJIGdvdCBleGNpdGVk IGF0IHRoZSBwcm9zcGVjdCBvZiBkb3dubG9hZGluZyBGcmVlQlNEIGZyb20gDQo+IHRoZSBBcHAg U3RvcmUgYW5kIGhhdmluZyB0aGUgaW5zdGFsbGVyICJqdXN0IHdvcmsiIGluIGEgbW9kZXJuIEdV SS4NCj4gWW91IGhhdmUgdG8gYWRtaXQsIEZyZWVCU0QgaXMgbGFja2luZyBpbiB0aGlzIGFyZWEu IEl0IHdvdWxkIGJlIGEgDQo+IGJvb24uDQo+IA0KPiBPbiBXZWQsIE1heSAxNiwgMjAxMiBhdCA3 OjE4IEFNLCBEYWctRXJsaW5nIFNtw7hyZ3JhdiA8ZGVzQGRlcy5ubz4gd3JvdGU6DQo+PiBWYW5j ZSBTaWVtZW5zIDx2YW5jZS5zaWVtZW5zQGdtYWlsLmNvbT4gd3JpdGVzOg0KPj4+IENhbiB5b3Ug c2hhcmUgYSBicmllZiBvdmVydmlldyBvZiB3aGF0J3Mgd3Jvbmcgd2l0aCBpdD8NCj4+IA0KPj4g VW1tLCBpdCdzIGFib3V0IGFzIGZhY3R1YWwgYXMgVGhlIE9uaW9uLCBleGNlcHQgbm90IGFzIGZ1 bm55LiAgDQo+PiBGcmVlQlNEIG5ldmVyIGhhZCB0byAiamV0dGlzb24gdHdvIHRoaXJkcyBvZiBp dHMgY29kZSBiYXNlIGFuZCBzdGFydCANCj4+IGZyb20gc2NyYXRjaCIuICBBcHBsZSBpcyBub3Qg aW52b2x2ZWQgaW4gRnJlZUJTRCBkZXZlbG9wbWVudC4gIE5vIE1hYyANCj4+IE9TIFggb3IgRGFy d2luIHZlcnNpb24gImluY2x1ZGVzIiBGcmVlQlNELiAgRnJlZUJTRCBhbmQgTWFjIE9TIFggd2ls bCANCj4+IG5ldmVyIG1lcmdlLiAgRnJlZUJTRCB3YXMgbmV2ZXIgYWNxdWlyZWQgYnkgV2luRHJp dmVyIFN5c3RlbXMgb3IgYnkgDQo+PiBhbnlvbmUgZWxzZSwgYWx0aG91Z2ggYSBjb21wYW55IG5h bWVkIFdpbmRSaXZlciBTeXN0ZW1zIChtYWtlcnMgb2YgDQo+PiB0aGUgZW1iZWRkZWQgb3BlcmF0 aW5nIHN5c3RlbSBWeFdvcmtzLCBub3Qgb2YgV2luZG93cyB2aWRlbyBkcml2ZXJzKSANCj4+IGRp ZCBhdCBvbmUgcG9pbnQgYWNxdWlyZSBCU0RJLCB3aGljaCBoYWQgcHJldmlvdXNseSBhY3F1aXJl ZCBXYWxudXQgDQo+PiBDcmVlayBDRC1ST00sIHdoaWNoIHdhcyBoZWF2aWx5IGludm9sdmVkIGlu IHRoZSBlYXJseSBoaXN0b3J5IG9mIGJvdGggDQo+PiBGcmVlQlNEIGFuZCBTbGFja3dhcmUgTGlu dXguICBUaGUgcmVtYWlucyBvZiBXYWxudXQgQ3JlZWsgQ0QtUk9NIGFuZCANCj4+IEJTREkgYXJl IG5vdyBrbm93biBhcyBGcmVlQlNEIE1hbGwgYW5kIGlYc3lzdGVtcyAob2YgUEMtQlNEIGFuZCBG cmVlTkFTIGZhbWUpLg0KPj4gDQo+PiBERVMNCj4+IC0tDQo+PiBEYWctRXJsaW5nIFNtw7hyZ3Jh diAtIGRlc0BkZXMubm8NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gZnJlZWJzZC1jaGF0QGZyZWVic2Qub3JnIG1haWxpbmcgbGlzdA0KPiBodHRw Oi8vbGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVlYnNkLWNoYXQNCj4gVG8g dW5zdWJzY3JpYmUsIHNlbmQgYW55IG1haWwgdG8gImZyZWVic2QtY2hhdC11bnN1YnNjcmliZUBm cmVlYnNkLm9yZyINCg== From owner-freebsd-current@FreeBSD.ORG Fri May 18 20:42:56 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DED00106566B; Fri, 18 May 2012 20:42:56 +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 ED75A8FC18; Fri, 18 May 2012 20:42:54 +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 q4IKggk7025378; Fri, 18 May 2012 23:42:42 +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 q4IKgfhZ081943; Fri, 18 May 2012 23:42:41 +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 q4IKgfga081942; Fri, 18 May 2012 23:42:41 +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, 18 May 2012 23:42:41 +0300 From: Konstantin Belousov To: Alberto Villa Message-ID: <20120518204241.GE2358@deviant.kiev.zoral.com.ua> References: <4F9E9E06.4070004@entel.upc.edu> <2D080258-652B-4EFA-8F6F-6ECA3CA4404B@freebsd.org> <4FA028D9.1010403@entel.upc.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8M+gQFKLhTGBxzRu" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-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: Adrian Chadd , Gustau P?rez i Querol , kan@freebsd.org, Jason Evans , Andriy Gapon , FreeBSD current , kib@freebsd.org Subject: Re: RFC: jemalloc: qdbus sigsegv in malloc_init X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 20:42:57 -0000 --8M+gQFKLhTGBxzRu Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 18, 2012 at 07:01:25PM +0200, Alberto Villa wrote: > On Tue, May 1, 2012 at 8:18 PM, Gustau P?rez i Querol > wrote: > > =9ASo the problem seems to be not related to jemalloc or malloc. As the > > experimental 4.8.1 devel/dbus-qt4 port works fine in stable, the proble= m has > > do to with some differences between head and stable. When we get more h= ints > > where the problem is, I will post them in a new thread in freebsd-curre= nt@. >=20 > Gus has been away for a while, but before disappearing he found a > workaround to be building devel/dbus-qt4 with -fno-use-cxa-atexit. So > I had a look around, and found this NetBSD bug report: > http://www.archivum.info/fa.netbsd.bugs/2007-12/00070/lib-37654-libc's-at= exit_mutex-should-be-fully-recursive.html >=20 > Since qdbus crashes after exit(3) here too, that might be an > explanation. Or, at least, something related. >=20 > kib@ and kan@ are CCed as per avg@ suggestion. You provided zero information. The reference to NetBSD is completely meaningless, we drop atexit_mutex when calling registered atexit handlers. At least bother to provide useful bug report if you suspect a bug in base system and want it fixed. --8M+gQFKLhTGBxzRu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+2tEEACgkQC3+MBN1Mb4ivrwCfUpUNFI6dgyf2fFQOVVb3vj6H 4nIAnR0ITFQNbi5fc/doDOTKfwa178uW =qz8A -----END PGP SIGNATURE----- --8M+gQFKLhTGBxzRu-- From owner-freebsd-current@FreeBSD.ORG Fri May 18 21:28:10 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 300CB106566B; Fri, 18 May 2012 21:28:10 +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 9DB6B8FC14; Fri, 18 May 2012 21:28:08 +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 AAA26262; Sat, 19 May 2012 00:28:06 +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 1SVUiU-00072v-I2; Sat, 19 May 2012 00:28:06 +0300 Message-ID: <4FB6BEE4.60307@FreeBSD.org> Date: Sat, 19 May 2012 00:28:04 +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: Alberto Villa References: <4F9E9E06.4070004@entel.upc.edu> <2D080258-652B-4EFA-8F6F-6ECA3CA4404B@freebsd.org> <4FA028D9.1010403@entel.upc.edu> In-Reply-To: X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Adrian Chadd , =?ISO-8859-1?Q?Gustau_P=E9rez_i_Querol?= , kan@FreeBSD.org, Jason Evans , FreeBSD current , kib@FreeBSD.org Subject: Re: RFC: jemalloc: qdbus sigsegv in malloc_init X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 21:28:10 -0000 on 18/05/2012 20:01 Alberto Villa said the following: > On Tue, May 1, 2012 at 8:18 PM, Gustau Pérez i Querol > wrote: >> So the problem seems to be not related to jemalloc or malloc. As the >> experimental 4.8.1 devel/dbus-qt4 port works fine in stable, the problem has >> do to with some differences between head and stable. When we get more hints >> where the problem is, I will post them in a new thread in freebsd-current@. > > Gus has been away for a while, but before disappearing he found a > workaround to be building devel/dbus-qt4 with -fno-use-cxa-atexit. So > I had a look around, and found this NetBSD bug report: > http://www.archivum.info/fa.netbsd.bugs/2007-12/00070/lib-37654-libc's-atexit_mutex-should-be-fully-recursive.html > > Since qdbus crashes after exit(3) here too, that might be an > explanation. Or, at least, something related. > > kib@ and kan@ are CCed as per avg@ suggestion. Alberto, you have add new people to the discussion, but unfortunately too little of the original context is present here... That is, this email doesn't even include a description of an actual problem. Could you please provide the useful context either as a link to a mailing list archive or in some other equally useful way? Thank you! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri May 18 22:17:33 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5BBB3106564A; Fri, 18 May 2012 22:17:33 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4286F8FC08; Fri, 18 May 2012 22:17:32 +0000 (UTC) Received: by werg1 with SMTP id g1so2753110wer.13 for ; Fri, 18 May 2012 15:17:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=ciFfVGxHDHX1zO+EQPesrAv/9M4XEZ4dr+wsNYW3+ds=; b=LafIelDHOWGcgq8rCGnGy3lq8V2vbPHpUIW/btuWYpz8R6CJ0b4WzAPYgXFUUicC6U RDj4G+7Grh6tesPrhqpMQWWgWmD4e7cIvJXIY1/kMwHLl+iLHrppW4anDg0RK4vYwBCH KYYlBLJp/BaoCAGgFoUntFD6giG8cTaK7og1w9PXvS9EHvTzxPuhMcdglCMvxze7gnmn v1XCCj4lbieLK6H5x5P6YvGrwPnaGH0M7GM6qzczmB9xvcG0wI9AsZAqY5o8vppmM1Ry 48VjI1ASrhBlYMZYCmaBIhoL1GjfvMx06la8LXbkqmD4KUJnlqGRu5XAR4Ws1GOJXHX+ K9fw== Received: by 10.180.78.233 with SMTP id e9mr5432348wix.5.1337379451221; Fri, 18 May 2012 15:17:31 -0700 (PDT) MIME-Version: 1.0 Sender: villa.alberto@gmail.com Received: by 10.227.112.132 with HTTP; Fri, 18 May 2012 15:16:59 -0700 (PDT) In-Reply-To: <4FB6BEE4.60307@FreeBSD.org> References: <4F9E9E06.4070004@entel.upc.edu> <2D080258-652B-4EFA-8F6F-6ECA3CA4404B@freebsd.org> <4FA028D9.1010403@entel.upc.edu> <4FB6BEE4.60307@FreeBSD.org> From: Alberto Villa Date: Sat, 19 May 2012 00:16:59 +0200 X-Google-Sender-Auth: L9YX96I2HOj_ht5S0_n3MLsclqA Message-ID: To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Adrian Chadd , =?ISO-8859-1?Q?Gustau_P=E9rez_i_Querol?= , kan@freebsd.org, Jason Evans , FreeBSD current , kib@freebsd.org Subject: Re: RFC: jemalloc: qdbus sigsegv in malloc_init X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 22:17:33 -0000 On Fri, May 18, 2012 at 11:28 PM, Andriy Gapon wrote: > you have add new people to the discussion, but unfortunately too little o= f the > original context is present here... =A0That is, this email doesn't even i= nclude a > description of an actual problem. > Could you please provide the useful context either as a link to a mailing= list > archive or in some other equally useful way? Sorry, Gmail showed the thread with all the history, but I see that in the archives it's considered as two different conversations. Here's the original thread: http://lists.freebsd.org/pipermail/freebsd-current/2012-April/033547.html I think I understand that the NetBSD problem is not related to our case, Also, Gustau told me that he narrowed the problem down to __pthread_cxa_finalize. He will add new information very soon, anyway. --=20 Alberto Villa, FreeBSD committer http://people.FreeBSD.org/~avilla From owner-freebsd-current@FreeBSD.ORG Fri May 18 22:37:30 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 458EE106566C; Fri, 18 May 2012 22:37:30 +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 AFF828FC08; Fri, 18 May 2012 22:37:29 +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 q4IMbHKR053559; Sat, 19 May 2012 01:37:17 +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 q4IMbHG9082529; Sat, 19 May 2012 01:37:17 +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 q4IMbHdn082528; Sat, 19 May 2012 01:37:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 19 May 2012 01:37:17 +0300 From: Konstantin Belousov To: Alberto Villa Message-ID: <20120518223717.GG2358@deviant.kiev.zoral.com.ua> References: <4F9E9E06.4070004@entel.upc.edu> <2D080258-652B-4EFA-8F6F-6ECA3CA4404B@freebsd.org> <4FA028D9.1010403@entel.upc.edu> <4FB6BEE4.60307@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vj77qGokqwYdeLil" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-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: Adrian Chadd , Gustau P?rez i Querol , kan@freebsd.org, Jason Evans , Andriy Gapon , FreeBSD current Subject: Re: RFC: jemalloc: qdbus sigsegv in malloc_init X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 22:37:30 -0000 --vj77qGokqwYdeLil Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 19, 2012 at 12:16:59AM +0200, Alberto Villa wrote: > On Fri, May 18, 2012 at 11:28 PM, Andriy Gapon wrote: > > you have add new people to the discussion, but unfortunately too little= of the > > original context is present here... =9AThat is, this email doesn't even= include a > > description of an actual problem. > > Could you please provide the useful context either as a link to a maili= ng list > > archive or in some other equally useful way? >=20 > Sorry, Gmail showed the thread with all the history, but I see that in > the archives it's considered as two different conversations. >=20 > Here's the original thread: > http://lists.freebsd.org/pipermail/freebsd-current/2012-April/033547.html >=20 > I think I understand that the NetBSD problem is not related to our > case, Also, Gustau told me that he narrowed the problem down to > __pthread_cxa_finalize. He will add new information very soon, anyway. Well, there is still not much to read. And, http://pastebin.com/ryBXtqGF. shows 'Unknown Paste ID!'. That said, why do you think that the problem is in system and not in the application ? The fact that the issue does not manifests itself under stable/9 is not enough to arrive at this conclusion. --vj77qGokqwYdeLil Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+2zxwACgkQC3+MBN1Mb4hlDgCbBYjG9IZQq9/3BYFs3yhfvShn +GsAn0boGDswr2sarmZgl2ysRftcckvL =zaIo -----END PGP SIGNATURE----- --vj77qGokqwYdeLil-- From owner-freebsd-current@FreeBSD.ORG Fri May 18 22:49:24 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD2BA1065672; Fri, 18 May 2012 22:49:24 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id A45328FC0A; Fri, 18 May 2012 22:49:23 +0000 (UTC) Received: by werg1 with SMTP id g1so2765198wer.13 for ; Fri, 18 May 2012 15:49:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=dOsnzevzJUCsLOjeAOkOTBPrb+CkseoyKVhqyGl15Ic=; b=Ph0QHgr2IfOL1bCA0zhZb+M1JKEUmIouOWPzLbKXU78pGc9ee9lfSbnhtlFO+fWhrK HP1hWjBDbha/jFU0kVBswdl82McNxr/FEibKH5dUIKVXTCsd9TD66xoNB7OfFyCq374o b3of3vND3iv4G+X/qFaBXRNAMsxjZnEqDF77AJCS1kiiGHkBxKu04Ce8gqgWXM8df0nC lWIfQgor8QGXPg8/s1FrauH3djhRJFAdlrBYOsLigiAfkwDrYALi8AJ+torwck54HZG0 ZsH43B5c4VEu/B+8/CUUb1tdiP9tREAf/VREtYWpxauUBPu8eau9sVnxiV6n/ReaUnXR B2Tg== Received: by 10.180.80.97 with SMTP id q1mr5540791wix.13.1337381362495; Fri, 18 May 2012 15:49:22 -0700 (PDT) MIME-Version: 1.0 Sender: villa.alberto@gmail.com Received: by 10.227.112.132 with HTTP; Fri, 18 May 2012 15:49:02 -0700 (PDT) In-Reply-To: <20120518223717.GG2358@deviant.kiev.zoral.com.ua> References: <4F9E9E06.4070004@entel.upc.edu> <2D080258-652B-4EFA-8F6F-6ECA3CA4404B@freebsd.org> <4FA028D9.1010403@entel.upc.edu> <4FB6BEE4.60307@FreeBSD.org> <20120518223717.GG2358@deviant.kiev.zoral.com.ua> From: Alberto Villa Date: Sat, 19 May 2012 00:49:02 +0200 X-Google-Sender-Auth: otKl96cwEWFocC1q4166YZvCJoM Message-ID: To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: Adrian Chadd , Gustau P?rez i Querol , kan@freebsd.org, Jason Evans , Andriy Gapon , FreeBSD current Subject: Re: RFC: jemalloc: qdbus sigsegv in malloc_init X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 22:49:24 -0000 On Sat, May 19, 2012 at 12:37 AM, Konstantin Belousov wrote: > Well, there is still not much to read. And, http://pastebin.com/ryBXtqGF. > shows 'Unknown Paste ID!'. Eh, sorry, Gus will provide updated data. > That said, why do you think that the problem is in system and not in the > application ? The fact that the issue does not manifests itself under > stable/9 is not enough to arrive at this conclusion. We thought it because it suddenly appeared, but neither me nor Gus are sure of this. We asked for help because this is affecting the whole Qt update, and as a kde@ member this is a major concern for me (and many others, I guess). Whether the issue will be found in the system or in the application is mostly of no interest. That said, if there is no information to examine at the moment, let's just wait for Gus mail. Sorry for the noise, then. -- Alberto Villa, FreeBSD committer http://people.FreeBSD.org/~avilla From owner-freebsd-current@FreeBSD.ORG Fri May 18 22:53:05 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62A7F1065670; Fri, 18 May 2012 22:53:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id AF0D48FC12; Fri, 18 May 2012 22:53:04 +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 q4IMqsVg057464; Sat, 19 May 2012 01:52:54 +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 q4IMqrRj082615; Sat, 19 May 2012 01:52:53 +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 q4IMqr1g082614; Sat, 19 May 2012 01:52:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 19 May 2012 01:52:53 +0300 From: Konstantin Belousov To: Alberto Villa Message-ID: <20120518225253.GH2358@deviant.kiev.zoral.com.ua> References: <4F9E9E06.4070004@entel.upc.edu> <2D080258-652B-4EFA-8F6F-6ECA3CA4404B@freebsd.org> <4FA028D9.1010403@entel.upc.edu> <4FB6BEE4.60307@FreeBSD.org> <20120518223717.GG2358@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W8NyRpvKkamwD9y8" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-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: Adrian Chadd , Gustau P?rez i Querol , kan@FreeBSD.org, Jason Evans , Andriy Gapon , FreeBSD current Subject: Re: RFC: jemalloc: qdbus sigsegv in malloc_init X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 22:53:05 -0000 --W8NyRpvKkamwD9y8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 19, 2012 at 12:49:02AM +0200, Alberto Villa wrote: > On Sat, May 19, 2012 at 12:37 AM, Konstantin Belousov > wrote: > > Well, there is still not much to read. And, http://pastebin.com/ryBXtqG= F. > > shows 'Unknown Paste ID!'. >=20 > Eh, sorry, Gus will provide updated data. >=20 > > That said, why do you think that the problem is in system and not in the > > application ? The fact that the issue does not manifests itself under > > stable/9 is not enough to arrive at this conclusion. >=20 > We thought it because it suddenly appeared, but neither me nor Gus are > sure of this. We asked for help because this is affecting the whole Qt > update, and as a kde@ member this is a major concern for me (and many > others, I guess). Whether the issue will be found in the system or in > the application is mostly of no interest. >=20 > That said, if there is no information to examine at the moment, let's > just wait for Gus mail. Sorry for the noise, then. How to reproduce the issue locally ? (I do not want to install all KDE to my test box). --W8NyRpvKkamwD9y8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+20sUACgkQC3+MBN1Mb4j2XQCgiu54g6Fzu+JDFVDDAhjTvOjZ gYgAn3TRbnEXMDDlWTO3OChwIu6hEbGj =Co0y -----END PGP SIGNATURE----- --W8NyRpvKkamwD9y8-- From owner-freebsd-current@FreeBSD.ORG Fri May 18 23:15:08 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1B55F106566B; Fri, 18 May 2012 23:15:08 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0D7D38FC16; Fri, 18 May 2012 23:15:06 +0000 (UTC) Received: by werg1 with SMTP id g1so2774323wer.13 for ; Fri, 18 May 2012 16:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=mCDb7lVZpwKpSAyDy1SJWYCJgzQiVijFxYSbw8Wrg5g=; b=Z5TjiUb20glObFRUomwrzF84HQhfeiJSzK+c4FZqG8L76k2tErXkT3fzHQlmQo08um x/P+6ACmfpO0DlXY+AZX43JjetcerY+WrJyR4t7wIibkNSCC3YBJru2qm4rIKEKQu0yD 6p1/fEg0wOFrfhx3BCmUE9Gqm1WNleSRIyqTm/cV9SkzUrB3UDVCw3Zo/Z7dXQ6pkgDO 67isCs+kHZoOymLd46PFofy2rt6lbwbfmiKkADvLZYiVUtEHTpcXD4X1F3axgwASS+RB CcIfb6g3oga8loKBSa9mWy2AbCKFAU4YmcNbDhT46tDEKPMEIl4TZF3lcDQg14cqecvQ 1AFA== Received: by 10.180.78.233 with SMTP id e9mr5757714wix.5.1337382905715; Fri, 18 May 2012 16:15:05 -0700 (PDT) MIME-Version: 1.0 Sender: villa.alberto@gmail.com Received: by 10.227.112.132 with HTTP; Fri, 18 May 2012 16:14:45 -0700 (PDT) In-Reply-To: <20120518225253.GH2358@deviant.kiev.zoral.com.ua> References: <4F9E9E06.4070004@entel.upc.edu> <2D080258-652B-4EFA-8F6F-6ECA3CA4404B@freebsd.org> <4FA028D9.1010403@entel.upc.edu> <4FB6BEE4.60307@FreeBSD.org> <20120518223717.GG2358@deviant.kiev.zoral.com.ua> <20120518225253.GH2358@deviant.kiev.zoral.com.ua> From: Alberto Villa Date: Sat, 19 May 2012 01:14:45 +0200 X-Google-Sender-Auth: CFiHf5l0li_pX5icgBdj3Ld-bMo Message-ID: To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: Adrian Chadd , Gustau P?rez i Querol , kan@freebsd.org, Jason Evans , Andriy Gapon , FreeBSD current Subject: Re: RFC: jemalloc: qdbus sigsegv in malloc_init X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 23:15:08 -0000 On Sat, May 19, 2012 at 12:52 AM, Konstantin Belousov wrote: > How to reproduce the issue locally ? (I do not want to install all KDE > to my test box). Just build devel/dbus-qt4 on 10-CURRENT and run qdbus. It should crash (should you have D-Bus running, which you probably don't have, it would first print all D-Bus connections and then crash on exit). -- Alberto Villa, FreeBSD committer http://people.FreeBSD.org/~avilla From owner-freebsd-current@FreeBSD.ORG Sat May 19 02:07:24 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A60A9106566C; Sat, 19 May 2012 02:07:24 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 6C1068FC08; Sat, 19 May 2012 02:07:24 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q4J27IjO056255; Fri, 18 May 2012 22:07:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q4J27IcC056234; Sat, 19 May 2012 02:07:18 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 19 May 2012 02:07:18 GMT Message-Id: <201205190207.q4J27IcC056234@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 02:07:24 -0000 TB --- 2012-05-18 20:30:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-05-18 20:30:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-05-18 20:30:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-05-18 20:30:00 - cleaning the object tree TB --- 2012-05-18 20:30:00 - cvsupping the source tree TB --- 2012-05-18 20:30:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-05-18 20:38:35 - building world TB --- 2012-05-18 20:38:35 - CROSS_BUILD_TESTING=YES TB --- 2012-05-18 20:38:35 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-18 20:38:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-18 20:38:35 - SRCCONF=/dev/null TB --- 2012-05-18 20:38:35 - TARGET=i386 TB --- 2012-05-18 20:38:35 - TARGET_ARCH=i386 TB --- 2012-05-18 20:38:35 - TZ=UTC TB --- 2012-05-18 20:38:35 - __MAKE_CONF=/dev/null TB --- 2012-05-18 20:38:35 - cd /src TB --- 2012-05-18 20:38:35 - /usr/bin/make -B buildworld >>> World build started on Fri May 18 20:38:36 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 Fri May 18 22:57:37 UTC 2012 TB --- 2012-05-18 22:57:37 - generating LINT kernel config TB --- 2012-05-18 22:57:37 - cd /src/sys/i386/conf TB --- 2012-05-18 22:57:37 - /usr/bin/make -B LINT TB --- 2012-05-18 22:57:37 - cd /src/sys/i386/conf TB --- 2012-05-18 22:57:37 - /usr/sbin/config -m LINT TB --- 2012-05-18 22:57:37 - building LINT kernel TB --- 2012-05-18 22:57:37 - CROSS_BUILD_TESTING=YES TB --- 2012-05-18 22:57:37 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-18 22:57:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-18 22:57:37 - SRCCONF=/dev/null TB --- 2012-05-18 22:57:37 - TARGET=i386 TB --- 2012-05-18 22:57:37 - TARGET_ARCH=i386 TB --- 2012-05-18 22:57:37 - TZ=UTC TB --- 2012-05-18 22:57:37 - __MAKE_CONF=/dev/null TB --- 2012-05-18 22:57:37 - cd /src TB --- 2012-05-18 22:57:37 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri May 18 22:57: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 >>> Kernel build for LINT completed on Fri May 18 23:30:51 UTC 2012 TB --- 2012-05-18 23:30:51 - cd /src/sys/i386/conf TB --- 2012-05-18 23:30:51 - /usr/sbin/config -m LINT-NOINET TB --- 2012-05-18 23:30:51 - building LINT-NOINET kernel TB --- 2012-05-18 23:30:51 - CROSS_BUILD_TESTING=YES TB --- 2012-05-18 23:30:51 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-18 23:30:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-18 23:30:51 - SRCCONF=/dev/null TB --- 2012-05-18 23:30:51 - TARGET=i386 TB --- 2012-05-18 23:30:51 - TARGET_ARCH=i386 TB --- 2012-05-18 23:30:51 - TZ=UTC TB --- 2012-05-18 23:30:51 - __MAKE_CONF=/dev/null TB --- 2012-05-18 23:30:51 - cd /src TB --- 2012-05-18 23:30:51 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Fri May 18 23:30:51 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 >>> Kernel build for LINT-NOINET completed on Sat May 19 00:01:38 UTC 2012 TB --- 2012-05-19 00:01:38 - cd /src/sys/i386/conf TB --- 2012-05-19 00:01:38 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-05-19 00:01:38 - building LINT-NOINET6 kernel TB --- 2012-05-19 00:01:38 - CROSS_BUILD_TESTING=YES TB --- 2012-05-19 00:01:38 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-19 00:01:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-19 00:01:38 - SRCCONF=/dev/null TB --- 2012-05-19 00:01:38 - TARGET=i386 TB --- 2012-05-19 00:01:38 - TARGET_ARCH=i386 TB --- 2012-05-19 00:01:38 - TZ=UTC TB --- 2012-05-19 00:01:38 - __MAKE_CONF=/dev/null TB --- 2012-05-19 00:01:38 - cd /src TB --- 2012-05-19 00:01:38 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Sat May 19 00:01: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 >>> Kernel build for LINT-NOINET6 completed on Sat May 19 00:33:12 UTC 2012 TB --- 2012-05-19 00:33:12 - cd /src/sys/i386/conf TB --- 2012-05-19 00:33:12 - /usr/sbin/config -m LINT-NOIP TB --- 2012-05-19 00:33:12 - building LINT-NOIP kernel TB --- 2012-05-19 00:33:12 - CROSS_BUILD_TESTING=YES TB --- 2012-05-19 00:33:12 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-19 00:33:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-19 00:33:12 - SRCCONF=/dev/null TB --- 2012-05-19 00:33:12 - TARGET=i386 TB --- 2012-05-19 00:33:12 - TARGET_ARCH=i386 TB --- 2012-05-19 00:33:12 - TZ=UTC TB --- 2012-05-19 00:33:12 - __MAKE_CONF=/dev/null TB --- 2012-05-19 00:33:12 - cd /src TB --- 2012-05-19 00:33:12 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Sat May 19 00:33:12 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 >>> Kernel build for LINT-NOIP completed on Sat May 19 01:01:27 UTC 2012 TB --- 2012-05-19 01:01:27 - cd /src/sys/i386/conf TB --- 2012-05-19 01:01:27 - /usr/sbin/config -m LINT-VIMAGE TB --- 2012-05-19 01:01:27 - building LINT-VIMAGE kernel TB --- 2012-05-19 01:01:27 - CROSS_BUILD_TESTING=YES TB --- 2012-05-19 01:01:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-19 01:01:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-19 01:01:27 - SRCCONF=/dev/null TB --- 2012-05-19 01:01:27 - TARGET=i386 TB --- 2012-05-19 01:01:27 - TARGET_ARCH=i386 TB --- 2012-05-19 01:01:27 - TZ=UTC TB --- 2012-05-19 01:01:27 - __MAKE_CONF=/dev/null TB --- 2012-05-19 01:01:27 - cd /src TB --- 2012-05-19 01:01:27 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Sat May 19 01:01: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 >>> Kernel build for LINT-VIMAGE completed on Sat May 19 01:33:38 UTC 2012 TB --- 2012-05-19 01:33:38 - cd /src/sys/i386/conf TB --- 2012-05-19 01:33:38 - /usr/sbin/config -m GENERIC TB --- 2012-05-19 01:33:38 - building GENERIC kernel TB --- 2012-05-19 01:33:38 - CROSS_BUILD_TESTING=YES TB --- 2012-05-19 01:33:38 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-19 01:33:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-19 01:33:38 - SRCCONF=/dev/null TB --- 2012-05-19 01:33:38 - TARGET=i386 TB --- 2012-05-19 01:33:38 - TARGET_ARCH=i386 TB --- 2012-05-19 01:33:38 - TZ=UTC TB --- 2012-05-19 01:33:38 - __MAKE_CONF=/dev/null TB --- 2012-05-19 01:33:38 - cd /src TB --- 2012-05-19 01:33:38 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat May 19 01:33: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 >>> Kernel build for GENERIC completed on Sat May 19 02:00:37 UTC 2012 TB --- 2012-05-19 02:00:37 - cd /src/sys/i386/conf TB --- 2012-05-19 02:00:37 - /usr/sbin/config -m PAE TB --- 2012-05-19 02:00:37 - building PAE kernel TB --- 2012-05-19 02:00:37 - CROSS_BUILD_TESTING=YES TB --- 2012-05-19 02:00:37 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-19 02:00:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-19 02:00:37 - SRCCONF=/dev/null TB --- 2012-05-19 02:00:37 - TARGET=i386 TB --- 2012-05-19 02:00:37 - TARGET_ARCH=i386 TB --- 2012-05-19 02:00:37 - TZ=UTC TB --- 2012-05-19 02:00:37 - __MAKE_CONF=/dev/null TB --- 2012-05-19 02:00:37 - cd /src TB --- 2012-05-19 02:00:37 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Sat May 19 02:00: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 -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/isci/scil/scif_sas_timer.c ctfconvert -L VERSION -g scif_sas_timer.o cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/acpica/acpi_machdep.c ctfconvert -L VERSION -g acpi_machdep.o cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/acpica/acpi_wakeup.c cc1: warnings being treated as errors /src/sys/i386/acpica/acpi_wakeup.c: In function 'acpi_install_wakeup_handler': /src/sys/i386/acpica/acpi_wakeup.c:379: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] *** Error code 1 Stop in /obj/i386.i386/src/sys/PAE. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-05-19 02:07:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-05-19 02:07:18 - ERROR: failed to build PAE kernel TB --- 2012-05-19 02:07:18 - 15553.79 user 2137.84 system 20237.59 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat May 19 03:50:16 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D3A1106564A for ; Sat, 19 May 2012 03:50:16 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 666528FC12 for ; Sat, 19 May 2012 03:50:16 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q4J3o8Lc015517; Sat, 19 May 2012 03:50:08 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id quncu9j2swmz5rh5a2ue36m5d2; Sat, 19 May 2012 03:50:08 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <20769DCB-D3EF-49C6-A791-E190A5CCECAE@lists.zabbadoz.net> Date: Fri, 18 May 2012 20:50:07 -0700 Content-Transfer-Encoding: 7bit Message-Id: <8E6581F5-1AFE-4C3F-95E6-2323DA583E42@kientzle.com> References: <2103A722-43BF-4BCF-AEDE-2E0CB13DF620@kientzle.com> <20769DCB-D3EF-49C6-A791-E190A5CCECAE@lists.zabbadoz.net> To: "Bjoern A. Zeeb" X-Mailer: Apple Mail (2.1257) Cc: freebsd-current FreeBSD Subject: Re: SUJ file system corruption. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 03:50:16 -0000 On May 18, 2012, at 3:18 AM, Bjoern A. Zeeb wrote: > > On 13. May 2012, at 22:35 , Tim Kientzle wrote: > >> FYI: Saw a crash due to filesystem corruption when running SUJ. >> >> This is on a ARM AM335x system (BeagleBone) that is >> still pretty experimental, so I certainly cannot rule out other >> problems, but in case it means something to >> someone, here's the scenario: >> >> Reset the board to reboot (which is routine for these >> small embedded boards) and when it came back up >> it went through SUJ recovery, and then a little later >> the kernel panicked with this stack trace: >> >> rm: /var/run/dmesg.boot: Bad file descriptor >> panic: ffs_write: type 0xc1e86660 0 (0,1024) > > > Can you tell us if this was HEAD, stable/9 or 9.0-RELEASE? Apologies: This was with the armv6 projects tree, which is not quite CURRENT. Tim From owner-freebsd-current@FreeBSD.ORG Sat May 19 11:20:44 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D7571065672; Sat, 19 May 2012 11:20:44 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 32CEA8FC14; Sat, 19 May 2012 11:20:44 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q4JBKhLC058199; Sat, 19 May 2012 07:20:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q4JBKhTN058195; Sat, 19 May 2012 11:20:43 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 19 May 2012 11:20:43 GMT Message-Id: <201205191120.q4JBKhTN058195@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 11:20:44 -0000 TB --- 2012-05-19 05:10:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-05-19 05:10:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-05-19 05:10:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-05-19 05:10:00 - cleaning the object tree TB --- 2012-05-19 05:14:39 - cvsupping the source tree TB --- 2012-05-19 05:14:39 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-05-19 05:15:28 - building world TB --- 2012-05-19 05:15:28 - CROSS_BUILD_TESTING=YES TB --- 2012-05-19 05:15:28 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-19 05:15:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-19 05:15:28 - SRCCONF=/dev/null TB --- 2012-05-19 05:15:28 - TARGET=i386 TB --- 2012-05-19 05:15:28 - TARGET_ARCH=i386 TB --- 2012-05-19 05:15:28 - TZ=UTC TB --- 2012-05-19 05:15:28 - __MAKE_CONF=/dev/null TB --- 2012-05-19 05:15:28 - cd /src TB --- 2012-05-19 05:15:28 - /usr/bin/make -B buildworld >>> World build started on Sat May 19 05:15:29 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 Sat May 19 07:45:25 UTC 2012 TB --- 2012-05-19 07:45:25 - generating LINT kernel config TB --- 2012-05-19 07:45:25 - cd /src/sys/i386/conf TB --- 2012-05-19 07:45:25 - /usr/bin/make -B LINT TB --- 2012-05-19 07:45:25 - cd /src/sys/i386/conf TB --- 2012-05-19 07:45:25 - /usr/sbin/config -m LINT TB --- 2012-05-19 07:45:26 - building LINT kernel TB --- 2012-05-19 07:45:26 - CROSS_BUILD_TESTING=YES TB --- 2012-05-19 07:45:26 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-19 07:45:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-19 07:45:26 - SRCCONF=/dev/null TB --- 2012-05-19 07:45:26 - TARGET=i386 TB --- 2012-05-19 07:45:26 - TARGET_ARCH=i386 TB --- 2012-05-19 07:45:26 - TZ=UTC TB --- 2012-05-19 07:45:26 - __MAKE_CONF=/dev/null TB --- 2012-05-19 07:45:26 - cd /src TB --- 2012-05-19 07:45:26 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat May 19 07:45:26 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 >>> Kernel build for LINT completed on Sat May 19 08:19:24 UTC 2012 TB --- 2012-05-19 08:19:24 - cd /src/sys/i386/conf TB --- 2012-05-19 08:19:24 - /usr/sbin/config -m LINT-NOINET TB --- 2012-05-19 08:19:25 - building LINT-NOINET kernel TB --- 2012-05-19 08:19:25 - CROSS_BUILD_TESTING=YES TB --- 2012-05-19 08:19:25 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-19 08:19:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-19 08:19:25 - SRCCONF=/dev/null TB --- 2012-05-19 08:19:25 - TARGET=i386 TB --- 2012-05-19 08:19:25 - TARGET_ARCH=i386 TB --- 2012-05-19 08:19:25 - TZ=UTC TB --- 2012-05-19 08:19:25 - __MAKE_CONF=/dev/null TB --- 2012-05-19 08:19:25 - cd /src TB --- 2012-05-19 08:19:25 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Sat May 19 08:19:25 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 >>> Kernel build for LINT-NOINET completed on Sat May 19 09:04:55 UTC 2012 TB --- 2012-05-19 09:04:55 - cd /src/sys/i386/conf TB --- 2012-05-19 09:04:55 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-05-19 09:04:55 - building LINT-NOINET6 kernel TB --- 2012-05-19 09:04:55 - CROSS_BUILD_TESTING=YES TB --- 2012-05-19 09:04:55 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-19 09:04:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-19 09:04:55 - SRCCONF=/dev/null TB --- 2012-05-19 09:04:55 - TARGET=i386 TB --- 2012-05-19 09:04:55 - TARGET_ARCH=i386 TB --- 2012-05-19 09:04:55 - TZ=UTC TB --- 2012-05-19 09:04:55 - __MAKE_CONF=/dev/null TB --- 2012-05-19 09:04:55 - cd /src TB --- 2012-05-19 09:04:55 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Sat May 19 09:04:56 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 >>> Kernel build for LINT-NOINET6 completed on Sat May 19 09:36:23 UTC 2012 TB --- 2012-05-19 09:36:23 - cd /src/sys/i386/conf TB --- 2012-05-19 09:36:23 - /usr/sbin/config -m LINT-NOIP TB --- 2012-05-19 09:36:23 - building LINT-NOIP kernel TB --- 2012-05-19 09:36:23 - CROSS_BUILD_TESTING=YES TB --- 2012-05-19 09:36:23 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-19 09:36:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-19 09:36:23 - SRCCONF=/dev/null TB --- 2012-05-19 09:36:23 - TARGET=i386 TB --- 2012-05-19 09:36:23 - TARGET_ARCH=i386 TB --- 2012-05-19 09:36:23 - TZ=UTC TB --- 2012-05-19 09:36:23 - __MAKE_CONF=/dev/null TB --- 2012-05-19 09:36:23 - cd /src TB --- 2012-05-19 09:36:23 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Sat May 19 09:36:23 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 >>> Kernel build for LINT-NOIP completed on Sat May 19 10:05:16 UTC 2012 TB --- 2012-05-19 10:05:16 - cd /src/sys/i386/conf TB --- 2012-05-19 10:05:16 - /usr/sbin/config -m LINT-VIMAGE TB --- 2012-05-19 10:05:16 - building LINT-VIMAGE kernel TB --- 2012-05-19 10:05:16 - CROSS_BUILD_TESTING=YES TB --- 2012-05-19 10:05:16 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-19 10:05:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-19 10:05:16 - SRCCONF=/dev/null TB --- 2012-05-19 10:05:16 - TARGET=i386 TB --- 2012-05-19 10:05:16 - TARGET_ARCH=i386 TB --- 2012-05-19 10:05:16 - TZ=UTC TB --- 2012-05-19 10:05:16 - __MAKE_CONF=/dev/null TB --- 2012-05-19 10:05:16 - cd /src TB --- 2012-05-19 10:05:16 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Sat May 19 10:05:16 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 >>> Kernel build for LINT-VIMAGE completed on Sat May 19 10:36:47 UTC 2012 TB --- 2012-05-19 10:36:47 - cd /src/sys/i386/conf TB --- 2012-05-19 10:36:47 - /usr/sbin/config -m GENERIC TB --- 2012-05-19 10:36:47 - building GENERIC kernel TB --- 2012-05-19 10:36:47 - CROSS_BUILD_TESTING=YES TB --- 2012-05-19 10:36:47 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-19 10:36:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-19 10:36:47 - SRCCONF=/dev/null TB --- 2012-05-19 10:36:47 - TARGET=i386 TB --- 2012-05-19 10:36:47 - TARGET_ARCH=i386 TB --- 2012-05-19 10:36:47 - TZ=UTC TB --- 2012-05-19 10:36:47 - __MAKE_CONF=/dev/null TB --- 2012-05-19 10:36:47 - cd /src TB --- 2012-05-19 10:36:47 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat May 19 10:36: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 >>> Kernel build for GENERIC completed on Sat May 19 11:03:59 UTC 2012 TB --- 2012-05-19 11:03:59 - cd /src/sys/i386/conf TB --- 2012-05-19 11:03:59 - /usr/sbin/config -m PAE TB --- 2012-05-19 11:03:59 - building PAE kernel TB --- 2012-05-19 11:03:59 - CROSS_BUILD_TESTING=YES TB --- 2012-05-19 11:03:59 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-19 11:03:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-19 11:03:59 - SRCCONF=/dev/null TB --- 2012-05-19 11:03:59 - TARGET=i386 TB --- 2012-05-19 11:03:59 - TARGET_ARCH=i386 TB --- 2012-05-19 11:03:59 - TZ=UTC TB --- 2012-05-19 11:03:59 - __MAKE_CONF=/dev/null TB --- 2012-05-19 11:03:59 - cd /src TB --- 2012-05-19 11:03:59 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Sat May 19 11:03: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 >>> Kernel build for PAE completed on Sat May 19 11:11:35 UTC 2012 TB --- 2012-05-19 11:11:35 - cd /src/sys/i386/conf TB --- 2012-05-19 11:11:35 - /usr/sbin/config -m XBOX TB --- 2012-05-19 11:11:35 - building XBOX kernel TB --- 2012-05-19 11:11:35 - CROSS_BUILD_TESTING=YES TB --- 2012-05-19 11:11:35 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-19 11:11:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-19 11:11:35 - SRCCONF=/dev/null TB --- 2012-05-19 11:11:35 - TARGET=i386 TB --- 2012-05-19 11:11:35 - TARGET_ARCH=i386 TB --- 2012-05-19 11:11:35 - TZ=UTC TB --- 2012-05-19 11:11:35 - __MAKE_CONF=/dev/null TB --- 2012-05-19 11:11:35 - cd /src TB --- 2012-05-19 11:11:35 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Sat May 19 11:11:35 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 >>> Kernel build for XBOX completed on Sat May 19 11:14:59 UTC 2012 TB --- 2012-05-19 11:14:59 - cd /src/sys/i386/conf TB --- 2012-05-19 11:14:59 - /usr/sbin/config -m XEN TB --- 2012-05-19 11:14:59 - building XEN kernel TB --- 2012-05-19 11:14:59 - CROSS_BUILD_TESTING=YES TB --- 2012-05-19 11:14:59 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-19 11:14:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-19 11:14:59 - SRCCONF=/dev/null TB --- 2012-05-19 11:14:59 - TARGET=i386 TB --- 2012-05-19 11:14:59 - TARGET_ARCH=i386 TB --- 2012-05-19 11:14:59 - TZ=UTC TB --- 2012-05-19 11:14:59 - __MAKE_CONF=/dev/null TB --- 2012-05-19 11:14:59 - cd /src TB --- 2012-05-19 11:14:59 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Sat May 19 11:14: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 [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh XEN cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror vers.c linking kernel.debug exception.o: In function `Xcpususpend': /src/sys/i386/i386/apic_vector.s:349: undefined reference to `cpususpend_handler' *** Error code 1 Stop in /obj/i386.i386/src/sys/XEN. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-05-19 11:20:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-05-19 11:20:43 - ERROR: failed to build XEN kernel TB --- 2012-05-19 11:20:43 - 15996.28 user 2218.82 system 22242.46 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat May 19 13:55:21 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6216106566C; Sat, 19 May 2012 13:55:21 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 887BC8FC0A; Sat, 19 May 2012 13:55:21 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1SVk7m-0005Vf-TI>; Sat, 19 May 2012 15:55:15 +0200 Received: from e178020111.adsl.alicedsl.de ([85.178.20.111] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1SVk7m-00067T-Kt>; Sat, 19 May 2012 15:55:14 +0200 Message-ID: <4FB7A63C.70509@zedat.fu-berlin.de> Date: Sat, 19 May 2012 15:55:08 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120502 Thunderbird/12.0.1 MIME-Version: 1.0 To: Current FreeBSD , freebsd-questions@freebsd.org X-Enigmail-Version: 1.5pre Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3FE2B60471D4EF092A7F9CC9" X-Originating-IP: 85.178.20.111 Cc: Subject: CURRENT: buildworld fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 13:55:22 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3FE2B60471D4EF092A7F9CC9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Since approx. a week for now, I can not build FreeBSD 10.0-CURRENT/amd64 anymore! This happens to be on ALL(!) FreeBSD 10 boxes around here I maintain. Build is usually performed with CLANG, but also legacy gcc 4.2.1 build do fail. The error is always the same, as documented below. I allow to build with "WITH_BSD_SORT" in /etc/src.conf. CFLAGS and COPTFLAGS are set to -pipe -O3 -fno-strict-aliasing -march=3Dnative when compiling with CLANG, otherwise the standard is used= as introduced by the vanilla sources. What I tried so far: a) build and install kernel -> works b) build and install /usr/src/lib via "make clean cleandepend depend obj all install" doesn't work anymore, it fails with =2E"/usr/src/lib/Makefile", line 179: Malformed conditional (${MK_NAND} != =3D "no") "/usr/src/lib/Makefile", line 181: if-less endif c) make installincludes from /usr/src works. But it doesn't relief as I hoped. As the error below may suggest, there seems to be an issue with the libstc++ lib. Building ports also fails due to errors refering to libstdc++.so. I feel helpless at the moment since the problem seems only to be sticky with me around here. Do others around here also allow the build of new C++ stuff with WITH_LIBCPLUSPLUS=3D YES in /etc/src.conf? Regards, Oliver [...] clang++ -O2 -fno-strict-aliasing -pipe -pipe -O3 -fno-strict-aliasing -march=3Dnative -Qunused-arguments -fstack-protector -Wsystem-headers -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-parentheses -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -o gperf bool-array.o hash-table.o input.o keyword-list.o keyword.o main.o options.o output.o positions.o search.o version.o getline.o hash.o /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_ifstream >::is_open() const' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_string, std::allocator >::_Rep::_M_set_length_and_sharable(unsigned long= )' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_string, std::allocator >::_M_check_length(unsigned long, unsigned long, char const*) const' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_fstream >::is_open() const' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_istream >::ignore()' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_string, std::allocator >::_M_copy(wchar_t*, wchar_t const*, unsigned lon= g)' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::string::_M_assign(char*, unsigned long, char)' /usr/obj/usr/src/tmp/usr/bin/ld: Warning: size of symbol `_ZNSt13basic_istreamIwSt11char_traitsIwEE6ignoreEv@GLIBCXX_3.4' changed from 243 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so to 211 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_fstream >::is_open() const' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_string, std::allocator >::_M_move(wchar_t*, wchar_t const*, unsigned lon= g)' /usr/obj/usr/src/tmp/usr/bin/ld: Warning: size of symbol `_ZNSbIwSt11char_traitsIwESaIwEE4_Rep26_M_set_length_and_sharableEm@GLIBC= XX_3.4' changed from 19 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so to 24 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::string::_M_move(char*, char const*, unsigned long)' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::istream::ignore()' /usr/obj/usr/src/tmp/usr/bin/ld: Warning: size of symbol `_ZNKSs15_M_check_lengthEmmPKc@GLIBCXX_3.4' changed from 39 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so to 36 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_ofstream >::is_open() const' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_string, std::allocator >::_M_assign(wchar_t*, unsigned long, wchar_t)' /usr/obj/usr/src/tmp/usr/bin/ld: Warning: size of symbol `_ZNKSbIwSt11char_traitsIwESaIwEE15_M_check_lengthEmmPKc@GLIBCXX_3.4' changed from 39 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so to 36 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so /usr/obj/usr/src/tmp/usr/bin/ld: Warning: size of symbol `_ZNSi6ignoreEv@GLIBCXX_3.4' changed from 243 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so to 211 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_ifstream >::is_open() const' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::string::_M_copy(char*, char const*, unsigned long)' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_ofstream >::is_open() const' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::string::_M_check_length(unsigned long, unsigned long, char const*) const' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::string::_Rep::_M_set_length_and_sharable(unsigned lon= g)' clang++: error: linker command failed with exit code 1 (use -v to see invocation) *** [gperf] Error code 1 Stop in /usr/src/gnu/usr.bin/gperf. *** [all] Error code 1 Stop in /usr/src/gnu/usr.bin. *** [all] Error code 1 Stop in /usr/src/gnu. *** [gnu.all__D] Error code 1 Stop in /usr/src. *** [everything] Error code 1 Stop in /usr/src. *** [buildworld] Error code 1 Stop in /usr/src. --------------enig3FE2B60471D4EF092A7F9CC9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJPt6ZCAAoJEOgBcD7A/5N8YSMIALl1kI1bcHLZjXYtCNgI6ecY RpRhREoxTpD5fnJGjvBn0TJ6NoMClYB3x8NF3y1dx7OX789XRHpu8RWmpYe5MrWk pIaQTyRSfUYi2CcdR5fb9wfu0V8FhXrXiaPalT9PNoQkFmBrPC7q/TZEUD6gSJTA yaOoVK65YPzsa2WFrJWSxvWlVkCTbKJet2deWTIyrWTVsf4rPkpwe6Jf5/uZ1EY+ 1VbUb81wl2fEcl3D8TqeFgqBAZhoKVQzd+NtaYNZP01nFs7j0evR3tHXbZMBXpXw kzC7GPTsXfWMRn0IVUcyDSk6gh6lIyckB2CcZRVM6DUDyAe75Prl2qJrjHG6omg= =3FaR -----END PGP SIGNATURE----- --------------enig3FE2B60471D4EF092A7F9CC9-- From owner-freebsd-current@FreeBSD.ORG Sat May 19 14:40:16 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B84F7106566B; Sat, 19 May 2012 14:40:16 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 1F22D8FC0C; Sat, 19 May 2012 14:40:14 +0000 (UTC) Received: by wibhj8 with SMTP id hj8so836609wib.13 for ; Sat, 19 May 2012 07:40:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; bh=W1qP9qSPPajf1uVPxkUbcZPnFCn0n61vxscc0k3UOvE=; b=kwHVObVcPnILADaYteCDT/Nc6b6W7Cg3xSD+LpPxoM7mm8det5By9O/4bE2QpgaTWJ IvYWJNntGYgm/11PD/TVALH/oEAF6DAY23yeGVpMNmi7+Vs292Mb9E1aoH4XBExnNgx+ PYCljguvI3QdcCVN6SX1MCddUzY3dAFBaIHuEYdFfSanQk75F61JLp4GtSvAMRuW8z5B xd58wPgQlRNxIgM1EO9OGDOkdn8cNAKr10V2cSkPqkN9r/4ewvz/7ndxzEGQgelUS3Z/ 5h0NhkVfCpQa1PBLh0RFyrt4rwcOiDZln6fFw8o46qGpZoMgFFn0hAEbCDeWndWOlxYc uNHw== Received: by 10.216.200.22 with SMTP id y22mr5423146wen.118.1337438414239; Sat, 19 May 2012 07:40:14 -0700 (PDT) Received: from ernst.jennejohn.org (p578E0D2F.dip.t-dialin.net. [87.142.13.47]) by mx.google.com with ESMTPS id o9sm15314014wia.3.2012.05.19.07.40.12 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 19 May 2012 07:40:13 -0700 (PDT) Date: Sat, 19 May 2012 16:40:11 +0200 From: Gary Jennejohn To: "O. Hartmann" Message-ID: <20120519164011.3afd508d@ernst.jennejohn.org> In-Reply-To: <4FB7A63C.70509@zedat.fu-berlin.de> References: <4FB7A63C.70509@zedat.fu-berlin.de> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Current FreeBSD , freebsd-questions@freebsd.org Subject: Re: CURRENT: buildworld fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 14:40:16 -0000 On Sat, 19 May 2012 15:55:08 +0200 "O. Hartmann" wrote: > Since approx. a week for now, I can not build FreeBSD 10.0-CURRENT/amd64 > anymore! This happens to be on ALL(!) FreeBSD 10 boxes around here I > maintain. > Build is usually performed with CLANG, but also legacy gcc 4.2.1 build > do fail. > > The error is always the same, as documented below. > > I allow to build with "WITH_BSD_SORT" in /etc/src.conf. > > CFLAGS and COPTFLAGS are set to -pipe -O3 -fno-strict-aliasing > -march=native when compiling with CLANG, otherwise the standard is used > as introduced by the vanilla sources. > > What I tried so far: > > a) build and install kernel -> works > b) build and install /usr/src/lib via "make clean cleandepend depend obj > all install" doesn't work anymore, it fails with > ."/usr/src/lib/Makefile", line 179: Malformed conditional (${MK_NAND} != > "no") > "/usr/src/lib/Makefile", line 181: if-less endif > > c) make installincludes from /usr/src works. But it doesn't relief as I > hoped. > > As the error below may suggest, there seems to be an issue with the > libstc++ lib. > Building ports also fails due to errors refering to libstdc++.so. > > I feel helpless at the moment since the problem seems only to be sticky > with me around here. Do others around here also allow the build of new > C++ stuff with > WITH_LIBCPLUSPLUS= YES > in /etc/src.conf? > [snip error output] I just successfully did ``make buildworld'' and ``make buildkernel'' on HEAD updated about 4 hours ago. This is a 6-core AMD64 system. I have WITH_BSD_SORT defined but I DO NOT have WITH_LIBCPLUSPLUS defined in /etc/src.conf. I'm also using the stock gcc in base and not clang. HTH. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Sat May 19 17:02:24 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5F191065680 for ; Sat, 19 May 2012 17:02:24 +0000 (UTC) (envelope-from deeptech71@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 2A8908FC1C for ; Sat, 19 May 2012 17:02:22 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so3832583wgb.31 for ; Sat, 19 May 2012 10:02:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=blbcpCxSa+UWbqewBhA7N5WF1QqrH484t1gyYDF5dqM=; b=uRZgaKXgQB7zzNWLc8WMGy08b9qbEv8D/zdzHioN9gHRJ8k5MP9HpSe2mqo3t/Ebl1 GCmZIaMcxB8g4D4un64hus9xMKHNntqo1Rx4360pvA7X79ivyfC/if7vmtojWQzhOreV F59yc6LLam4r8uDshnUIOSD9xbbtq4jx6pqCk/xn7eakR3j/VfBZesz5GPlFG+it6NC7 ZYnA+IHAM9laRAIDdTOdk8SpTQr5CwfNG2Qb/dmLY7CqDqtqSH3BxbG7XPetpe0zbRY0 2f6J9Yhp+F27My73EiSy5rfYsAo8GaXvSniYKXFCMoM7gGKgsBgynFMRB+BNUmHEKy0G tDIA== Received: by 10.216.225.166 with SMTP id z38mr9398572wep.3.1337446942284; Sat, 19 May 2012 10:02:22 -0700 (PDT) Received: from [192.168.1.80] (BC069DC5.dsl.pool.telekom.hu. [188.6.157.197]) by mx.google.com with ESMTPS id j4sm10883476wiz.1.2012.05.19.10.02.20 (version=SSLv3 cipher=OTHER); Sat, 19 May 2012 10:02:21 -0700 (PDT) Message-ID: <4FB7D2B5.6030609@gmail.com> Date: Sat, 19 May 2012 19:04:53 +0200 From: deeptech71@gmail.com User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:12.0) Gecko/20120518 Firefox/12.0 SeaMonkey/2.9.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="------------060203080300070104010907" Subject: video drivers are locked up; panic during shutdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 17:02:24 -0000 This is a multi-part message in MIME format. --------------060203080300070104010907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit So while the unstable, reverse-engineered ATI drivers were locked up (which is usual, it happens ~5 times a day on average), I pressed the ATX power button to initiate a clean shutdown (statistically, this usually succeeds). During the shutdown procedure, a panic occurred. (As a result, the filesystem wasn't cleanly unmounted.) I was doing a ``git pull --rebase'' (which turned out to have succeeded) when the driver lockup occurred. The crashinfo output is attached. Note: the kernel used during the panic has no debugging symbols; a version compiled with debugging symbols was used for crashinfo. --------------060203080300070104010907 Content-Type: text/plain; charset=UTF-8; name="core.txt.0" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="core.txt.0" dumped core - see /var/crash/vmcore.0 Sat May 19 18:36:13 CEST 2012 FreeBSD 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r235500M: Sat May 19 17:53:32 CEST 2012 root@:/usr/obj/usr/src/sys/HQ i386 panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Cannot access memory at address 0x0 (kgdb) #0 0x00000000 in ?? () (kgdb) ------------------------------------------------------------------------ ps -axl UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND ------------------------------------------------------------------------ vmstat -s 0 cpu context switches 3230491304 device interrupts 0 software interrupts 3230491296 traps 0 system calls 3230491472 kernel threads created 0 fork() calls 3230491464 vfork() calls 0 rfork() calls 0 swap pager pageins 0 swap pager pages paged in 3230491336 swap pager pageouts 3230491344 swap pager pages paged out 0 vnode pager pageins 0 vnode pager pages paged in 3230491352 vnode pager pageouts 3230491360 vnode pager pages paged out 0 page daemon wakeups 3230491376 pages examined by the page daemon 3230491368 pages reactivated 0 copy-on-write faults 3230491320 copy-on-write optimized faults 0 zero fill pages zeroed 3230491328 zero fill pages prezeroed 0 intransit blocking page faults 3230491312 total VM faults taken 3230491488 pages affected by kernel thread creation 0 pages affected by fork() 3230491480 pages affected by vfork() 0 pages affected by rfork() 0 pages cached 3230491392 pages freed 3230491384 pages freed by daemon 0 pages freed by exiting processes 3230491424 pages active 3230491432 pages inactive 0 pages in VM cache 0 pages wired down 3230491416 pages free 0 bytes per page -2108415131 total name lookups cache hits (0% pos + 0% neg) system 0% per-directory deletions 0%, falsehits 50%, toolong -1% ------------------------------------------------------------------------ vmstat -m vmstat: memstat_kvm_malloc: invalid address (0x7cd6d6c6) Type InUse MemUse HighUse Requests Size(s) ------------------------------------------------------------------------ vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP ------------------------------------------------------------------------ vmstat -i vmstat: malloc(): Cannot allocate memory ------------------------------------------------------------------------ pstat -T 19/ 0 files 0M/0M swap space ------------------------------------------------------------------------ pstat -s Device 1K-blocks Used Avail Capacity ------------------------------------------------------------------------ iostat iostat: devstat_checkversion: userland devstat version 6 is not the same as the kernel devstat_checkversion: devstat version -1065155924 devstat_checkversion: libdevstat newer than kernel ------------------------------------------------------------------------ ipcs -a ipcs: shmsegs: invalid address (0x0) Message Queues: T ID KEY MODE OWNER GROUP CREATOR CGROUP CBYTES QNUM QBYTES LSPID LRPID STIME RTIME CTIME ------------------------------------------------------------------------ ipcs -T msginfo: msgmax: 0 (max characters in a message) msgmni: 0 (# of message queues) msgmnb: 1312130 (max characters in a message queue) msgtql: -65536 (max # of messages in system) msgssz: 60 (size of a message segment) msgseg: 0 (# of message segments in system) shminfo: shmmax: 25165824 (max shared memory segment size) shmmin: 268435455 (min shared memory segment size) shmmni: 3227543568 (max number of shared memory identifiers) shmseg: 3230161136 (max shared memory segments per process) shmall: 1 (max amount of shared memory in pages) seminfo: semmni: 0 (# of semaphore identifiers) semmns: 0 (# of semaphores in system) semmnu: 0 (# of undo structures in system) semmsl: 0 (max # of semaphores per id) semopm: 0 (max # of operations per semop call) semume: 0 (max # of undo entries per process) semusz: 0 (size in bytes of undo structure) semvmx: 0 (semaphore maximum value) semaem: 0 (adjust on exit max value) ------------------------------------------------------------------------ nfsstat nfsstat: new client/server not loaded ------------------------------------------------------------------------ netstat -s netstat: igmp_stats: version mismatch (0 != 3) netstat: igmp_stats: size mismatch (-1067316968 != 168) tcp: 4 packets sent 0 data packets (0 bytes) 0 data packets (0 bytes) retransmitted 0 data packets unnecessarily retransmitted 21168128 resends initiated by MTU discovery 0 ack-only packets (0 delayed) 3229870621 URG only packets 3230488056 window probe packets 21168128 window update packets 0 control packets 0 packets received 0 acks (for 3230488152 bytes) 0 duplicate acks 0 acks for unsent data 4 packets (0 bytes) received in-sequence 0 completely duplicate packets (3230488104 bytes) 21168128 old duplicate packets 3229870621 packets with some dup. data (21168128 bytes duped) 0 out-of-order packets (0 bytes) 4 packets (0 bytes) of data after window 0 window probes 3229870621 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 3229870621 connection requests 21168128 connection accepts 3229870621 bad connection attempts 0 listen queue overflows 0 ignored RSTs in the windows 0 connections established (including accepts) 0 connections closed (including 0 drops) 0 connections updated cached RTT on close 0 connections updated cached RTT variance on close 0 connections updated cached ssthresh on close 4 embryonic connections dropped 0 segments updated rtt (of 0 attempts) 3230488008 retransmit timeouts 0 connections dropped by rexmit timeout 3229870621 persist timeouts 3230488200 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 21168128 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 0 correct ACK header predictions 0 correct data packet header predictions 4 syncache entries added 0 retransmitted 0 dupsyn 0 dropped 0 completed 0 bucket overflow 0 cache overflow 3230488248 reset 3229870621 stale 21168128 aborted 0 badack 0 unreach 4 zone failures 0 cookies sent 0 cookies received 0 hostcache entries added 0 bucket overflow 0 SACK recovery episodes 3230488296 segment rexmits in SACK recovery episodes 3229870621 byte rexmits in SACK recovery episodes 21168128 SACK options (SACK blocks) received 0 SACK options (SACK blocks) sent 0 SACK scoreboard overflow 4 packets with ECN CE bit set 0 packets with ECN ECT(0) bit set 0 packets with ECN ECT(1) bit set 0 successful ECN handshakes 0 times ECN reduced the congestion window udp: 4 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 0 with no checksum 0 dropped due to no socket 0 broadcast/multicast datagrams undelivered 3230488920 dropped due to full socket buffers 3229870628 not for hashed pcb 1064478380 delivered 196608 datagrams output 4 times multicast source filter matched ip: 4 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 21168128 with bad options 0 with incorrect version number 0 fragments received 3230486328 fragments dropped (dup or out of space) 3229870621 fragments dropped after timeout 0 packets reassembled ok 0 packets for this host 0 packets for unknown/unsupported protocol 21168128 packets forwarded (0 packets fast forwarded) 0 packets not forwardable 0 packets received for unknown multicast group 4 redirects sent 0 packets sent from this host 4 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 3230486376 fragments created 3229870621 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header icmp: 4 calls to icmp_error 0 errors not generated in response to an icmp message Output histogram: source quench: 3230485848 routing redirect: 3229870621 #6: 21168128 router advertisement: 4 information request reply: 3230485896 address mask request: 3229870621 address mask reply: 21168128 #21: 4 #28: 3230485944 #29: 3229870621 icmp traceroute: 21168128 IPv6 where-are-you: 4 icmp photuris: 3230485992 3229870621 messages with bad code fields 21168128 messages less than the minimum length 0 messages with bad checksum 0 messages with bad length 0 multicast echo requests ignored 3230486184 multicast timestamp requests ignored Input histogram: #6: 3230486040 #7: 3229870621 echo: 21168128 time exceeded: 4 address mask reply: 3230486088 #19: 3229870621 #20: 21168128 #23: 4 icmp traceroute: 3230486136 datagram conversion error: 3229870621 mobile host redirect: 21168128 mobile registration req: 4 4 message responses generated 3229870621 invalid return addresses 21168128 no return routes igmp: 0 messages received 0 messages received with too few bytes 4294967297 messages received with wrong TTL 13862652601683673088 messages received with bad checksum 43021 V1/V2 membership queries received 0 V3 membership queries received 4294967297 membership queries received with invalid field(s) 13862652601683673088 general queries received 43021 group queries received 0 group-source queries received 4294967296 group-source queries dropped 13862652601683673088 membership reports received 0 membership reports received with invalid field(s) 0 membership reports received for groups to which we belong 4294967297 V3 reports received without Router Alert 13862652601683673088 membership reports sent arp: 0 ARP requests sent 0 ARP replies sent 0 ARP requests received 3230485320 ARP replies received 3229870621 ARP packets received 0 total packets dropped due to no ARP entry 0 ARP entrys timed out 0 Duplicate IPs seen ------------------------------------------------------------------------ netstat -m netstat: memstat_kvm_all: invalid address (0x7cd6d6c6) ------------------------------------------------------------------------ netstat -id netstat: invalid address (0x0) ------------------------------------------------------------------------ netstat -anr netstat: invalid address (0x0) netstat: invalid address (0x4) netstat: invalid address (0x8) netstat: invalid address (0xc) netstat: invalid address (0x10) netstat: invalid address (0x14) netstat: invalid address (0x18) netstat: invalid address (0x1c) netstat: invalid address (0x20) netstat: invalid address (0x24) netstat: invalid address (0x28) netstat: invalid address (0x2c) netstat: invalid address (0x30) netstat: invalid address (0x34) netstat: invalid address (0x38) netstat: invalid address (0x3c) netstat: invalid address (0x40) netstat: invalid address (0x44) netstat: invalid address (0x48) netstat: invalid address (0x4c) netstat: invalid address (0x50) netstat: invalid address (0x54) netstat: invalid address (0x58) netstat: invalid address (0x5c) netstat: invalid address (0x60) netstat: invalid address (0x64) netstat: invalid address (0x68) netstat: invalid address (0x6c) netstat: invalid address (0x70) netstat: invalid address (0x74) netstat: invalid address (0x78) netstat: invalid address (0x7c) netstat: invalid address (0x80) netstat: invalid address (0x84) netstat: invalid address (0x88) netstat: invalid address (0x8c) netstat: invalid address (0x90) netstat: invalid address (0x94) netstat: invalid address (0x98) Routing tables ------------------------------------------------------------------------ netstat -anA netstat: invalid address (0x0) netstat: invalid address (0x1430000) netstat: invalid address (0x1430000) netstat: invalid address (0x1430000) netstat: invalid address (0x1430000) netstat: invalid address (0x1430000) netstat: invalid address (0x1430000) netstat: invalid address (0x1430000) netstat: invalid address (0x78746d75) netstat: invalid address (0x1430000) ------------------------------------------------------------------------ netstat -aL netstat: invalid address (0x0) netstat: invalid address (0x1430000) netstat: invalid address (0x1430000) netstat: invalid address (0x1430000) netstat: invalid address (0x1430000) netstat: invalid address (0x1430000) netstat: invalid address (0x1430000) netstat: invalid address (0x1430000) netstat: invalid address (0x78746d75) netstat: invalid address (0x1430000) ------------------------------------------------------------------------ fstat fstat: procstat_getprocs() ------------------------------------------------------------------------ dmesg dmesg: _kvm_vatop: virtual address 0x0 not minidumped dmesg: kvm_read: invalid address (0x0) ------------------------------------------------------------------------ kernel config options CONFIG_AUTOGENERATED ident HQ machine i386 cpu I686_CPU makeoptions DEBUG=-g options ATA_STATIC_ID options ATA_CAM options SMP options INCLUDE_CONFIG_FILE options KBD_INSTALL_CDEV options PRINTF_BUFR_SIZE=128 options _KPOSIX_PRIORITY_SCHEDULING options SYSVSEM options SYSVMSG options SYSVSHM options SCSI_DELAY=1000 options COMPAT_FREEBSD7 options COMPAT_FREEBSD6 options COMPAT_FREEBSD5 options COMPAT_FREEBSD4 options GEOM_LABEL options GEOM_PART_GPT options CD9660 options MSDOSFS options MD_ROOT options UFS_DIRHASH options SOFTUPDATES options FFS options INET options PREEMPTION options SCHED_ULE options NEW_PCIB options NATIVE options GEOM_PART_MBR options GEOM_PART_EBR_COMPAT options GEOM_PART_EBR options GEOM_PART_BSD options ISAPNP device isa device npx device mem device io device uart_ns8250 device atpic device apic device acpi device pci device ahci device ata device scbus device ch device da device cd device pass device ses device atkbdc device atkbd device psm device vga device sc device agp device pmtimer device miibus device sk device loop device random device ether device md device firmware device uhci device ohci device ehci device usb device uhid device ukbd device umass device ums device sound device snd_es137x device drm device radeondrm ------------------------------------------------------------------------ ddb capture buffer ddb: ddb_capture: kvm_nlist --------------060203080300070104010907-- From owner-freebsd-current@FreeBSD.ORG Sat May 19 19:56:28 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D7FE106566C; Sat, 19 May 2012 19:56:28 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id EE34C8FC14; Sat, 19 May 2012 19:56:27 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q4JJuQip012499; Sat, 19 May 2012 15:56:26 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q4JJuQbP012482; Sat, 19 May 2012 19:56:26 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 19 May 2012 19:56:26 GMT Message-Id: <201205191956.q4JJuQbP012482@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 19:56:28 -0000 TB --- 2012-05-19 14:10:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-05-19 14:10:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-05-19 14:10:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-05-19 14:10:00 - cleaning the object tree TB --- 2012-05-19 14:15:31 - cvsupping the source tree TB --- 2012-05-19 14:15:31 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-05-19 14:17:13 - building world TB --- 2012-05-19 14:17:13 - CROSS_BUILD_TESTING=YES TB --- 2012-05-19 14:17:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-19 14:17:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-19 14:17:13 - SRCCONF=/dev/null TB --- 2012-05-19 14:17:13 - TARGET=i386 TB --- 2012-05-19 14:17:13 - TARGET_ARCH=i386 TB --- 2012-05-19 14:17:13 - TZ=UTC TB --- 2012-05-19 14:17:13 - __MAKE_CONF=/dev/null TB --- 2012-05-19 14:17:13 - cd /src TB --- 2012-05-19 14:17:13 - /usr/bin/make -B buildworld >>> World build started on Sat May 19 14:17:15 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 Sat May 19 16:38:13 UTC 2012 TB --- 2012-05-19 16:38:13 - generating LINT kernel config TB --- 2012-05-19 16:38:13 - cd /src/sys/i386/conf TB --- 2012-05-19 16:38:13 - /usr/bin/make -B LINT TB --- 2012-05-19 16:38:13 - cd /src/sys/i386/conf TB --- 2012-05-19 16:38:13 - /usr/sbin/config -m LINT TB --- 2012-05-19 16:38:14 - building LINT kernel TB --- 2012-05-19 16:38:14 - CROSS_BUILD_TESTING=YES TB --- 2012-05-19 16:38:14 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-19 16:38:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-19 16:38:14 - SRCCONF=/dev/null TB --- 2012-05-19 16:38:14 - TARGET=i386 TB --- 2012-05-19 16:38:14 - TARGET_ARCH=i386 TB --- 2012-05-19 16:38:14 - TZ=UTC TB --- 2012-05-19 16:38:14 - __MAKE_CONF=/dev/null TB --- 2012-05-19 16:38:14 - cd /src TB --- 2012-05-19 16:38:14 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat May 19 16:38:14 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 >>> Kernel build for LINT completed on Sat May 19 17:11:04 UTC 2012 TB --- 2012-05-19 17:11:04 - cd /src/sys/i386/conf TB --- 2012-05-19 17:11:04 - /usr/sbin/config -m LINT-NOINET TB --- 2012-05-19 17:11:04 - building LINT-NOINET kernel TB --- 2012-05-19 17:11:04 - CROSS_BUILD_TESTING=YES TB --- 2012-05-19 17:11:04 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-19 17:11:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-19 17:11:04 - SRCCONF=/dev/null TB --- 2012-05-19 17:11:04 - TARGET=i386 TB --- 2012-05-19 17:11:04 - TARGET_ARCH=i386 TB --- 2012-05-19 17:11:04 - TZ=UTC TB --- 2012-05-19 17:11:04 - __MAKE_CONF=/dev/null TB --- 2012-05-19 17:11:04 - cd /src TB --- 2012-05-19 17:11:04 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Sat May 19 17:11:04 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 >>> Kernel build for LINT-NOINET completed on Sat May 19 17:41:05 UTC 2012 TB --- 2012-05-19 17:41:05 - cd /src/sys/i386/conf TB --- 2012-05-19 17:41:05 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-05-19 17:41:05 - building LINT-NOINET6 kernel TB --- 2012-05-19 17:41:05 - CROSS_BUILD_TESTING=YES TB --- 2012-05-19 17:41:05 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-19 17:41:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-19 17:41:05 - SRCCONF=/dev/null TB --- 2012-05-19 17:41:05 - TARGET=i386 TB --- 2012-05-19 17:41:05 - TARGET_ARCH=i386 TB --- 2012-05-19 17:41:05 - TZ=UTC TB --- 2012-05-19 17:41:05 - __MAKE_CONF=/dev/null TB --- 2012-05-19 17:41:05 - cd /src TB --- 2012-05-19 17:41:05 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Sat May 19 17:41:06 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 >>> Kernel build for LINT-NOINET6 completed on Sat May 19 18:12:34 UTC 2012 TB --- 2012-05-19 18:12:34 - cd /src/sys/i386/conf TB --- 2012-05-19 18:12:34 - /usr/sbin/config -m LINT-NOIP TB --- 2012-05-19 18:12:34 - building LINT-NOIP kernel TB --- 2012-05-19 18:12:34 - CROSS_BUILD_TESTING=YES TB --- 2012-05-19 18:12:34 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-19 18:12:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-19 18:12:34 - SRCCONF=/dev/null TB --- 2012-05-19 18:12:34 - TARGET=i386 TB --- 2012-05-19 18:12:34 - TARGET_ARCH=i386 TB --- 2012-05-19 18:12:34 - TZ=UTC TB --- 2012-05-19 18:12:34 - __MAKE_CONF=/dev/null TB --- 2012-05-19 18:12:34 - cd /src TB --- 2012-05-19 18:12:34 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Sat May 19 18:12:34 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 >>> Kernel build for LINT-NOIP completed on Sat May 19 18:40:40 UTC 2012 TB --- 2012-05-19 18:40:40 - cd /src/sys/i386/conf TB --- 2012-05-19 18:40:40 - /usr/sbin/config -m LINT-VIMAGE TB --- 2012-05-19 18:40:40 - building LINT-VIMAGE kernel TB --- 2012-05-19 18:40:40 - CROSS_BUILD_TESTING=YES TB --- 2012-05-19 18:40:40 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-19 18:40:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-19 18:40:40 - SRCCONF=/dev/null TB --- 2012-05-19 18:40:40 - TARGET=i386 TB --- 2012-05-19 18:40:40 - TARGET_ARCH=i386 TB --- 2012-05-19 18:40:40 - TZ=UTC TB --- 2012-05-19 18:40:40 - __MAKE_CONF=/dev/null TB --- 2012-05-19 18:40:40 - cd /src TB --- 2012-05-19 18:40:40 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Sat May 19 18:40:40 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 >>> Kernel build for LINT-VIMAGE completed on Sat May 19 19:13:04 UTC 2012 TB --- 2012-05-19 19:13:04 - cd /src/sys/i386/conf TB --- 2012-05-19 19:13:04 - /usr/sbin/config -m GENERIC TB --- 2012-05-19 19:13:04 - building GENERIC kernel TB --- 2012-05-19 19:13:04 - CROSS_BUILD_TESTING=YES TB --- 2012-05-19 19:13:04 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-19 19:13:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-19 19:13:04 - SRCCONF=/dev/null TB --- 2012-05-19 19:13:04 - TARGET=i386 TB --- 2012-05-19 19:13:04 - TARGET_ARCH=i386 TB --- 2012-05-19 19:13:04 - TZ=UTC TB --- 2012-05-19 19:13:04 - __MAKE_CONF=/dev/null TB --- 2012-05-19 19:13:04 - cd /src TB --- 2012-05-19 19:13:04 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat May 19 19:13:05 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 >>> Kernel build for GENERIC completed on Sat May 19 19:40:02 UTC 2012 TB --- 2012-05-19 19:40:02 - cd /src/sys/i386/conf TB --- 2012-05-19 19:40:02 - /usr/sbin/config -m PAE TB --- 2012-05-19 19:40:02 - building PAE kernel TB --- 2012-05-19 19:40:02 - CROSS_BUILD_TESTING=YES TB --- 2012-05-19 19:40:02 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-19 19:40:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-19 19:40:02 - SRCCONF=/dev/null TB --- 2012-05-19 19:40:02 - TARGET=i386 TB --- 2012-05-19 19:40:02 - TARGET_ARCH=i386 TB --- 2012-05-19 19:40:02 - TZ=UTC TB --- 2012-05-19 19:40:02 - __MAKE_CONF=/dev/null TB --- 2012-05-19 19:40:02 - cd /src TB --- 2012-05-19 19:40:02 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Sat May 19 19:40:02 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 >>> Kernel build for PAE completed on Sat May 19 19:47:27 UTC 2012 TB --- 2012-05-19 19:47:27 - cd /src/sys/i386/conf TB --- 2012-05-19 19:47:27 - /usr/sbin/config -m XBOX TB --- 2012-05-19 19:47:27 - building XBOX kernel TB --- 2012-05-19 19:47:27 - CROSS_BUILD_TESTING=YES TB --- 2012-05-19 19:47:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-19 19:47:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-19 19:47:27 - SRCCONF=/dev/null TB --- 2012-05-19 19:47:27 - TARGET=i386 TB --- 2012-05-19 19:47:27 - TARGET_ARCH=i386 TB --- 2012-05-19 19:47:27 - TZ=UTC TB --- 2012-05-19 19:47:27 - __MAKE_CONF=/dev/null TB --- 2012-05-19 19:47:27 - cd /src TB --- 2012-05-19 19:47:27 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Sat May 19 19:47: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 >>> Kernel build for XBOX completed on Sat May 19 19:50:44 UTC 2012 TB --- 2012-05-19 19:50:44 - cd /src/sys/i386/conf TB --- 2012-05-19 19:50:44 - /usr/sbin/config -m XEN TB --- 2012-05-19 19:50:45 - building XEN kernel TB --- 2012-05-19 19:50:45 - CROSS_BUILD_TESTING=YES TB --- 2012-05-19 19:50:45 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-19 19:50:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-19 19:50:45 - SRCCONF=/dev/null TB --- 2012-05-19 19:50:45 - TARGET=i386 TB --- 2012-05-19 19:50:45 - TARGET_ARCH=i386 TB --- 2012-05-19 19:50:45 - TZ=UTC TB --- 2012-05-19 19:50:45 - __MAKE_CONF=/dev/null TB --- 2012-05-19 19:50:45 - cd /src TB --- 2012-05-19 19:50:45 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Sat May 19 19:50:45 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 [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh XEN cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror vers.c linking kernel.debug exception.o: In function `Xcpususpend': /src/sys/i386/i386/apic_vector.s:349: undefined reference to `cpususpend_handler' *** Error code 1 Stop in /obj/i386.i386/src/sys/XEN. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-05-19 19:56:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-05-19 19:56:26 - ERROR: failed to build XEN kernel TB --- 2012-05-19 19:56:26 - 15997.02 user 2226.98 system 20786.13 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat May 19 20:33:21 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6D9F0106566B; Sat, 19 May 2012 20:33:21 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 27D5A8FC12; Sat, 19 May 2012 20:33:21 +0000 (UTC) Received: by obcni5 with SMTP id ni5so7800969obc.13 for ; Sat, 19 May 2012 13:33:20 -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=LaStJm6P9Gg+AK8wQ9CLk6aeE66wWDkrBv7AINgOIhs=; b=uctbHjb1CzjDHqDxwS603g+jQ4aR5aoUE9MEf4CXRglCNDf3BCAKMIUJIeq8V0J8ZZ zHihCvGFkSxgtNBnYlr/MglKBVM/EB1+hFLJNwMY6FgDfBLcqEAhhJJdVNPqREh5bOUY 8byFD9+DCMlZyKWLAymi4i6wM0SApMayAu03LXvpk+dqXKyudwB009GRvcElHvvUQsvp XCfmsfgdDZE8w69tPjjBawOW0kQE7kMqJVGvnhmUmDMJzeGE9mHs1vYInuHKFqdVnQV8 HT61mOngXpGvIK/0x+5TSmlWTSTnrHoQFgow+k23zkMtlcGTNJrpDjJIRRB4OHwc9uhW b4Fg== MIME-Version: 1.0 Received: by 10.182.48.100 with SMTP id k4mr14248049obn.21.1337459600395; Sat, 19 May 2012 13:33:20 -0700 (PDT) Received: by 10.76.153.72 with HTTP; Sat, 19 May 2012 13:33:20 -0700 (PDT) In-Reply-To: <4FB7A63C.70509@zedat.fu-berlin.de> References: <4FB7A63C.70509@zedat.fu-berlin.de> Date: Sat, 19 May 2012 13:33:20 -0700 Message-ID: From: Garrett Cooper To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 Cc: Current FreeBSD , freebsd-questions@freebsd.org Subject: Re: CURRENT: buildworld fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 20:33:21 -0000 On Sat, May 19, 2012 at 6:55 AM, O. Hartmann wrote: > Since approx. a week for now, I can not build FreeBSD 10.0-CURRENT/amd64 > anymore! This happens to be on ALL(!) FreeBSD 10 boxes around here I > maintain. ... > b) build and install /usr/src/lib via "make clean cleandepend depend obj > all install" doesn't work anymore, it fails with > ."/usr/src/lib/Makefile", line 179: Malformed conditional (${MK_NAND} != > "no") > "/usr/src/lib/Makefile", line 181: if-less endif Your mk files in /usr/share/mk are out of synch with your build tree. If you opt out of using buildworld, then you need to do 'make -C share/mk install' beforehand. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sat May 19 23:39:07 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 001AB106566C for ; Sat, 19 May 2012 23:39:06 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 547B88FC08 for ; Sat, 19 May 2012 23:39:05 +0000 (UTC) Received: by wibhj8 with SMTP id hj8so1011548wib.13 for ; Sat, 19 May 2012 16:39:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=y0WQppbRoFGZ/3U8KAEcC7DgZC1ACs4LpFWLsnbeeig=; b=m0tIleEreZVEIUpKvIEy/NLhdldq+PS8J6uDeCk2jfSxGFKSci0CY6tAG8G2qZeWzh ilSzz62UQQksIRPKS9/Z08zxs6XKWtxwmeSFENGd+TSxaRnLTmQdyCxJ2Lynzr/p7toD GiCQFz+ij4kmqXe2u4ebEvKh7RHJfpa2nL8AgJkSlvhniT3YUauVNtXqYppTRgix+Tws e1MXb+EmoTTJTvjWv9nnmAwoODfAcE7/wYDvZghV/gNiEf58k8vkQ1x4rlCdyvG9jjto rl/f1JYBmR5cABr5T8wH12oWt54xPYxvm2ztQnSyb+y3+E8CwmY1vyLxiIcNgATaQUS/ /W7w== Received: by 10.216.139.12 with SMTP id b12mr10327253wej.4.1337470745055; Sat, 19 May 2012 16:39:05 -0700 (PDT) Received: from [192.168.1.80] (dsl51B63860.pool.t-online.hu. [81.182.56.96]) by mx.google.com with ESMTPS id j4sm13375816wiz.1.2012.05.19.16.39.02 (version=SSLv3 cipher=OTHER); Sat, 19 May 2012 16:39:04 -0700 (PDT) Message-ID: <4FB82FB1.7000902@gmail.com> Date: Sun, 20 May 2012 01:41:37 +0200 From: deeptech71@gmail.com User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:12.0) Gecko/20120518 Firefox/12.0 SeaMonkey/2.9.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4FB7D2B5.6030609@gmail.com> In-Reply-To: <4FB7D2B5.6030609@gmail.com> Content-Type: multipart/mixed; boundary="------------040903060705070509050804" Subject: Re: video drivers are locked up; panic during shutdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 23:39:07 -0000 This is a multi-part message in MIME format. --------------040903060705070509050804 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit A perhaps more useful crashinfo output, gathered with the use of the original (non-debug) kernel. --------------040903060705070509050804 Content-Type: text/plain; charset=UTF-8; name="core.txt.0" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="core.txt.0" IGR1bXBlZCBjb3JlIC0gc2VlIC92YXIvY3Jhc2gvdm1jb3JlLjAKClN1biBNYXkgMjAgMDE6 MzU6MjUgQ0VTVCAyMDEyCgoobm8gZGVidWdnaW5nIHN5bWJvbHMgZm91bmQpLi4uICAobm8g ZGVidWdnaW5nIHN5bWJvbHMgZm91bmQpLi4uIChubyBkZWJ1Z2dpbmcgc3ltYm9scyBmb3Vu ZCkuLi4gKG5vIGRlYnVnZ2luZyBzeW1ib2xzIGZvdW5kKS4uLgoKcGFuaWM6IHBhZ2UgZmF1 bHQKCkdOVSBnZGIgNi4xLjEgW0ZyZWVCU0RdCkNvcHlyaWdodCAyMDA0IEZyZWUgU29mdHdh cmUgRm91bmRhdGlvbiwgSW5jLgpHREIgaXMgZnJlZSBzb2Z0d2FyZSwgY292ZXJlZCBieSB0 aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UsIGFuZCB5b3UgYXJlCndlbGNvbWUgdG8g Y2hhbmdlIGl0IGFuZC9vciBkaXN0cmlidXRlIGNvcGllcyBvZiBpdCB1bmRlciBjZXJ0YWlu IGNvbmRpdGlvbnMuClR5cGUgInNob3cgY29weWluZyIgdG8gc2VlIHRoZSBjb25kaXRpb25z LgpUaGVyZSBpcyBhYnNvbHV0ZWx5IG5vIHdhcnJhbnR5IGZvciBHREIuICBUeXBlICJzaG93 IHdhcnJhbnR5IiBmb3IgZGV0YWlscy4KVGhpcyBHREIgd2FzIGNvbmZpZ3VyZWQgYXMgImkz ODYtbWFyY2VsLWZyZWVic2QiLi4uKG5vIGRlYnVnZ2luZyBzeW1ib2xzIGZvdW5kKS4uLgpB dHRlbXB0IHRvIGV4dHJhY3QgYSBjb21wb25lbnQgb2YgYSB2YWx1ZSB0aGF0IGlzIG5vdCBh IHN0cnVjdHVyZSBwb2ludGVyLgpBdHRlbXB0IHRvIGV4dHJhY3QgYSBjb21wb25lbnQgb2Yg YSB2YWx1ZSB0aGF0IGlzIG5vdCBhIHN0cnVjdHVyZSBwb2ludGVyLgojMCAgMHhjMDYxOTgx ZCBpbiBkb2FkdW1wICgpCihrZ2RiKSAjMCAgMHhjMDYxOTgxZCBpbiBkb2FkdW1wICgpCiMx ICAweGMwNjE5ZGE2IGluIGtlcm5fcmVib290ICgpCiMyICAweGMwNjFhNDEyIGluIHBhbmlj ICgpCiMzICAweGMwN2EzNTlmIGluIHRyYXBfZmF0YWwgKCkKIzQgIDB4YzA3YTM4NDYgaW4g dHJhcF9wZmF1bHQgKCkKIzUgIDB4YzA3YTQ0ZDEgaW4gdHJhcCAoKQojNiAgMHhjMDc4Zjcy YyBpbiBjYWxsdHJhcCAoKQojNyAgMHhjMDYwOTM4MSBpbiBfbXR4X2xvY2tfc2xlZXAgKCkK IzggIDB4YzA2YTc4NTkgaW4gdmRyb3AgKCkKIzkgIDB4YzA2YTgwNjEgaW4gYnVmb2JqX2lu dmFsYnVmICgpCiMxMCAweGMwNmE4MmU0IGluIHZnb25lbCAoKQojMTEgMHhjMDZhYjZiNSBp biB2Zmx1c2ggKCkKIzEyIDB4YzA3MzBjYWIgaW4gZmZzX2ZsdXNoZmlsZXMgKCkKIzEzIDB4 YzA3MzBkOWYgaW4gZmZzX3VubW91bnQgKCkKIzE0IDB4YzA2OWZlMGYgaW4gZG91bm1vdW50 ICgpCiMxNSAweGMwNmE4YzU3IGluIHZmc191bm1vdW50YWxsICgpCiMxNiAweGMwNjFhMTA3 IGluIGtlcm5fcmVib290ICgpCiMxNyAweGMwNjFhMTgyIGluIHN5c19yZWJvb3QgKCkKIzE4 IDB4YzA3YTNlYTcgaW4gc3lzY2FsbCAoKQojMTkgMHhjMDc4Zjc5MSBpbiBYaW50MHg4MF9z eXNjYWxsICgpCiMyMCAweDAwMDAwMDMzIGluID8/ICgpClByZXZpb3VzIGZyYW1lIGlubmVy IHRvIHRoaXMgZnJhbWUgKGNvcnJ1cHQgc3RhY2s/KQooa2dkYikgCgotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0KcHMgLWF4bAoKVUlEIFBJRCBQUElEIENQVSBQUkkgTkkgICAgVlNaICAgICBSU1Mg TVdDSEFOICAgU1RBVCBUVCAgICAgICBUSU1FIENPTU1BTkQKICAwICAgMCAgICAwICAgMCAt NTIgIDAgICAgICAwICAgICAgIDAgLSAgICAgICAgRExzICAgLSAgICAwOjAwLjA3IFtrZXJu ZWxdCiAgMCAgIDEgICAgMCAgIDAgLTYwICAwICAgOTE2OCAgMTk3NDg4IC0gICAgICAgIFJM cyAgIC0gICAgMDowMC4wMSBbaW5pdF0KICAwICAgMiAgICAwICAgMCAtMTYgIDAgICAgICAw ICAgICAgIDAgY2NiX3NjYW4gREwgICAgLSAgICAwOjAwLjAwIFt4cHRfdGhyZF0KICAwICAg MyAgICAwICAgMCAtMTYgIDAgICAgICAwICAgICAgIDAgcHNsZWVwICAgREwgICAgLSAgICAw OjA2LjY2IFtwYWdlZGFlbW9uXQogIDAgICA0ICAgIDAgICAwIC0xNiAgMCAgICAgIDAgICAg ICAgMCBwc2xlZXAgICBETCAgICAtICAgIDA6MDAuMDYgW3ZtZGFlbW9uXQogIDAgICA1ICAg IDAgICAwIDE1NSAgMCAgICAgIDAgICAgICAgMCBwZ3plcm8gICBETCAgICAtICAgIDA6MDAu MDAgW3BhZ2V6ZXJvXQogIDAgICA2ICAgIDAgICAwIC0xNiAgMCAgICAgIDAgICAgICAgMCBr cHN1c3AgICBETCAgICAtICAgIDA6MDAuMTcgW2J1ZmRhZW1vbl0KICAwICAgNyAgICAwICAg MCAtMTYgIDAgICAgICAwICAgICAgIDAga3BzdXNwICAgREwgICAgLSAgICAwOjAwLjE0IFt2 bmxydV0KICAwICAgOCAgICAwICAgMCAgMTYgIDAgICAgICAwICAgICAgIDAga3BzdXNwICAg REwgICAgLSAgICAwOjAwLjQxIFtzeW5jZXJdCiAgMCAgIDkgICAgMCAgIDAgLTE2ICAwICAg ICAgMCAgICAgICAwIHNkZmx1c2ggIERMICAgIC0gICAgMDowMC4xNiBbc29mdGRlcGZsdXMK ICAwICAxMCAgICAwICAgMCAxNTUgIDAgICAgICAwICAgICAgIDAgLSAgICAgICAgUkwgICAg LSAgNzU5OjMyLjQ2IFtpZGxlXQogIDAgIDExICAgIDAgICAwIC04NCAgMCAgICAgIDAgICAg ICAgMCAtICAgICAgICBXTCAgICAtICAgIDE6MTEuMDUgW2ludHJdCiAgMCAgMTIgICAgMCAg IDAgIC04ICAwICAgICAgMCAgICAgICAwIC0gICAgICAgIERMICAgIC0gICAgMDowNS4yNiBb Z2VvbV0KICAwICAxMyAgICAwICAgMCAtMTYgIDAgICAgICAwICAgICAgIDAgLSAgICAgICAg REwgICAgLSAgICAwOjAxLjYxIFt5YXJyb3ddCiAgMCAgMTQgICAgMCAgIDAgLTY4ICAwICAg ICAgMCAgICAgICAwIC0gICAgICAgIERMICAgIC0gICAgMDowOS42NSBbdXNiXQogIDAgNjQx ICAgIDEgICAwICA1MiAgMCAyMjQ5MTIgNDE0ODg5NiAtICAgICAgICBSRSAgICAtICAgMTI6 MzUuNDcgW1hvcmddCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0Kdm1zdGF0IC1zCgogMjAzMDQzMzYg Y3B1IGNvbnRleHQgc3dpdGNoZXMKICAgODkyOTc0IGRldmljZSBpbnRlcnJ1cHRzCiAgMjA2 NTI4OCBzb2Z0d2FyZSBpbnRlcnJ1cHRzCiAgNTczODM1NSB0cmFwcwogODM4NjMxNjkgc3lz dGVtIGNhbGxzCiAgICAgICAxNCBrZXJuZWwgdGhyZWFkcyBjcmVhdGVkCiAgICAgMTY5NyAg Zm9yaygpIGNhbGxzCiAgICAgMTU1MSB2Zm9yaygpIGNhbGxzCiAgICAgICAgMCByZm9yaygp IGNhbGxzCiAgICAgNTM4NCBzd2FwIHBhZ2VyIHBhZ2VpbnMKICAgIDIwNzUxIHN3YXAgcGFn ZXIgcGFnZXMgcGFnZWQgaW4KICAgICA2OTY5IHN3YXAgcGFnZXIgcGFnZW91dHMKICAgIDMx NzM0IHN3YXAgcGFnZXIgcGFnZXMgcGFnZWQgb3V0CiAgICAgODMyMSB2bm9kZSBwYWdlciBw YWdlaW5zCiAgICA2MTkwOSB2bm9kZSBwYWdlciBwYWdlcyBwYWdlZCBpbgogICAgICAgIDQg dm5vZGUgcGFnZXIgcGFnZW91dHMKICAgICAgIDMyIHZub2RlIHBhZ2VyIHBhZ2VzIHBhZ2Vk IG91dAogICAgICAyNTggcGFnZSBkYWVtb24gd2FrZXVwcwogIDM3MTAzMjMgcGFnZXMgZXhh bWluZWQgYnkgdGhlIHBhZ2UgZGFlbW9uCiAgICAgMzkwNSBwYWdlcyByZWFjdGl2YXRlZAog ICAxMTYxMDYgY29weS1vbi13cml0ZSBmYXVsdHMKICAgICAgMzQ4IGNvcHktb24td3JpdGUg b3B0aW1pemVkIGZhdWx0cwogIDE0MjQ2ODMgemVybyBmaWxsIHBhZ2VzIHplcm9lZAogICAg MjU3NTcgemVybyBmaWxsIHBhZ2VzIHByZXplcm9lZAogICAgIDU3NjIgaW50cmFuc2l0IGJs b2NraW5nIHBhZ2UgZmF1bHRzCiAgMTc1MDg1OSB0b3RhbCBWTSBmYXVsdHMgdGFrZW4KICAg ICAgICAwIHBhZ2VzIGFmZmVjdGVkIGJ5IGtlcm5lbCB0aHJlYWQgY3JlYXRpb24KICAgIDYz NDM1IHBhZ2VzIGFmZmVjdGVkIGJ5ICBmb3JrKCkKICAgIDU5OTI0IHBhZ2VzIGFmZmVjdGVk IGJ5IHZmb3JrKCkKICAgICAgICAwIHBhZ2VzIGFmZmVjdGVkIGJ5IHJmb3JrKCkKICAgICAg ICAwIHBhZ2VzIGNhY2hlZAogIDE3Mzk5MzEgcGFnZXMgZnJlZWQKICAgICAgICAwIHBhZ2Vz IGZyZWVkIGJ5IGRhZW1vbgogICAgICAgIDAgcGFnZXMgZnJlZWQgYnkgZXhpdGluZyBwcm9j ZXNzZXMKICAgICA3OTUyIHBhZ2VzIGFjdGl2ZQogICAgIDYxNTQgcGFnZXMgaW5hY3RpdmUK ICAgICAyOTQyIHBhZ2VzIGluIFZNIGNhY2hlCiAgICAyMzMwMiBwYWdlcyB3aXJlZCBkb3du CiAgICA4NTkxOCBwYWdlcyBmcmVlCiAgICAgNDA5NiBieXRlcyBwZXIgcGFnZQogIDE5OTUy MDUgdG90YWwgbmFtZSBsb29rdXBzCiAgICAgICAgICBjYWNoZSBoaXRzICg5NCUgcG9zICsg MyUgbmVnKSBzeXN0ZW0gMCUgcGVyLWRpcmVjdG9yeQogICAgICAgICAgZGVsZXRpb25zIDAl LCBmYWxzZWhpdHMgMCUsIHRvb2xvbmcgMCUKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQp2bXN0YXQg LW0KCiAgICAgICAgIFR5cGUgSW5Vc2UgTWVtVXNlIEhpZ2hVc2UgUmVxdWVzdHMgIFNpemUo cykKICAgICAgYWNwaWRldiAgICAzMiAgICAgMUsgICAgICAgLSAgICAgICAzMiAgMzIKICAg ICAgICBzaWdpbyAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAgMiAgMzIKICAgICBmaWxl ZGVzYyAgICAxOCAgICAgNUsgICAgICAgLSAgICAgMzI5MCAgMTYsMzIsNjQsMjU2LDUxMiwx MDI0LDIwNDgsNDA5NgogICAgICAgICBrZW52ICAgIDg4ICAgICA4SyAgICAgICAtICAgICAg IDk4ICAxNiwzMiw2NCwxMjgsNDA5NgogICAgICAga3F1ZXVlICAgICAwICAgICAwSyAgICAg ICAtICAgICAgODMzICAxMjgsMjU2LDEwMjQsMjA0OAogICAgcHJvYy1hcmdzICAgICAyICAg ICAxSyAgICAgICAtICAgICA3NjI4ICAxNiwzMiw2NCwxMjgsMjU2CiAgICAgICAgaGhvb2sg ICAgIDIgICAgIDFLICAgICAgIC0gICAgICAgIDIgIDEyOAogICAgICBlbnRyb3B5ICAxMDI0 ICAgIDY0SyAgICAgICAtICAgICAxMDI0ICA2NAogICAgICBpdGhyZWFkICAgIDY3ICAgICA2 SyAgICAgICAtICAgICAgIDY3ICAxNiw2NCwxMjgKICAgICAgIGxpbmtlciAgICA2NCAgICAg M0sgICAgICAgLSAgICAgICA2NiAgMTYsMzIsNjQsMjU2CiAgICAgICAgbG9ja2YgICAgIDIg ICAgIDFLICAgICAgIC0gICAgNTY1MDAgIDMyLDY0CiAgIGxvZ2luY2xhc3MgICAgIDEgICAg IDFLICAgICAgIC0gICAgICAxMzMgIDY0CiAgICAgYWNwaWludHIgICAgIDEgICAgIDFLICAg ICAgIC0gICAgICAgIDEgIDMyCiAgICAgICAgIHRlbXAgICAgMTkgICAxNjFLICAgICAgIC0g ICAgMjc4NTkgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDEwMjQsMjA0OCw0MDk2CiAgICAgICBk ZXZidWYgIDE2OTMgIDI0ODdLICAgICAgIC0gICAgIDYxMTEgIDE2LDMyLDY0LDEyOCwyNTYs NTEyLDEwMjQsMjA0OCw0MDk2CiAgICAgICAgIGFjOTcgICAgIDIgICAgIDFLICAgICAgIC0g ICAgICAgIDIgIDE2LDUxMgogICAgICAgbW9kdWxlICAgMjA5ICAgIDE0SyAgICAgICAtICAg ICAgMjA5ICA2NCwxMjgKICAgICAgIGFjcGljYSAgMTc4NSAgICA5M0sgICAgICAgLSAgICAz Nzk1MyAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNAogICAgIG10eF9wb29sICAgICAyICAg ICA4SyAgICAgICAtICAgICAgICAyICA0MDk2CiAgICAgcGNpX2xpbmsgICAgMTYgICAgIDJL ICAgICAgIC0gICAgICAgMTYgIDY0LDEyOAogICAgIGFjcGl0YXNrICAgICAxICAgICAxSyAg ICAgICAtICAgICAgICAxICAxMDI0CiAgICAgcG1jaG9va3MgICAgIDEgICAgIDFLICAgICAg IC0gICAgICAgIDEgIDY0CiAgICAgIHN1YnByb2MgICAxMjIgICAgOTFLICAgICAgIC0gICAg IDMzNjkgIDI1Niw0MDk2CiAgICAgICAgIHByb2MgICAgIDIgICAgIDRLICAgICAgIC0gICAg ICAgIDIgIDIwNDgKICAgICAgc2Vzc2lvbiAgICAgMiAgICAgMUsgICAgICAgLSAgICAgIDE3 MCAgNjQKICAgICAgICAgcGdycCAgICAgMiAgICAgMUsgICAgICAgLSAgICAgIDMyNiAgNjQK ICAgICAgICAgY3JlZCAgICAxNiAgICAgMksgICAgICAgLSAgIDE2MTE4NiAgNjQsMTI4CiAg ICAgIHVpZGluZm8gICAgIDMgICAgIDFLICAgICAgIC0gICAgICAxMzAgIDY0LDUxMgogICAg ICAgcGxpbWl0ICAgICAyICAgICAxSyAgICAgICAtICAgICAxODUxICAyNTYKICAgICAgICAg IGFncCAgICAgMyAgIDI1N0sgICAgICAgLSAgICAgICAgMyAgMTYsNjQKICAgICAgQ0FNIFNJ TSAgICAgNCAgICAgMUsgICAgICAgLSAgICAgICAgNCAgMTI4CiAgICAgICBmZWVkZXIgICAg MTQgICAgIDFLICAgICAgIC0gICAgIDY1MTEgIDE2LDY0CiAgICBzeXNjdGx0bXAgICAgIDAg ICAgIDBLICAgICAgIC0gICAgIDExOTYgIDE2LDMyLDY0LDEyOCwyMDQ4CiAgICBzeXNjdGxv aWQgIDI1NTcgICAgNzhLICAgICAgIC0gICAgIDI2MjMgIDE2LDMyLDY0CiAgICAgICBzeXNj dGwgICAgIDAgICAgIDBLICAgICAgIC0gICAgIDEzNzEgIDE2LDMyLDY0CiAgICAgIHRpZGhh c2ggICAgIDEgICAgIDRLICAgICAgIC0gICAgICAgIDEgIDQwOTYKICAgICAgY2FsbG91dCAg ICAgMSAgIDEyOEsgICAgICAgLSAgICAgICAgMSAgCiAgICAgICAgIHVtdHggICAzODAgICAg MzZLICAgICAgIC0gICAgICAzODAgIDY0LDEyOAogICAgIHAxMDAzLjFiICAgICAxICAgICAx SyAgICAgICAtICAgICAgICAxICAxNgogICAgICAgICBTV0FQICAgICAyICAgMjA5SyAgICAg ICAtICAgICAgICAyICA2NAogICAgICAgYnVzLXNjICAgIDU1ICAgIDg3SyAgICAgICAtICAg ICAgNzc4ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgKICAgICAgICAgIGJ1cyAg IDYzNiAgICAzMEsgICAgICAgLSAgICAgMjM3NiAgMTYsMzIsNjQsMTI4LDI1NiwxMDI0CiAg ICAgIGRldnN0YXQgICAgIDYgICAgMTNLICAgICAgIC0gICAgICAgIDYgIDE2LDQwOTYKIGV2 ZW50aGFuZGxlciAgICA2MyAgICAgNEsgICAgICAgLSAgICAgICA2MyAgMzIsNjQsMTI4CiAg IENBTSBwZXJpcGggICAgIDggICAgIDFLICAgICAgIC0gICAgICAgMjIgIDE2LDMyLDY0LDEy OAogICAgICAgICBrb2JqICAgMTU2ICAgMzEySyAgICAgICAtICAgICAzNDI3ICAyMDQ4CiAg ICAgIFBlci1jcHUgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDE2CiAgICAgIGF0 YV9wY2kgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDMyCiAgICAgIGFjcGlzZW0g ICAgMTYgICAgIDJLICAgICAgIC0gICAgICAgMTYgIDY0LDEyOAogICAgICBDQU0gWFBUICAg IDQ1ICAgIDIwSyAgICAgICAtICAgICAgMTE2ICAxNiwzMiw2NCwyNTYsMTAyNCwyMDQ4CiAg ICAgICAgIHJtYW4gICAxNTYgICAgMTBLICAgICAgIC0gICAgICA1MTYgIDE2LDMyLDY0CiAg ICAgICAgbWl4ZXIgICAgIDEgICAgIDRLICAgICAgIC0gICAgICAgIDEgIDQwOTYKICAgICAg ICAgc2J1ZiAgICAgMCAgICAgMEsgICAgICAgLSAgICAgIDY5NCAgMTYsMzIsNjQsMTI4LDI1 Niw1MTIsMTAyNCwyMDQ4LDQwOTYKICAgICAgc2NzaV9jZCAgICAgMCAgICAgMEsgICAgICAg LSAgICAgICAgNCAgMTYKICAgIHRhc2txdWV1ZSAgICAxNSAgICAgMUsgICAgICAgLSAgICAg ICAxNSAgMTYsNjQKICAgICAgIFVuaXRubyAgICAxNCAgICAgMUsgICAgICAgLSAgICAgMjc1 OCAgMTYsNjQKICAgICAgICAgIGlvdiAgICAgMCAgICAgMEsgICAgICAgLSAgMzIxNjM4OCAg MTYsNjQsMTI4LDI1NgogICAgICAgc2VsZWN0ICAgIDYzICAgICA0SyAgICAgICAtICAgICAg IDYzICA2NAogICAgIGlvY3Rsb3BzICAgICAwICAgICAwSyAgICAgICAtICA5ODQxNzQ4ICAx NiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0CiAgICAgICAgICBtc2cgICAgIDQgICAgMjVLICAg ICAgIC0gICAgICAgIDQgIDEwMjQsNDA5NgogICAgICAgICAgc2VtICAgICA0ICAgMTAxSyAg ICAgICAtICAgICAgICA0ICAxMDI0LDQwOTYKICAgICAgICAgIHNobSAgICAgMiAgICAxM0sg ICAgICAgLSAgICAgICA0MCAgMTAyNAogICAgICAgICAgdHR5ICAgIDE3ICAgICA5SyAgICAg ICAtICAgICAgIDI2ICA1MTIsMTAyNAogICAgICAgICAgcHRzICAgICAwICAgICAwSyAgICAg ICAtICAgICAgICA3ICAxMjgKICAgICBtYnVmX3RhZyAgICAgMCAgICAgMEsgICAgICAgLSAg ICAgICAgMSAgMzIKICAgICAgICBzaG1mZCAgICAgMSAgICAgNEsgICAgICAgLSAgICAgICAg MSAgNDA5NgogICAgICAgICAgcGNiICAgICA5ICAgICA3SyAgICAgICAtICAgICAyMDcxICAx Niw1MTIsMTAyNCwyMDQ4CiAgICAgICBzb25hbWUgICAgMTAgICAgIDJLICAgICAgIC0gICAg MTc3NzkgIDE2LDMyLDY0LDEyOAogICAgICAgYmlvYnVmICAgIDIwICAgIDQwSyAgICAgICAt ICAgICAxODQ0ICAyMDQ4CiAgICAgdmZzY2FjaGUgICAgIDEgICAyNTZLICAgICAgIC0gICAg ICAgIDEgIAogICBjbF9zYXZlYnVmICAgICAwICAgICAwSyAgICAgICAtICAgICA1ODc3ICAz Miw2NAogICAgIHZmc19oYXNoICAgICAxICAgMTI4SyAgICAgICAtICAgICAgICAxICAKICAg ICAgIHZub2RlcyAgICAgMiAgICAgMUsgICAgICAgLSAgICAgICAgMiAgMTI4CiAgICAgICAg bW91bnQgICAgMTkgICAgIDFLICAgICAgIC0gICAgICAxMjYgIDE2LDMyLDY0LDEyOCwyNTYK ICB2bm9kZW1hcmtlciAgICAgMSAgICAgMUsgICAgICAgLSAgICAgMjQzOSAgNTEyCiAgZXRo ZXJfbXVsdGkgICAgIDcgICAgIDFLICAgICAgIC0gICAgICAgIDggIDE2LDMyLDY0CiAgICAg ICBpZmFkZHIgICAgMjMgICAgIDZLICAgICAgIC0gICAgICAgMjMgIDE2LDMyLDI1Niw1MTIs MjA0OAogICAgICAgIGlmbmV0ICAgICA2ICAgICA2SyAgICAgICAtICAgICAgICA2ICA2NCwx MDI0CmRybV9jdHhiaXRtYXAgICAgIDEgICAgIDRLICAgICAgIC0gICAgICAgIDEgIDQwOTYK ICAgICAgIGFycGNvbSAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgMTYKICAgICAg bGx0YWJsZSAgICAgNyAgICAgMksgICAgICAgLSAgICAgICAgNyAgMTI4LDI1NgogZHJtX2Fn cGxpc3RzICAgICAyICAgICAxSyAgICAgICAtICAgICAgICAyICAzMiw2NAogICAgICAgVVNC ZGV2ICAgIDI1ICAgICA0SyAgICAgICAtICAgICAgIDI3ICAzMiw2NCwxMjgsMjU2LDIwNDgK ICAgICAgICAgIFVTQiAgICAzOSAgICA0MUsgICAgICAgLSAgICAgICA0MiAgMTYsMzIsNjQs MTI4LDEwMjQsMjA0OCw0MDk2CiAgICAgcm91dGV0YmwgICAgMTEgICAgIDJLICAgICAgIC0g ICAgICAgNDggIDE2LDMyLDY0LDEyOCwyNTYKICAgICAgICAgaWdtcCAgICAgNSAgICAgMUsg ICAgICAgLSAgICAgICAgNSAgMTI4CiAgICBkcm1fZmlsZXMgICAgIDAgICAgIDBLICAgICAg IC0gICAgICAgMTggIDE2LDY0CiAgICAgaW5fbXVsdGkgICAgIDIgICAgIDFLICAgICAgIC0g ICAgICAgIDIgIDEyOAogICAgaG9zdGNhY2hlICAgICAxICAgIDE2SyAgICAgICAtICAgICAg ICAxICAKICAgICBzeW5jYWNoZSAgICAgMSAgICA3MksgICAgICAgLSAgICAgICAgMSAgCiAg ICAgZnJlZXdvcmsgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDY0CiAgICAgICBu ZXdibGsgICAgIDEgICAgMTZLICAgICAgIC0gICAgICAgIDEgIAogICAgYm1zYWZlbWFwICAg ICAxICAgICA0SyAgICAgICAtICAgICAgICAxICA0MDk2CiAgICAgaW5vZGVkZXAgICAgIDEg ICAxMjhLICAgICAgIC0gICAgICAgIDEgIAogICAgICBwYWdlZGVwICAgICAxICAgIDE2SyAg ICAgICAtICAgICAgICAxICAKICB1ZnNfZGlyaGFzaCAgICAgNyAgICAgNEsgICAgICAgLSAg ICAgIDQ4MSAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMjA0OCw0MDk2CiAgICB1ZnNfbW91bnQg ICAgIDMgICAgMTFLICAgICAgIC0gICAgICAgIDMgIDI1NiwyMDQ4CiAgICB2bV9wZ2RhdGEg ICAgIDIgICAgMzNLICAgICAgIC0gICAgICAgIDIgIDY0CiAgICAgIFVNQUhhc2ggICAgIDIg ICAgIDJLICAgICAgIC0gICAgICAgIDQgIDI1Niw1MTIsMTAyNAogICAgICAgREVWRlMxICAg IDg4ICAgIDIySyAgICAgICAtICAgICAgIDk4ICAyNTYKICAgICAgIERFVkZTMyAgIDEwOCAg ICAxNEsgICAgICAgLSAgICAgIDEyNSAgMTI4CiAgICAgYXRrYmRkZXYgICAgIDIgICAgIDFL ICAgICAgIC0gICAgICAgIDIgIDMyCiAgICAgICAgREVWRlMgICAgMTggICAgIDFLICAgICAg IC0gICAgICAgMTkgIDE2LDY0CiAgICAgICBERVZGU1AgICAgIDIgICAgIDFLICAgICAgIC0g ICAgICAgMTEgIDMyCiBtc2Rvc2ZzX25vZGUgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAg MjEgIDEyOAogIG1zZG9zZnNfZmF0ICAgICAwICAgICAwSyAgICAgICAtICAgICAgICAxICAK bXNkb3Nmc19tb3VudCAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAgMSAgMjU2CiAgICAg IG1lbWRlc2MgICAgIDEgICAgIDRLICAgICAgIC0gICAgICAgIDQgIDMyLDQwOTYKICAgICAg ICAgR0VPTSAgICA5NCAgICAyN0sgICAgICAgLSAgICAgIDM5NiAgMTYsMzIsNjQsMTI4LDUx MiwxMDI0LDIwNDgKICAgICBkcm1fYnVmcyAgICAzNiAgICAgM0sgICAgICAgLSAgICAgICAz NiAgMTYsMzIsMTI4LDIwNDgKICAgICBkcm1fbWFwcyAgICAgOCAgICAgOUsgICAgICAgLSAg ICAgICAyMCAgNjQKICAgIGRybV9tYWdpYyAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAg MiAgMTYKICAgZHJtX2RyaXZlciAgICAgNiAgICAgNEsgICAgICAgLSAgICAgICAxNSAgMTYs MzIsNjQsMjU2LDEwMjQsMjA0OAogICAgZHJtX3NhcmVhICAgICAxICAgICAxSyAgICAgICAt ICAgICAgICAxICAxNgogICAgICAgYXBtZGV2ICAgICAxICAgICAxSyAgICAgICAtICAgICAg ICAxICA2NAogICBtYWR0X3RhYmxlICAgICAwICAgICAwSyAgICAgICAtICAgICAgICAxICAy MDQ4CiAgICAgICBpc2FkZXYgICAgIDkgICAgIDFLICAgICAgIC0gICAgICAgIDkgIDY0CiAg ICAgIGlvX2FwaWMgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDEwMjQKQ0FNIGRl diBxdWV1ZSAgICAgNCAgICAgMUsgICAgICAgLSAgICAgICAgNCAgMTI4CiAgICAgIHNjc2lf ZGEgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgMTEgIDE2CiAgICAgICAgICBNQ0EgICAg IDQgICAgIDFLICAgICAgIC0gICAgICAgIDQgIDEyOAogICAgIG5leHVzZGV2ICAgICA0ICAg ICAxSyAgICAgICAtICAgICAgICA0ICAxNgogICAgICAgICBjZGV2ICAgICA4ICAgICAxSyAg ICAgICAtICAgICAgICA4ICAxMjgKICAgIENBTSBxdWV1ZSAgICAxNyAgICAgMUsgICAgICAg LSAgICAgICA2MyAgMTYKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQp2bXN0YXQgLXoKCklURU0gICAg ICAgICAgICAgICAgICAgU0laRSAgTElNSVQgICAgIFVTRUQgICAgIEZSRUUgICAgICBSRVEg RkFJTCBTTEVFUAoKVU1BIEtlZ3M6ICAgICAgICAgICAgICAgMTI4LCAgICAgIDAsICAgICAg NzQsICAgICAgMTYsICAgICAgNzQsICAgMCwgICAwClVNQSBab25lczogICAgICAgICAgICAg IDE3NiwgICAgICAwLCAgICAgIDc0LCAgICAgICA2LCAgICAgIDc0LCAgIDAsICAgMApVTUEg U2xhYnM6ICAgICAgICAgICAgICAyODQsICAgICAgMCwgICAgIDYwMiwgICAgIDE4MiwgICAg MzcyOCwgICAwLCAgIDAKVU1BIFJDbnRTbGFiczogICAgICAgICAgNTQ0LCAgICAgIDAsICAg ICA2MDgsICAgICAxOTcsICAgIDY2OTAsICAgMCwgICAwClVNQSBIYXNoOiAgICAgICAgICAg ICAgIDEyOCwgICAgICAwLCAgICAgICAwLCAgICAgIDMwLCAgICAgICAyLCAgIDAsICAgMAox NiBCdWNrZXQ6ICAgICAgICAgICAgICAgNzYsICAgICAgMCwgICAgICAyOSwgICAgICA3MSwg ICAgIDEwNCwgICAwLCAgIDAKMzIgQnVja2V0OiAgICAgICAgICAgICAgMTQwLCAgICAgIDAs ICAgICAgNDcsICAgICAgIDksICAgICAxOTEsICAgMCwgICAwCjY0IEJ1Y2tldDogICAgICAg ICAgICAgIDI2OCwgICAgICAwLCAgICAgIDQ1LCAgICAgIDExLCAgICAgMzk1LCAgMjMsICAg MAoxMjggQnVja2V0OiAgICAgICAgICAgICA1MjQsICAgICAgMCwgICAgIDQyNCwgICAgICAg MywgICAgMTQyNCwxMjY3LCAgIDAKVk0gT0JKRUNUOiAgICAgICAgICAgICAgMTQ4LCAgICAg IDAsICAgIDM5MDUsICAgIDk3MTksICAgODQwNjMsICAgMCwgICAwCk1BUDogICAgICAgICAg ICAgICAgICAgIDE0MCwgICAgICAwLCAgICAgICA3LCAgICAgIDQ5LCAgICAgICA3LCAgIDAs ICAgMApLTUFQIEVOVFJZOiAgICAgICAgICAgICAgNzIsICAzMTk1OSwgICAgICA3OCwgICAg IDcxNywgICA2MzAyMSwgICAwLCAgIDAKTUFQIEVOVFJZOiAgICAgICAgICAgICAgIDcyLCAg ICAgIDAsICAgICAxMTIsICAgIDI5MDksICAxNTY2NzEsICAgMCwgICAwCmZha2VwZzogICAg ICAgICAgICAgICAgICA3MiwgICAgICAwLCAgIDMzMzAyLCAgICAgIDM1LCAgIDMzMzIwLCAg IDAsICAgMAptdF96b25lOiAgICAgICAgICAgICAgIDIwNjAsICAgICAgMCwgICAgIDIxNSwg ICAgICAgMCwgICAgIDIxNSwgICAwLCAgIDAKMTY6ICAgICAgICAgICAgICAgICAgICAgIDE2 LCAgICAgIDAsICAgIDIwNjgsICAgICAzNjgsIDUyMjc3NTUsICAgMCwgICAwCjMyOiAgICAg ICAgICAgICAgICAgICAgICAzMiwgICAgICAwLCAgICAxNjQxLCAgICAgMzkzLCAgIDI2MzIw LCAgIDAsICAgMAo2NDogICAgICAgICAgICAgICAgICAgICAgNjQsICAgICAgMCwgICAgMzcy NSwgICAgIDM0NiwgODAzNTM4MiwgICAwLCAgIDAKMTI4OiAgICAgICAgICAgICAgICAgICAg MTI4LCAgICAgIDAsICAgIDE1MzIsICAgICAyNjgsICAgODg1MDYsICAgMCwgICAwCjI1Njog ICAgICAgICAgICAgICAgICAgIDI1NiwgICAgICAwLCAgICAgNTU2LCAgICAgMjI0LCAgICA2 NDE0LCAgIDAsICAgMAo1MTI6ICAgICAgICAgICAgICAgICAgICA1MTIsICAgICAgMCwgICAg ICA2NiwgICAgICA4NiwgICAxMjc5OCwgICAwLCAgIDAKMTAyNDogICAgICAgICAgICAgICAg ICAxMDI0LCAgICAgIDAsICAgICAgNDIsICAgICAgNzgsICAgIDg2NDIsICAgMCwgICAwCjIw NDg6ICAgICAgICAgICAgICAgICAgMjA0OCwgICAgICAwLCAgICAgMjA4LCAgICAgMjg0LCAg ICA1NDcwLCAgIDAsICAgMAo0MDk2OiAgICAgICAgICAgICAgICAgIDQwOTYsICAgICAgMCwg ICAgICA2NSwgICAgICA4NiwgICAgODAxNSwgICAwLCAgIDAKRmlsZXM6ICAgICAgICAgICAg ICAgICAgIDU2LCAgICAgIDAsICAgICAgMTIsICAgICA3OTIsICAxMDU5NDYsICAgMCwgICAw ClRVUk5TVElMRTogICAgICAgICAgICAgICA3MiwgICAgICAwLCAgICAgMTkxLCAgICAgIDQ5 LCAgICAgMTkxLCAgIDAsICAgMAp1bXR4IHBpOiAgICAgICAgICAgICAgICAgNTIsICAgICAg MCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKUFJPQzogICAgICAgICAg ICAgICAgICAgNzE2LCAgICAgIDAsICAgICAgMTUsICAgICAgOTAsICAgIDMyNjIsICAgMCwg ICAwClRIUkVBRDogICAgICAgICAgICAgICAgIDczMiwgICAgICAwLCAgICAgMTQyLCAgICAg IDQ4LCAgICAgNTczLCAgIDAsICAgMApTTEVFUFFVRVVFOiAgICAgICAgICAgICAgNDQsICAg ICAgMCwgICAgIDE5MSwgICAgIDEwNCwgICAgIDE5MSwgICAwLCAgIDAKVk1TUEFDRTogICAg ICAgICAgICAgICAgMjMyLCAgICAgIDAsICAgICAgIDIsICAgICAxMzQsICAgIDMyNDksICAg MCwgICAwCmNwdXNldDogICAgICAgICAgICAgICAgICA0MCwgICAgICAwLCAgICAgIDUyLCAg ICAgMTMyLCAgICAgIDUyLCAgIDAsICAgMAptYnVmX3BhY2tldDogICAgICAgICAgICAyNTYs ICAgICAgMCwgICAgIDI1NiwgICAgIDUyMywgIDMzMDY2MSwgICAwLCAgIDAKbWJ1ZjogICAg ICAgICAgICAgICAgICAgMjU2LCAgICAgIDAsICAgICAgMTIsICAgICA1MTEsIDQzNTIzNTgs ICAgMCwgICAwCm1idWZfY2x1c3RlcjogICAgICAgICAgMjA0OCwgIDE3MDg4LCAgICAgNTEy LCAgICAgMzUyLCAgIDE3MDI0LCAgIDAsICAgMAptYnVmX2p1bWJvX3BhZ2U6ICAgICAgIDQw OTYsICAgODU0NCwgICAgICAgNywgICAgIDE2OSwgMTMwOTAzMiwgICAwLCAgIDAKbWJ1Zl9q dW1ib185azogICAgICAgICA5MjE2LCAgMTI4MTYsICAgICAgIDAsICAgICAgIDAsICAgICAg IDAsICAgMCwgICAwCm1idWZfanVtYm9fMTZrOiAgICAgICAxNjM4NCwgICA4NTQ0LCAgICAg ICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAptYnVmX2V4dF9yZWZjbnQ6ICAgICAg ICAgIDQsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKZ19i aW86ICAgICAgICAgICAgICAgICAgMTQwLCAgICAgIDAsICAgICAgIDAsICAgICA2NDQsICA0 MTc4MzIsICAgMCwgICAwCnR0eWlucTogICAgICAgICAgICAgICAgIDE1MiwgICAgICAwLCAg ICAgICAwLCAgICAgNDk0LCAgICAgOTc1LCAgIDAsICAgMAp0dHlvdXRxOiAgICAgICAgICAg ICAgICAyNTYsICAgICAgMCwgICAgICAgMCwgICAgIDI0MCwgICAgIDUxMywgICAwLCAgIDAK YXRhX3JlcXVlc3Q6ICAgICAgICAgICAgMjA4LCAgICAgIDAsICAgICAgIDEsICAgICAxNjQs ICAxMDc0NDksICAgMCwgICAwCmF0YV9jb21wb3NpdGU6ICAgICAgICAgIDE4MCwgICAgICAw LCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApWTk9ERTogICAgICAgICAg ICAgICAgICAyNzIsICAgICAgMCwgICAgMzg5NywgICAgODI5NywgICAxNjkyMiwgICAwLCAg IDAKVk5PREVQT0xMOiAgICAgICAgICAgICAgIDYwLCAgICAgIDAsICAgICAgIDQsICAgICA1 MDAsICAgICA0NzcsICAgMCwgICAwCk5BTUVJOiAgICAgICAgICAgICAgICAgMTAyNCwgICAg ICAwLCAgICAgICAwLCAgICAgMTUyLCAgNDUzMTQyLCAgIDAsICAgMApTIFZGUyBDYWNoZTog ICAgICAgICAgICAgNzIsICAgICAgMCwgICAgICAgMCwgICAxMTEzMCwgICAzMDExMSwgICAw LCAgIDAKU1RTIFZGUyBDYWNoZTogICAgICAgICAgIDkyLCAgICAgIDAsICAgICAgIDAsICAg ICAgIDAsICAgICAgIDAsICAgMCwgICAwCkwgVkZTIENhY2hlOiAgICAgICAgICAgIDI5Miwg ICAgICAwLCAgICAgICAwLCAgICAxNzU1LCAgICAyNTgxLCAgIDAsICAgMApMVFMgVkZTIENh Y2hlOiAgICAgICAgICAzMTIsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwg ICAwLCAgIDAKRElSSEFTSDogICAgICAgICAgICAgICAxMDI0LCAgICAgIDAsICAgICAgIDAs ICAgICAyODgsICAgIDMzOTEsICAgMCwgICAwCk1vdW50cG9pbnRzOiAgICAgICAgICAgIDY1 NiwgICAgICAwLCAgICAgICAyLCAgICAgIDE2LCAgICAgICAzLCAgIDAsICAgMApwaXBlOiAg ICAgICAgICAgICAgICAgICA0MDAsICAgICAgMCwgICAgICAgMCwgICAgICA3MCwgICAgMTgy NSwgICAwLCAgIDAKa3NpZ2luZm86ICAgICAgICAgICAgICAgIDgwLCAgICAgIDAsICAgICAx MTAsICAgICAzNzAsICAyODA4NDksICAgMCwgICAwCml0aW1lcjogICAgICAgICAgICAgICAg IDIyMCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApLTk9U RTogICAgICAgICAgICAgICAgICAgNzIsICAgICAgMCwgICAgICAgMCwgICAgIDM3MSwgICAg MjMxOCwgICAwLCAgIDAKc29ja2V0OiAgICAgICAgICAgICAgICAgNDE2LCAgMTcwOTEsICAg ICAgMTEsICAgICAxNzgsICAgIDUxNDgsICAgMCwgICAwCnVucGNiOiAgICAgICAgICAgICAg ICAgIDE3MiwgIDE3MDg5LCAgICAgIDEwLCAgICAgMTA1LCAgICAyOTk2LCAgIDAsICAgMApp cHE6ICAgICAgICAgICAgICAgICAgICAgMzIsICAgIDU2NSwgICAgICAgMCwgICAgICAgMCwg ICAgICAgMCwgICAwLCAgIDAKdWRwX2lucGNiOiAgICAgICAgICAgICAgMjUyLCAgMTcxMDAs ICAgICAgIDAsICAgICAgOTAsICAgICA1MDAsICAgMCwgICAwCnVkcGNiOiAgICAgICAgICAg ICAgICAgICAgOCwgIDE3MjU1LCAgICAgICAwLCAgICAgNDA2LCAgICAgNTAwLCAgIDAsICAg MAp0Y3BfaW5wY2I6ICAgICAgICAgICAgICAyNTIsICAxNzEwMCwgICAgICAgMywgICAgIDE5 MiwgICAgMTY1MSwgICAwLCAgIDAKdGNwY2I6ICAgICAgICAgICAgICAgICAgNjg4LCAgMTcw OTAsICAgICAgIDEsICAgICAxMzQsICAgIDE2NTEsICAgMCwgICAwCnRjcHR3OiAgICAgICAg ICAgICAgICAgICA1MiwgICAzNDU2LCAgICAgICAyLCAgICAgMjE0LCAgICAgNTA3LCAgIDAs ICAgMApzeW5jYWNoZTogICAgICAgICAgICAgICAxMjAsICAxNTM2MCwgICAgICAgMCwgICAg ICAgMCwgICAgICAgMCwgICAwLCAgIDAKaG9zdGNhY2hlOiAgICAgICAgICAgICAgIDc2LCAg MTU0MDAsICAgICAgIDUsICAgICAxOTUsICAgICAgNzIsICAgMCwgICAwCnRjcHJlYXNzOiAg ICAgICAgICAgICAgICAyMCwgICAxMTgzLCAgICAgICAwLCAgICAgNTA3LCAgIDIzMjcxLCAg IDAsICAgMApzYWNraG9sZTogICAgICAgICAgICAgICAgMjAsICAgICAgMCwgICAgICAgMCwg ICAgIDMzOCwgICAgICAgOCwgICAwLCAgIDAKcmlwY2I6ICAgICAgICAgICAgICAgICAgMjUy LCAgMTcxMDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnJ0ZW50cnk6 ICAgICAgICAgICAgICAgIDEwOCwgICAgICAwLCAgICAgICA0LCAgICAgMTA0LCAgICAgICA0 LCAgIDAsICAgMApzZWxmZDogICAgICAgICAgICAgICAgICAgMjgsICAgICAgMCwgICAgICA4 NiwgICAgIDU0OSw0OTM3OTA1MywgICAwLCAgIDAKU1dBUE1FVEE6ICAgICAgICAgICAgICAg Mjc2LCAgNjMxNTQsICAgICAxMDYsICAgIDIzODYsICAgIDM1NzIsICAgMCwgICAwCkZGUyBp bm9kZTogICAgICAgICAgICAgIDExNiwgICAgICAwLCAgICAzODg3LCAgICA4ODE4LCAgIDE2 ODQ3LCAgIDAsICAgMApGRlMxIGRpbm9kZTogICAgICAgICAgICAxMjgsICAgICAgMCwgICAg ICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKRkZTMiBkaW5vZGU6ICAgICAgICAg ICAgMjU2LCAgICAgIDAsICAgIDM4ODcsICAgIDgxNDMsICAgMTY4NDcsICAgMCwgICAwCgoK LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tCnZtc3RhdCAtaQoKaW50ZXJydXB0ICAgICAgICAgICAgICAg ICAgICAgICAgICB0b3RhbCAgICAgICByYXRlCmlycTE6IGF0a2JkMCAgICAgICAgICAgICAg ICAgICAgICAgNTU3MDkgICAgICAgICA3OQppcnE5OiBhY3BpMCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAxICAgICAgICAgIDAKaXJxMTQ6IGF0YTAgICAgICAgICAgICAgICAgICAg ICAgIDEwNjExOSAgICAgICAgMTUwCmlycTE1OiBhdGExICAgICAgICAgICAgICAgICAgICAg ICAgICAgMjEgICAgICAgICAgMAppcnExNjogdWhjaTArICAgICAgICAgICAgICAgICAgICAg MjQyNDQyICAgICAgICAzNDQKaXJxMjA6IHBjbTAgICAgICAgICAgICAgICAgICAgICAgIDIy OTY5MyAgICAgICAgMzI2CmlycTIyOiBza2MwICAgICAgICAgICAgICAgICAgICAgICAyNTg3 MzYgICAgICAgIDM2OAppcnEyMzogZWhjaTAgICAgICAgICAgICAgICAgICAgICAgICAgMjUz ICAgICAgICAgIDAKY3B1MDp0aW1lciAgICAgICAgICAgICAgICAgICAgICAgMzYwNzc1MSAg ICAgICA1MTMxCmNwdTE6dGltZXIgICAgICAgICAgICAgICAgICAgICAgIDI4MDY0OTAgICAg ICAgMzk5MgpUb3RhbCAgICAgICAgICAgICAgICAgICAgICAgICAgICA3MzA3MjE1ICAgICAg MTAzOTQKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpwc3RhdCAtVAoKIDEyLzgwNzIgZmlsZXMKM00v MTUzNU0gc3dhcCBzcGFjZQoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCnBzdGF0IC1zCgpEZXZpY2Ug ICAgICAgICAgMUstYmxvY2tzICAgICBVc2VkICAgIEF2YWlsIENhcGFjaXR5Ci9kZXYvYWRh MHMxYiAgICAgIDE1NzI3MzYgICAgIDQwNjQgIDE1Njg2NzIgICAgIDAlCgotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0KaW9zdGF0Cgppb3N0YXQ6IGt2bV9yZWFkKF90a19uaW4pOiBpbnZhbGlkIGFk ZHJlc3MgKDB4MCkKaW9zdGF0OiBkaXNhYmxpbmcgVFRZIHN0YXRpc3RpY3MKICAgICAgICAg ICAgYWRhMCAgICAgICAgICAgICAgZGEwICAgICAgICAgICAgICBjZDAgICAgICAgICAgICAg Y3B1CiAgS0IvdCB0cHMgIE1CL3MgICBLQi90IHRwcyAgTUIvcyAgIEtCL3QgdHBzICBNQi9z ICB1cyBuaSBzeSBpbiBpZAogMTkuNjMgMTUxICAyLjg5ICAgMS45MiAgIDAgIDAuMDAgICAw LjAwICAgMCAgMC4wMCAgIDcgIDAgIDEgIDAgOTIKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQppcGNz IC1hCgpNZXNzYWdlIFF1ZXVlczoKVCAgICAgICAgICAgSUQgICAgICAgICAgS0VZIE1PREUg ICAgICAgIE9XTkVSICAgIEdST1VQICAgIENSRUFUT1IgIENHUk9VUCAgICAgICAgICAgICAg ICAgQ0JZVEVTICAgICAgICAgICAgICAgICBRTlVNICAgICAgICAgICAgICAgUUJZVEVTICAg ICAgICBMU1BJRCAgICAgICAgTFJQSUQgU1RJTUUgICAgUlRJTUUgICAgQ1RJTUUgICAKClNo YXJlZCBNZW1vcnk6ClQgICAgICAgICAgIElEICAgICAgICAgIEtFWSBNT0RFICAgICAgICBP V05FUiAgICBHUk9VUCAgICBDUkVBVE9SICBDR1JPVVAgICAgICAgICBOQVRUQ0ggICAgICAg IFNFR1NaICAgICAgICAgQ1BJRCAgICAgICAgIExQSUQgQVRJTUUgICAgRFRJTUUgICAgQ1RJ TUUgICAKbSAgICAgICAzMjc2ODAgICAgICAgICAgICAwIC0tcnctLS0tLS0tIGRldmhjICAg IGRldmhjICAgIGRldmhjICAgIGRldmhjICAgICAgICAgICAgICAgMSAgICAgICAzOTMyMTYg ICAgICAgICAxNDAyICAgICAgICAgIDY0MSAxNToyODoyOCAxNzoyMjo0NiAxNToyODoyOApt ICAgICAgICA2NTUzNyAgICAgICAgICAgIDAgLS1ydy0tLS0tLS0gZGV2aGMgICAgZGV2aGMg ICAgZGV2aGMgICAgZGV2aGMgICAgICAgICAgICAgICAxICAgICAgIDM5MzIxNiAgICAgICAg ICA2OTMgICAgICAgICAgNjQxIDEwOjM4OjIxIDE3OjIyOjM3IDEwOjM4OjIxCm0gICAgICAg MTMxMDc0ICAgICAgICAgICAgMCAtLXJ3LS0tLS0tLSBkZXZoYyAgICBkZXZoYyAgICBkZXZo YyAgICBkZXZoYyAgICAgICAgICAgICAgIDEgICAgICAgMzkzMjE2ICAgICAgICAgMTQwMiAg ICAgICAgICA2NDEgMTU6Mjg6MjggMTc6MjI6NDYgMTU6Mjg6MjgKbSAgICAgICAxMzEwNzUg ICAgICAgICAgICAwIC0tcnctLS0tLS0tIGRldmhjICAgIGRldmhjICAgIGRldmhjICAgIGRl dmhjICAgICAgICAgICAgICAgMSAgICAgICAzOTMyMTYgICAgICAgICAxNDA5ICAgICAgICAg IDY0MSAxNToyODozMCAxNzoyMjo0NiAxNToyODozMAptICAgICAgIDI2MjE0OCAgICAgICAg ICAgIDAgLS1ydy0tLS0tLS0gZGV2aGMgICAgZGV2aGMgICAgZGV2aGMgICAgZGV2aGMgICAg ICAgICAgICAgICAxICAgICAgIDM5MzIxNiAgICAgICAgIDEzODkgICAgICAgICAgNjQxIDE1 OjI4OjAyIDE3OjIyOjM2IDE1OjI4OjAyCm0gICAgICAgMjYyMTQ5ICAgICAgICAgICAgMCAt LXJ3LS0tLS0tLSBkZXZoYyAgICBkZXZoYyAgICBkZXZoYyAgICBkZXZoYyAgICAgICAgICAg ICAgIDEgICAgICAgMzkzMjE2ICAgICAgICAgIDg3NCAgICAgICAgICA2NDEgMTI6MDQ6MTAg MTc6MjI6MzYgMTI6MDQ6MTAKbSAgICAgICAxMzEwNzggICAgICAgICAgICAwIC0tcnctLS0t LS0tIGRldmhjICAgIGRldmhjICAgIGRldmhjICAgIGRldmhjICAgICAgICAgICAgICAgMSAg ICAgICAzOTMyMTYgICAgICAgICAgNjkzICAgICAgICAgIDY0MSAxNTowODoxOCAxNzoyMjoz NyAxNTowODoxOAptICAgICAgIDE5NjYxNSAgICAgICAgICAgIDAgLS1ydy0tLS0tLS0gZGV2 aGMgICAgZGV2aGMgICAgZGV2aGMgICAgZGV2aGMgICAgICAgICAgICAgICAxICAgICAgIDM5 MzIxNiAgICAgICAgIDEzODkgICAgICAgICAgNjQxIDE1OjI4OjU0IDE3OjIyOjM2IDE1OjI4 OjU0Cm0gICAgICAgIDY1NTQ0ICAgICAgICAgICAgMCAtLXJ3LS0tLS0tLSBkZXZoYyAgICBk ZXZoYyAgICBkZXZoYyAgICBkZXZoYyAgICAgICAgICAgICAgIDEgICAgICAgMzkzMjE2ICAg ICAgICAgMTQwOSAgICAgICAgICA2NDEgMTU6MzA6MDkgMTc6MjI6NDYgMTU6MzA6MDkKbSAg ICAgICAxMzEwODEgICAgICAgICAgICAwIC0tcnctLS0tLS0tIGRldmhjICAgIGRldmhjICAg IGRldmhjICAgIGRldmhjICAgICAgICAgICAgICAgMSAgICAgICAzOTMyMTYgICAgICAgICAx NTA4ICAgICAgICAgIDY0MSAxNjoxMDowNSAxNzoyMjozNiAxNjoxMDowNQoKU2VtYXBob3Jl czoKVCAgICAgICAgICAgSUQgICAgICAgICAgS0VZIE1PREUgICAgICAgIE9XTkVSICAgIEdS T1VQICAgIENSRUFUT1IgIENHUk9VUCAgICAgICAgICBOU0VNUyBPVElNRSAgICBDVElNRSAg IAoKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQppcGNzIC1UCgptc2dpbmZvOgoJbXNnbWF4OiAgICAg ICAgMTYzODQJKG1heCBjaGFyYWN0ZXJzIGluIGEgbWVzc2FnZSkKCW1zZ21uaTogICAgICAg ICAgIDQwCSgjIG9mIG1lc3NhZ2UgcXVldWVzKQoJbXNnbW5iOiAgICAgICAgIDIwNDgJKG1h eCBjaGFyYWN0ZXJzIGluIGEgbWVzc2FnZSBxdWV1ZSkKCW1zZ3RxbDogICAgICAgICAgIDQw CShtYXggIyBvZiBtZXNzYWdlcyBpbiBzeXN0ZW0pCgltc2dzc3o6ICAgICAgICAgICAgOAko c2l6ZSBvZiBhIG1lc3NhZ2Ugc2VnbWVudCkKCW1zZ3NlZzogICAgICAgICAyMDQ4CSgjIG9m IG1lc3NhZ2Ugc2VnbWVudHMgaW4gc3lzdGVtKQoKc2htaW5mbzoKCXNobW1heDogICAgNTM2 ODcwOTEyCShtYXggc2hhcmVkIG1lbW9yeSBzZWdtZW50IHNpemUpCglzaG1taW46ICAgICAg ICAgICAgMQkobWluIHNoYXJlZCBtZW1vcnkgc2VnbWVudCBzaXplKQoJc2htbW5pOiAgICAg ICAgICAxOTIJKG1heCBudW1iZXIgb2Ygc2hhcmVkIG1lbW9yeSBpZGVudGlmaWVycykKCXNo bXNlZzogICAgICAgICAgMTI4CShtYXggc2hhcmVkIG1lbW9yeSBzZWdtZW50cyBwZXIgcHJv Y2VzcykKCXNobWFsbDogICAgICAgMTMxMDcyCShtYXggYW1vdW50IG9mIHNoYXJlZCBtZW1v cnkgaW4gcGFnZXMpCgpzZW1pbmZvOgoJc2VtbW5pOiAgICAgICAgICAgNTAJKCMgb2Ygc2Vt YXBob3JlIGlkZW50aWZpZXJzKQoJc2VtbW5zOiAgICAgICAgICAzNDAJKCMgb2Ygc2VtYXBo b3JlcyBpbiBzeXN0ZW0pCglzZW1tbnU6ICAgICAgICAgIDE1MAkoIyBvZiB1bmRvIHN0cnVj dHVyZXMgaW4gc3lzdGVtKQoJc2VtbXNsOiAgICAgICAgICAzNDAJKG1heCAjIG9mIHNlbWFw aG9yZXMgcGVyIGlkKQoJc2Vtb3BtOiAgICAgICAgICAxMDAJKG1heCAjIG9mIG9wZXJhdGlv bnMgcGVyIHNlbW9wIGNhbGwpCglzZW11bWU6ICAgICAgICAgICA1MAkobWF4ICMgb2YgdW5k byBlbnRyaWVzIHBlciBwcm9jZXNzKQoJc2VtdXN6OiAgICAgICAgICA2MTYJKHNpemUgaW4g Ynl0ZXMgb2YgdW5kbyBzdHJ1Y3R1cmUpCglzZW12bXg6ICAgICAgICAzMjc2Nwkoc2VtYXBo b3JlIG1heGltdW0gdmFsdWUpCglzZW1hZW06ICAgICAgICAxNjM4NAkoYWRqdXN0IG9uIGV4 aXQgbWF4IHZhbHVlKQoKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpuZnNzdGF0CgpuZnNzdGF0OiBu ZXcgY2xpZW50L3NlcnZlciBub3QgbG9hZGVkCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KbmV0c3Rh dCAtcwoKdGNwOgoJMTE2ODIwIHBhY2tldHMgc2VudAoJCTgwMTIgZGF0YSBwYWNrZXRzICgz OTgwODcwIGJ5dGVzKQoJCTIzNyBkYXRhIHBhY2tldHMgKDExNDgxMiBieXRlcykgcmV0cmFu c21pdHRlZAoJCTI1IGRhdGEgcGFja2V0cyB1bm5lY2Vzc2FyaWx5IHJldHJhbnNtaXR0ZWQK CQkwIHJlc2VuZHMgaW5pdGlhdGVkIGJ5IE1UVSBkaXNjb3ZlcnkKCQk3MTI5NiBhY2stb25s eSBwYWNrZXRzICg2NDU0IGRlbGF5ZWQpCgkJMCBVUkcgb25seSBwYWNrZXRzCgkJMCB3aW5k b3cgcHJvYmUgcGFja2V0cwoJCTMzODQxIHdpbmRvdyB1cGRhdGUgcGFja2V0cwoJCTM0MzQg Y29udHJvbCBwYWNrZXRzCgkxNDQyMTcgcGFja2V0cyByZWNlaXZlZAoJCTEwODg2IGFja3Mg KGZvciAzOTU0OTc2IGJ5dGVzKQoJCTE2MzYgZHVwbGljYXRlIGFja3MKCQkwIGFja3MgZm9y IHVuc2VudCBkYXRhCgkJMTEzNDkzIHBhY2tldHMgKDE1NTM5MzM3NCBieXRlcykgcmVjZWl2 ZWQgaW4tc2VxdWVuY2UKCQk0NDEgY29tcGxldGVseSBkdXBsaWNhdGUgcGFja2V0cyAoNDk2 NjU1IGJ5dGVzKQoJCTAgb2xkIGR1cGxpY2F0ZSBwYWNrZXRzCgkJNCBwYWNrZXRzIHdpdGgg c29tZSBkdXAuIGRhdGEgKDEyNzQgYnl0ZXMgZHVwZWQpCgkJMjMyNTMgb3V0LW9mLW9yZGVy IHBhY2tldHMgKDMyNzY5NjI5IGJ5dGVzKQoJCTAgcGFja2V0cyAoMCBieXRlcykgb2YgZGF0 YSBhZnRlciB3aW5kb3cKCQkwIHdpbmRvdyBwcm9iZXMKCQkxMjcgd2luZG93IHVwZGF0ZSBw YWNrZXRzCgkJODAgcGFja2V0cyByZWNlaXZlZCBhZnRlciBjbG9zZQoJCTEgZGlzY2FyZGVk IGZvciBiYWQgY2hlY2tzdW0KCQkwIGRpc2NhcmRlZCBmb3IgYmFkIGhlYWRlciBvZmZzZXQg ZmllbGRzCgkJMCBkaXNjYXJkZWQgYmVjYXVzZSBwYWNrZXQgdG9vIHNob3J0CgkJMCBkaXNj YXJkZWQgZHVlIHRvIG1lbW9yeSBwcm9ibGVtcwoJMTY0OCBjb25uZWN0aW9uIHJlcXVlc3Rz CgkwIGNvbm5lY3Rpb24gYWNjZXB0cwoJMCBiYWQgY29ubmVjdGlvbiBhdHRlbXB0cwoJMCBs aXN0ZW4gcXVldWUgb3ZlcmZsb3dzCgkwIGlnbm9yZWQgUlNUcyBpbiB0aGUgd2luZG93cwoJ MTY0OCBjb25uZWN0aW9ucyBlc3RhYmxpc2hlZCAoaW5jbHVkaW5nIGFjY2VwdHMpCgkxNjQ4 IGNvbm5lY3Rpb25zIGNsb3NlZCAoaW5jbHVkaW5nIDE1NyBkcm9wcykKCQk1ODIgY29ubmVj dGlvbnMgdXBkYXRlZCBjYWNoZWQgUlRUIG9uIGNsb3NlCgkJNjI2IGNvbm5lY3Rpb25zIHVw ZGF0ZWQgY2FjaGVkIFJUVCB2YXJpYW5jZSBvbiBjbG9zZQoJCTIxMyBjb25uZWN0aW9ucyB1 cGRhdGVkIGNhY2hlZCBzc3RocmVzaCBvbiBjbG9zZQoJMCBlbWJyeW9uaWMgY29ubmVjdGlv bnMgZHJvcHBlZAoJMTAyNzEgc2VnbWVudHMgdXBkYXRlZCBydHQgKG9mIDk4NTEgYXR0ZW1w dHMpCgkxOTQ1IHJldHJhbnNtaXQgdGltZW91dHMKCQkxNDcgY29ubmVjdGlvbnMgZHJvcHBl ZCBieSByZXhtaXQgdGltZW91dAoJMCBwZXJzaXN0IHRpbWVvdXRzCgkJMCBjb25uZWN0aW9u cyBkcm9wcGVkIGJ5IHBlcnNpc3QgdGltZW91dAoJMCBDb25uZWN0aW9ucyAoZmluX3dhaXRf MikgZHJvcHBlZCBiZWNhdXNlIG9mIHRpbWVvdXQKCTAga2VlcGFsaXZlIHRpbWVvdXRzCgkJ MCBrZWVwYWxpdmUgcHJvYmVzIHNlbnQKCQkwIGNvbm5lY3Rpb25zIGRyb3BwZWQgYnkga2Vl cGFsaXZlCgk2MTMgY29ycmVjdCBBQ0sgaGVhZGVyIHByZWRpY3Rpb25zCgkxMDcyMzIgY29y cmVjdCBkYXRhIHBhY2tldCBoZWFkZXIgcHJlZGljdGlvbnMKCTAgc3luY2FjaGUgZW50cmll cyBhZGRlZAoJCTAgcmV0cmFuc21pdHRlZAoJCTAgZHVwc3luCgkJMCBkcm9wcGVkCgkJMCBj b21wbGV0ZWQKCQkwIGJ1Y2tldCBvdmVyZmxvdwoJCTAgY2FjaGUgb3ZlcmZsb3cKCQkwIHJl c2V0CgkJMCBzdGFsZQoJCTAgYWJvcnRlZAoJCTAgYmFkYWNrCgkJMCB1bnJlYWNoCgkJMCB6 b25lIGZhaWx1cmVzCgkwIGNvb2tpZXMgc2VudAoJMCBjb29raWVzIHJlY2VpdmVkCgk3MiBo b3N0Y2FjaGUgZW50cmllcyBhZGRlZAoJCTAgYnVja2V0IG92ZXJmbG93Cgk2IFNBQ0sgcmVj b3ZlcnkgZXBpc29kZXMKCTMgc2VnbWVudCByZXhtaXRzIGluIFNBQ0sgcmVjb3ZlcnkgZXBp c29kZXMKCTM1MzkgYnl0ZSByZXhtaXRzIGluIFNBQ0sgcmVjb3ZlcnkgZXBpc29kZXMKCTU1 IFNBQ0sgb3B0aW9ucyAoU0FDSyBibG9ja3MpIHJlY2VpdmVkCgkyMDI2NyBTQUNLIG9wdGlv bnMgKFNBQ0sgYmxvY2tzKSBzZW50CgkwIFNBQ0sgc2NvcmVib2FyZCBvdmVyZmxvdwoJMCBw YWNrZXRzIHdpdGggRUNOIENFIGJpdCBzZXQKCTAgcGFja2V0cyB3aXRoIEVDTiBFQ1QoMCkg Yml0IHNldAoJMCBwYWNrZXRzIHdpdGggRUNOIEVDVCgxKSBiaXQgc2V0CgkwIHN1Y2Nlc3Nm dWwgRUNOIGhhbmRzaGFrZXMKCTAgdGltZXMgRUNOIHJlZHVjZWQgdGhlIGNvbmdlc3Rpb24g d2luZG93CnVkcDoKCTEyNDMgZGF0YWdyYW1zIHJlY2VpdmVkCgkwIHdpdGggaW5jb21wbGV0 ZSBoZWFkZXIKCTAgd2l0aCBiYWQgZGF0YSBsZW5ndGggZmllbGQKCTAgd2l0aCBiYWQgY2hl Y2tzdW0KCTAgd2l0aCBubyBjaGVja3N1bQoJMCBkcm9wcGVkIGR1ZSB0byBubyBzb2NrZXQK CTg0MyBicm9hZGNhc3QvbXVsdGljYXN0IGRhdGFncmFtcyB1bmRlbGl2ZXJlZAoJMCBkcm9w cGVkIGR1ZSB0byBmdWxsIHNvY2tldCBidWZmZXJzCgkwIG5vdCBmb3IgaGFzaGVkIHBjYgoJ NDAwIGRlbGl2ZXJlZAoJNDEzIGRhdGFncmFtcyBvdXRwdXQKCTAgdGltZXMgbXVsdGljYXN0 IHNvdXJjZSBmaWx0ZXIgbWF0Y2hlZAppcDoKCTE0NTQ2MyB0b3RhbCBwYWNrZXRzIHJlY2Vp dmVkCgkzIGJhZCBoZWFkZXIgY2hlY2tzdW1zCgkwIHdpdGggc2l6ZSBzbWFsbGVyIHRoYW4g bWluaW11bQoJMCB3aXRoIGRhdGEgc2l6ZSA8IGRhdGEgbGVuZ3RoCgkwIHdpdGggaXAgbGVu Z3RoID4gbWF4IGlwIHBhY2tldCBzaXplCgkwIHdpdGggaGVhZGVyIGxlbmd0aCA8IGRhdGEg c2l6ZQoJMCB3aXRoIGRhdGEgbGVuZ3RoIDwgaGVhZGVyIGxlbmd0aAoJMCB3aXRoIGJhZCBv cHRpb25zCgkwIHdpdGggaW5jb3JyZWN0IHZlcnNpb24gbnVtYmVyCgkwIGZyYWdtZW50cyBy ZWNlaXZlZAoJMCBmcmFnbWVudHMgZHJvcHBlZCAoZHVwIG9yIG91dCBvZiBzcGFjZSkKCTAg ZnJhZ21lbnRzIGRyb3BwZWQgYWZ0ZXIgdGltZW91dAoJMCBwYWNrZXRzIHJlYXNzZW1ibGVk IG9rCgkxNDU0NjAgcGFja2V0cyBmb3IgdGhpcyBob3N0CgkwIHBhY2tldHMgZm9yIHVua25v d24vdW5zdXBwb3J0ZWQgcHJvdG9jb2wKCTAgcGFja2V0cyBmb3J3YXJkZWQgKDAgcGFja2V0 cyBmYXN0IGZvcndhcmRlZCkKCTAgcGFja2V0cyBub3QgZm9yd2FyZGFibGUKCTAgcGFja2V0 cyByZWNlaXZlZCBmb3IgdW5rbm93biBtdWx0aWNhc3QgZ3JvdXAKCTAgcmVkaXJlY3RzIHNl bnQKCTExNzczMiBwYWNrZXRzIHNlbnQgZnJvbSB0aGlzIGhvc3QKCTAgcGFja2V0cyBzZW50 IHdpdGggZmFicmljYXRlZCBpcCBoZWFkZXIKCTAgb3V0cHV0IHBhY2tldHMgZHJvcHBlZCBk dWUgdG8gbm8gYnVmcywgZXRjLgoJMCBvdXRwdXQgcGFja2V0cyBkaXNjYXJkZWQgZHVlIHRv IG5vIHJvdXRlCgkwIG91dHB1dCBkYXRhZ3JhbXMgZnJhZ21lbnRlZAoJMCBmcmFnbWVudHMg Y3JlYXRlZAoJMCBkYXRhZ3JhbXMgdGhhdCBjYW4ndCBiZSBmcmFnbWVudGVkCgkwIHR1bm5l bGluZyBwYWNrZXRzIHRoYXQgY2FuJ3QgZmluZCBnaWYKCTAgZGF0YWdyYW1zIHdpdGggYmFk IGFkZHJlc3MgaW4gaGVhZGVyCmljbXA6CgkwIGNhbGxzIHRvIGljbXBfZXJyb3IKCTAgZXJy b3JzIG5vdCBnZW5lcmF0ZWQgaW4gcmVzcG9uc2UgdG8gYW4gaWNtcCBtZXNzYWdlCgkwIG1l c3NhZ2VzIHdpdGggYmFkIGNvZGUgZmllbGRzCgkwIG1lc3NhZ2VzIGxlc3MgdGhhbiB0aGUg bWluaW11bSBsZW5ndGgKCTAgbWVzc2FnZXMgd2l0aCBiYWQgY2hlY2tzdW0KCTAgbWVzc2Fn ZXMgd2l0aCBiYWQgbGVuZ3RoCgkwIG11bHRpY2FzdCBlY2hvIHJlcXVlc3RzIGlnbm9yZWQK CTAgbXVsdGljYXN0IHRpbWVzdGFtcCByZXF1ZXN0cyBpZ25vcmVkCgkwIG1lc3NhZ2UgcmVz cG9uc2VzIGdlbmVyYXRlZAoJMCBpbnZhbGlkIHJldHVybiBhZGRyZXNzZXMKCTAgbm8gcmV0 dXJuIHJvdXRlcwppZ21wOgoJMCBtZXNzYWdlcyByZWNlaXZlZAoJMCBtZXNzYWdlcyByZWNl aXZlZCB3aXRoIHRvbyBmZXcgYnl0ZXMKCTAgbWVzc2FnZXMgcmVjZWl2ZWQgd2l0aCB3cm9u ZyBUVEwKCTAgbWVzc2FnZXMgcmVjZWl2ZWQgd2l0aCBiYWQgY2hlY2tzdW0KCTAgVjEvVjIg bWVtYmVyc2hpcCBxdWVyaWVzIHJlY2VpdmVkCgkwIFYzIG1lbWJlcnNoaXAgcXVlcmllcyBy ZWNlaXZlZAoJMCBtZW1iZXJzaGlwIHF1ZXJpZXMgcmVjZWl2ZWQgd2l0aCBpbnZhbGlkIGZp ZWxkKHMpCgkwIGdlbmVyYWwgcXVlcmllcyByZWNlaXZlZAoJMCBncm91cCBxdWVyaWVzIHJl Y2VpdmVkCgkwIGdyb3VwLXNvdXJjZSBxdWVyaWVzIHJlY2VpdmVkCgkwIGdyb3VwLXNvdXJj ZSBxdWVyaWVzIGRyb3BwZWQKCTAgbWVtYmVyc2hpcCByZXBvcnRzIHJlY2VpdmVkCgkwIG1l bWJlcnNoaXAgcmVwb3J0cyByZWNlaXZlZCB3aXRoIGludmFsaWQgZmllbGQocykKCTAgbWVt YmVyc2hpcCByZXBvcnRzIHJlY2VpdmVkIGZvciBncm91cHMgdG8gd2hpY2ggd2UgYmVsb25n CgkwIFYzIHJlcG9ydHMgcmVjZWl2ZWQgd2l0aG91dCBSb3V0ZXIgQWxlcnQKCTAgbWVtYmVy c2hpcCByZXBvcnRzIHNlbnQKYXJwOgoJMiBBUlAgcmVxdWVzdHMgc2VudAoJMjYgQVJQIHJl cGxpZXMgc2VudAoJMjYwIEFSUCByZXF1ZXN0cyByZWNlaXZlZAoJMSBBUlAgcmVwbHkgcmVj ZWl2ZWQKCTI2MSBBUlAgcGFja2V0cyByZWNlaXZlZAoJMCB0b3RhbCBwYWNrZXRzIGRyb3Bw ZWQgZHVlIHRvIG5vIEFSUCBlbnRyeQoJMCBBUlAgZW50cnlzIHRpbWVkIG91dAoJMCBEdXBs aWNhdGUgSVBzIHNlZW4KCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpuZXRzdGF0IC1tCgoyNjgvMTAz NC8xMzAyIG1idWZzIGluIHVzZSAoY3VycmVudC9jYWNoZS90b3RhbCkKMTg0NDY3NDQwNzM3 MDk1NTE2MDUvODc1Lzg2NC8xNzA4OCBtYnVmIGNsdXN0ZXJzIGluIHVzZSAoY3VycmVudC9j YWNoZS90b3RhbC9tYXgpCjI1Ni81MjMgbWJ1ZitjbHVzdGVycyBvdXQgb2YgcGFja2V0IHNl Y29uZGFyeSB6b25lIGluIHVzZSAoY3VycmVudC9jYWNoZSkKNy8xNjkvMTc2Lzg1NDQgNGsg KHBhZ2Ugc2l6ZSkganVtYm8gY2x1c3RlcnMgaW4gdXNlIChjdXJyZW50L2NhY2hlL3RvdGFs L21heCkKMC8wLzAvMTI4MTYgOWsganVtYm8gY2x1c3RlcnMgaW4gdXNlIChjdXJyZW50L2Nh Y2hlL3RvdGFsL21heCkKMC8wLzAvODU0NCAxNmsganVtYm8gY2x1c3RlcnMgaW4gdXNlIChj dXJyZW50L2NhY2hlL3RvdGFsL21heCkKNzNLLzI2ODRLLzI3NTdLIGJ5dGVzIGFsbG9jYXRl ZCB0byBuZXR3b3JrIChjdXJyZW50L2NhY2hlL3RvdGFsKQowLzAvMCByZXF1ZXN0cyBmb3Ig bWJ1ZnMgZGVuaWVkIChtYnVmcy9jbHVzdGVycy9tYnVmK2NsdXN0ZXJzKQowLzAvMCByZXF1 ZXN0cyBmb3IganVtYm8gY2x1c3RlcnMgZGVuaWVkICg0ay85ay8xNmspCjAgcmVxdWVzdHMg Zm9yIHNmYnVmcyBkZW5pZWQKMCByZXF1ZXN0cyBmb3Igc2ZidWZzIGRlbGF5ZWQKMCByZXF1 ZXN0cyBmb3IgSS9PIGluaXRpYXRlZCBieSBzZW5kZmlsZQowIGNhbGxzIHRvIHByb3RvY29s IGRyYWluIHJvdXRpbmVzCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KbmV0c3RhdCAtaWQKCk5hbWUg ICAgTXR1IE5ldHdvcmsgICAgICAgQWRkcmVzcyAgICAgICAgICAgICAgSXBrdHMgSWVycnMg SWRyb3AgICAgT3BrdHMgT2VycnMgIENvbGwgRHJvcAp1c2J1cyAgICAgMCA8TGluayMxPiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwICAgICAwICAgICAwICAgICAgICAwICAg ICAwICAgICAwICAgIDAgCnVzYnVzICAgICAwIDxMaW5rIzI+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDAgICAgIDAgICAgIDAgICAgICAgIDAgICAgIDAgICAgIDAgICAgMCAK dXNidXMgICAgIDAgPExpbmsjMz4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMCAg ICAgMCAgICAgMCAgICAgICAgMCAgICAgMCAgICAgMCAgICAwIApzazAgICAgMTUwMCA8TGlu ayM0PiAgICAgIDAwOjBlOmE2OjM1OjE1OjkxICAgMTQ1NzI0ICAgICAwICAgICAwICAgMTE3 NzcyICAgICAwICAgICAwICAgIDAgCnNrMCAgICAxNTAwIDE5Mi4xNjguMS4wICAgMTkyLjE2 OC4xLjgwICAgICAgICAxNDUzODQgICAgIC0gICAgIC0gICAxMTc3MzYgICAgIC0gICAgIC0g ICAgLSAKbG8wICAgMTYzODQgPExpbmsjNT4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgMCAgICAgMCAgICAgMCAgICAgICAgMCAgICAgMCAgICAgMCAgICAwIApsbzAgICAxNjM4 NCB5b3VyLW5ldCAgICAgIGxvY2FsaG9zdCAgICAgICAgICAgICAgICAwICAgICAtICAgICAt ICAgICAgICAwICAgICAtICAgICAtICAgIC0gCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KbmV0c3Rh dCAtYW5yCgpSb3V0aW5nIHRhYmxlcwoKSW50ZXJuZXQ6CkRlc3RpbmF0aW9uICAgICAgICBH YXRld2F5ICAgICAgICAgICAgRmxhZ3MgICAgUmVmcyAgICAgIFVzZSAgTmV0aWYgRXhwaXJl CmRlZmF1bHQgICAgICAgICAgICAxOTIuMTY4LjEuMSAgICAgICAgVUdTICAgICAgICAgMCAg IDExNzc0MyAgICBzazAKMTI3LjAuMC4xICAgICAgICAgIGxpbmsjNSAgICAgICAgICAgICBV SCAgICAgICAgICAwICAgICAgICAwICAgIGxvMAoxOTIuMTY4LjEuMC8yNCAgICAgbGluayM0 ICAgICAgICAgICAgIFUgICAgICAgICAgIDAgICAgICAgIDEgICAgc2swCjE5Mi4xNjguMS44 MCAgICAgICBsaW5rIzQgICAgICAgICAgICAgVUhTICAgICAgICAgMCAgICAgICAgMCAgICBs bzAKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpuZXRzdGF0IC1hbkEKCkFjdGl2ZSBJbnRlcm5ldCBj b25uZWN0aW9ucyAoaW5jbHVkaW5nIHNlcnZlcnMpClRjcGNiICAgIFByb3RvIFJlY3YtUSBT ZW5kLVEgTG9jYWwgQWRkcmVzcyAgICAgIEZvcmVpZ24gQWRkcmVzcyAgICAoc3RhdGUpCmM0 M2E0NTYwIHRjcDQgICAgICAgMCAgICAgIDAgMTkyLjE2OC4xLjgwLjI4ODgyIDc0LjgxLjE3 NS4yMC4zNjkwICBGSU5fV0FJVF8xCmMzZmJhNDEwIHRjcDQgICAgICAgMCAgICAgIDAgMTky LjE2OC4xLjgwLjE0NjgwIDIwOC42OC4xNjMuMjIwLjUyMiBUSU1FX1dBSVQKYzNmYmE0NDQg dGNwNCAgICAgICAwICAgICAgMCAxOTIuMTY4LjEuODAuMTQ3ODIgMTMwLjIzNy4xODguMjAw LjY2IFRJTUVfV0FJVApBY3RpdmUgVU5JWCBkb21haW4gc29ja2V0cwpBZGRyZXNzICBUeXBl ICAgUmVjdi1RIFNlbmQtUSAgICBJbm9kZSAgICAgQ29ubiAgICAgUmVmcyAgTmV4dHJlZiBB ZGRyCmM0MDJiYzE4IHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwICAgICAgICAwICAg ICAgICAwICAgICAgICAwIC90bXAvLlgxMS11bml4L1gwCmM0ZGMzMTU4IHN0cmVhbSAgICA1 MDQgICAgICAwICAgICAgICAwICAgICAgICAwICAgICAgICAwICAgICAgICAwIC90bXAvLlgx MS11bml4L1gwCmM0MDJiZWM4IHN0cmVhbSAgIDgxOTIgICAgICAwICAgICAgICAwICAgICAg ICAwICAgICAgICAwICAgICAgICAwIC90bXAvLlgxMS11bml4L1gwCmM0ZGMzMDAwIHN0cmVh bSAgIDgxOTIgICAgICAwICAgICAgICAwICAgICAgICAwICAgICAgICAwICAgICAgICAwIC90 bXAvLlgxMS11bml4L1gwCmMzOTg5MjA0IHN0cmVhbSAgIDgxMzYgICAgICAwICAgICAgICAw ICAgICAgICAwICAgICAgICAwICAgICAgICAwIC90bXAvLlgxMS11bml4L1gwCmMzOGM0ZTFj IHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwICAgICAgICAwICAgICAgICAwICAgICAg ICAwIC90bXAvLlgxMS11bml4L1gwCmMzOGM1ODEwIHN0cmVhbSAgICAgIDAgICAgICAwICAg ICAgICAwICAgICAgICAwICAgICAgICAwICAgICAgICAwIC90bXAvLlgxMS11bml4L1gwCmMz OGM0MDAwIHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwICAgICAgICAwICAgICAgICAw ICAgICAgICAwIC90bXAvLlgxMS11bml4L1gwCmMzOGM0NmI4IHN0cmVhbSAgICAgIDAgICAg ICAwICAgICAgICAwICAgICAgICAwICAgICAgICAwICAgICAgICAwIC90bXAvLlgxMS11bml4 L1gwCmMzOGM1Y2M0IHN0cmVhbSAgICAgMTIgICAgICAwICAgICAgICAwICAgICAgICAwICAg ICAgICAwICAgICAgICAwIC90bXAvLlgxMS11bml4L1gwCgotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K bmV0c3RhdCAtYUwKCkN1cnJlbnQgbGlzdGVuIHF1ZXVlIHNpemVzIChxbGVuL2luY3FsZW4v bWF4cWxlbikKUHJvdG8gTGlzdGVuICAgICAgICAgTG9jYWwgQWRkcmVzcyAgICAgICAgIAoK LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tCmZzdGF0CgpVU0VSICAgICBDTUQgICAgICAgICAgUElEICAg RkQgTU9VTlQgICAgICBJTlVNIE1PREUgICAgICAgICBTWnxEViBSL1cKcm9vdCAgICAgWG9y ZyAgICAgICAgIDY0MSByb290IC0gICAgICAgICAtICAgICAgICAgYmFkICAgIC0Kcm9vdCAg ICAgWG9yZyAgICAgICAgIDY0MSAgIHdkIC0gICAgICAgICAtICAgICAgICAgYmFkICAgIC0K cm9vdCAgICAgWG9yZyAgICAgICAgIDY0MSB0ZXh0IC0gICAgICAgICAtICAgICAgICAgYmFk ICAgIC0Kcm9vdCAgICAgWG9yZyAgICAgICAgIDY0MSAgIDEwIC9kZXYgICAgICAgICA5OCBj cnctci0tci0tICAgIHVtczAgcncKcm9vdCAgICAgWG9yZyAgICAgICAgIDY0MSAgIDExKiBs b2NhbCBzdHJlYW0gYzM4YzVjYzQKcm9vdCAgICAgWG9yZyAgICAgICAgIDY0MSAgIDEyKiBs b2NhbCBzdHJlYW0gYzM4YzQ2YjgKcm9vdCAgICAgWG9yZyAgICAgICAgIDY0MSAgIDEzKiBs b2NhbCBzdHJlYW0gYzRkYzMwMDAKcm9vdCAgICAgWG9yZyAgICAgICAgIDY0MSAgIDE0KiBs b2NhbCBzdHJlYW0gYzM4YzQwMDAKcm9vdCAgICAgWG9yZyAgICAgICAgIDY0MSAgIDE1KiBs b2NhbCBzdHJlYW0gYzM4YzU4MTAKcm9vdCAgICAgWG9yZyAgICAgICAgIDY0MSAgIDE2KiBs b2NhbCBzdHJlYW0gYzM4YzRlMWMKcm9vdCAgICAgWG9yZyAgICAgICAgIDY0MSAgIDE3KiBs b2NhbCBzdHJlYW0gYzQwMmJlYzgKcm9vdCAgICAgWG9yZyAgICAgICAgIDY0MSAgIDE4KiBs b2NhbCBzdHJlYW0gYzRkYzMxNTgKcm9vdCAgICAgWG9yZyAgICAgICAgIDY0MSAgIDE5KiBs b2NhbCBzdHJlYW0gYzM5ODkyMDQKcm9vdCAgICAgWG9yZyAgICAgICAgIDY0MSAgIDIwKiBs b2NhbCBzdHJlYW0gYzQwMmJjMTgKcm9vdCAgICAgaW5pdCAgICAgICAgICAgMSByb290IC0g ICAgICAgICAtICAgICAgICAgYmFkICAgIC0Kcm9vdCAgICAgaW5pdCAgICAgICAgICAgMSAg IHdkIC0gICAgICAgICAtICAgICAgICAgYmFkICAgIC0Kcm9vdCAgICAgaW5pdCAgICAgICAg ICAgMSB0ZXh0IC0gICAgICAgICAtICAgICAgICAgYmFkICAgIC0Kcm9vdCAgICAga2VybmVs ICAgICAgICAgMCByb290IC0gICAgICAgICAtICAgICAgICAgYmFkICAgIC0Kcm9vdCAgICAg a2VybmVsICAgICAgICAgMCAgIHdkIC0gICAgICAgICAtICAgICAgICAgYmFkICAgIC0KCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQpkbWVzZwoKQ29weXJpZ2h0IChjKSAxOTkyLTIwMTIgVGhlIEZy ZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChjKSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAx OTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAxOTk0CglUaGUgUmVnZW50cyBvZiB0aGUg VW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmlnaHRzIHJlc2VydmVkLgpGcmVlQlNE IGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZyZWVCU0QgRm91bmRhdGlvbi4K RnJlZUJTRCAxMC4wLUNVUlJFTlQgIzAgcjIzNTUwME06IFdlZCBNYXkgMTYgMTM6MjA6Mzgg Q0VTVCAyMDEyCiAgICByb290QDovdXNyL29iai91c3Ivc3JjL3N5cy9IUSBpMzg2CkNQVTog SW50ZWwoUikgUGVudGl1bShSKSA0IENQVSAyLjgwR0h6ICgyNzk4LjcyLU1IeiA2ODYtY2xh c3MgQ1BVKQogIE9yaWdpbiA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4ZjI5ICBGYW1pbHkg PSBmICBNb2RlbCA9IDIgIFN0ZXBwaW5nID0gOQogIEZlYXR1cmVzPTB4YmZlYmZiZmY8RlBV LFZNRSxERSxQU0UsVFNDLE1TUixQQUUsTUNFLENYOCxBUElDLFNFUCxNVFJSLFBHRSxNQ0Es Q01PVixQQVQsUFNFMzYsQ0xGTFVTSCxEVFMsQUNQSSxNTVgsRlhTUixTU0UsU1NFMixTUyxI VFQsVE0sUEJFPgogIEZlYXR1cmVzMj0weDQ0MDA8Q05YVC1JRCx4VFBSPgpyZWFsIG1lbW9y eSAgPSA1MzY4NzA5MTIgKDUxMiBNQikKYXZhaWwgbWVtb3J5ID0gNTE0MDQzOTA0ICg0OTAg TUIpCkV2ZW50IHRpbWVyICJMQVBJQyIgcXVhbGl0eSA0MDAKQUNQSSBBUElDIFRhYmxlOiA8 QSBNIEkgIE9FTUFQSUMgPgpGcmVlQlNEL1NNUDogTXVsdGlwcm9jZXNzb3IgU3lzdGVtIERl dGVjdGVkOiAyIENQVXMKRnJlZUJTRC9TTVA6IDEgcGFja2FnZShzKSB4IDEgY29yZShzKSB4 IDIgSFRUIHRocmVhZHMKIGNwdTAgKEJTUCk6IEFQSUMgSUQ6ICAwCiBjcHUxIChBUC9IVCk6 IEFQSUMgSUQ6ICAxCmlvYXBpYzAgPFZlcnNpb24gMi4wPiBpcnFzIDAtMjMgb24gbW90aGVy Ym9hcmQKYWNwaTA6IDxBIE0gSSBPRU1YU0RUPiBvbiBtb3RoZXJib2FyZAphY3BpMDogUG93 ZXIgQnV0dG9uIChmaXhlZCkKYWNwaTA6IHJlc2VydmF0aW9uIG9mIDAsIGEwMDAwICgzKSBm YWlsZWQKYWNwaTA6IHJlc2VydmF0aW9uIG9mIDEwMDAwMCwgMWZlZjAwMDAgKDMpIGZhaWxl ZApkcml2ZXIgYnVnOiBVbmFibGUgdG8gc2V0IGRldmNsYXNzIChjbGFzczogYWNwaV9zeXNy ZXNvdXJjZSBkZXZuYW1lOiAodW5rbm93bikpCmRyaXZlciBidWc6IFVuYWJsZSB0byBzZXQg ZGV2Y2xhc3MgKGNsYXNzOiBhY3BpX3RpbWVyIGRldm5hbWU6ICh1bmtub3duKSkKY3B1MDog PEFDUEkgQ1BVPiBvbiBhY3BpMApkcml2ZXIgYnVnOiBVbmFibGUgdG8gc2V0IGRldmNsYXNz IChjbGFzczogYWNwaV9zeXNyZXNvdXJjZSBkZXZuYW1lOiAodW5rbm93bikpCmNwdTE6IDxB Q1BJIENQVT4gb24gYWNwaTAKYXR0aW1lcjA6IDxBVCB0aW1lcj4gcG9ydCAweDQwLTB4NDMg aXJxIDAgb24gYWNwaTAKVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBI eiBxdWFsaXR5IDAKRXZlbnQgdGltZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBx dWFsaXR5IDEwMAphdHJ0YzA6IDxBVCByZWFsdGltZSBjbG9jaz4gcG9ydCAweDcwLTB4NzEg aXJxIDggb24gYWNwaTAKRXZlbnQgdGltZXIgIlJUQyIgZnJlcXVlbmN5IDMyNzY4IEh6IHF1 YWxpdHkgMApUaW1lY291bnRlciAiQUNQSS1mYXN0IiBmcmVxdWVuY3kgMzU3OTU0NSBIeiBx dWFsaXR5IDkwMAphY3BpX3RpbWVyMDogPDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0NU1Iej4g cG9ydCAweDgwOC0weDgwYiBvbiBhY3BpMApwY2liMDogPEFDUEkgSG9zdC1QQ0kgYnJpZGdl PiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkwCnBjaTA6IDxBQ1BJIFBDSSBidXM+IG9uIHBj aWIwCmFncDA6IDxJbnRlbCA4Mjg2NSBob3N0IHRvIEFHUCBicmlkZ2U+IG9uIGhvc3RiMApw Y2liMTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAxLjAgb24gcGNpMApwY2li MTogZmFpbGVkIHRvIGFsbG9jYXRlIGluaXRpYWwgcHJlZmV0Y2ggd2luZG93OiAweGMwMDAw MDAwLTB4ZmFmZmZmZmYKcGNpMTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjEKdmdhcGNpMDog PFZHQS1jb21wYXRpYmxlIGRpc3BsYXk+IHBvcnQgMHhkMDAwLTB4ZDBmZiBtZW0gMHhjMDAw MDAwMC0weGNmZmZmZmZmLDB4ZmJlZTAwMDAtMHhmYmVlZmZmZiBpcnEgMTYgYXQgZGV2aWNl IDAuMCBvbiBwY2kxCmRybTA6IDxBVEkgUmFkZW9uIEFQIDk2MDA+IG9uIHZnYXBjaTAKaW5m bzogW2RybV0gQUdQIGF0IDB4ZTAwMDAwMDAgMjU2TUIKaW5mbzogW2RybV0gSW5pdGlhbGl6 ZWQgcmFkZW9uIDEuMzEuMCAyMDA4MDYxMwp2Z2FwY2kxOiA8VkdBLWNvbXBhdGlibGUgZGlz cGxheT4gbWVtIDB4ZDAwMDAwMDAtMHhkZmZmZmZmZiwweGZiZWYwMDAwLTB4ZmJlZmZmZmYg YXQgZGV2aWNlIDAuMSBvbiBwY2kxCnVoY2kwOiA8SW50ZWwgODI4MDFFQiAoSUNINSkgVVNC IGNvbnRyb2xsZXIgVVNCLUE+IHBvcnQgMHhjODgwLTB4Yzg5ZiBpcnEgMTYgYXQgZGV2aWNl IDI5LjAgb24gcGNpMAp1c2J1czAgb24gdWhjaTAKdWhjaTE6IDxJbnRlbCA4MjgwMUVCIChJ Q0g1KSBVU0IgY29udHJvbGxlciBVU0ItQj4gcG9ydCAweGNjMDAtMHhjYzFmIGlycSAxOSBh dCBkZXZpY2UgMjkuMSBvbiBwY2kwCnVzYnVzMSBvbiB1aGNpMQplaGNpMDogPEludGVsIDgy ODAxRUIvUiAoSUNINSkgVVNCIDIuMCBjb250cm9sbGVyPiBtZW0gMHhmYmRmZmMwMC0weGZi ZGZmZmZmIGlycSAyMyBhdCBkZXZpY2UgMjkuNyBvbiBwY2kwCnVzYnVzMjogRUhDSSB2ZXJz aW9uIDEuMAp1c2J1czIgb24gZWhjaTAKcGNpYjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBh dCBkZXZpY2UgMzAuMCBvbiBwY2kwCnBjaTI6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIyCnNr YzA6IDwzQ29tIDNDOTQwIEdpZ2FiaXQgRXRoZXJuZXQ+IHBvcnQgMHhlODAwLTB4ZThmZiBt ZW0gMHhmYmZmYzAwMC0weGZiZmZmZmZmIGlycSAyMiBhdCBkZXZpY2UgNS4wIG9uIHBjaTIK c2tjMDogM0NvbSBHaWdhYml0IExPTSAoM0M5NDApIHJldi4gKDB4MSkKc2swOiA8TWFydmVs bCBTZW1pY29uZHVjdG9yLCBJbmMuIFl1a29uPiBvbiBza2MwCnNrMDogRXRoZXJuZXQgYWRk cmVzczogMDA6MGU6YTY6MzU6MTU6OTEKbWlpYnVzMDogPE1JSSBidXM+IG9uIHNrMAplMTAw MHBoeTA6IDxNYXJ2ZWxsIDg4RTEwMTEgR2lnYWJpdCBQSFk+IFBIWSAwIG9uIG1paWJ1czAK ZTEwMDBwaHkwOiAgbm9uZSwgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAw YmFzZVRYLUZEWCwgMTAwMGJhc2VULCAxMDAwYmFzZVQtbWFzdGVyLCAxMDAwYmFzZVQtRkRY LCAxMDAwYmFzZVQtRkRYLW1hc3RlciwgYXV0bwpwY20wOiA8Q3JlYXRpdmUgQ1Q1ODgwLUU+ IHBvcnQgMHhlYzAwLTB4ZWMzZiBpcnEgMjAgYXQgZGV2aWNlIDEyLjAgb24gcGNpMgpwY20w OiA8ZU1pY3JvIEVNMjgwMjggQUM5NyBDb2RlYz4KcGNtMDogPFBsYXliYWNrOiBEQUMxLERB QzIgLyBSZWNvcmQ6IEFEQz4KaXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNlIDMx LjAgb24gcGNpMAppc2EwOiA8SVNBIGJ1cz4gb24gaXNhYjAKYXRhcGNpMDogPEludGVsIElD SDUgVURNQTEwMCBjb250cm9sbGVyPiBwb3J0IDB4MWYwLTB4MWY3LDB4M2Y2LDB4MTcwLTB4 MTc3LDB4Mzc2LDB4ZmMwMC0weGZjMGYgYXQgZGV2aWNlIDMxLjEgb24gcGNpMAphdGEwOiA8 QVRBIGNoYW5uZWw+IGF0IGNoYW5uZWwgMCBvbiBhdGFwY2kwCmF0YTE6IDxBVEEgY2hhbm5l bD4gYXQgY2hhbm5lbCAxIG9uIGF0YXBjaTAKcGNpMDogPHNlcmlhbCBidXMsIFNNQnVzPiBh dCBkZXZpY2UgMzEuMyAobm8gZHJpdmVyIGF0dGFjaGVkKQphY3BpX2J1dHRvbjA6IDxQb3dl ciBCdXR0b24+IG9uIGFjcGkwCmF0a2JkYzA6IDxLZXlib2FyZCBjb250cm9sbGVyIChpODA0 Mik+IHBvcnQgMHg2MCwweDY0IGlycSAxIG9uIGFjcGkwCmF0a2JkMDogPEFUIEtleWJvYXJk PiBpcnEgMSBvbiBhdGtiZGMwCmtiZDAgYXQgYXRrYmQwCmF0a2JkMDogW0dJQU5ULUxPQ0tF RF0KcG10aW1lcjAgb24gaXNhMApvcm0wOiA8SVNBIE9wdGlvbiBST00+IGF0IGlvbWVtIDB4 YzAwMDAtMHhjY2ZmZiBwbnBpZCBPUk0wMDAwIG9uIGlzYTAKc2MwOiA8U3lzdGVtIGNvbnNv bGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTAKc2MwOiBWR0EgPDE2IHZpcnR1YWwgY29uc29s ZXMsIGZsYWdzPTB4MzAwPgp2Z2EwOiA8R2VuZXJpYyBJU0EgVkdBPiBhdCBwb3J0IDB4M2Mw LTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBpc2EwClRpbWVjb3VudGVycyB0aWNr IGV2ZXJ5IDEuMDAwIG1zZWMKdXNidXMwOiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1 c2J1czE6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVzMjogNDgwTWJwcyBIaWdo IFNwZWVkIFVTQiB2Mi4wCnVnZW4wLjE6IDxJbnRlbD4gYXQgdXNidXMwCnVodWIwOiA8SW50 ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9u IHVzYnVzMAp1Z2VuMS4xOiA8SW50ZWw+IGF0IHVzYnVzMQp1aHViMTogPEludGVsIFVIQ0kg cm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czEK dWdlbjIuMTogPEludGVsPiBhdCB1c2J1czIKdWh1YjI6IDxJbnRlbCBFSENJIHJvb3QgSFVC LCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMyCmF0YTE6IERN QSBsaW1pdGVkIHRvIFVETUEzMywgY29udHJvbGxlciBmb3VuZCBub24tQVRBNjYgY2FibGUK YWRhMCBhdCBhdGEwIGJ1cyAwIHNjYnVzMCB0YXJnZXQgMCBsdW4gMAphZGEwOiA8TWF4dG9y IDZZMDgwUDAgWUFSNDFCVzA+IEFUQS03IGRldmljZQphZGEwOiAxMDAuMDAwTUIvcyB0cmFu c2ZlcnMgKFVETUE1LCBQSU8gODE5MmJ5dGVzKQphZGEwOiA3ODE2N01CICgxNjAwODY1Mjgg NTEyIGJ5dGUgc2VjdG9yczogMTZIIDYzUy9UIDE2MzgzQykKY2QwIGF0IGF0YTEgYnVzIDAg c2NidXMxIHRhcmdldCAwIGx1biAwCmNkMDogPFNPTlkgRFZEIFJXIERXLUQyNkEgSllTMj4g UmVtb3ZhYmxlIENELVJPTSBTQ1NJLTAgZGV2aWNlIApjZDA6IDMzLjMwME1CL3MgdHJhbnNm ZXJzIChVRE1BMiwgQVRBUEkgMTJieXRlcywgUElPIDY1NTM0Ynl0ZXMpCmNkMDogQXR0ZW1w dCB0byBxdWVyeSBkZXZpY2Ugc2l6ZSBmYWlsZWQ6IE5PVCBSRUFEWSwgTWVkaXVtIG5vdCBw cmVzZW50CmFkYTA6IFByZXZpb3VzbHkgd2FzIGtub3duIGFzIGFkMApTTVA6IEFQIENQVSAj MSBMYXVuY2hlZCEKdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dl cmVkCnVodWIxOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApSb290 IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czIKdWh1YjI6IDQgcG9ydHMgd2l0aCA0IHJlbW92 YWJsZSwgc2VsZiBwb3dlcmVkClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzMgp1Z2Vu Mi4yOiA8SmV0Rmxhc2g+IGF0IHVzYnVzMgp1bWFzczA6IDxKZXRGbGFzaCBNYXNzIFN0b3Jh Z2UgRGV2aWNlLCBjbGFzcyAwLzAsIHJldiAyLjAwLzEuNDEsIGFkZHIgMj4gb24gdXNidXMy ClRyeWluZyB0byBtb3VudCByb290IGZyb20gdWZzOi9kZXYvYWRhMHMxYSBbcncsbm9hdGlt ZV0uLi4KZGEwIGF0IHVtYXNzLXNpbTAgYnVzIDAgc2NidXMyIHRhcmdldCAwIGx1biAwCmRh MDogPEpldEZsYXNoIFRTMkdKRlYzMCA4LjA3PiBSZW1vdmFibGUgRGlyZWN0IEFjY2VzcyBT Q1NJLTIgZGV2aWNlIApkYTA6IDQwLjAwME1CL3MgdHJhbnNmZXJzCmRhMDogMTk1NU1CICg0 MDA1ODg2IDUxMiBieXRlIHNlY3RvcnM6IDI1NUggNjNTL1QgMjQ5QykKdWdlbjAuMjogPHZl bmRvciAweDA0ZmM+IGF0IHVzYnVzMAp1bXMwOiA8dmVuZG9yIDB4MDRmYyBVU0IgTXVsdGkt U21hcnQgTW91c2UsIGNsYXNzIDAvMCwgcmV2IDIuMDAvMTYuMTEsIGFkZHIgMj4gb24gdXNi dXMwCnVtczA6IDUgYnV0dG9ucyBhbmQgW1hZWlRdIGNvb3JkaW5hdGVzIElEPTEKU2V0dGlu ZyBob3N0dXVpZDogMDAwMjAwMDMtMDAwNC0wMDA1LTAwMDYtMDAwNzAwMDgwMDA5LgpTZXR0 aW5nIGhvc3RpZDogMHg4MWY0ZWM2OC4KRW50cm9weSBoYXJ2ZXN0aW5nOiBpbnRlcnJ1cHRz IGV0aGVybmV0IHBvaW50X3RvX3BvaW50IGtpY2tzdGFydC4KU3RhcnRpbmcgZmlsZSBzeXN0 ZW0gY2hlY2tzOgovZGV2L2FkYTBzMWE6IEZJTEUgU1lTVEVNIENMRUFOOyBTS0lQUElORyBD SEVDS1MKL2Rldi9hZGEwczFhOiBjbGVhbiwgMTM3NjE4NyBmcmVlICg0NDM0NyBmcmFncywg MTY2NDgwIGJsb2NrcywgMC4yJSBmcmFnbWVudGF0aW9uKQpNb3VudGluZyBsb2NhbCBmaWxl IHN5c3RlbXM6LgovZXRjL3JjOiBXQVJOSU5HOiAkaG9zdG5hbWUgaXMgbm90IHNldCAtLSBz ZWUgcmMuY29uZig1KS4KU3RhcnRpbmcgTmV0d29yazogbG8wIHNrMC4KbG8wOiBmbGFncz04 MDQ5PFVQLExPT1BCQUNLLFJVTk5JTkcsTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgMTYzODQK CW9wdGlvbnM9MzxSWENTVU0sVFhDU1VNPgoJaW5ldCAxMjcuMC4wLjEgbmV0bWFzayAweGZm MDAwMDAwIApzazA6IGZsYWdzPTg4NDM8VVAsQlJPQURDQVNULFJVTk5JTkcsU0lNUExFWCxN VUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAxNTAwCglvcHRpb25zPTgwMDA5PFJYQ1NVTSxWTEFO X01UVSxMSU5LU1RBVEU+CglldGhlciAwMDowZTphNjozNToxNTo5MQoJaW5ldCAxOTIuMTY4 LjEuODAgbmV0bWFzayAweGZmZmZmZjAwIGJyb2FkY2FzdCAxOTIuMTY4LjEuMjU1IAoJbWVk aWE6IEV0aGVybmV0IGF1dG9zZWxlY3QgKG5vbmUpCglzdGF0dXM6IG5vIGNhcnJpZXIKU3Rh cnRpbmcgZGV2ZC4KU3RhcnRpbmcgdW1zMCBtb3VzZWRtb3VzZWQ6IG5vIHN1Y2ggbW91c2Ug dHlwZSBgbm9uZScKdXNhZ2U6IG1vdXNlZCBbLURSY2Rmc10gWy1JIGZpbGVdIFstRiByYXRl XSBbLXIgcmVzb2x1dGlvbl0gWy1TIGJhdWRyYXRlXQogICAgICAgICAgICAgIFstVkggWy1V IHRocmVzaG9sZF1dIFstYSBYWyxZXV0gWy1DIHRocmVzaG9sZF0gWy1tIE49TV0gWy13IE5d CiAgICAgICAgICAgICAgWy16IE5dIFstdCA8bW91c2V0eXBlPl0gWy1sIGxldmVsXSBbLTMg Wy1FIHRpbWVvdXRdXQogICAgICAgICAgICAgIFstVCBkaXN0YW5jZVssdGltZVssYWZ0ZXJd XV0gLXAgPHBvcnQ+CiAgICAgICBtb3VzZWQgWy1kXSAtaSA8cG9ydHxpZnx0eXBlfG1vZGVs fGFsbD4gLXAgPHBvcnQ+Ci4KYWRkIG5ldCBkZWZhdWx0OiBnYXRld2F5IDE5Mi4xNjguMS4x CkVMRiBsZGNvbmZpZyBwYXRoOiAvbGliIC91c3IvbGliIC91c3IvbGliL2NvbXBhdCAvdXNy L2xvY2FsL2xpYiAvdXNyL2xvY2FsL2xpYi9jb21wYXQvcGtnIC91c3IvbG9jYWwva2RlNC9s aWIgL3Vzci9sb2NhbC9saWIvY29tcGF0L3BrZyAvdXNyL2xvY2FsL2xpYi9nY2M0NiAvdXNy L2xvY2FsL2xpYi9nZWdsLTAuMSAvdXNyL2xvY2FsL2xpYi9ncmFwaHZpeiAvdXNyL2xvY2Fs L2xpYi9uc3MgL3Vzci9sb2NhbC9saWIvcXQ0CmEub3V0IGxkY29uZmlnIHBhdGg6IC91c3Iv bGliL2FvdXQgL3Vzci9saWIvY29tcGF0L2FvdXQKQ3JlYXRpbmcgYW5kL29yIHRyaW1taW5n IGxvZyBmaWxlcy4KU3RhcnRpbmcgc3lzbG9nZC4KTm8gY29yZSBkdW1wcyBmb3VuZC4KQ2xl YXJpbmcgL3RtcCAoWCByZWxhdGVkKS4KVXBkYXRpbmcgbW90ZDouCnNrMDogbGluayBzdGF0 ZSBjaGFuZ2VkIHRvIFVQCkNvbmZpZ3VyaW5nIHN5c2NvbnM6IGJsYW5rdGltZS4KU3RhcnRp bmcgY3Jvbi4KL2V0Yy9yYy5kL3N5c2N0bDogV0FSTklORzogc3lzY3RsIGRlYnVnLmRlYnVn Z2VyX29uX3BhbmljIGRvZXMgbm90IGV4aXN0LgpTdGFydGluZyBiYWNrZ3JvdW5kIGZpbGUg c3lzdGVtIGNoZWNrcyBpbiA2MCBzZWNvbmRzLgpQUkVTUyBTQ1JPTEwtTE9DSwpGQUlMIDEK RkFJTCAyCgpTYXQgTWF5IDE5IDEwOjMwOjA5IENFU1QgMjAxMgppbmZvOiBbZHJtXSBTZXR0 aW5nIEdBUlQgbG9jYXRpb24gYmFzZWQgb24gbmV3IG1lbW9yeSBtYXAKaW5mbzogW2RybV0g TG9hZGluZyBSMzAwIE1pY3JvY29kZQppbmZvOiBbZHJtXSBOdW0gcGlwZXM6IDEKaW5mbzog W2RybV0gd3JpdGViYWNrIHRlc3Qgc3VjY2VlZGVkIGluIDEgdXNlY3MKU3RvcHBpbmcgY3Jv bi4KU3RvcHBpbmcgZGV2ZC4KV2FpdGluZyBmb3IgUElEUzogMzUzLgpXcml0aW5nIGVudHJv cHkgZmlsZTouClRlcm1pbmF0ZWQKLgpNYXkgMTkgMTc6MjI6MzYgIHN5c2xvZ2Q6IGV4aXRp bmcgb24gc2lnbmFsIDE1Ck1heSAxOSAxNzoyMjo1NiBpbml0OiBzb21lIHByb2Nlc3NlcyB3 b3VsZCBub3QgZGllOyBwcyBheGwgYWR2aXNlZApXYWl0aW5nIChtYXggNjAgc2Vjb25kcykg Zm9yIHN5c3RlbSBwcm9jZXNzIGB2bmxydScgdG8gc3RvcC4uLmRvbmUKV2FpdGluZyAobWF4 IDYwIHNlY29uZHMpIGZvciBzeXN0ZW0gcHJvY2VzcyBgYnVmZGFlbW9uJyB0byBzdG9wLi4u ZG9uZQpXYWl0aW5nIChtYXggNjAgc2Vjb25kcykgZm9yIHN5c3RlbSBwcm9jZXNzIGBzeW5j ZXInIHRvIHN0b3AuLi4KU3luY2luZyBkaXNrcywgdm5vZGVzIHJlbWFpbmluZy4uLjAgZG9u ZQpBbGwgYnVmZmVycyBzeW5jZWQuCgoKRmF0YWwgdHJhcCAxMjogcGFnZSBmYXVsdCB3aGls ZSBpbiBrZXJuZWwgbW9kZQpjcHVpZCA9IDA7IGFwaWMgaWQgPSAwMApmYXVsdCB2aXJ0dWFs IGFkZHJlc3MJPSAweDI0NApmYXVsdCBjb2RlCQk9IHN1cGVydmlzb3IgcmVhZCwgcGFnZSBu b3QgcHJlc2VudAppbnN0cnVjdGlvbiBwb2ludGVyCT0gMHgyMDoweGMwNjA5MzgxCnN0YWNr IHBvaW50ZXIJICAgICAgICA9IDB4Mjg6MHhjMzM4Yzk2NApmcmFtZSBwb2ludGVyCSAgICAg ICAgPSAweDI4OjB4YzMzOGM5N2MKY29kZSBzZWdtZW50CQk9IGJhc2UgMHgwLCBsaW1pdCAw eGZmZmZmLCB0eXBlIDB4MWIKCQkJPSBEUEwgMCwgcHJlcyAxLCBkZWYzMiAxLCBncmFuIDEK cHJvY2Vzc29yIGVmbGFncwk9IGludGVycnVwdCBlbmFibGVkLCByZXN1bWUsIElPUEwgPSAw CmN1cnJlbnQgcHJvY2VzcwkJPSAxIChpbml0KQp0cmFwIG51bWJlcgkJPSAxMgpwYW5pYzog cGFnZSBmYXVsdApjcHVpZCA9IDAKVXB0aW1lOiA2aDUzbTNzClBoeXNpY2FsIG1lbW9yeTog NTAyIE1CCkR1bXBpbmcgODEgTUI6IDY2IDUwIDM0IDE4IDIKCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQprZXJuZWwgY29uZmlnCgpvcHRpb25zCUNPTkZJR19BVVRPR0VORVJBVEVECmlkZW50CUhR Cm1hY2hpbmUJaTM4NgpjcHUJSTY4Nl9DUFUKb3B0aW9ucwlBVEFfU1RBVElDX0lECm9wdGlv bnMJQVRBX0NBTQpvcHRpb25zCVNNUApvcHRpb25zCUlOQ0xVREVfQ09ORklHX0ZJTEUKb3B0 aW9ucwlLQkRfSU5TVEFMTF9DREVWCm9wdGlvbnMJUFJJTlRGX0JVRlJfU0laRT0xMjgKb3B0 aW9ucwlfS1BPU0lYX1BSSU9SSVRZX1NDSEVEVUxJTkcKb3B0aW9ucwlTWVNWU0VNCm9wdGlv bnMJU1lTVk1TRwpvcHRpb25zCVNZU1ZTSE0Kb3B0aW9ucwlTQ1NJX0RFTEFZPTEwMDAKb3B0 aW9ucwlDT01QQVRfRlJFRUJTRDcKb3B0aW9ucwlDT01QQVRfRlJFRUJTRDYKb3B0aW9ucwlD T01QQVRfRlJFRUJTRDUKb3B0aW9ucwlDT01QQVRfRlJFRUJTRDQKb3B0aW9ucwlHRU9NX0xB QkVMCm9wdGlvbnMJR0VPTV9QQVJUX0dQVApvcHRpb25zCUNEOTY2MApvcHRpb25zCU1TRE9T RlMKb3B0aW9ucwlNRF9ST09UCm9wdGlvbnMJVUZTX0RJUkhBU0gKb3B0aW9ucwlTT0ZUVVBE QVRFUwpvcHRpb25zCUZGUwpvcHRpb25zCUlORVQKb3B0aW9ucwlQUkVFTVBUSU9OCm9wdGlv bnMJU0NIRURfVUxFCm9wdGlvbnMJTkVXX1BDSUIKb3B0aW9ucwlOQVRJVkUKb3B0aW9ucwlH RU9NX1BBUlRfTUJSCm9wdGlvbnMJR0VPTV9QQVJUX0VCUl9DT01QQVQKb3B0aW9ucwlHRU9N X1BBUlRfRUJSCm9wdGlvbnMJR0VPTV9QQVJUX0JTRApvcHRpb25zCUlTQVBOUApkZXZpY2UJ aXNhCmRldmljZQlucHgKZGV2aWNlCW1lbQpkZXZpY2UJaW8KZGV2aWNlCXVhcnRfbnM4MjUw CmRldmljZQlhdHBpYwpkZXZpY2UJYXBpYwpkZXZpY2UJYWNwaQpkZXZpY2UJcGNpCmRldmlj ZQlhaGNpCmRldmljZQlhdGEKZGV2aWNlCXNjYnVzCmRldmljZQljaApkZXZpY2UJZGEKZGV2 aWNlCWNkCmRldmljZQlwYXNzCmRldmljZQlzZXMKZGV2aWNlCWF0a2JkYwpkZXZpY2UJYXRr YmQKZGV2aWNlCXBzbQpkZXZpY2UJdmdhCmRldmljZQlzYwpkZXZpY2UJYWdwCmRldmljZQlw bXRpbWVyCmRldmljZQltaWlidXMKZGV2aWNlCXNrCmRldmljZQlsb29wCmRldmljZQlyYW5k b20KZGV2aWNlCWV0aGVyCmRldmljZQltZApkZXZpY2UJZmlybXdhcmUKZGV2aWNlCXVoY2kK ZGV2aWNlCW9oY2kKZGV2aWNlCWVoY2kKZGV2aWNlCXVzYgpkZXZpY2UJdWhpZApkZXZpY2UJ dWtiZApkZXZpY2UJdW1hc3MKZGV2aWNlCXVtcwpkZXZpY2UJc291bmQKZGV2aWNlCXNuZF9l czEzN3gKZGV2aWNlCWRybQpkZXZpY2UJcmFkZW9uZHJtCgotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K ZGRiIGNhcHR1cmUgYnVmZmVyCgpkZGI6IGRkYl9jYXB0dXJlOiBrdm1fbmxpc3QK --------------040903060705070509050804--