From owner-freebsd-current@FreeBSD.ORG Sun Oct 23 01:50:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6656E106564A; Sun, 23 Oct 2011 01:50:25 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 2C5338FC08; Sun, 23 Oct 2011 01:50:24 +0000 (UTC) Received: from lstewart1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id D59657E820; Sun, 23 Oct 2011 12:35:15 +1100 (EST) Message-ID: <4EA36F53.9050907@freebsd.org> Date: Sun, 23 Oct 2011 12:35:15 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111016 Thunderbird/7.0.1 MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20111022084931.GD1697@garage.freebsd.pl> In-Reply-To: <20111022084931.GD1697@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Andre Oppermann Subject: Re: 9.0-RC1 panic in tcp_input: negative winow. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Oct 2011 01:50:25 -0000 On 10/22/11 19:49, Pawel Jakub Dawidek wrote: > The panic message says: > > panic: tcp_input negative window: tp 0xfffffe007763e000 rcv_nxt 3718269252 rcv_adv 3718268291 > > I only have picture of the backtrace: > > http://people.freebsd.org/~pjd/misc/panic_negative_window.jpg > ewww that is not good. Can you give us any more information about the machine and what it's doing? Is it terminating TCP connections from the internet at large or only local LAN (i.e. is there likely to be packet loss happening)? Are you doing TSO or LRO? Do you have any non-default tuning in place? Cheers, Lawrence From owner-freebsd-current@FreeBSD.ORG Sun Oct 23 03:44:09 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05423106564A; Sun, 23 Oct 2011 03:44:09 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailA.acsu.buffalo.edu (localmail.buffalo.edu [128.205.5.196]) by mx1.freebsd.org (Postfix) with ESMTP id CAB678FC08; Sun, 23 Oct 2011 03:44:08 +0000 (UTC) Received: from localmailA.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 07E28F683; Sat, 22 Oct 2011 23:44:07 -0400 (EDT) Received: from localmailA.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailA.acsu.buffalo.edu (Postfix) with ESMTP id 5BDAEF6B3; Sat, 22 Oct 2011 23:44:05 -0400 (EDT) Received: from smtp3.acsu.buffalo.edu (smtp3.acsu.buffalo.edu [128.205.5.226]) by localmailA.acsu.buffalo.edu (Prefixe) with ESMTP id 546E3F683; Sat, 22 Oct 2011 23:44:05 -0400 (EDT) Received: from [192.168.1.101] (cpe-72-231-248-9.buffalo.res.rr.com [72.231.248.9]) (Authenticated sender: kensmith@buffalo.edu) by smtp3.acsu.buffalo.edu (Postfix) with ESMTPSA id 05671464F0; Sat, 22 Oct 2011 23:44:05 -0400 (EDT) From: Ken Smith To: freebsd-current@freebsd.org, freebsd-stable Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-F5yjy/3R9S6J8Iy4E/OT" Organization: U. Buffalo Date: Sat, 22 Oct 2011 23:43:53 -0400 Message-ID: <1319341433.49428.7.camel@neo.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-PM-EL-Spam-Prob: XX: 27% Cc: Subject: FreeBSD 9.0-RC1 Available... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Oct 2011 03:44:09 -0000 --=-F5yjy/3R9S6J8Iy4E/OT Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The first of the Release Candidate builds of the 9.0-RELEASE release cycle is now available. Since this is the first release of a brand new branch I cross-post the announcements on both -current and -stable. But just so you know most of the developers active in head and stable/9 pay more attention to the -current mailing list. If you notice problems you can report them through the normal Gnats PR system or on the -current mailing list. The 9.0-RELEASE cycle will be tracked here: http://wiki.freebsd.org/Releng/9.0-TODO Wrapping up RC1 was a bit delayed due to a bug found during the initial testing of the RC1 images and a few glitches that came up as part of making FreeBSD-Update available. We'll update the schedule soon. NOTE: The location of the FTP install tree and ISOs is the same as it had been for BETA2/BETA3, though we are still deciding if this will be the layout we switch to for the release. ISO images for the following architectures are available, with pathnames given relative to the top-level of the FTP site: amd64: .../releases/amd64/amd64/ISO-IMAGES/9.0/ i386: .../releases/i386/i386/ISO-IMAGES/9.0/ ia64: .../releases/ia64/ia64/ISO-IMAGES/9.0/ powerpc: .../releases/powerpc/powerpc/ISO-IMAGES/9.0/ powerpc64: .../releases/powerpc/powerpc64/ISO-IMAGES/9.0/ sparc64: .../releases/sparc64/sparc64/ISO-IMAGES/9.0/ MD5/SHA256 checksums are tacked on below. If you would like to use csup/cvsup mechanisms to access the source tree the branch tag to use is now "RELENG_9", if you use "." (head) you will get 10-CURRENT. If you would like to access the source tree via SVN it is "svn://svn.freebsd.org/base/stable/9/". We still have the nit that the creation of a new SVN branch winds up causing what looks like a check-in of the entire tree in CVS (a side-effect of the svn2cvs exporter) so "mergemaster -F" is your friend if you are using csup/cvsup. FreeBSD Update -------------- The freebsd-update(8) utility supports binary upgrades of i386 and amd64 sy= stems running earlier FreeBSD releases. Systems running 7.[34]-RELEASE, 8.[12]-RELEASE, or 9.0-BETA[123] can upgrade as follows: First, a minor change must be made to the freebsd-update code in order for it to accept file names appearing in FreeBSD 9.0 which contain the '%' and '@' characters; without this change, freebsd-update will error out with the message "The update metadata is correctly signed, but failed an integrity check". # sed -i '' -e 's/=3D_/=3D%@_/' /usr/sbin/freebsd-update Now freebsd-update can fetch bits belonging to 9.0-RC1. During this proces= s freebsd-update will ask for help in merging configuration files. # freebsd-update upgrade -r 9.0-RC1 Due to changes in the way that FreeBSD is packaged on the release media, tw= o complications may arise in this process: 1. The FreeBSD kernel, which previously could appear in either /boot/kernel or /boot/GENERIC, now only appears as /boot/kernel. As a result, any kerne= l appearing in /boot/GENERIC will be deleted. Please carefully read the outp= ut printed by freebsd-update and confirm that an updated kernel will be placed into /boot/kernel before proceeding beyond this point. 2. The FreeBSD source tree in /usr/src (if present) will be deleted. (Norm= ally freebsd-update will update a source tree, but in this case the changes in release packaging result in freebsd-update not recognizing that the source = tree from the old release and the source tree from the new release correspond to= the same part of FreeBSD.) # freebsd-update install The system must now be rebooted with the newly installed kernel before the non-kernel components are updated. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install At this point, users of systems being upgraded from FreeBSD 8.2-RELEASE or earlier will be prompted by freebsd-update to rebuild all third-party applications (e.g., ports installed from the ports tree) due to updates in system libraries. After updating installed third-party applications (and again, only if freebsd-update printed a message indicating that this was necessary), run freebsd-update again so that it can delete the old (no longer used) system libraries: # freebsd-update install Finally, reboot into 9.0-RC1: # shutdown -r now Checksums: MD5 (FreeBSD-9.0-RC1-amd64-bootonly.iso) =3D 625d64340f952de2fca7102dac7f18= 0f MD5 (FreeBSD-9.0-RC1-amd64-dvd1.iso) =3D 5cccbb21a8448e54e4d631619b5f4861 MD5 (FreeBSD-9.0-RC1-amd64-memstick.img) =3D 07f83c8015a1907953b826b0c65069= f0 MD5 (FreeBSD-9.0-RC1-i386-bootonly.iso) =3D 59f1c057eaa6bff6c69d8e411adeb13= c MD5 (FreeBSD-9.0-RC1-i386-dvd1.iso) =3D 0f168bcfa832282cf6e3914ffc5a5014 MD5 (FreeBSD-9.0-RC1-i386-memstick.img) =3D ccbc2db07a19b3e77e75958cd747064= 3 MD5 (FreeBSD-9.0-RC1-ia64-bootonly.iso) =3D e2e80ffae14950d0437c067e7c6553f= 1 MD5 (FreeBSD-9.0-RC1-ia64-memstick) =3D 997bb23954682d503ba10fc3f1a2d624 MD5 (FreeBSD-9.0-RC1-ia64-release.iso) =3D 3703dc72d55fb9c66450e800b123cffe MD5 (FreeBSD-9.0-RC1-powerpc-bootonly.iso) =3D 2a651f4af37af85e49b6a8fcaa42= a77f MD5 (FreeBSD-9.0-RC1-powerpc-memstick) =3D a2c33dfab3f98b0d83db382d73cdd87a MD5 (FreeBSD-9.0-RC1-powerpc-release.iso) =3D af4afc51149dcd61488b44ecbbf96= fc5 MD5 (FreeBSD-9.0-RC1-powerpc64-bootonly.iso) =3D 96f2bce40f2974be55578bf9cc= 7318a1 MD5 (FreeBSD-9.0-RC1-powerpc64-memstick) =3D e4647934091f4c72b4df331eb1134e= b3 MD5 (FreeBSD-9.0-RC1-powerpc64-release.iso) =3D b6989f2e4285b7479a72f4503dc= 420cf MD5 (FreeBSD-9.0-RC1-sparc64-bootonly.iso) =3D df7146d2497a16b502e92e35ae24= 921e MD5 (FreeBSD-9.0-RC1-sparc64-dvd1.iso) =3D 6cd56a20a6d907525077424c55a163a4 SHA256 (FreeBSD-9.0-RC1-amd64-bootonly.iso) =3D ec44fefd1c54fb724079b83951c= fe721404ecb76a4a861a2ef4c2a1b63b88aff SHA256 (FreeBSD-9.0-RC1-amd64-dvd1.iso) =3D 6558689957ce2a48f3aa235ab11cd46= 13db7afe11f102b0ae5d566b22e30c132 SHA256 (FreeBSD-9.0-RC1-amd64-memstick.img) =3D c04abe37f83c8ed07e3645cbaff= 8cfa21d223f94cda059a053bd1a469c6b753c SHA256 (FreeBSD-9.0-RC1-i386-bootonly.iso) =3D 9e720cb8306171b137ae50d3887a= bf09f90fab6f953b39a9f552c87c3221d441 SHA256 (FreeBSD-9.0-RC1-i386-dvd1.iso) =3D 488599d5328b20278e90d5489b8d2afd= 49bf466a5d7a31694f3c0eb66d97c6f1 SHA256 (FreeBSD-9.0-RC1-i386-memstick.img) =3D 9eadded30ee684840bb6ead60f98= d8d8e455e690148491b55dec9b657ab7ac10 SHA256 (FreeBSD-9.0-RC1-ia64-bootonly.iso) =3D b4b33ecc30555b532be4ebcc3a5f= 566189265066141b852a3a912ddc8e1aa203 SHA256 (FreeBSD-9.0-RC1-ia64-memstick) =3D f437f5af4c8dd780d329bb90f5189c7b= b1b270df1b05bff979e7fbcc7cf819d6 SHA256 (FreeBSD-9.0-RC1-ia64-release.iso) =3D aaa21f0244d1238b11f5af267935c= 7cbea20f0d5fb393bef7534011ab7f017f1 SHA256 (FreeBSD-9.0-RC1-powerpc-bootonly.iso) =3D 5a45de1a72fd2c15f58c73068= 02533d48a5dee512b5e6f0377e859bf4a25200e SHA256 (FreeBSD-9.0-RC1-powerpc-memstick) =3D fe85b8232123a510468658380117e= 51a2ca3737e92cacb525717cefb73b9740c SHA256 (FreeBSD-9.0-RC1-powerpc-release.iso) =3D 8024a84ccf4962fe8ec7e03042= 1a476f96c410fe67c9c9b25935248304029682 SHA256 (FreeBSD-9.0-RC1-powerpc64-bootonly.iso) =3D 43e97f229ccf82337807834= 8390b6b75b3ca5c95db107a48087d6a5fc3980e92 SHA256 (FreeBSD-9.0-RC1-powerpc64-memstick) =3D 7323eb46e90849bab53c3b15875= 3b1824ae9e464c63ffe7bb33fe726c6a7c415 SHA256 (FreeBSD-9.0-RC1-powerpc64-release.iso) =3D 6c0643f2de33a04426d168dd= 23187a71c971d3e4bfd222eb32bdbaa65f2c0368 SHA256 (FreeBSD-9.0-RC1-sparc64-bootonly.iso) =3D 8664ed9a0282b80341c6e2436= 43011c84b058f4c8450a5e6e2b3f99bd9df469c SHA256 (FreeBSD-9.0-RC1-sparc64-dvd1.iso) =3D 5220f817e078024208b9ab3060518= 911c4e0ed0693575ca101a97608b73121af --=20 Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-F5yjy/3R9S6J8Iy4E/OT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk6jjXEACgkQ/G14VSmup/ZS6gCdGvd6UUj/WGq1STG7ovADU+8I okIAn2SZNOoAT7u2KWvMJyAm8J8Tf6Br =ngbT -----END PGP SIGNATURE----- --=-F5yjy/3R9S6J8Iy4E/OT-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 23 05:10:57 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4350E1065673; Sun, 23 Oct 2011 05:10:57 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id D9DC38FC12; Sun, 23 Oct 2011 05:10:56 +0000 (UTC) Received: by iaky10 with SMTP id y10so8202582iak.13 for ; Sat, 22 Oct 2011 22:10:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version:content-type; bh=cw5I1gzp7n0pAQURDcFw8AR8RrTbf9jnmeFqv+CTVLU=; b=k76d6/j+ECAxt4OIfzH3w/5Gu4RUky04GIi2eFWcRYOOhsXbUmlDc8yBHS5bXncP81 B/hJp9YH0MJuNTGQ9jY4XDFKu5W+1eM0IOEDsZUBRrgN9uinSHNPgwCl+C01tD515Bxv HaCrkuqXG3xSZ2yF03hszfXaPFU2vpW5PSHuo= Received: by 10.42.153.74 with SMTP id l10mr33891595icw.52.1319346656139; Sat, 22 Oct 2011 22:10:56 -0700 (PDT) Received: from c-24-6-49-154.hsd1.ca.comcast.net (c-24-6-49-154.hsd1.ca.comcast.net. [24.6.49.154]) by mx.google.com with ESMTPS id ge16sm48341449ibb.2.2011.10.22.22.10.54 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 22 Oct 2011 22:10:55 -0700 (PDT) Date: Sat, 22 Oct 2011 22:10:52 -0700 (PDT) From: Garrett Cooper To: Lawrence Stewart In-Reply-To: <4EA36F53.9050907@freebsd.org> Message-ID: References: <20111022084931.GD1697@garage.freebsd.pl> <4EA36F53.9050907@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Andre Oppermann , freebsd-current@freebsd.org, Pawel Jakub Dawidek Subject: Re: 9.0-RC1 panic in tcp_input: negative winow. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Oct 2011 05:10:57 -0000 On Sun, 23 Oct 2011, Lawrence Stewart wrote: > On 10/22/11 19:49, Pawel Jakub Dawidek wrote: >> The panic message says: >> >> panic: tcp_input negative window: tp 0xfffffe007763e000 rcv_nxt >> 3718269252 rcv_adv 3718268291 >> >> I only have picture of the backtrace: >> >> http://people.freebsd.org/~pjd/misc/panic_negative_window.jpg >> > > ewww that is not good. Can you give us any more information about the machine > and what it's doing? Is it terminating TCP connections from the internet at > large or only local LAN (i.e. is there likely to be packet loss happening)? > Are you doing TSO or LRO? Do you have any non-default tuning in place? I can't speak for pjd@, but when this issue occured a couple months ago for me, the system I had run into the issue with was doing packet forwarding via ipfw from an internal NAT via ipfw to a corporate network. The system was using bce(4) on the internal and external interface. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Oct 23 05:45:13 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76EBA106564A for ; Sun, 23 Oct 2011 05:45:13 +0000 (UTC) (envelope-from greglmiller@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id DA23F8FC0C for ; Sun, 23 Oct 2011 05:45:12 +0000 (UTC) Received: by wwi18 with SMTP id 18so7313563wwi.31 for ; Sat, 22 Oct 2011 22:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NUn+LIjFOJ/Xx/oirC9l1cdEi+TA8z0VWM3oidFls6o=; b=uYY/xddvHIlBdOBrooGWHEjnDby/6A9bL2eYD5P9oT87dOyUZLzX+DVocmdUugE/hI DucFdE0ERVsua6d+bpEsFX7Itn6XzU/hi0W1kAW93h6mJhgk90Ix1yY44NMIFHGcUcIU aiSyOezIiF9yRhR56zp1g3lAO0Mj56BqVinPw= MIME-Version: 1.0 Received: by 10.227.160.78 with SMTP id m14mr7970272wbx.7.1319348711696; Sat, 22 Oct 2011 22:45:11 -0700 (PDT) Received: by 10.180.89.38 with HTTP; Sat, 22 Oct 2011 22:45:11 -0700 (PDT) In-Reply-To: <1319341433.49428.7.camel@neo.cse.buffalo.edu> References: <1319341433.49428.7.camel@neo.cse.buffalo.edu> Date: Sun, 23 Oct 2011 00:45:11 -0500 Message-ID: From: Greg Miller To: Ken Smith Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, freebsd-stable Subject: Re: FreeBSD 9.0-RC1 Available... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Oct 2011 05:45:13 -0000 On 10/22/11, Ken Smith wrote: > > The first of the Release Candidate builds of the 9.0-RELEASE release > cycle is now available. Since this is the first release of a brand New in RC1, with GENERIC: cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=native -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 -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror /usr/src/sys/fs/devfs/devfs_devs.c cc1: warnings being treated as errors /usr/src/sys/fs/devfs/devfs_devs.c: In function 'devfs_free': /usr/src/sys/fs/devfs/devfs_devs.c:174: warning: implicit declaration of function 'devfs_free_cdp_inode' /usr/src/sys/fs/devfs/devfs_devs.c:174: warning: nested extern declaration of 'devfs_free_cdp_inode' [-Wnested-externs] /usr/src/sys/fs/devfs/devfs_devs.c: At top level: /usr/src/sys/fs/devfs/devfs_devs.c:689: warning: no previous prototype for 'devfs_alloc_cdp_inode' [-Wmissing-prototypes] /usr/src/sys/fs/devfs/devfs_devs.c:696: warning: no previous prototype for 'devfs_free_cdp_inode' [-Wmissing-prototypes] /usr/src/sys/fs/devfs/devfs_devs.c:696: warning: conflicting types for 'devfs_free_cdp_inode' /usr/src/sys/fs/devfs/devfs_devs.c:174: warning: previous implicit declaration of 'devfs_free_cdp_inode' was here *** Error code 1 From owner-freebsd-current@FreeBSD.ORG Sun Oct 23 06:09:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5973C1065674 for ; Sun, 23 Oct 2011 06:09:44 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id E93B78FC0C for ; Sun, 23 Oct 2011 06:09:43 +0000 (UTC) Received: by ggnq2 with SMTP id q2so4718622ggn.13 for ; Sat, 22 Oct 2011 23:09:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MIlAnqKAW23iTPrM4REBRX5c1RlT62RrWI5/36M8wSs=; b=s+ffyYb4W0atxqkzMOCgkHBXcnA82ILwRAiEaT8UOgDZjimn/PD0EDqW22rQQHtqyw z9lyz01wxl3LhgpcTy+JfqB8/s13PDuMT/u+by1w0Ej+h+Q5LV1zXu25J/HbRmAGDeuM vLVpY9YpECSvM2gfO+kMEi7+zxBgaa5owBg34= MIME-Version: 1.0 Received: by 10.182.7.10 with SMTP id f10mr2300365oba.56.1319350183101; Sat, 22 Oct 2011 23:09:43 -0700 (PDT) Received: by 10.182.122.33 with HTTP; Sat, 22 Oct 2011 23:09:43 -0700 (PDT) In-Reply-To: References: <1319341433.49428.7.camel@neo.cse.buffalo.edu> Date: Sat, 22 Oct 2011 23:09:43 -0700 Message-ID: From: Garrett Cooper To: Greg Miller Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Konstantin Belousov , freebsd-current@freebsd.org, freebsd-stable Subject: Re: FreeBSD 9.0-RC1 Available... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Oct 2011 06:09:44 -0000 On Sat, Oct 22, 2011 at 10:45 PM, Greg Miller wrote= : > On 10/22/11, Ken Smith wrote: >> >> The first of the Release Candidate builds of the 9.0-RELEASE release >> cycle is now available. =A0Since this is the first release of a brand > > New in RC1, with GENERIC: Was r226041 MFCed properly? -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Oct 23 06:11:27 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8EA41065698; Sun, 23 Oct 2011 06:11:27 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 018678FC1F; Sun, 23 Oct 2011 06:11:26 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 31661464; Sun, 23 Oct 2011 08:11:24 +0200 (CEST) Date: Sun, 23 Oct 2011 08:10:38 +0200 From: Pawel Jakub Dawidek To: Lawrence Stewart Message-ID: <20111023061038.GE1697@garage.freebsd.pl> References: <20111022084931.GD1697@garage.freebsd.pl> <4EA36F53.9050907@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k3qmt+ucFURmlhDS" Content-Disposition: inline In-Reply-To: <4EA36F53.9050907@freebsd.org> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Andre Oppermann Subject: Re: 9.0-RC1 panic in tcp_input: negative winow. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Oct 2011 06:11:27 -0000 --k3qmt+ucFURmlhDS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 23, 2011 at 12:35:15PM +1100, Lawrence Stewart wrote: > On 10/22/11 19:49, Pawel Jakub Dawidek wrote: > > The panic message says: > > > > panic: tcp_input negative window: tp 0xfffffe007763e000 rcv_nxt 371826= 9252 rcv_adv 3718268291 > > > > I only have picture of the backtrace: > > > > http://people.freebsd.org/~pjd/misc/panic_negative_window.jpg > > >=20 > ewww that is not good. Can you give us any more information about the=20 > machine and what it's doing? Is it terminating TCP connections from the= =20 > internet at large or only local LAN (i.e. is there likely to be packet=20 > loss happening)? Are you doing TSO or LRO? Do you have any non-default=20 > tuning in place? It is my local file server. It is doing NFS and AFP over LAN and also downloads files from the internet. It is triggered after few hours. I changed the KASSERT() into printf() and added printing 'win' variable and this is what got logged during the night: 05:16:24 tcp_input negative window: tp 0xfffffe0026772b70 rcv_nxt 110782726= 9 rcv_adv 1107826256 win=3D242 05:16:29 tcp_input negative window: tp 0xfffffe0026772b70 rcv_nxt 110783345= 1 rcv_adv 1107832977 win=3D880 05:16:41 tcp_input negative window: tp 0xfffffe0026772b70 rcv_nxt 110784956= 3 rcv_adv 1107848860 win=3D639 05:20:02 tcp_input negative window: tp 0xfffffe0026772b70 rcv_nxt 110810823= 0 rcv_adv 1108107331 win=3D567 05:24:30 tcp_input negative window: tp 0xfffffe0026772b70 rcv_nxt 110843330= 2 rcv_adv 1108432272 win=3D974 05:24:46 tcp_input negative window: tp 0xfffffe0026772b70 rcv_nxt 110845038= 5 rcv_adv 1108450060 win=3D751 05:26:44 tcp_input negative window: tp 0xfffffe0026772b70 rcv_nxt 110857481= 8 rcv_adv 1108573851 win=3D71 05:28:03 tcp_input negative window: tp 0xfffffe0026772b70 rcv_nxt 110865410= 3 rcv_adv 1108653166 win=3D0 05:28:43 tcp_input negative window: tp 0xfffffe0026772b70 rcv_nxt 110869239= 6 rcv_adv 1108691451 win=3D0 05:30:06 tcp_input negative window: tp 0xfffffe0026772b70 rcv_nxt 110878125= 8 rcv_adv 1108780372 win=3D235 05:35:05 tcp_input negative window: tp 0xfffffe0026772b70 rcv_nxt 110906757= 8 rcv_adv 1109067335 win=3D663 05:37:03 tcp_input negative window: tp 0xfffffe0026772b70 rcv_nxt 110918040= 3 rcv_adv 1109179411 win=3D0 05:41:03 tcp_input negative window: tp 0xfffffe0026772b70 rcv_nxt 110942826= 5 rcv_adv 1109427375 win=3D170 And the systems seems to be fine. I'm happy to test patches, but one round would take 24h. My suggestion would be that if we won't be able to fix it before 9.0, we should turn this assertion off, as the system seems to be able to recover. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --k3qmt+ucFURmlhDS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk6jr9oACgkQForvXbEpPzRU0QCdFfQwbyw7POvY827S/P9iFvcG Ru8An3jQWQ3oDpiSjZGeToiRh1c/5KGK =oRuU -----END PGP SIGNATURE----- --k3qmt+ucFURmlhDS-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 23 06:45:20 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE65B106566B for ; Sun, 23 Oct 2011 06:45:20 +0000 (UTC) (envelope-from martin@sugioarto.com) Received: from mailserv.regfish.com (mailserv.regfish.com [79.140.61.33]) by mx1.freebsd.org (Postfix) with ESMTP id 3A6F68FC0A for ; Sun, 23 Oct 2011 06:45:19 +0000 (UTC) Received: (qmail 26005 invoked from network); 23 Oct 2011 06:45:18 -0000 Received: from pd9ec1855.dip0.t-ipconnect.de (HELO yuni.sugioarto.com) (46959-0001@[217.236.24.85]) (envelope-sender ) by mailserv.regfish.com (qmail-ldap-1.03) with SMTP for ; 23 Oct 2011 06:45:18 -0000 Received: from zelda.sugioarto.com (zelda.sugioarto.com [192.168.0.12]) by yuni.sugioarto.com (Postfix) with ESMTP id BB8D91BAC57 for ; Sun, 23 Oct 2011 08:45:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sugioarto.com; s=mail; t=1319352314; bh=tOSkXD7GXkmkEju8Pl9g6NTGfS97N56ynUg7pFzydTs=; h=Date:From:To:Subject:Message-ID:Mime-Version:Content-Type; b=jAExBvHg5dtdQDd3kYBNP/nwLbD66Gn9j6GjQteXP5yL6GIb28nebr0OONwX9b0l2 zgMnbuB669mTUcV2YEVkzK9LD0kuAHSgvBqIS2cyjv+B/q+TA6tyQH966e8umMFFkc VJWO0Q9Jj5tMQQrmLJqFf0PiqHrNal66ywwvm4WE= Date: Sun, 23 Oct 2011 08:44:45 +0200 From: Martin Sugioarto To: freebsd-current@freebsd.org Message-ID: <20111023084445.0f47b092@zelda.sugioarto.com> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/w6+y5bctJPxOYaqJjwq2YJl"; protocol="application/pgp-signature" Subject: Question about: /etc/periodic/security/800.loginfail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Oct 2011 06:45:20 -0000 --Sig_/w6+y5bctJPxOYaqJjwq2YJl Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi, I noticed that the daily security emails don't show failed logins properly, because the logged string does not match. This is how the lines are grepped for failed logins: n=3D$(catmsgs | egrep -ia "^$yesterday.*: .*(fail|invalid|bad|illegal)" | tee /dev/stderr | wc -l) This is how the lines look like that I don't see: Oct 23 08:21:16 hostname.domain.com sshd[21547]: error: PAM: authentication error for root from xxx.yyy.com Is there a reason why these messages don't belong into the security mails (except that it would blow up the output)? I think that these log lines are much more useful than those "POSSIBLE BREAK-IN ATTEMPT!" lines or pam_ldap errors, like this one below, which don't tell the origin of the attack: Oct 22 00:07:48 hostname.domain.com sshd[77983]: pam_ldap: error trying to bind as user "uid=3Droot,ou=3DPeople,dc=3Ddomain" (Invalid credentials) So the question is if this egrep pipe sufficient and if it tells you precisely enough what's going on. Any opinions on this? -- Martin --Sig_/w6+y5bctJPxOYaqJjwq2YJl Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQIcBAEBAgAGBQJOo7f5AAoJEF8wvLx/5p/7TIIP/1Jx0MpA8bdVWTIeITvaNQOv 11ToLZeG9MdJ6OA/jlM9YRBS2E62fbZpv+tD8xAewiSl5SWHaQBOgPmrm+64z+87 8KSh71LOln4s3YeaPKSr2qTMj/1HfqcQkbZRtPWZfpQUXWm40rQ0BIzLLURqxBT1 jR7nTkOdYMnsJPkDELt443hUrhZI3HG3zQAlTFQLxTsyFars7GISCvRbckvKbT5h K+Kl8x5w3dk5qaJ/8mo8EEATIKG8Q+0z3svWR+8WVTsoZ7qqocXCBcoqq1LabcQE wZLsAANv0wup3xOkLko7zppvs3idxZCFJsjgQTlDFEjPYiSIw1Iz8yy7GcpVODn/ 0QiYPX0yvFsI+z4i8KUa3SoZWVhmyQoj5kyOC0LcO/aAeTVdfhMXq5YDdOK+KAKE r6dUMOVd85sevODtPD0oHI7YuPAZ9kKMWcHoz/k3XVuEf9u+VK3nwCutu/OqbRfJ /mWFIO2BTZBlaGLIYDLSIH7P4G9Voi9E1Uxj4pkif49qjbFL8+89Xgoyfkwsmhnt wWi4eVkOGV5MfzEcyk5JeBXln0Bg4Xp5fE1bOGx5Iwc9VcM6rFSfm2HbxXxfwPl9 txTqwS6m4mfQPAmbVXqs/LTLlV/gx0mxi+gtJzq8cXftQc4kZqv8K7V9JSG/PICL nQZgRrXivmtAEnDM5Nkf =Uh8Q -----END PGP SIGNATURE----- --Sig_/w6+y5bctJPxOYaqJjwq2YJl-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 23 07:49:39 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F356106566C; Sun, 23 Oct 2011 07:49:39 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id C30E08FC15; Sun, 23 Oct 2011 07:49:37 +0000 (UTC) Received: from alph.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id p9N7nJI7055101; Sun, 23 Oct 2011 16:49:29 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p9N7nCeP010360; Sun, 23 Oct 2011 16:49:16 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sun, 23 Oct 2011 16:48:48 +0900 (JST) Message-Id: <20111023.164848.1772538364295153252.hrs@allbsd.org> To: jhay@meraka.org.za From: Hiroki Sato In-Reply-To: <20111022193418.GA53988@zibbi.meraka.csir.co.za> References: <4EA23C08.6060906@FreeBSD.org> <20111022.161336.1708295810836213738.hrs@allbsd.org> <20111022193418.GA53988@zibbi.meraka.csir.co.za> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sun_Oct_23_16_48_48_2011_639)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Sun, 23 Oct 2011 16:49:34 +0900 (JST) X-Spam-Status: No, score=-104.6 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, RDNS_NONE, SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: dougb@FreeBSD.org, current@FreeBSD.org Subject: Re: IPv6 accept_rtadv + bfe0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Oct 2011 07:49:39 -0000 ----Security_Multipart(Sun_Oct_23_16_48_48_2011_639)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Hay wrote in <20111022193418.GA53988@zibbi.meraka.csir.co.za>: jh> I can maybe just say, I have now upgraded various machines from 7.x or jh> 8.x to 9 and even though I have read the rc.conf manual I keep tripping jh> on the new IPv6 rc stuff. Various being client, server and router / jh> firewall. It looks like ipv6_prefix_IF now needs an ifconfig_IF_ipv6 = jh> "inet6 auto_linklocal" otherwise it is ignored. This is intentional because $ifconfig_IF_ipv6 is designed as per-interface version of the old $ipv6_enable. I added an explicit description about this to rc.conf(5). jh> In the rc.conf man page, in the ifconfig__ipv6 section, it is jh> suggested to use ifconfig__alias for aliases, but somewhere jh> else it says that that _alias is deprecated. What would be nice is jh> something like the ipv4_addrs_IF= variable. $ipv6_prefix_IF is the counterpart of $ipv4_addrs_IF. It is limited to /64 prefixes, though. I didn't notice it said ifconfig_IF_aliasN was deprecated. Although the man page explains the depreciation is due to a difficult behavior of _aliasN, if it is the reason, it is easy to support multiple lines in the variable like this: ifconfig_em0_aliases=" inet 192.168.0.1/32 inet 192.168.0.2/32 inet 192.168.0.3/32 " jh> The last paragraph in ifconfig__ipv6, about "inet6 accept_rtadv" jh> should probably be closer to the begining, with some added sentence to jh> make it clear that it is probably what the normal client machine needs. Moved it to just after a normal GUA configuration example in rc.conf(5). -- Hiroki ----Security_Multipart(Sun_Oct_23_16_48_48_2011_639)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk6jxuAACgkQTyzT2CeTzy2ACgCeMRIdE1NGf29C99vBD2qEGyLv 0bIAnix0ojc4HpHSuz18K6E2tpprK1WO =lUxV -----END PGP SIGNATURE----- ----Security_Multipart(Sun_Oct_23_16_48_48_2011_639)---- From owner-freebsd-current@FreeBSD.ORG Sun Oct 23 08:12:06 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF85C1065670 for ; Sun, 23 Oct 2011 08:12:06 +0000 (UTC) (envelope-from jdevelop@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 49D988FC0C for ; Sun, 23 Oct 2011 08:12:06 +0000 (UTC) Received: by bkbzu17 with SMTP id zu17so8741178bkb.13 for ; Sun, 23 Oct 2011 01:12:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=4W2W0CyOqctpjCZHKblMOJlIZrenQo/tReYlV5zp2zM=; b=vvG0dktCqzNSxRwIRXIrCgJ0y0kTd5cUBZAch5/qsWtchLDtl9AYpI0+Y0E0ljXoRh RFH4U45n/F25BAg1E26NHqi8bsFt6p8cGE6y4GtDxsa1A3V8jBaqC2f8ARCCAhkNXnhO t7rw5Kk4y4Y2G2nbgg07Culbjlb/pczb736kU= Received: by 10.223.4.215 with SMTP id 23mr35946915fas.8.1319357525200; Sun, 23 Oct 2011 01:12:05 -0700 (PDT) Received: from devbox ([89.105.248.57]) by mx.google.com with ESMTPS id w11sm2178050fad.7.2011.10.23.01.12.04 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 23 Oct 2011 01:12:04 -0700 (PDT) Received: from bofh by devbox with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RHtA3-0000y1-Jt; Sun, 23 Oct 2011 11:12:03 +0300 Date: Sun, 23 Oct 2011 11:12:03 +0300 From: Eugene Dzhurinsky To: Bruce Cran Message-ID: <20111023081203.GA3698@devbox> References: <20111022103623.GA73764@devbox> <42AC5043-6760-401E-B911-CA567853F4E0@cran.org.uk> <20111022152107.GA1994@devbox> <4EA32EC1.9060601@cran.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k1lZvvs/B4yU6o8G" Content-Disposition: inline In-Reply-To: <4EA32EC1.9060601@cran.org.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-current@freebsd.org" Subject: Re: replacement of ataidle for freebsd 9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Oct 2011 08:12:06 -0000 --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 22, 2011 at 09:59:45PM +0100, Bruce Cran wrote: > On 22/10/2011 16:21, Eugene Dzhurinsky wrote: > >> ataidle -P 0 /dev/ada0 > > ataidle: error opening /dev/ada0 >=20 > Thanks for reporting the breakage, I'll see if I can get it fixed in=20 > time for 9.0. Wow, it would be great! :) In the mentime, can you please advice how can I use camcontrol in order to disable APM for my HDD? Many thanks! --=20 Eugene N Dzhurinsky --k1lZvvs/B4yU6o8G Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBAgAGBQJOo8xSAAoJEJl2g18bZPdRtt0H+QGGQAZUtfsYY9iW8+LbB5dM 9zW2iJ+NVj84bw9sBSJ3WsFT7rsP5QRYk9dt3uYz839y6eTslDU25JnaDAh8+V5e T90ITnUqTopCVDEMn1XZB9C3kGlX1RiyyPJvs+6/XWAWD4TkSzNRPyFDZg4GbZw+ /OZNrGksaE8oE+whdOG7nivj4p7THMsIyGQYpJEZYIBsEDJImITr0Ov4QpnlEeC0 6YIa+E9ahhTtequVo0ZYtvpaAr6t73H9AwNV2cHfHnpqQcHwAcfxtvjKf88YBFMt QTNHd92Yi4GuNcrrJEA56vciQH2knXTdM8CjbELYk+yA00MEkFiylHaBRnPerlI= =XQY/ -----END PGP SIGNATURE----- --k1lZvvs/B4yU6o8G-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 23 08:24:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6AC9106566B for ; Sun, 23 Oct 2011 08:24:16 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (vlakno.cz [46.28.110.116]) by mx1.freebsd.org (Postfix) with ESMTP id A93868FC08 for ; Sun, 23 Oct 2011 08:24:16 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id 9E4357F3822; Sun, 23 Oct 2011 10:24:12 +0200 (CEST) Date: Sun, 23 Oct 2011 10:24:12 +0200 From: Roman Divacky To: Patrick Lamaiziere Message-ID: <20111023082412.GA74520@freebsd.org> References: <20111022205129.32569ec5@davenulle.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111022205129.32569ec5@davenulle.org> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Current Subject: Re: 9.0 RC1/Clang / illegal instruction (Signal 4) in gengtype while building cc_tools on i586. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Oct 2011 08:24:17 -0000 > Program received signal SIGILL, Illegal instruction. > 0x08048b24 in do_typedef (s=0x80532bf "CUMULATIVE_ARGS", pos=0x805e1a4) > at /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/gengtype.c:103 > 103 { > > (gdb) disas 0x08048b24 > Dump of assembler code for function do_typedef: > 0x08048b10 : push %ebp > 0x08048b11 : mov %esp,%ebp > 0x08048b13 : push %ebx > 0x08048b14 : push %edi > 0x08048b15 : push %esi > 0x08048b16 : sub $0xc,%esp > 0x08048b19 : mov $0x805e1d4,%edi > 0x08048b1e : mov 0x10(%ebp),%esi > 0x08048b21 : mov 0x8(%ebp),%ebx > 0x08048b24 : nopw %cs:0x0(%eax,%eax,1) LLVM attempts to use an optimal nop sequence when writing N-byte nop, by using these nop instructions static const uint8_t Nops[10][10] = { // nop {0x90}, // xchg %ax,%ax {0x66, 0x90}, // nopl (%[re]ax) {0x0f, 0x1f, 0x00}, // nopl 0(%[re]ax) {0x0f, 0x1f, 0x40, 0x00}, // nopl 0(%[re]ax,%[re]ax,1) {0x0f, 0x1f, 0x44, 0x00, 0x00}, // nopw 0(%[re]ax,%[re]ax,1) {0x66, 0x0f, 0x1f, 0x44, 0x00, 0x00}, // nopl 0L(%[re]ax) {0x0f, 0x1f, 0x80, 0x00, 0x00, 0x00, 0x00}, // nopl 0L(%[re]ax,%[re]ax,1) {0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00}, // nopw 0L(%[re]ax,%[re]ax,1) {0x66, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00}, // nopw %cs:0L(%[re]ax,%[re]ax,1) {0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00}, }; There's no checking for a supported CPU, is it so that AMD geode doesnt support any of these? Any other cpu that doesnt support these? If this is CPU dependant, I suggest to open a bug report upstream as it's a bug. roman From owner-freebsd-current@FreeBSD.ORG Sun Oct 23 08:43:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FEED106564A; Sun, 23 Oct 2011 08:43:36 +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 D4E608FC0C; Sun, 23 Oct 2011 08:43:35 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p9N8hV2M047210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 23 Oct 2011 11:43:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id p9N8hU9N083482; Sun, 23 Oct 2011 11:43:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id p9N8hUJo083481; Sun, 23 Oct 2011 11:43:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 23 Oct 2011 11:43:30 +0300 From: Kostik Belousov To: Roman Divacky Message-ID: <20111023084330.GA50300@deviant.kiev.zoral.com.ua> References: <20111022205129.32569ec5@davenulle.org> <20111023082412.GA74520@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8Y8a5CJOPM/zJV44" Content-Disposition: inline In-Reply-To: <20111023082412.GA74520@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: FreeBSD Current , Patrick Lamaiziere Subject: Re: 9.0 RC1/Clang / illegal instruction (Signal 4) in gengtype while building cc_tools on i586. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Oct 2011 08:43:36 -0000 --8Y8a5CJOPM/zJV44 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 23, 2011 at 10:24:12AM +0200, Roman Divacky wrote: > > Program received signal SIGILL, Illegal instruction. > > 0x08048b24 in do_typedef (s=3D0x80532bf "CUMULATIVE_ARGS", pos=3D0x805e= 1a4) > > at /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/gengtyp= e.c:103 > > 103 { > >=20 > > (gdb) disas 0x08048b24 > > Dump of assembler code for function do_typedef: > > 0x08048b10 : push %ebp > > 0x08048b11 : mov %esp,%ebp > > 0x08048b13 : push %ebx > > 0x08048b14 : push %edi > > 0x08048b15 : push %esi > > 0x08048b16 : sub $0xc,%esp > > 0x08048b19 : mov $0x805e1d4,%edi > > 0x08048b1e : mov 0x10(%ebp),%esi > > 0x08048b21 : mov 0x8(%ebp),%ebx > > 0x08048b24 : nopw %cs:0x0(%eax,%eax,1) >=20 > LLVM attempts to use an optimal nop sequence when writing N-byte nop, > by using these nop instructions >=20 > static const uint8_t Nops[10][10] =3D { > // nop > {0x90}, > // xchg %ax,%ax > {0x66, 0x90}, > // nopl (%[re]ax) > {0x0f, 0x1f, 0x00}, > // nopl 0(%[re]ax) > {0x0f, 0x1f, 0x40, 0x00}, > // nopl 0(%[re]ax,%[re]ax,1) > {0x0f, 0x1f, 0x44, 0x00, 0x00}, > // nopw 0(%[re]ax,%[re]ax,1) > {0x66, 0x0f, 0x1f, 0x44, 0x00, 0x00}, > // nopl 0L(%[re]ax) > {0x0f, 0x1f, 0x80, 0x00, 0x00, 0x00, 0x00}, > // nopl 0L(%[re]ax,%[re]ax,1) > {0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00}, > // nopw 0L(%[re]ax,%[re]ax,1) > {0x66, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00}, > // nopw %cs:0L(%[re]ax,%[re]ax,1) > {0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00}, > }; >=20 > There's no checking for a supported CPU, is it so that AMD geode doesnt s= upport any of these? > Any other cpu that doesnt support these? If this is CPU dependant, I sugg= est to open a bug > report upstream as it's a bug. Long nops are supported only on specific CPUs. Unconditional use of them is a plain bug, like unconditional use of cmovXX. --8Y8a5CJOPM/zJV44 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk6j07EACgkQC3+MBN1Mb4jKGgCePnVGFf8bcwIJj4CGnN/gzw7V tv0AoL19C0JxUJyoR/BXubZJQoBO8YUQ =6+hY -----END PGP SIGNATURE----- --8Y8a5CJOPM/zJV44-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 23 08:45:00 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E73DA1065676; Sun, 23 Oct 2011 08:44:59 +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 66A5A8FC15; Sun, 23 Oct 2011 08:44:59 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p9N8ik5V047727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 23 Oct 2011 11:44:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id p9N8ij5D083505; Sun, 23 Oct 2011 11:44:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id p9N8ijEU083504; Sun, 23 Oct 2011 11:44:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 23 Oct 2011 11:44:45 +0300 From: Kostik Belousov To: Pawel Jakub Dawidek Message-ID: <20111023084445.GB50300@deviant.kiev.zoral.com.ua> References: <20111022084931.GD1697@garage.freebsd.pl> <4EA36F53.9050907@freebsd.org> <20111023061038.GE1697@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NP+fiIeNjDlB/E6h" Content-Disposition: inline In-Reply-To: <20111023061038.GE1697@garage.freebsd.pl> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Lawrence Stewart , freebsd-current@freebsd.org, Andre Oppermann , freebsd-net@freebsd.org Subject: Re: 9.0-RC1 panic in tcp_input: negative winow. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Oct 2011 08:45:00 -0000 --NP+fiIeNjDlB/E6h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 23, 2011 at 08:10:38AM +0200, Pawel Jakub Dawidek wrote: > On Sun, Oct 23, 2011 at 12:35:15PM +1100, Lawrence Stewart wrote: > > On 10/22/11 19:49, Pawel Jakub Dawidek wrote: > > > The panic message says: > > > > > > panic: tcp_input negative window: tp 0xfffffe007763e000 rcv_nxt 3718= 269252 rcv_adv 3718268291 > > > > > > I only have picture of the backtrace: > > > > > > http://people.freebsd.org/~pjd/misc/panic_negative_window.jpg > > > > >=20 > > ewww that is not good. Can you give us any more information about the= =20 > > machine and what it's doing? Is it terminating TCP connections from the= =20 > > internet at large or only local LAN (i.e. is there likely to be packet= =20 > > loss happening)? Are you doing TSO or LRO? Do you have any non-default= =20 > > tuning in place? >=20 > It is my local file server. It is doing NFS and AFP over LAN and also > downloads files from the internet. It is triggered after few hours. > I changed the KASSERT() into printf() and added printing 'win' variable > and this is what got logged during the night: >=20 > 05:16:24 tcp_input negative window: tp 0xfffffe0026772b70 rcv_nxt 1107827= 269 rcv_adv 1107826256 win=3D242 > 05:16:29 tcp_input negative window: tp 0xfffffe0026772b70 rcv_nxt 1107833= 451 rcv_adv 1107832977 win=3D880 > 05:16:41 tcp_input negative window: tp 0xfffffe0026772b70 rcv_nxt 1107849= 563 rcv_adv 1107848860 win=3D639 > 05:20:02 tcp_input negative window: tp 0xfffffe0026772b70 rcv_nxt 1108108= 230 rcv_adv 1108107331 win=3D567 > 05:24:30 tcp_input negative window: tp 0xfffffe0026772b70 rcv_nxt 1108433= 302 rcv_adv 1108432272 win=3D974 > 05:24:46 tcp_input negative window: tp 0xfffffe0026772b70 rcv_nxt 1108450= 385 rcv_adv 1108450060 win=3D751 > 05:26:44 tcp_input negative window: tp 0xfffffe0026772b70 rcv_nxt 1108574= 818 rcv_adv 1108573851 win=3D71 > 05:28:03 tcp_input negative window: tp 0xfffffe0026772b70 rcv_nxt 1108654= 103 rcv_adv 1108653166 win=3D0 > 05:28:43 tcp_input negative window: tp 0xfffffe0026772b70 rcv_nxt 1108692= 396 rcv_adv 1108691451 win=3D0 > 05:30:06 tcp_input negative window: tp 0xfffffe0026772b70 rcv_nxt 1108781= 258 rcv_adv 1108780372 win=3D235 > 05:35:05 tcp_input negative window: tp 0xfffffe0026772b70 rcv_nxt 1109067= 578 rcv_adv 1109067335 win=3D663 > 05:37:03 tcp_input negative window: tp 0xfffffe0026772b70 rcv_nxt 1109180= 403 rcv_adv 1109179411 win=3D0 > 05:41:03 tcp_input negative window: tp 0xfffffe0026772b70 rcv_nxt 1109428= 265 rcv_adv 1109427375 win=3D170 >=20 > And the systems seems to be fine. >=20 > I'm happy to test patches, but one round would take 24h. >=20 > My suggestion would be that if we won't be able to fix it before 9.0, > we should turn this assertion off, as the system seems to be able to > recover. Shipped kernels have all assertions turned off. --NP+fiIeNjDlB/E6h Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk6j0/0ACgkQC3+MBN1Mb4h5iwCfQa26LAP0gzvVdmSIiR9rLNvj 5UsAnRPP8tZxdYYn9jOXOHo2pvnPM0bJ =/lze -----END PGP SIGNATURE----- --NP+fiIeNjDlB/E6h-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 23 10:11:10 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15C24106566C for ; Sun, 23 Oct 2011 10:11:10 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [46.28.110.116]) by mx1.freebsd.org (Postfix) with ESMTP id CEEF18FC08 for ; Sun, 23 Oct 2011 10:11:09 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id E36687F3822; Sun, 23 Oct 2011 12:11:05 +0200 (CEST) Date: Sun, 23 Oct 2011 12:11:05 +0200 From: Roman Divacky To: Kostik Belousov Message-ID: <20111023101105.GA87729@freebsd.org> References: <20111022205129.32569ec5@davenulle.org> <20111023082412.GA74520@freebsd.org> <20111023084330.GA50300@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111023084330.GA50300@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Current , Patrick Lamaiziere Subject: Re: 9.0 RC1/Clang / illegal instruction (Signal 4) in gengtype while building cc_tools on i586. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Oct 2011 10:11:10 -0000 On Sun, Oct 23, 2011 at 11:43:30AM +0300, Kostik Belousov wrote: > On Sun, Oct 23, 2011 at 10:24:12AM +0200, Roman Divacky wrote: > > > Program received signal SIGILL, Illegal instruction. > > > 0x08048b24 in do_typedef (s=0x80532bf "CUMULATIVE_ARGS", pos=0x805e1a4) > > > at /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/gengtype.c:103 > > > 103 { > > > > > > (gdb) disas 0x08048b24 > > > Dump of assembler code for function do_typedef: > > > 0x08048b10 : push %ebp > > > 0x08048b11 : mov %esp,%ebp > > > 0x08048b13 : push %ebx > > > 0x08048b14 : push %edi > > > 0x08048b15 : push %esi > > > 0x08048b16 : sub $0xc,%esp > > > 0x08048b19 : mov $0x805e1d4,%edi > > > 0x08048b1e : mov 0x10(%ebp),%esi > > > 0x08048b21 : mov 0x8(%ebp),%ebx > > > 0x08048b24 : nopw %cs:0x0(%eax,%eax,1) > > > > LLVM attempts to use an optimal nop sequence when writing N-byte nop, > > by using these nop instructions > > > > static const uint8_t Nops[10][10] = { > > // nop > > {0x90}, > > // xchg %ax,%ax > > {0x66, 0x90}, > > // nopl (%[re]ax) > > {0x0f, 0x1f, 0x00}, > > // nopl 0(%[re]ax) > > {0x0f, 0x1f, 0x40, 0x00}, > > // nopl 0(%[re]ax,%[re]ax,1) > > {0x0f, 0x1f, 0x44, 0x00, 0x00}, > > // nopw 0(%[re]ax,%[re]ax,1) > > {0x66, 0x0f, 0x1f, 0x44, 0x00, 0x00}, > > // nopl 0L(%[re]ax) > > {0x0f, 0x1f, 0x80, 0x00, 0x00, 0x00, 0x00}, > > // nopl 0L(%[re]ax,%[re]ax,1) > > {0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00}, > > // nopw 0L(%[re]ax,%[re]ax,1) > > {0x66, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00}, > > // nopw %cs:0L(%[re]ax,%[re]ax,1) > > {0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00}, > > }; > > > > There's no checking for a supported CPU, is it so that AMD geode doesnt support any of these? > > Any other cpu that doesnt support these? If this is CPU dependant, I suggest to open a bug > > report upstream as it's a bug. > > Long nops are supported only on specific CPUs. Unconditional use of them > is a plain bug, like unconditional use of cmovXX. Yes, it's a bug, I filed http://llvm.org/bugs/show_bug.cgi?id=11212 upstream. Patric, as a temporary workaround please add "-no-integrated-as" to your CFLAGS, that will make clang use gnu as instead of its own intergrated assembler, thus avoiding this problem. Thanks for the great analysis! roman From owner-freebsd-current@FreeBSD.ORG Sun Oct 23 12:50:46 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34446106566C for ; Sun, 23 Oct 2011 12:50:46 +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 7FD158FC12 for ; Sun, 23 Oct 2011 12:50:44 +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 PAA04164; Sun, 23 Oct 2011 15:50:39 +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 1RHxVe-0003at-Rv; Sun, 23 Oct 2011 15:50:38 +0300 Message-ID: <4EA40D9D.7030003@FreeBSD.org> Date: Sun, 23 Oct 2011 15:50:37 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111002 Thunderbird/7.0.1 MIME-Version: 1.0 To: Gunnar Schaefer References: <20111021085851.GA51368@neveragain.de> <201110211633.38764.jhb@freebsd.org> <4EA1E3D0.9000300@FreeBSD.org> <4EA1E60C.8040403@FreeBSD.org> <1B6A6A46-C971-450D-A744-C325B2DA0B34@stanford.edu> In-Reply-To: <1B6A6A46-C971-450D-A744-C325B2DA0B34@stanford.edu> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Fresh installed Freebsd 9 don't boot from hd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Oct 2011 12:50:46 -0000 on 22/10/2011 01:22 Gunnar Schaefer said the following: > On Oct 21, 2011, at 2:37 PM, Andriy Gapon wrote: >> A litmus question: do those experiencing the trouble all have BTX_SERIAL defined? > > Not sure where BTX_SERIAL would be defined, but I'm seeing the problem with the generic kernel. Does that answer your question? It's a make knob for boot code. > Also, how does this relate to my observation that my system boots in IDE mode, but hangs in AHCI mode? No relation. I do not have any explanation for what you experience. I believe that FreeBSD code doesn't know anything about IDE vs AHCI and interacts with HDDs entirely through BIOS interfaces. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Oct 23 13:38:22 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3816E1065670 for ; Sun, 23 Oct 2011 13:38:22 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [94.23.254.147]) by mx1.freebsd.org (Postfix) with ESMTP id DD6A78FC0C for ; Sun, 23 Oct 2011 13:38:21 +0000 (UTC) Received: from baby-jane.lamaiziere.net (63.9.74.86.rev.sfr.net [86.74.9.63]) by smtp.lamaiziere.net (Postfix) with ESMTPA id C3E62FAA31A5; Sun, 23 Oct 2011 15:38:20 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id A9C2E73106; Sun, 23 Oct 2011 15:38:21 +0200 (CEST) Date: Sun, 23 Oct 2011 15:38:21 +0200 From: Patrick Lamaiziere To: Roman Divacky Message-ID: <20111023153821.37870302@davenulle.org> In-Reply-To: <20111023101105.GA87729@freebsd.org> References: <20111022205129.32569ec5@davenulle.org> <20111023082412.GA74520@freebsd.org> <20111023084330.GA50300@deviant.kiev.zoral.com.ua> <20111023101105.GA87729@freebsd.org> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: FreeBSD Current Subject: Re: 9.0 RC1/Clang / illegal instruction (Signal 4) in gengtype while building cc_tools on i586. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Oct 2011 13:38:22 -0000 Le Sun, 23 Oct 2011 12:11:05 +0200, Roman Divacky a écrit : > > Long nops are supported only on specific CPUs. Unconditional use of > > them is a plain bug, like unconditional use of cmovXX. > > Yes, it's a bug, I filed http://llvm.org/bugs/show_bug.cgi?id=11212 > upstream. Patric, as a temporary workaround please add > "-no-integrated-as" to your CFLAGS, that will make clang use gnu as > instead of its own intergrated assembler, thus avoiding this problem. Unless you think that it will be helpful to test with the workaround, I would prefer to test patches from llvm (it takes days to build FreeBSD on a net5501...). This proves it is useful to test with uncommon hardware, and I would like to check the crypto engine, hifn(4) and glxsb(4) built with llvm (that worked fine around january). Thanks a lot, regards. From owner-freebsd-current@FreeBSD.ORG Sun Oct 23 13:43:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 283D21065675; Sun, 23 Oct 2011 13:43:25 +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 DE26E8FC0A; Sun, 23 Oct 2011 13:43:24 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:7cad:61c8:8c4a:e83f]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 769004AC2D; Sun, 23 Oct 2011 17:43:23 +0400 (MSD) Date: Sun, 23 Oct 2011 17:43:22 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <3110594059.20111023174322@serebryakov.spb.ru> To: Patrick Lamaiziere In-Reply-To: <20111023153821.37870302@davenulle.org> References: <20111022205129.32569ec5@davenulle.org> <20111023082412.GA74520@freebsd.org> <20111023084330.GA50300@deviant.kiev.zoral.com.ua> <20111023101105.GA87729@freebsd.org> <20111023153821.37870302@davenulle.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: Roman Divacky , FreeBSD Current Subject: Re: 9.0 RC1/Clang / illegal instruction (Signal 4) in gengtype while building cc_tools on i586. 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: Sun, 23 Oct 2011 13:43:25 -0000 Hello, Patrick. You wrote 23 =EE=EA=F2=FF=E1=F0=FF 2011 =E3., 17:38:21: > Unless you think that it will be helpful to test with the workaround, I > would prefer to test patches from llvm (it takes days to build FreeBSD > on a net5501...). Another important case: build on "common" hardware for such "strange" systems. My net5501 boots from image built on Intel Q9650-based system (i386, of course). --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Sun Oct 23 15:27:56 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FACF106564A; Sun, 23 Oct 2011 15:27:56 +0000 (UTC) (envelope-from dkmail@mail.neveragain.de) Received: from mail.neveragain.de (mail.neveragain.de [IPv6:2001:aa8:fffc::25]) by mx1.freebsd.org (Postfix) with ESMTP id 9FA118FC13; Sun, 23 Oct 2011 15:27:55 +0000 (UTC) Received: by mail.neveragain.de (Postfix, from userid 1029) id 5941517025; Sun, 23 Oct 2011 17:27:54 +0200 (CEST) Date: Sun, 23 Oct 2011 17:27:54 +0200 From: Dennis Koegel To: John Baldwin Message-ID: <20111023152754.GA35505@neveragain.de> References: <20111021085851.GA51368@neveragain.de> <201110211633.38764.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201110211633.38764.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Pavel Timofeev , freebsd-current@freebsd.org, avg@freebsd.org Subject: Re: Fresh installed Freebsd 9 don't boot from hd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Oct 2011 15:27:56 -0000 On Fri, Oct 21, 2011 at 04:33:38PM -0400, John Baldwin wrote: > Working offline with Dennis, we found that changing the CFLAGS in > sys/boot/i386/gptboot/Makefile from "-O1" to "-Os -mrtd" (partially reverting > an earlier commit) fixed gptboot. The next test for someone to do would be to > try just adding "-mrtd" and leaving "-O1" as-is to see if that fixes it. More test results: gcc -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time \ -mno-align-long-strings -mrtd [from before r225530]: Boots OK gcc -Os -mrtd: Boots OK gcc -O1 -mrtd: Fails gcc -O1: Fails gcc -O0: Fails gcc -Os: Boots OK clang -O1: Fails clang -Os: Fails clang -Oz: Fails I've put some printf()s into gpt{,boot}.c to trace where the reboot is triggered. It appears to be in drvsize() (called from gptread()). OTOH the debug output may have changed where the problem occurs, I don't know about that. With 9.0R drawing near, CFLAGS should be s/-O1/-Os/, until we can figure out what happens. But as for why gcc's magic -Os is required and clang's output doesn't work at all, I'm clueless. - D. From owner-freebsd-current@FreeBSD.ORG Sun Oct 23 15:59:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA226106564A; Sun, 23 Oct 2011 15:59:16 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 8B0CF8FC08; Sun, 23 Oct 2011 15:59:16 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id DEB075D5; Sun, 23 Oct 2011 17:59:14 +0200 (CEST) Date: Sun, 23 Oct 2011 17:58:28 +0200 From: Pawel Jakub Dawidek To: Kostik Belousov Message-ID: <20111023155827.GH1697@garage.freebsd.pl> References: <20111022084931.GD1697@garage.freebsd.pl> <4EA36F53.9050907@freebsd.org> <20111023061038.GE1697@garage.freebsd.pl> <20111023084445.GB50300@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="K1n7F7fSdjvFAEnM" Content-Disposition: inline In-Reply-To: <20111023084445.GB50300@deviant.kiev.zoral.com.ua> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Lawrence Stewart , freebsd-current@freebsd.org, Andre Oppermann , freebsd-net@freebsd.org Subject: Re: 9.0-RC1 panic in tcp_input: negative winow. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Oct 2011 15:59:16 -0000 --K1n7F7fSdjvFAEnM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 23, 2011 at 11:44:45AM +0300, Kostik Belousov wrote: > On Sun, Oct 23, 2011 at 08:10:38AM +0200, Pawel Jakub Dawidek wrote: > > My suggestion would be that if we won't be able to fix it before 9.0, > > we should turn this assertion off, as the system seems to be able to > > recover. >=20 > Shipped kernels have all assertions turned off. Yes, I'm aware of that, but many people compile their production kernels with INVARIANTS/INVARIANT_SUPPORT to fail early instead of eg. corrupting data. I'd be fine in moving this under DIAGNOSTIC or changing it into a printf, so it will be visible. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --K1n7F7fSdjvFAEnM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk6kOaMACgkQForvXbEpPzT1ngCgtl7iI+54RRH21P4rNgTdJm/V 2OQAn08pCE6pj5aAo4Sz6SiCLkv3rXlR =eaYX -----END PGP SIGNATURE----- --K1n7F7fSdjvFAEnM-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 23 17:58:05 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3AC4106566B; Sun, 23 Oct 2011 17:58:05 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9CDD28FC14; Sun, 23 Oct 2011 17:58:04 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA06313; Sun, 23 Oct 2011 20:58:01 +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 1RI2J7-0003hh-39; Sun, 23 Oct 2011 20:58:01 +0300 Message-ID: <4EA455A7.2060301@FreeBSD.org> Date: Sun, 23 Oct 2011 20:57:59 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111002 Thunderbird/7.0.1 MIME-Version: 1.0 To: Dennis Koegel References: <20111021085851.GA51368@neveragain.de> <201110211633.38764.jhb@freebsd.org> <20111023152754.GA35505@neveragain.de> In-Reply-To: <20111023152754.GA35505@neveragain.de> X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Pavel Timofeev , freebsd-current@FreeBSD.org, John Baldwin Subject: Re: Fresh installed Freebsd 9 don't boot from hd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Oct 2011 17:58:05 -0000 on 23/10/2011 18:27 Dennis Koegel said the following: > On Fri, Oct 21, 2011 at 04:33:38PM -0400, John Baldwin wrote: >> Working offline with Dennis, we found that changing the CFLAGS in >> sys/boot/i386/gptboot/Makefile from "-O1" to "-Os -mrtd" (partially reverting >> an earlier commit) fixed gptboot. The next test for someone to do would be to >> try just adding "-mrtd" and leaving "-O1" as-is to see if that fixes it. > > More test results: > > gcc -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time \ > -mno-align-long-strings -mrtd [from before r225530]: Boots OK > gcc -Os -mrtd: Boots OK > gcc -O1 -mrtd: Fails > gcc -O1: Fails > gcc -O0: Fails > gcc -Os: Boots OK > > clang -O1: Fails > clang -Os: Fails > clang -Oz: Fails > > I've put some printf()s into gpt{,boot}.c to trace where the reboot is > triggered. It appears to be in drvsize() (called from gptread()). OTOH > the debug output may have changed where the problem occurs, I don't > know about that. > > With 9.0R drawing near, CFLAGS should be s/-O1/-Os/, until we can figure > out what happens. But as for why gcc's magic -Os is required and clang's > output doesn't work at all, I'm clueless. Thank you for your very valuable analysis! I looked at a difference in assembly code of the drvsize function produced by gcc -Os and by gcc -O1. One thing that was immediately obvious is that gcc places the params array and the sectors variable in a different order for different options. One idea is that if BIOS actually writes beyond the end of the array, then in one case it could be harmless (overwrites the sector variable), but in the other case it could be more harmful. I found a document that suggests a possibility of BIOS writing more bytes to the array than its current size of 0x42: http://www.t13.org/documents/UploadedDocuments/docs2008/e08134r1-BIOS_Enhanced_Disk_Drive_Services_4.0.pdf Of course, the size of the array is passed to BIOS at the start of the array and so a _non-buggy_ BIOS should not write beyond the array, but we live in a non-perfect world. Could you please test this hypothesis by trying the following patch? diff --git a/sys/boot/i386/common/drv.c b/sys/boot/i386/common/drv.c index 11f6628..5996a80 100644 --- a/sys/boot/i386/common/drv.c +++ b/sys/boot/i386/common/drv.c @@ -37,10 +37,10 @@ __FBSDID("$FreeBSD$"); uint64_t drvsize(struct dsk *dskp) { - unsigned char params[0x42]; + unsigned char params[0x4A]; uint64_t sectors; - *(uint32_t *)params = sizeof(params); + *(uint16_t *)params = sizeof(params); v86.ctl = V86_FLAGS; v86.addr = 0x13; P.S. the assembly diff to which I referred above: --- drvsize.Os.S 2011-10-23 20:17:56.871996966 +0300 +++ drvsize.O1.S 2011-10-23 20:18:27.430995560 +0300 @@ -4,8 +4,8 @@ pushl %ebp movl %esp, %ebp subl $76, %esp - leal -74(%ebp), %ecx - movl $66, -74(%ebp) + leal -66(%ebp), %ecx + movl $66, -66(%ebp) movl $262144, __v86 movl $19, __v86+4 movl $18432, __v86+24 @@ -28,20 +28,20 @@ pushl %eax pushl $.LC4 call printf - xorl %eax, %eax - xorl %edx, %edx - popl %ecx - popl %ecx + movl $0, %eax + movl $0, %edx + addl $8, %esp jmp .L16 + .p2align 2,,3 .L14: pushl $8 - leal -58(%ebp), %eax + leal -50(%ebp), %eax pushl %eax - leal -8(%ebp), %eax + leal -76(%ebp), %eax pushl %eax call memcpy - movl -8(%ebp), %eax - movl -4(%ebp), %edx + movl -76(%ebp), %eax + movl -72(%ebp), %edx addl $12, %esp .L16: leave -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Oct 23 18:20:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73027106566B; Sun, 23 Oct 2011 18:20:25 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1D7C38FC08; Sun, 23 Oct 2011 18:20:24 +0000 (UTC) Received: by vcbfo13 with SMTP id fo13so6724564vcb.13 for ; Sun, 23 Oct 2011 11:20:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=rVEc+R2m0what9RQKNFHULWAHqnxVjO/JUmEcOR8MP8=; b=DjOo5cz0GZKtBFySQ4UfDgetHOqAOdtWUoMH6Q1vMhod6F0A9mafoYbkjocPYXkoBr NhCY5e5XP3SxgrfVeytvJKgpXviHQnYGPpXfr1EE8gWgX1QQiZKWTAeS5hpTBhnV93Zg tCdKXuoJRq55pVOODYoBzTNmNtvJgAER7vCQE= MIME-Version: 1.0 Received: by 10.52.68.240 with SMTP id z16mr20079334vdt.120.1319394024340; Sun, 23 Oct 2011 11:20:24 -0700 (PDT) Received: by 10.220.199.138 with HTTP; Sun, 23 Oct 2011 11:20:24 -0700 (PDT) In-Reply-To: <1319341433.49428.7.camel@neo.cse.buffalo.edu> References: <1319341433.49428.7.camel@neo.cse.buffalo.edu> Date: Sun, 23 Oct 2011 22:20:24 +0400 Message-ID: From: Andrey Fesenko To: Ken Smith Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-stable Subject: Re: FreeBSD 9.0-RC1 Available... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Oct 2011 18:20:25 -0000 On Sun, Oct 23, 2011 at 7:43 AM, Ken Smith wrote: > > The 9.0-RELEASE cycle will be tracked here: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0http://wiki.freebsd.org/Releng/9.0-TODO > link error, need http://wiki.freebsd.org/Releng/9.0TODO still no actual information on this page. Branch status not actual. From owner-freebsd-current@FreeBSD.ORG Sun Oct 23 19:02:45 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8E3B106566B; Sun, 23 Oct 2011 19:02:45 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailB.acsu.buffalo.edu (localmailb.acsu.buffalo.edu [128.205.5.200]) by mx1.freebsd.org (Postfix) with ESMTP id AAA808FC0C; Sun, 23 Oct 2011 19:02:45 +0000 (UTC) Received: from localmailB.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 42713ADDB; Sun, 23 Oct 2011 15:02:43 -0400 (EDT) Received: from localmailB.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailB.acsu.buffalo.edu (Postfix) with ESMTP id 9A3E816A52; Sun, 23 Oct 2011 15:02:42 -0400 (EDT) Received: from smtp1.acsu.buffalo.edu (smtp1.acsu.buffalo.edu [128.205.5.253]) by localmailB.acsu.buffalo.edu (Prefixe) with ESMTP id 927FEADDB; Sun, 23 Oct 2011 15:02:42 -0400 (EDT) Received: from ken-smiths-macbook-pro.local (cpe-72-231-248-9.buffalo.res.rr.com [72.231.248.9]) (Authenticated sender: kensmith@buffalo.edu) by smtp1.acsu.buffalo.edu (Postfix) with ESMTPSA id 5044946098; Sun, 23 Oct 2011 15:02:42 -0400 (EDT) Message-ID: <4EA464C4.70105@buffalo.edu> Date: Sun, 23 Oct 2011 15:02:28 -0400 From: Ken Smith User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Andrey Fesenko References: <1319341433.49428.7.camel@neo.cse.buffalo.edu> In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-PM-EL-Spam-Prob: XX: 28% Cc: freebsd-current@freebsd.org, freebsd-stable Subject: Re: FreeBSD 9.0-RC1 Available... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Oct 2011 19:02:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/23/11 2:20 PM, Andrey Fesenko wrote: > On Sun, Oct 23, 2011 at 7:43 AM, Ken Smith > wrote: >> >> The 9.0-RELEASE cycle will be tracked here: >> >> http://wiki.freebsd.org/Releng/9.0-TODO >> > > link error, need http://wiki.freebsd.org/Releng/9.0TODO Correct, sorry about the hyphen sneaking in. > still no actual information on this page. Branch status not > actual. I updated the dates. If by "Branch Status" you're referring to the section with that title it is actual. We've created stable/9 but not releng/9.0 yet. That might come with RC2, sorta depends on how much people find wrong with RC1. When releng/9.0 gets created it will take one commit and two merges to get fixes into 9.0-RELEASE which is a bit of a pain if there is a lot of activity. - -- Ken Smith - - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodor Geisel | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6kZMQACgkQ/G14VSmup/amiACgj1mmb1TG+39IlZzQzFRTIcKi mGYAn2kdMJ5A8HEK6wBhE2RgrQmRKLzr =/j9J -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Oct 23 19:56:16 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2AD0106566B; Sun, 23 Oct 2011 19:56:16 +0000 (UTC) (envelope-from dkmail@mail.neveragain.de) Received: from mail.neveragain.de (mail.neveragain.de [IPv6:2001:aa8:fffc::25]) by mx1.freebsd.org (Postfix) with ESMTP id 88CD68FC0A; Sun, 23 Oct 2011 19:56:16 +0000 (UTC) Received: by mail.neveragain.de (Postfix, from userid 1029) id 7425A1702D; Sun, 23 Oct 2011 21:56:15 +0200 (CEST) Date: Sun, 23 Oct 2011 21:56:15 +0200 From: Dennis Koegel To: Andriy Gapon Message-ID: <20111023195615.GB35505@neveragain.de> References: <20111021085851.GA51368@neveragain.de> <201110211633.38764.jhb@freebsd.org> <20111023152754.GA35505@neveragain.de> <4EA455A7.2060301@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4EA455A7.2060301@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: Pavel Timofeev , freebsd-current@FreeBSD.org, John Baldwin Subject: Re: Fresh installed Freebsd 9 don't boot from hd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Oct 2011 19:56:16 -0000 On Sun, Oct 23, 2011 at 08:57:59PM +0300, Andriy Gapon wrote: > I found a document that suggests a possibility of BIOS writing more bytes to the > array than its current size of 0x42: [...] > Could you please test this hypothesis by trying the following patch? With -O1 and this patch, it boots. Thank you! - D. From owner-freebsd-current@FreeBSD.ORG Sun Oct 23 20:08:32 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F46B106566B; Sun, 23 Oct 2011 20:08:32 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4DF2C8FC12; Sun, 23 Oct 2011 20:08:32 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:49e5:3d59:f85e:515a] (unknown [IPv6:2001:7b8:3a7:0:49e5:3d59:f85e:515a]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 8E6765C37; Sun, 23 Oct 2011 22:08:31 +0200 (CEST) Message-ID: <4EA47446.5060405@FreeBSD.org> Date: Sun, 23 Oct 2011 22:08:38 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111012 Thunderbird/8.0 MIME-Version: 1.0 To: Dennis Koegel References: <20111021085851.GA51368@neveragain.de> <201110211633.38764.jhb@freebsd.org> <20111023152754.GA35505@neveragain.de> <4EA455A7.2060301@FreeBSD.org> <20111023195615.GB35505@neveragain.de> In-Reply-To: <20111023195615.GB35505@neveragain.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Pavel Timofeev , freebsd-current@FreeBSD.org, John Baldwin , Andriy Gapon Subject: Re: Fresh installed Freebsd 9 don't boot from hd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Oct 2011 20:08:32 -0000 On 2011-10-23 21:56, Dennis Koegel wrote: > On Sun, Oct 23, 2011 at 08:57:59PM +0300, Andriy Gapon wrote: >> I found a document that suggests a possibility of BIOS writing more bytes to the >> array than its current size of 0x42: [...] >> Could you please test this hypothesis by trying the following patch? > > With -O1 and this patch, it boots. Thank you! If you have some time, can you also re-check the other cases you listed before? E.g.: gcc -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time \ -mno-align-long-strings -mrtd [from before r225530]: gcc -Os -mrtd: gcc -O1 -mrtd: gcc -O1: gcc -O0: gcc -Os: clang -O1: clang -Os: clang -Oz: Thanks. :) From owner-freebsd-current@FreeBSD.ORG Sun Oct 23 21:52:35 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AFAD1065670 for ; Sun, 23 Oct 2011 21:52:35 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1BD1F8FC0A for ; Sun, 23 Oct 2011 21:52:34 +0000 (UTC) Received: by qadz32 with SMTP id z32so2855002qad.13 for ; Sun, 23 Oct 2011 14:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=hp4Cj/9dnJ7/qAVUuhoIbswLYZrcwmzo9CtCcgACGtc=; b=tQHmunM9027mMfl6znTeafCYKpYKW4dsUmeZMe49Pcit1njS6U55TnwcuHH35KsuER l8d21LwVl+LrnaC0delnZOlcWclAy0zDajLFaiswa1pZgNNa93dx4flCbMlPw0rdYyUo Vgh27tfauUTyOLZ9zfjF+szSENl8QnH8P7jZc= MIME-Version: 1.0 Received: by 10.224.187.75 with SMTP id cv11mr16979805qab.89.1319405343916; Sun, 23 Oct 2011 14:29:03 -0700 (PDT) Received: by 10.224.19.212 with HTTP; Sun, 23 Oct 2011 14:29:03 -0700 (PDT) Date: Sun, 23 Oct 2011 17:29:03 -0400 Message-ID: From: Mehmet Erol Sanliturk To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: FreeBSD 9.0 RC1 USB Mouse and Keyboard X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Oct 2011 21:52:35 -0000 I have installed FreeBSD 9.0 RC1 . During installation and boots , and ( as root ) console mode , both USB keyboard and mouse are working . When a graphical desktop ( Fluxbox , Gnome , or KDE ) is started , both of them are becoming frozen . Detach and attach of mouse are detected , but input is not possible . PS/2 mouse is also not working . I did not check PS/2 keyboard . Only Ctrl-Alt-F1 is discontinuing graphical display , and Ctrl-C is returning to root prompt . KDE is staying as it is after displaying of hard disk symbol and then it is waiting there . Gnome is displaying all the parts , but no input possibility . Fluxbox is displaying its window , but no input possibility . It seems that X is NOT able to register dbus related parts ( understood from messages left on the screen after discontinuation ) . On the same computer , I have installed Fedora 15 and everything is working as expected , means there is no any hardware problem . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Sun Oct 23 21:54:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A44D71065675; Sun, 23 Oct 2011 21:54:29 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 174738FC13; Sun, 23 Oct 2011 21:54:28 +0000 (UTC) Received: by wyi40 with SMTP id 40so7191310wyi.13 for ; Sun, 23 Oct 2011 14:54:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=phqavS7bPsdmbSb/pGRywCZIAV1KdIDaF65e4WiQoqM=; b=e4EBpxsnYEVfGaVHakFR10B5vuWPGLkQ3GlcxpKQ6JcrEtJE839mzD4QDz+DbyRaDZ wVK+NaWZe1DG4Li6g2U1TIERCOpLoEyWBIELz+iCxLso6KTHWUZCCrF0YGJ8JLuLn4ha jng0zbv/7d/Fm63UbTXVdp6ojx1Z2prsMcvKc= MIME-Version: 1.0 Received: by 10.216.82.78 with SMTP id n56mr72871wee.71.1319406868067; Sun, 23 Oct 2011 14:54:28 -0700 (PDT) Received: by 10.180.105.162 with HTTP; Sun, 23 Oct 2011 14:54:28 -0700 (PDT) In-Reply-To: <4E8F5D47.9070904@yandex.ru> References: <81477.1318015137@critter.freebsd.dk> <4E8F55CC.3060302@FreeBSD.org> <4E8F5D47.9070904@yandex.ru> Date: Sun, 23 Oct 2011 17:54:28 -0400 Message-ID: From: Arnaud Lacombe To: "Andrey V. Elsukov" Content-Type: text/plain; charset=ISO-8859-1 Cc: Warren Block , Garrett Cooper , Glen Barber , Poul-Henning Kamp , freebsd-current@freebsd.org, Benjamin Kaduk Subject: Re: aliasing (or renaming) kern.geom.debugflags X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Oct 2011 21:54:29 -0000 Hi, 2011/10/7 Andrey V. Elsukov : > On 07.10.2011 23:41, Glen Barber wrote: >> In my experience, without kern.geom.debugflags=16, the MBR will not be >> written to the memstick, leaving you with what would effectively be a >> coaster in the not-so-distant past. > > The problem is that this bad suggestion is everywhere in the Internet. > And users use it always even when it not needed. I think it is bad idea > add it in the our official documentation. FWIW, boot0cfg(8) also mentions it: NOTE Protection mechanisms in the geom(4) subsystem might prevent boot0cfg from being able to update the MBR on a mounted disk. Instructions for temporarily disabling these protection mechanisms can be found in the geom(4) manpage. Specifically, do a sysctl kern.geom.debugflags=0x10 to allow writing to the MBR, and restore it to 0 afterwards. - Arnaud > When you doing all in the right way using debugflags=16 is not needed. > And it is really dangerous when you doing something what you do not know > exactly. > > -- > WBR, Andrey V. Elsukov > > From owner-freebsd-current@FreeBSD.ORG Sun Oct 23 22:31:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6FF61065675 for ; Sun, 23 Oct 2011 22:31:24 +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 94BEF8FC0C for ; Sun, 23 Oct 2011 22:31:24 +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 <1RI6Zf-0003IZ-Cs>; Mon, 24 Oct 2011 00:31:23 +0200 Received: from e178040207.adsl.alicedsl.de ([85.178.40.207] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1RI6Zf-000365-9i>; Mon, 24 Oct 2011 00:31:23 +0200 Message-ID: <4EA495BA.7080802@zedat.fu-berlin.de> Date: Mon, 24 Oct 2011 00:31:22 +0200 From: "Hartmann, O." User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111019 Thunderbird/7.0.1 To: freebsd-current Content-Transfer-Encoding: 8bit X-Originating-IP: 85.178.40.207 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: "/usr/src/sys/conf/kern.mk", line 10: Malformed conditional (${FREEBSD_GCC}), "/usr/src/sys/conf/kern.mk", line 14: if-less endif X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Oct 2011 22:31:24 -0000 Kernel building fails since today when kernel gets compiled via CLANG: -------------------------------------------------------------- >>> stage 2.1: cleaning up the object tree -------------------------------------------------------------- cd /usr/obj/usr/src/sys/THOR; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE=native GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp VERSION="FreeBSD 10.0-CURRENT amd64 1000000" INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/ usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr /sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbi n:/bin:/usr/sbin:/usr/bin /usr/obj/usr/src/make.amd64/make KERNEL=kernel cleandir "/usr/src/sys/conf/kern.mk", line 10: Malformed conditional (${FREEBSD_GCC}) "/usr/src/sys/conf/kern.mk", line 14: if-less endif make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. From owner-freebsd-current@FreeBSD.ORG Sun Oct 23 22:38:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05D64106564A for ; Sun, 23 Oct 2011 22:38:24 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id C36BF8FC14 for ; Sun, 23 Oct 2011 22:38:23 +0000 (UTC) Received: by iaky10 with SMTP id y10so9151782iak.13 for ; Sun, 23 Oct 2011 15:38:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=5/2NdvLw8wX+hkgIdtGgcebOnNPbM+LzjorKFtFFdOM=; b=QN5GzD76fFHW4/o4JAiT7pX8hd9FTnK6NzVb6TKzbqg+ofG92T7Unhk96/MLmmqAyD ILbHbvj4eGFICFCx2zwuEDgl9ElRjK0AVAsoKscBeXAkHjbI3O0YyTxlFQB2VjUgOTDs N65h3EgPiKyXOilC05iYq7/b3OECNl40qMwEI= Received: by 10.68.39.231 with SMTP id s7mr43639234pbk.33.1319409502930; Sun, 23 Oct 2011 15:38:22 -0700 (PDT) Received: from [192.168.20.4] (c-24-6-49-154.hsd1.ca.comcast.net. [24.6.49.154]) by mx.google.com with ESMTPS id e10sm51812622pbq.10.2011.10.23.15.38.21 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 23 Oct 2011 15:38:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <4EA495BA.7080802@zedat.fu-berlin.de> Date: Sun, 23 Oct 2011 15:38:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <87987AB8-BCAA-4CED-8B4F-C6EA5B61C0A5@gmail.com> References: <4EA495BA.7080802@zedat.fu-berlin.de> To: "Hartmann, O." X-Mailer: Apple Mail (2.1084) Cc: freebsd-current Subject: Re: "/usr/src/sys/conf/kern.mk", line 10: Malformed conditional (${FREEBSD_GCC}), "/usr/src/sys/conf/kern.mk", line 14: if-less endif X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Oct 2011 22:38:24 -0000 On Oct 23, 2011, at 3:31 PM, Hartmann, O. wrote: >=20 > Kernel building fails since today when kernel gets compiled via = CLANG: > -------------------------------------------------------------- >>>> stage 2.1: cleaning up the object tree > -------------------------------------------------------------- > cd /usr/obj/usr/src/sys/THOR; MAKEOBJDIRPREFIX=3D/usr/obj > MACHINE_ARCH=3Damd64 MACHINE=3Damd64 CPUTYPE=3Dnative > GROFF_BIN_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/bin > GROFF_FONT_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/groff_font > GROFF_TMAC_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/tmac > _SHLIBDIRPREFIX=3D/usr/obj/usr/src/tmp VERSION=3D"FreeBSD = 10.0-CURRENT > amd64 1000000" INSTALL=3D"sh /usr/src/tools/install.sh" > = PATH=3D/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/ > = usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr > = /sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbi > n:/bin:/usr/sbin:/usr/bin /usr/obj/usr/src/make.amd64/make > KERNEL=3Dkernel cleandir > "/usr/src/sys/conf/kern.mk", line 10: Malformed conditional > (${FREEBSD_GCC}) > "/usr/src/sys/conf/kern.mk", line 14: if-less endif > make: fatal errors encountered -- cannot continue > *** Error code 1 > Stop in /usr/src. > *** Error code 1 > Stop in /usr/src. It was noted not too long ago on the commit list as well; r226665 caused = the breakage. -Garrett= From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 02:38:13 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F185106566B; Mon, 24 Oct 2011 02:38:13 +0000 (UTC) (envelope-from fbsd8@a1poweruser.com) Received: from mail-03.name-services.com (mail-03.name-services.com [69.64.155.195]) by mx1.freebsd.org (Postfix) with ESMTP id 444AD8FC0C; Mon, 24 Oct 2011 02:38:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; q=dns/txt; s=DKIM-NAME-SERVICES; d=a1poweruser.com; h=From:To:Cc:Subject:Message-ID:X-Sender:X-Envelope-From; l=500; bh=GNQq9LqitpfZcg17x2VyXfdw/zy6NuVTWfK/Y9F6Fxw=; b=Dy7hgxUJSPT5XJCu09W6MWjqUCZMeE8MZzLfigAdFbUgkZeu0dLO8ut8vuWRDhxOSWaTYQLQOObwpJDpm/t/lK+Dy/IEwEazXdsHJl+guWpKC0lYOfRQ3vM0ND4w7fOhNB3vl1f+AfL11rohaqvmNZJOqStZqql+42hyaPx0JNk= Received: from [192.168.1.134] ([120.29.64.160]) by mail-03.name-services.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 23 Oct 2011 19:38:13 -0700 Message-ID: <4EA4CF91.1000706@a1poweruser.com> Date: Mon, 24 Oct 2011 10:38:09 +0800 From: Fbsd8 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: bug-followup@freebsd.org, FreeBSD Current , FreeBSD Questions Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Oct 2011 02:38:13.0405 (UTC) FILETIME=[F9FD64D0:01CC91F5] X-Sender: fbsd8@a1poweruser.com X-Envelope-From: fbsd8*a1poweruser.com Cc: Subject: Re: bin/161927: bsdinstall(8): has no help describing what is happening X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2011 02:38:13 -0000 From-To: open->closed By: nwhitehorn When: Sun Oct 23 15:18:39 UTC 2011 Why: There is help throughout, in particular in the partition editor, which shows help in the bottom line of the screen. More verbose help (e.g. pressing F1 to open a help screen) will likely come later. http://www.freebsd.org/cgi/query-pr.cgi?pr=161927 If there is help throughout it sure is not in the 9.0 RC1 version. I object to the closing of this pr without any review by the current list. I can not understand how you can say there is help info provided in bsdinstall. The very first dialog box where users select (install) has no help. Every dialog box shown should have a help option. Saying it will come later is not the professional way software is released to the public. This is not the Freebsd standard. bsdinstall is the front door to FreeBSD and is the first thing installers see when trying to install it. Do you really want to show the public such a lack of pride in doing a complete job. In its current condition bsdinstall is not ready to be released. It gives the public the wrong impression (image) of what a great OS Freebsd is. Too many developers and other volunteers have invested tons of hours to have their united effort disrespected by a installer that is incomplete. This pr about adding help info is not the only outstanding pr on bsdinstall. From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 03:11:14 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24191106566B; Mon, 24 Oct 2011 03:11: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 EA0A28FC13; Mon, 24 Oct 2011 03:11:13 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9O3BC1F075132; Sun, 23 Oct 2011 23:11:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9O3BCeR075119; Mon, 24 Oct 2011 03:11:12 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 24 Oct 2011 03:11:12 GMT Message-Id: <201110240311.p9O3BCeR075119@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, 24 Oct 2011 03:11:14 -0000 TB --- 2011-10-24 02:50:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 02:50:00 - starting HEAD tinderbox run for arm/arm TB --- 2011-10-24 02:50:00 - cleaning the object tree TB --- 2011-10-24 02:50:30 - cvsupping the source tree TB --- 2011-10-24 02:50:30 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-10-24 02:50:46 - building world TB --- 2011-10-24 02:50:46 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 02:50:46 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 02:50:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 02:50:46 - SRCCONF=/dev/null TB --- 2011-10-24 02:50:46 - TARGET=arm TB --- 2011-10-24 02:50:46 - TARGET_ARCH=arm TB --- 2011-10-24 02:50:46 - TZ=UTC TB --- 2011-10-24 02:50:46 - __MAKE_CONF=/dev/null TB --- 2011-10-24 02:50:46 - cd /src TB --- 2011-10-24 02:50:46 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 02:50:47 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign -W! no-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign -W! no-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign -W! no-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign -W! no-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign -W! no-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign -W! no-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c:40: /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_vfsops.h:43: error: expected specifier-qualifier-list before 'vfs_t' *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/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 --- 2011-10-24 03:11:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-24 03:11:12 - ERROR: failed to build world TB --- 2011-10-24 03:11:12 - 882.96 user 280.22 system 1271.61 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 03:17:41 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F8131065670; Mon, 24 Oct 2011 03:17:41 +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 61D6C8FC08; Mon, 24 Oct 2011 03:17:41 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9O3Hedf036302; Sun, 23 Oct 2011 23:17:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9O3He7s036297; Mon, 24 Oct 2011 03:17:40 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 24 Oct 2011 03:17:40 GMT Message-Id: <201110240317.p9O3He7s036297@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, 24 Oct 2011 03:17:41 -0000 TB --- 2011-10-24 02:50:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 02:50:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-10-24 02:50:00 - cleaning the object tree TB --- 2011-10-24 02:50:28 - cvsupping the source tree TB --- 2011-10-24 02:50:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-10-24 02:50:44 - building world TB --- 2011-10-24 02:50:44 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 02:50:44 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 02:50:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 02:50:44 - SRCCONF=/dev/null TB --- 2011-10-24 02:50:44 - TARGET=pc98 TB --- 2011-10-24 02:50:44 - TARGET_ARCH=i386 TB --- 2011-10-24 02:50:44 - TZ=UTC TB --- 2011-10-24 02:50:44 - __MAKE_CONF=/dev/null TB --- 2011-10-24 02:50:44 - cd /src TB --- 2011-10-24 02:50:44 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 02:50:44 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c:40: /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_vfsops.h:43: error: expected specifier-qualifier-list before 'vfs_t' *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/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 --- 2011-10-24 03:17:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-24 03:17:40 - ERROR: failed to build world TB --- 2011-10-24 03:17:40 - 1224.80 user 307.38 system 1659.59 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 03:17:52 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B4DF1065793; Mon, 24 Oct 2011 03:17: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 F1E678FC0C; Mon, 24 Oct 2011 03:17:51 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9O3HphM036691; Sun, 23 Oct 2011 23:17:51 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9O3Hp87036690; Mon, 24 Oct 2011 03:17:51 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 24 Oct 2011 03:17:51 GMT Message-Id: <201110240317.p9O3Hp87036690@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, 24 Oct 2011 03:17:52 -0000 TB --- 2011-10-24 02:50:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 02:50:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-10-24 02:50:00 - cleaning the object tree TB --- 2011-10-24 02:50:56 - cvsupping the source tree TB --- 2011-10-24 02:50:56 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-10-24 02:51:08 - building world TB --- 2011-10-24 02:51:08 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 02:51:08 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 02:51:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 02:51:08 - SRCCONF=/dev/null TB --- 2011-10-24 02:51:08 - TARGET=i386 TB --- 2011-10-24 02:51:08 - TARGET_ARCH=i386 TB --- 2011-10-24 02:51:08 - TZ=UTC TB --- 2011-10-24 02:51:08 - __MAKE_CONF=/dev/null TB --- 2011-10-24 02:51:08 - cd /src TB --- 2011-10-24 02:51:08 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 02:51:08 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c:40: /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_vfsops.h:43: error: expected specifier-qualifier-list before 'vfs_t' *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/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 --- 2011-10-24 03:17:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-24 03:17:51 - ERROR: failed to build world TB --- 2011-10-24 03:17:51 - 1230.52 user 308.95 system 1670.38 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 03:19:01 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE4141065674; Mon, 24 Oct 2011 03:19: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 916AF8FC24; Mon, 24 Oct 2011 03:19:01 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9O3J1cO040010; Sun, 23 Oct 2011 23:19:01 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9O3J0kt040009; Mon, 24 Oct 2011 03:19:00 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 24 Oct 2011 03:19:00 GMT Message-Id: <201110240319.p9O3J0kt040009@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, 24 Oct 2011 03:19:01 -0000 TB --- 2011-10-24 02:50:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 02:50:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-10-24 02:50:00 - cleaning the object tree TB --- 2011-10-24 02:50:56 - cvsupping the source tree TB --- 2011-10-24 02:50:56 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-10-24 02:51:07 - building world TB --- 2011-10-24 02:51:07 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 02:51:07 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 02:51:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 02:51:07 - SRCCONF=/dev/null TB --- 2011-10-24 02:51:07 - TARGET=amd64 TB --- 2011-10-24 02:51:07 - TARGET_ARCH=amd64 TB --- 2011-10-24 02:51:07 - TZ=UTC TB --- 2011-10-24 02:51:07 - __MAKE_CONF=/dev/null TB --- 2011-10-24 02:51:07 - cd /src TB --- 2011-10-24 02:51:07 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 02:51:08 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c:40: /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_vfsops.h:43: error: expected specifier-qualifier-list before 'vfs_t' *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/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 --- 2011-10-24 03:19:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-24 03:19:00 - ERROR: failed to build world TB --- 2011-10-24 03:19:00 - 1271.70 user 322.60 system 1739.98 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 03:37:38 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 759A1106566B; Mon, 24 Oct 2011 03:37:38 +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 412E08FC14; Mon, 24 Oct 2011 03:37:37 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9O3bbkx028890; Sun, 23 Oct 2011 23:37:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9O3bbIb028889; Mon, 24 Oct 2011 03:37:37 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 24 Oct 2011 03:37:37 GMT Message-Id: <201110240337.p9O3bbIb028889@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, 24 Oct 2011 03:37:38 -0000 TB --- 2011-10-24 03:11:13 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 03:11:13 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-10-24 03:11:13 - cleaning the object tree TB --- 2011-10-24 03:11:36 - cvsupping the source tree TB --- 2011-10-24 03:11:36 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-10-24 03:11:53 - building world TB --- 2011-10-24 03:11:53 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 03:11:53 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 03:11:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 03:11:53 - SRCCONF=/dev/null TB --- 2011-10-24 03:11:53 - TARGET=ia64 TB --- 2011-10-24 03:11:53 - TARGET_ARCH=ia64 TB --- 2011-10-24 03:11:53 - TZ=UTC TB --- 2011-10-24 03:11:53 - __MAKE_CONF=/dev/null TB --- 2011-10-24 03:11:53 - cd /src TB --- 2011-10-24 03:11:53 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 03:11:54 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign ! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign ! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign ! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign ! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign ! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign ! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c:40: /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_vfsops.h:43: error: expected specifier-qualifier-list before 'vfs_t' *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/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 --- 2011-10-24 03:37:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-24 03:37:36 - ERROR: failed to build world TB --- 2011-10-24 03:37:36 - 1180.05 user 304.33 system 1583.87 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 03:40:37 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D53EA1065673; Mon, 24 Oct 2011 03:40:37 +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 A64F68FC15; Mon, 24 Oct 2011 03:40:37 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9O3eaHo060398; Sun, 23 Oct 2011 23:40:36 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9O3eaRj060397; Mon, 24 Oct 2011 03:40:36 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 24 Oct 2011 03:40:36 GMT Message-Id: <201110240340.p9O3eaRj060397@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, 24 Oct 2011 03:40:38 -0000 TB --- 2011-10-24 03:17:40 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 03:17:40 - starting HEAD tinderbox run for mips/mips TB --- 2011-10-24 03:17:40 - cleaning the object tree TB --- 2011-10-24 03:17:48 - cvsupping the source tree TB --- 2011-10-24 03:17:48 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2011-10-24 03:18:44 - building world TB --- 2011-10-24 03:18:44 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 03:18:44 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 03:18:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 03:18:44 - SRCCONF=/dev/null TB --- 2011-10-24 03:18:44 - TARGET=mips TB --- 2011-10-24 03:18:44 - TARGET_ARCH=mips TB --- 2011-10-24 03:18:44 - TZ=UTC TB --- 2011-10-24 03:18:44 - __MAKE_CONF=/dev/null TB --- 2011-10-24 03:18:44 - cd /src TB --- 2011-10-24 03:18:44 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 03:18:44 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -G0 -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/mips/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-si! gn -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c cc -O -pipe -G0 -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/mips/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-si! gn -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c cc -O -pipe -G0 -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/mips/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-si! gn -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c cc -O -pipe -G0 -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/mips/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-si! gn -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c cc -O -pipe -G0 -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/mips/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-si! gn -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c cc -O -pipe -G0 -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/mips/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-si! gn -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c:40: /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_vfsops.h:43: error: expected specifier-qualifier-list before 'vfs_t' *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/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 --- 2011-10-24 03:40:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-24 03:40:36 - ERROR: failed to build world TB --- 2011-10-24 03:40:36 - 951.47 user 276.84 system 1376.04 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 03:43:46 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 200351065670; Mon, 24 Oct 2011 03:43:46 +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 E92298FC0C; Mon, 24 Oct 2011 03:43:42 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9O3hgwW082037; Sun, 23 Oct 2011 23:43:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9O3hgfp082032; Mon, 24 Oct 2011 03:43:42 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 24 Oct 2011 03:43:42 GMT Message-Id: <201110240343.p9O3hgfp082032@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 03:43:46 -0000 TB --- 2011-10-24 03:19:01 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 03:19:01 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-10-24 03:19:01 - cleaning the object tree TB --- 2011-10-24 03:19:16 - cvsupping the source tree TB --- 2011-10-24 03:19:16 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-10-24 03:19:28 - building world TB --- 2011-10-24 03:19:28 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 03:19:28 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 03:19:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 03:19:28 - SRCCONF=/dev/null TB --- 2011-10-24 03:19:28 - TARGET=powerpc TB --- 2011-10-24 03:19:28 - TARGET_ARCH=powerpc64 TB --- 2011-10-24 03:19:28 - TZ=UTC TB --- 2011-10-24 03:19:28 - __MAKE_CONF=/dev/null TB --- 2011-10-24 03:19:28 - cd /src TB --- 2011-10-24 03:19:28 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 03:19:28 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c:40: /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_vfsops.h:43: error: expected specifier-qualifier-list before 'vfs_t' *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/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 --- 2011-10-24 03:43:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-24 03:43:42 - ERROR: failed to build world TB --- 2011-10-24 03:43:42 - 1088.91 user 288.72 system 1480.80 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 03:45:18 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B7B4106566C; Mon, 24 Oct 2011 03:45: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 563F68FC15; Mon, 24 Oct 2011 03:45:18 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9O3jHBs086143; Sun, 23 Oct 2011 23:45:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9O3jHGZ086138; Mon, 24 Oct 2011 03:45:17 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 24 Oct 2011 03:45:17 GMT Message-Id: <201110240345.p9O3jHGZ086138@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 03:45:18 -0000 TB --- 2011-10-24 03:17:51 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 03:17:51 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-10-24 03:17:51 - cleaning the object tree TB --- 2011-10-24 03:18:01 - cvsupping the source tree TB --- 2011-10-24 03:18:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-10-24 03:18:44 - building world TB --- 2011-10-24 03:18:44 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 03:18:44 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 03:18:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 03:18:44 - SRCCONF=/dev/null TB --- 2011-10-24 03:18:44 - TARGET=powerpc TB --- 2011-10-24 03:18:44 - TARGET_ARCH=powerpc TB --- 2011-10-24 03:18:44 - TZ=UTC TB --- 2011-10-24 03:18:44 - __MAKE_CONF=/dev/null TB --- 2011-10-24 03:18:44 - cd /src TB --- 2011-10-24 03:18:44 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 03:18:44 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c:40: /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_vfsops.h:43: error: expected specifier-qualifier-list before 'vfs_t' *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/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 --- 2011-10-24 03:45:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-24 03:45:17 - ERROR: failed to build world TB --- 2011-10-24 03:45:17 - 1229.83 user 285.62 system 1646.05 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 03:57:28 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C765106566C; Mon, 24 Oct 2011 03:57: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 5154F8FC0A; Mon, 24 Oct 2011 03:57:28 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9O3vRnV027641; Sun, 23 Oct 2011 23:57:27 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9O3vRhj027640; Mon, 24 Oct 2011 03:57:27 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 24 Oct 2011 03:57:27 GMT Message-Id: <201110240357.p9O3vRhj027640@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 03:57:28 -0000 TB --- 2011-10-24 03:37:37 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 03:37:37 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-10-24 03:37:37 - cleaning the object tree TB --- 2011-10-24 03:37:49 - cvsupping the source tree TB --- 2011-10-24 03:37:49 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-10-24 03:38:00 - building world TB --- 2011-10-24 03:38:00 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 03:38:00 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 03:38:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 03:38:00 - SRCCONF=/dev/null TB --- 2011-10-24 03:38:00 - TARGET=sparc64 TB --- 2011-10-24 03:38:00 - TARGET_ARCH=sparc64 TB --- 2011-10-24 03:38:00 - TZ=UTC TB --- 2011-10-24 03:38:00 - __MAKE_CONF=/dev/null TB --- 2011-10-24 03:38:00 - cd /src TB --- 2011-10-24 03:38:00 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 03:38:01 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/sparc64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/sparc64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/sparc64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/sparc64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/sparc64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/sparc64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c:40: /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_vfsops.h:43: error: expected specifier-qualifier-list before 'vfs_t' *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/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 --- 2011-10-24 03:57:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-24 03:57:27 - ERROR: failed to build world TB --- 2011-10-24 03:57:27 - 952.77 user 231.66 system 1189.99 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 04:17:04 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA934106566B; Mon, 24 Oct 2011 04:17:04 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward6.mail.yandex.net (forward6.mail.yandex.net [IPv6:2a02:6b8:0:202::1]) by mx1.freebsd.org (Postfix) with ESMTP id 5EC008FC13; Mon, 24 Oct 2011 04:17:04 +0000 (UTC) Received: from smtp8.mail.yandex.net (smtp8.mail.yandex.net [77.88.61.54]) by forward6.mail.yandex.net (Yandex) with ESMTP id 2F1A9F82586; Mon, 24 Oct 2011 08:17:02 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1319429822; bh=Ple2tF09hOSZdzAj8TTjeaSvCSEgQkJb+RIL0ler8vw=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=NtufKBCjt08Az4gRVj1iRPTM/7xGb/owcvPvKDipS/ArXnDB9+yuUj93H7SS3xXeh c2Q428j1yuJt8jYTNbvjV3dZlQGFszrZ91rTjSHEztww/XCDtJFqJxHtZ8unfPafe8 OTnU2baMg1ETOoPbcenb4pCEbfQYygH2vXg+pezI= Received: from smtp8.mail.yandex.net (localhost [127.0.0.1]) by smtp8.mail.yandex.net (Yandex) with ESMTP id D0A601B603A4; Mon, 24 Oct 2011 08:17:01 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1319429822; bh=Ple2tF09hOSZdzAj8TTjeaSvCSEgQkJb+RIL0ler8vw=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=NtufKBCjt08Az4gRVj1iRPTM/7xGb/owcvPvKDipS/ArXnDB9+yuUj93H7SS3xXeh c2Q428j1yuJt8jYTNbvjV3dZlQGFszrZ91rTjSHEztww/XCDtJFqJxHtZ8unfPafe8 OTnU2baMg1ETOoPbcenb4pCEbfQYygH2vXg+pezI= Received: from mail.kirov.so-ups.ru (mail.kirov.so-ups.ru [178.74.170.1]) by smtp8.mail.yandex.net (nwsmtp/Yandex) with ESMTP id H1FSqDng-H1F4S31G; Mon, 24 Oct 2011 08:17:01 +0400 X-Yandex-Spam: 1 Message-ID: <4EA4E6B8.7040108@yandex.ru> Date: Mon, 24 Oct 2011 08:16:56 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Arnaud Lacombe References: <81477.1318015137@critter.freebsd.dk> <4E8F55CC.3060302@FreeBSD.org> <4E8F5D47.9070904@yandex.ru> In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig346D42F341644765A839ED48" Cc: Warren Block , Garrett Cooper , Glen Barber , Poul-Henning Kamp , freebsd-current@freebsd.org, Benjamin Kaduk Subject: Re: aliasing (or renaming) kern.geom.debugflags X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2011 04:17:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig346D42F341644765A839ED48 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 24.10.2011 1:54, Arnaud Lacombe wrote: > NOTE > Protection mechanisms in the geom(4) subsystem might prevent boot0cfg > from being able to update the MBR on a mounted disk. Instructions for= > temporarily disabling these protection mechanisms can be found in the > geom(4) manpage. Specifically, do a >=20 > sysctl kern.geom.debugflags=3D0x10 >=20 > to allow writing to the MBR, and restore it to 0 afterwards. This is stale message. boot0cfg might work without this. --=20 WBR, Andrey V. Elsukov --------------enig346D42F341644765A839ED48 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) iQEcBAEBAgAGBQJOpOa9AAoJEAHF6gQQyKF6o8UIALT7XLVNAmtnEA8xqJD0+3jJ b8XzGRmB72pNaOYlE+HfF2KjyPbRxDJIDZXAY4FtmhlDOYU33EvvnQ3ohdKDenVh QnusVWxMtW6mJVnbW7lEQTFQf4RVN3KnZyMRPEQWjvlxAYmOCY8gP0xtSZvLn3t4 ViyX/OgRVCNgGmMBvYAwcia6lSfq13nOQY/aMEYS2+LPmtXwFfhtTSE3WVbcXx1E Q93r7evXtk6nrpaKVXswFrLmYcxoD9D0fKt2saht2wgtAC15FboJmyeJv/Qxt73z H8CuUA1ilgPkcm2N+64v1T4xBfa/8JIbwaYrGIudhrkVD0flNDI2TLIdIj2CUEM= =ps97 -----END PGP SIGNATURE----- --------------enig346D42F341644765A839ED48-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 04:19:45 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 663DE1065670; Mon, 24 Oct 2011 04:19:45 +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 3964B8FC0C; Mon, 24 Oct 2011 04:19:45 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9O4Jiwl013406; Mon, 24 Oct 2011 00:19:44 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9O4JiZS013395; Mon, 24 Oct 2011 04:19:44 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 24 Oct 2011 04:19:44 GMT Message-Id: <201110240419.p9O4JiZS013395@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, 24 Oct 2011 04:19:45 -0000 TB --- 2011-10-24 04:00:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 04:00:00 - starting HEAD tinderbox run for arm/arm TB --- 2011-10-24 04:00:00 - cleaning the object tree TB --- 2011-10-24 04:00:06 - cvsupping the source tree TB --- 2011-10-24 04:00:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-10-24 04:00:19 - building world TB --- 2011-10-24 04:00:19 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 04:00:19 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 04:00:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 04:00:19 - SRCCONF=/dev/null TB --- 2011-10-24 04:00:19 - TARGET=arm TB --- 2011-10-24 04:00:19 - TARGET_ARCH=arm TB --- 2011-10-24 04:00:19 - TZ=UTC TB --- 2011-10-24 04:00:19 - __MAKE_CONF=/dev/null TB --- 2011-10-24 04:00:19 - cd /src TB --- 2011-10-24 04:00:19 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 04:00:19 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign -W! no-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign -W! no-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign -W! no-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign -W! no-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign -W! no-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign -W! no-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c:40: /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_vfsops.h:43: error: expected specifier-qualifier-list before 'vfs_t' *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/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 --- 2011-10-24 04:19:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-24 04:19:44 - ERROR: failed to build world TB --- 2011-10-24 04:19:44 - 869.03 user 264.48 system 1184.45 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 04:26:37 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9799106566B; Mon, 24 Oct 2011 04:26:37 +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 A757E8FC12; Mon, 24 Oct 2011 04:26:37 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9O4QbhW081410; Mon, 24 Oct 2011 00:26:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9O4QbGi081408; Mon, 24 Oct 2011 04:26:37 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 24 Oct 2011 04:26:37 GMT Message-Id: <201110240426.p9O4QbGi081408@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, 24 Oct 2011 04:26:38 -0000 TB --- 2011-10-24 04:00:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 04:00:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-10-24 04:00:00 - cleaning the object tree TB --- 2011-10-24 04:00:06 - cvsupping the source tree TB --- 2011-10-24 04:00:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-10-24 04:00:19 - building world TB --- 2011-10-24 04:00:19 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 04:00:19 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 04:00:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 04:00:19 - SRCCONF=/dev/null TB --- 2011-10-24 04:00:19 - TARGET=pc98 TB --- 2011-10-24 04:00:19 - TARGET_ARCH=i386 TB --- 2011-10-24 04:00:19 - TZ=UTC TB --- 2011-10-24 04:00:19 - __MAKE_CONF=/dev/null TB --- 2011-10-24 04:00:19 - cd /src TB --- 2011-10-24 04:00:19 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 04:00:19 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c:40: /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_vfsops.h:43: error: expected specifier-qualifier-list before 'vfs_t' *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/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 --- 2011-10-24 04:26:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-24 04:26:37 - ERROR: failed to build world TB --- 2011-10-24 04:26:37 - 1211.28 user 299.16 system 1596.91 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 04:27:40 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22780106567E; Mon, 24 Oct 2011 04:27: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 E98E48FC1C; Mon, 24 Oct 2011 04:27:39 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9O4RdWp085700; Mon, 24 Oct 2011 00:27:39 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9O4RdJg085699; Mon, 24 Oct 2011 04:27:39 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 24 Oct 2011 04:27:39 GMT Message-Id: <201110240427.p9O4RdJg085699@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, 24 Oct 2011 04:27:40 -0000 TB --- 2011-10-24 04:00:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 04:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-10-24 04:00:00 - cleaning the object tree TB --- 2011-10-24 04:00:06 - cvsupping the source tree TB --- 2011-10-24 04:00:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-10-24 04:00:19 - building world TB --- 2011-10-24 04:00:19 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 04:00:19 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 04:00:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 04:00:19 - SRCCONF=/dev/null TB --- 2011-10-24 04:00:19 - TARGET=amd64 TB --- 2011-10-24 04:00:19 - TARGET_ARCH=amd64 TB --- 2011-10-24 04:00:19 - TZ=UTC TB --- 2011-10-24 04:00:19 - __MAKE_CONF=/dev/null TB --- 2011-10-24 04:00:19 - cd /src TB --- 2011-10-24 04:00:19 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 04:00:19 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c:40: /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_vfsops.h:43: error: expected specifier-qualifier-list before 'vfs_t' *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/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 --- 2011-10-24 04:27:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-24 04:27:39 - ERROR: failed to build world TB --- 2011-10-24 04:27:39 - 1260.08 user 300.15 system 1659.09 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 04:32:18 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC76F106566C; Mon, 24 Oct 2011 04:32: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 AE7728FC17; Mon, 24 Oct 2011 04:32:18 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9O4WHDY037955; Mon, 24 Oct 2011 00:32:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9O4WH4j037944; Mon, 24 Oct 2011 04:32:17 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 24 Oct 2011 04:32:17 GMT Message-Id: <201110240432.p9O4WH4j037944@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, 24 Oct 2011 04:32:19 -0000 TB --- 2011-10-24 04:00:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 04:00:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-10-24 04:00:00 - cleaning the object tree TB --- 2011-10-24 04:00:06 - cvsupping the source tree TB --- 2011-10-24 04:00:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-10-24 04:05:30 - building world TB --- 2011-10-24 04:05:30 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 04:05:30 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 04:05:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 04:05:30 - SRCCONF=/dev/null TB --- 2011-10-24 04:05:30 - TARGET=i386 TB --- 2011-10-24 04:05:30 - TARGET_ARCH=i386 TB --- 2011-10-24 04:05:30 - TZ=UTC TB --- 2011-10-24 04:05:30 - __MAKE_CONF=/dev/null TB --- 2011-10-24 04:05:30 - cd /src TB --- 2011-10-24 04:05:30 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 04:05:30 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c:40: /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_vfsops.h:43: error: expected specifier-qualifier-list before 'vfs_t' *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/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 --- 2011-10-24 04:32:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-24 04:32:17 - ERROR: failed to build world TB --- 2011-10-24 04:32:17 - 1226.62 user 286.50 system 1937.73 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 04:46:05 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5E411065674; Mon, 24 Oct 2011 04:46:05 +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 A84B48FC08; Mon, 24 Oct 2011 04:46:05 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9O4k5eq073676; Mon, 24 Oct 2011 00:46:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9O4k5DC073656; Mon, 24 Oct 2011 04:46:05 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 24 Oct 2011 04:46:05 GMT Message-Id: <201110240446.p9O4k5DC073656@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, 24 Oct 2011 04:46:05 -0000 TB --- 2011-10-24 04:19:44 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 04:19:44 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-10-24 04:19:44 - cleaning the object tree TB --- 2011-10-24 04:19:49 - cvsupping the source tree TB --- 2011-10-24 04:19:49 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-10-24 04:20:01 - building world TB --- 2011-10-24 04:20:01 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 04:20:01 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 04:20:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 04:20:01 - SRCCONF=/dev/null TB --- 2011-10-24 04:20:01 - TARGET=ia64 TB --- 2011-10-24 04:20:01 - TARGET_ARCH=ia64 TB --- 2011-10-24 04:20:01 - TZ=UTC TB --- 2011-10-24 04:20:01 - __MAKE_CONF=/dev/null TB --- 2011-10-24 04:20:01 - cd /src TB --- 2011-10-24 04:20:01 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 04:20:02 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign ! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign ! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign ! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign ! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign ! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign ! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c:40: /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_vfsops.h:43: error: expected specifier-qualifier-list before 'vfs_t' *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/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 --- 2011-10-24 04:46:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-24 04:46:04 - ERROR: failed to build world TB --- 2011-10-24 04:46:04 - 1205.03 user 289.21 system 1580.16 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 04:48:28 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38A2B1065670; Mon, 24 Oct 2011 04:48: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 02CD48FC0A; Mon, 24 Oct 2011 04:48:27 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9O4mRQT006287; Mon, 24 Oct 2011 00:48:27 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9O4mRfD006277; Mon, 24 Oct 2011 04:48:27 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 24 Oct 2011 04:48:27 GMT Message-Id: <201110240448.p9O4mRfD006277@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, 24 Oct 2011 04:48:28 -0000 TB --- 2011-10-24 04:26:37 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 04:26:37 - starting HEAD tinderbox run for mips/mips TB --- 2011-10-24 04:26:37 - cleaning the object tree TB --- 2011-10-24 04:26:41 - cvsupping the source tree TB --- 2011-10-24 04:26:41 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2011-10-24 04:26:53 - building world TB --- 2011-10-24 04:26:53 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 04:26:53 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 04:26:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 04:26:53 - SRCCONF=/dev/null TB --- 2011-10-24 04:26:53 - TARGET=mips TB --- 2011-10-24 04:26:53 - TARGET_ARCH=mips TB --- 2011-10-24 04:26:53 - TZ=UTC TB --- 2011-10-24 04:26:53 - __MAKE_CONF=/dev/null TB --- 2011-10-24 04:26:53 - cd /src TB --- 2011-10-24 04:26:53 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 04:26:53 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -G0 -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/mips/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-si! gn -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c cc -O -pipe -G0 -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/mips/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-si! gn -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c cc -O -pipe -G0 -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/mips/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-si! gn -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c cc -O -pipe -G0 -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/mips/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-si! gn -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c cc -O -pipe -G0 -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/mips/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-si! gn -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c cc -O -pipe -G0 -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/mips/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-si! gn -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c:40: /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_vfsops.h:43: error: expected specifier-qualifier-list before 'vfs_t' *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/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 --- 2011-10-24 04:48:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-24 04:48:27 - ERROR: failed to build world TB --- 2011-10-24 04:48:27 - 939.23 user 261.73 system 1309.94 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 04:53:47 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C10A1065680; Mon, 24 Oct 2011 04:53:47 +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 6686F8FC0C; Mon, 24 Oct 2011 04:53:47 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9O4rkU4038740; Mon, 24 Oct 2011 00:53:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9O4rkDi038735; Mon, 24 Oct 2011 04:53:46 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 24 Oct 2011 04:53:46 GMT Message-Id: <201110240453.p9O4rkDi038735@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 04:53:47 -0000 TB --- 2011-10-24 04:27:39 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 04:27:39 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-10-24 04:27:39 - cleaning the object tree TB --- 2011-10-24 04:27:44 - cvsupping the source tree TB --- 2011-10-24 04:27:44 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-10-24 04:27:55 - building world TB --- 2011-10-24 04:27:55 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 04:27:55 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 04:27:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 04:27:55 - SRCCONF=/dev/null TB --- 2011-10-24 04:27:55 - TARGET=powerpc TB --- 2011-10-24 04:27:55 - TARGET_ARCH=powerpc TB --- 2011-10-24 04:27:55 - TZ=UTC TB --- 2011-10-24 04:27:55 - __MAKE_CONF=/dev/null TB --- 2011-10-24 04:27:55 - cd /src TB --- 2011-10-24 04:27:55 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 04:27:56 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c:40: /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_vfsops.h:43: error: expected specifier-qualifier-list before 'vfs_t' *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/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 --- 2011-10-24 04:53:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-24 04:53:46 - ERROR: failed to build world TB --- 2011-10-24 04:53:46 - 1205.80 user 279.33 system 1567.20 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 04:55:54 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFCFD1065675; Mon, 24 Oct 2011 04:55: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 8AAAC8FC13; Mon, 24 Oct 2011 04:55:54 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9O4tr2H056876; Mon, 24 Oct 2011 00:55:53 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9O4trDa056875; Mon, 24 Oct 2011 04:55:53 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 24 Oct 2011 04:55:53 GMT Message-Id: <201110240455.p9O4trDa056875@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 04:55:54 -0000 TB --- 2011-10-24 04:32:18 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 04:32:18 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-10-24 04:32:18 - cleaning the object tree TB --- 2011-10-24 04:32:22 - cvsupping the source tree TB --- 2011-10-24 04:32:22 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-10-24 04:32:34 - building world TB --- 2011-10-24 04:32:34 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 04:32:34 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 04:32:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 04:32:34 - SRCCONF=/dev/null TB --- 2011-10-24 04:32:34 - TARGET=powerpc TB --- 2011-10-24 04:32:34 - TARGET_ARCH=powerpc64 TB --- 2011-10-24 04:32:34 - TZ=UTC TB --- 2011-10-24 04:32:34 - __MAKE_CONF=/dev/null TB --- 2011-10-24 04:32:34 - cd /src TB --- 2011-10-24 04:32:34 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 04:32:34 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c:40: /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_vfsops.h:43: error: expected specifier-qualifier-list before 'vfs_t' *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/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 --- 2011-10-24 04:55:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-24 04:55:53 - ERROR: failed to build world TB --- 2011-10-24 04:55:53 - 1068.98 user 266.31 system 1415.73 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 05:05:20 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1763106564A; Mon, 24 Oct 2011 05:05:20 +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 A4BE28FC08; Mon, 24 Oct 2011 05:05:20 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9O55JGt085508; Mon, 24 Oct 2011 01:05:19 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9O55Jc7085507; Mon, 24 Oct 2011 05:05:19 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 24 Oct 2011 05:05:19 GMT Message-Id: <201110240505.p9O55Jc7085507@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 05:05:20 -0000 TB --- 2011-10-24 04:46:05 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 04:46:05 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-10-24 04:46:05 - cleaning the object tree TB --- 2011-10-24 04:46:09 - cvsupping the source tree TB --- 2011-10-24 04:46:09 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-10-24 04:46:22 - building world TB --- 2011-10-24 04:46:22 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 04:46:22 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 04:46:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 04:46:22 - SRCCONF=/dev/null TB --- 2011-10-24 04:46:22 - TARGET=sparc64 TB --- 2011-10-24 04:46:22 - TARGET_ARCH=sparc64 TB --- 2011-10-24 04:46:22 - TZ=UTC TB --- 2011-10-24 04:46:22 - __MAKE_CONF=/dev/null TB --- 2011-10-24 04:46:22 - cd /src TB --- 2011-10-24 04:46:22 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 04:46:23 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/sparc64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/sparc64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/sparc64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/sparc64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/sparc64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/sparc64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c:40: /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_vfsops.h:43: error: expected specifier-qualifier-list before 'vfs_t' *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/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 --- 2011-10-24 05:05:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-24 05:05:19 - ERROR: failed to build world TB --- 2011-10-24 05:05:19 - 928.16 user 227.54 system 1154.59 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 05:30:18 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D38421065676; Mon, 24 Oct 2011 05: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 A608F8FC13; Mon, 24 Oct 2011 05: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.4) with ESMTP id p9O5UHY8074078; Mon, 24 Oct 2011 01:30:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9O5UHIX074061; Mon, 24 Oct 2011 05:30:17 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 24 Oct 2011 05:30:17 GMT Message-Id: <201110240530.p9O5UHIX074061@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, 24 Oct 2011 05:30:18 -0000 TB --- 2011-10-24 05:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 05:10:00 - starting HEAD tinderbox run for arm/arm TB --- 2011-10-24 05:10:00 - cleaning the object tree TB --- 2011-10-24 05:10:06 - cvsupping the source tree TB --- 2011-10-24 05:10:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-10-24 05:10:51 - building world TB --- 2011-10-24 05:10:51 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 05:10:51 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 05:10:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 05:10:51 - SRCCONF=/dev/null TB --- 2011-10-24 05:10:51 - TARGET=arm TB --- 2011-10-24 05:10:51 - TARGET_ARCH=arm TB --- 2011-10-24 05:10:51 - TZ=UTC TB --- 2011-10-24 05:10:51 - __MAKE_CONF=/dev/null TB --- 2011-10-24 05:10:51 - cd /src TB --- 2011-10-24 05:10:51 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 05:10:51 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign -W! no-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign -W! no-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign -W! no-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign -W! no-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign -W! no-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign -W! no-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c:40: /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_vfsops.h:43: error: expected specifier-qualifier-list before 'vfs_t' *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/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 --- 2011-10-24 05:30:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-24 05:30:17 - ERROR: failed to build world TB --- 2011-10-24 05:30:17 - 870.05 user 264.31 system 1217.35 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 05:37:14 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD3901065673; Mon, 24 Oct 2011 05:37: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 8F18E8FC0A; Mon, 24 Oct 2011 05:37:14 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9O5bDb0040086; Mon, 24 Oct 2011 01:37:13 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9O5bDvU040084; Mon, 24 Oct 2011 05:37:13 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 24 Oct 2011 05:37:13 GMT Message-Id: <201110240537.p9O5bDvU040084@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, 24 Oct 2011 05:37:14 -0000 TB --- 2011-10-24 05:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 05:10:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-10-24 05:10:00 - cleaning the object tree TB --- 2011-10-24 05:10:06 - cvsupping the source tree TB --- 2011-10-24 05:10:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-10-24 05:10:51 - building world TB --- 2011-10-24 05:10:51 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 05:10:51 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 05:10:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 05:10:51 - SRCCONF=/dev/null TB --- 2011-10-24 05:10:51 - TARGET=pc98 TB --- 2011-10-24 05:10:51 - TARGET_ARCH=i386 TB --- 2011-10-24 05:10:51 - TZ=UTC TB --- 2011-10-24 05:10:51 - __MAKE_CONF=/dev/null TB --- 2011-10-24 05:10:51 - cd /src TB --- 2011-10-24 05:10:51 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 05:10:51 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c:40: /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_vfsops.h:43: error: expected specifier-qualifier-list before 'vfs_t' *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/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 --- 2011-10-24 05:37:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-24 05:37:13 - ERROR: failed to build world TB --- 2011-10-24 05:37:13 - 1209.58 user 301.58 system 1633.56 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 05:38:13 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90B8C106566C; Mon, 24 Oct 2011 05:38:13 +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 5E9278FC14; Mon, 24 Oct 2011 05:38:13 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9O5cCcj044873; Mon, 24 Oct 2011 01:38:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9O5cCRd044872; Mon, 24 Oct 2011 05:38:12 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 24 Oct 2011 05:38:12 GMT Message-Id: <201110240538.p9O5cCRd044872@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, 24 Oct 2011 05:38:13 -0000 TB --- 2011-10-24 05:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 05:10:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-10-24 05:10:00 - cleaning the object tree TB --- 2011-10-24 05:10:06 - cvsupping the source tree TB --- 2011-10-24 05:10:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-10-24 05:10:51 - building world TB --- 2011-10-24 05:10:51 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 05:10:51 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 05:10:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 05:10:51 - SRCCONF=/dev/null TB --- 2011-10-24 05:10:51 - TARGET=amd64 TB --- 2011-10-24 05:10:51 - TARGET_ARCH=amd64 TB --- 2011-10-24 05:10:51 - TZ=UTC TB --- 2011-10-24 05:10:51 - __MAKE_CONF=/dev/null TB --- 2011-10-24 05:10:51 - cd /src TB --- 2011-10-24 05:10:51 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 05:10:51 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c:40: /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_vfsops.h:43: error: expected specifier-qualifier-list before 'vfs_t' *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/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 --- 2011-10-24 05:38:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-24 05:38:12 - ERROR: failed to build world TB --- 2011-10-24 05:38:12 - 1257.36 user 302.82 system 1692.27 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 05:42:23 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF4461065670; Mon, 24 Oct 2011 05:42:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 8CE9B8FC12; Mon, 24 Oct 2011 05:42:23 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9O5gMRF088406; Mon, 24 Oct 2011 01:42:22 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9O5gMfQ088401; Mon, 24 Oct 2011 05:42:22 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 24 Oct 2011 05:42:22 GMT Message-Id: <201110240542.p9O5gMfQ088401@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, 24 Oct 2011 05:42:23 -0000 TB --- 2011-10-24 05:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 05:10:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-10-24 05:10:00 - cleaning the object tree TB --- 2011-10-24 05:10:06 - cvsupping the source tree TB --- 2011-10-24 05:10:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-10-24 05:15:43 - building world TB --- 2011-10-24 05:15:43 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 05:15:43 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 05:15:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 05:15:43 - SRCCONF=/dev/null TB --- 2011-10-24 05:15:43 - TARGET=i386 TB --- 2011-10-24 05:15:43 - TARGET_ARCH=i386 TB --- 2011-10-24 05:15:43 - TZ=UTC TB --- 2011-10-24 05:15:43 - __MAKE_CONF=/dev/null TB --- 2011-10-24 05:15:43 - cd /src TB --- 2011-10-24 05:15:43 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 05:15:44 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c:40: /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_vfsops.h:43: error: expected specifier-qualifier-list before 'vfs_t' *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/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 --- 2011-10-24 05:42:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-24 05:42:22 - ERROR: failed to build world TB --- 2011-10-24 05:42:22 - 1223.91 user 287.09 system 1942.36 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 05:56:35 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DC601065677; Mon, 24 Oct 2011 05:56:35 +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 70A688FC0A; Mon, 24 Oct 2011 05:56:34 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9O5uY8F031931; Mon, 24 Oct 2011 01:56:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9O5uYGs031922; Mon, 24 Oct 2011 05:56:34 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 24 Oct 2011 05:56:34 GMT Message-Id: <201110240556.p9O5uYGs031922@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, 24 Oct 2011 05:56:35 -0000 TB --- 2011-10-24 05:30:17 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 05:30:17 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-10-24 05:30:17 - cleaning the object tree TB --- 2011-10-24 05:30:22 - cvsupping the source tree TB --- 2011-10-24 05:30:22 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-10-24 05:30:38 - building world TB --- 2011-10-24 05:30:38 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 05:30:38 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 05:30:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 05:30:38 - SRCCONF=/dev/null TB --- 2011-10-24 05:30:38 - TARGET=ia64 TB --- 2011-10-24 05:30:38 - TARGET_ARCH=ia64 TB --- 2011-10-24 05:30:38 - TZ=UTC TB --- 2011-10-24 05:30:38 - __MAKE_CONF=/dev/null TB --- 2011-10-24 05:30:38 - cd /src TB --- 2011-10-24 05:30:38 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 05:30:39 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign ! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign ! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign ! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign ! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign ! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign ! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c:40: /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_vfsops.h:43: error: expected specifier-qualifier-list before 'vfs_t' *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/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 --- 2011-10-24 05:56:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-24 05:56:34 - ERROR: failed to build world TB --- 2011-10-24 05:56:34 - 1207.06 user 289.35 system 1576.51 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 05:59:12 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B9CE1065676; Mon, 24 Oct 2011 05:59:12 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 560DF8FC1E; Mon, 24 Oct 2011 05:59:12 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9O5xBWH067111; Mon, 24 Oct 2011 01:59:11 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9O5xBDh067109; Mon, 24 Oct 2011 05:59:11 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 24 Oct 2011 05:59:11 GMT Message-Id: <201110240559.p9O5xBDh067109@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, 24 Oct 2011 05:59:12 -0000 TB --- 2011-10-24 05:37:14 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 05:37:14 - starting HEAD tinderbox run for mips/mips TB --- 2011-10-24 05:37:14 - cleaning the object tree TB --- 2011-10-24 05:37:19 - cvsupping the source tree TB --- 2011-10-24 05:37:19 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2011-10-24 05:37:31 - building world TB --- 2011-10-24 05:37:31 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 05:37:31 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 05:37:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 05:37:31 - SRCCONF=/dev/null TB --- 2011-10-24 05:37:31 - TARGET=mips TB --- 2011-10-24 05:37:31 - TARGET_ARCH=mips TB --- 2011-10-24 05:37:31 - TZ=UTC TB --- 2011-10-24 05:37:31 - __MAKE_CONF=/dev/null TB --- 2011-10-24 05:37:31 - cd /src TB --- 2011-10-24 05:37:31 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 05:37:31 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -G0 -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/mips/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-si! gn -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c cc -O -pipe -G0 -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/mips/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-si! gn -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c cc -O -pipe -G0 -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/mips/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-si! gn -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c cc -O -pipe -G0 -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/mips/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-si! gn -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c cc -O -pipe -G0 -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/mips/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-si! gn -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c cc -O -pipe -G0 -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/mips/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-si! gn -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c:40: /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_vfsops.h:43: error: expected specifier-qualifier-list before 'vfs_t' *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/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 --- 2011-10-24 05:59:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-24 05:59:11 - ERROR: failed to build world TB --- 2011-10-24 05:59:11 - 939.37 user 264.78 system 1317.42 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 06:04:18 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77ED7106564A; Mon, 24 Oct 2011 06:04: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 4AD178FC0A; Mon, 24 Oct 2011 06:04:18 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9O64HpG098061; Mon, 24 Oct 2011 02:04:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9O64HGM098052; Mon, 24 Oct 2011 06:04:17 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 24 Oct 2011 06:04:17 GMT Message-Id: <201110240604.p9O64HGM098052@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 06:04:18 -0000 TB --- 2011-10-24 05:38:12 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 05:38:12 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-10-24 05:38:12 - cleaning the object tree TB --- 2011-10-24 05:38:18 - cvsupping the source tree TB --- 2011-10-24 05:38:18 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-10-24 05:38:31 - building world TB --- 2011-10-24 05:38:31 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 05:38:31 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 05:38:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 05:38:31 - SRCCONF=/dev/null TB --- 2011-10-24 05:38:31 - TARGET=powerpc TB --- 2011-10-24 05:38:31 - TARGET_ARCH=powerpc TB --- 2011-10-24 05:38:31 - TZ=UTC TB --- 2011-10-24 05:38:31 - __MAKE_CONF=/dev/null TB --- 2011-10-24 05:38:31 - cd /src TB --- 2011-10-24 05:38:31 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 05:38:31 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c:40: /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_vfsops.h:43: error: expected specifier-qualifier-list before 'vfs_t' *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/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 --- 2011-10-24 06:04:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-24 06:04:17 - ERROR: failed to build world TB --- 2011-10-24 06:04:17 - 1192.77 user 285.20 system 1564.89 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 06:06:05 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1BD7106568E; Mon, 24 Oct 2011 06:06:05 +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 92DAF8FC1C; Mon, 24 Oct 2011 06:06:05 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9O66444013685; Mon, 24 Oct 2011 02:06:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9O664bk013680; Mon, 24 Oct 2011 06:06:04 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 24 Oct 2011 06:06:04 GMT Message-Id: <201110240606.p9O664bk013680@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 06:06:05 -0000 TB --- 2011-10-24 05:42:22 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 05:42:22 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-10-24 05:42:22 - cleaning the object tree TB --- 2011-10-24 05:42:29 - cvsupping the source tree TB --- 2011-10-24 05:42:29 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-10-24 05:42:43 - building world TB --- 2011-10-24 05:42:43 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 05:42:43 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 05:42:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 05:42:43 - SRCCONF=/dev/null TB --- 2011-10-24 05:42:43 - TARGET=powerpc TB --- 2011-10-24 05:42:43 - TARGET_ARCH=powerpc64 TB --- 2011-10-24 05:42:43 - TZ=UTC TB --- 2011-10-24 05:42:43 - __MAKE_CONF=/dev/null TB --- 2011-10-24 05:42:43 - cd /src TB --- 2011-10-24 05:42:43 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 05:42:44 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c:40: /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_vfsops.h:43: error: expected specifier-qualifier-list before 'vfs_t' *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/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 --- 2011-10-24 06:06:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-24 06:06:04 - ERROR: failed to build world TB --- 2011-10-24 06:06:04 - 1069.11 user 268.36 system 1421.94 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 06:15:54 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E29E1065675; Mon, 24 Oct 2011 06:15: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 119218FC14; Mon, 24 Oct 2011 06:15:53 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9O6FrKv043493; Mon, 24 Oct 2011 02:15:53 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9O6Fr9K043492; Mon, 24 Oct 2011 06:15:53 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 24 Oct 2011 06:15:53 GMT Message-Id: <201110240615.p9O6Fr9K043492@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 06:15:54 -0000 TB --- 2011-10-24 05:56:34 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 05:56:34 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-10-24 05:56:34 - cleaning the object tree TB --- 2011-10-24 05:56:39 - cvsupping the source tree TB --- 2011-10-24 05:56:39 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-10-24 05:56:51 - building world TB --- 2011-10-24 05:56:51 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 05:56:51 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 05:56:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 05:56:51 - SRCCONF=/dev/null TB --- 2011-10-24 05:56:51 - TARGET=sparc64 TB --- 2011-10-24 05:56:51 - TARGET_ARCH=sparc64 TB --- 2011-10-24 05:56:51 - TZ=UTC TB --- 2011-10-24 05:56:51 - __MAKE_CONF=/dev/null TB --- 2011-10-24 05:56:51 - cd /src TB --- 2011-10-24 05:56:51 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 05:56:51 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/sparc64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/sparc64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/sparc64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/sparc64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/sparc64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/sparc64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protect! or -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c:40: /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_vfsops.h:43: error: expected specifier-qualifier-list before 'vfs_t' *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/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 --- 2011-10-24 06:15:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-24 06:15:53 - ERROR: failed to build world TB --- 2011-10-24 06:15:53 - 927.23 user 229.58 system 1158.70 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 06:40:28 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5BFD106564A; Mon, 24 Oct 2011 06:40: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 7042C8FC08; Mon, 24 Oct 2011 06:40:28 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9O6eRiD033452; Mon, 24 Oct 2011 02:40:27 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9O6eR1U033447; Mon, 24 Oct 2011 06:40:27 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 24 Oct 2011 06:40:27 GMT Message-Id: <201110240640.p9O6eR1U033447@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, 24 Oct 2011 06:40:28 -0000 TB --- 2011-10-24 06:20:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 06:20:00 - starting HEAD tinderbox run for arm/arm TB --- 2011-10-24 06:20:00 - cleaning the object tree TB --- 2011-10-24 06:20:06 - cvsupping the source tree TB --- 2011-10-24 06:20:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-10-24 06:20:59 - building world TB --- 2011-10-24 06:20:59 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 06:20:59 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 06:20:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 06:20:59 - SRCCONF=/dev/null TB --- 2011-10-24 06:20:59 - TARGET=arm TB --- 2011-10-24 06:20:59 - TARGET_ARCH=arm TB --- 2011-10-24 06:20:59 - TZ=UTC TB --- 2011-10-24 06:20:59 - __MAKE_CONF=/dev/null TB --- 2011-10-24 06:20:59 - cd /src TB --- 2011-10-24 06:20:59 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 06:21:00 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign -W! no-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign -W! no-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign -W! no-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign -W! no-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign -W! no-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign -W! no-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c:40: /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_vfsops.h:43: error: expected specifier-qualifier-list before 'vfs_t' *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/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 --- 2011-10-24 06:40:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-24 06:40:27 - ERROR: failed to build world TB --- 2011-10-24 06:40:27 - 869.09 user 265.16 system 1226.89 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 06:47:23 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A878F106566C; Mon, 24 Oct 2011 06:47:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 728168FC08; Mon, 24 Oct 2011 06:47:23 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9O6lMrZ098224; Mon, 24 Oct 2011 02:47:22 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9O6lMa8098223; Mon, 24 Oct 2011 06:47:22 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 24 Oct 2011 06:47:22 GMT Message-Id: <201110240647.p9O6lMa8098223@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, 24 Oct 2011 06:47:23 -0000 TB --- 2011-10-24 06:20:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 06:20:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-10-24 06:20:00 - cleaning the object tree TB --- 2011-10-24 06:20:06 - cvsupping the source tree TB --- 2011-10-24 06:20:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-10-24 06:20:59 - building world TB --- 2011-10-24 06:20:59 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 06:20:59 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 06:20:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 06:20:59 - SRCCONF=/dev/null TB --- 2011-10-24 06:20:59 - TARGET=i386 TB --- 2011-10-24 06:20:59 - TARGET_ARCH=i386 TB --- 2011-10-24 06:20:59 - TZ=UTC TB --- 2011-10-24 06:20:59 - __MAKE_CONF=/dev/null TB --- 2011-10-24 06:20:59 - cd /src TB --- 2011-10-24 06:20:59 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 06:21:00 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c:40: /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_vfsops.h:43: error: expected specifier-qualifier-list before 'vfs_t' *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/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 --- 2011-10-24 06:47:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-24 06:47:22 - ERROR: failed to build world TB --- 2011-10-24 06:47:22 - 1217.55 user 290.13 system 1641.88 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 06:48:24 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67C141065674; Mon, 24 Oct 2011 06:48: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 3A69A8FC1F; Mon, 24 Oct 2011 06:48:23 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9O6mNP3002964; Mon, 24 Oct 2011 02:48:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9O6mNdn002959; Mon, 24 Oct 2011 06:48:23 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 24 Oct 2011 06:48:23 GMT Message-Id: <201110240648.p9O6mNdn002959@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, 24 Oct 2011 06:48:24 -0000 TB --- 2011-10-24 06:20:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 06:20:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-10-24 06:20:00 - cleaning the object tree TB --- 2011-10-24 06:20:06 - cvsupping the source tree TB --- 2011-10-24 06:20:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-10-24 06:20:59 - building world TB --- 2011-10-24 06:20:59 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 06:20:59 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 06:20:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 06:20:59 - SRCCONF=/dev/null TB --- 2011-10-24 06:20:59 - TARGET=amd64 TB --- 2011-10-24 06:20:59 - TARGET_ARCH=amd64 TB --- 2011-10-24 06:20:59 - TZ=UTC TB --- 2011-10-24 06:20:59 - __MAKE_CONF=/dev/null TB --- 2011-10-24 06:20:59 - cd /src TB --- 2011-10-24 06:20:59 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 06:21:00 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c:40: /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_vfsops.h:43: error: expected specifier-qualifier-list before 'vfs_t' *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/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 --- 2011-10-24 06:48:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-24 06:48:23 - ERROR: failed to build world TB --- 2011-10-24 06:48:23 - 1255.41 user 303.38 system 1702.63 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 06:52:11 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CCDC10656D2; Mon, 24 Oct 2011 06:52:11 +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 103478FC17; Mon, 24 Oct 2011 06:52:10 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9O6qAdb043608; Mon, 24 Oct 2011 02:52:10 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9O6qAnX043603; Mon, 24 Oct 2011 06:52:10 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 24 Oct 2011 06:52:10 GMT Message-Id: <201110240652.p9O6qAnX043603@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, 24 Oct 2011 06:52:11 -0000 TB --- 2011-10-24 06:20:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 06:20:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-10-24 06:20:00 - cleaning the object tree TB --- 2011-10-24 06:20:06 - cvsupping the source tree TB --- 2011-10-24 06:20:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-10-24 06:25:30 - building world TB --- 2011-10-24 06:25:30 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 06:25:30 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 06:25:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 06:25:30 - SRCCONF=/dev/null TB --- 2011-10-24 06:25:30 - TARGET=pc98 TB --- 2011-10-24 06:25:30 - TARGET_ARCH=i386 TB --- 2011-10-24 06:25:30 - TZ=UTC TB --- 2011-10-24 06:25:30 - __MAKE_CONF=/dev/null TB --- 2011-10-24 06:25:30 - cd /src TB --- 2011-10-24 06:25:30 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 06:25:30 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector ! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c:40: /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_vfsops.h:43: error: expected specifier-qualifier-list before 'vfs_t' *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/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 --- 2011-10-24 06:52:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-24 06:52:10 - ERROR: failed to build world TB --- 2011-10-24 06:52:10 - 1222.33 user 290.70 system 1929.50 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 07:06:52 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC082106566C; Mon, 24 Oct 2011 07:06: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 860EE8FC0C; Mon, 24 Oct 2011 07:06:52 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9O76peg090350; Mon, 24 Oct 2011 03:06:51 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9O76pLH090326; Mon, 24 Oct 2011 07:06:51 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 24 Oct 2011 07:06:51 GMT Message-Id: <201110240706.p9O76pLH090326@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, 24 Oct 2011 07:06:52 -0000 TB --- 2011-10-24 06:40:27 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 06:40:27 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-10-24 06:40:27 - cleaning the object tree TB --- 2011-10-24 06:40:32 - cvsupping the source tree TB --- 2011-10-24 06:40:32 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-10-24 06:40:46 - building world TB --- 2011-10-24 06:40:46 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 06:40:46 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 06:40:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 06:40:46 - SRCCONF=/dev/null TB --- 2011-10-24 06:40:46 - TARGET=ia64 TB --- 2011-10-24 06:40:46 - TARGET_ARCH=ia64 TB --- 2011-10-24 06:40:46 - TZ=UTC TB --- 2011-10-24 06:40:46 - __MAKE_CONF=/dev/null TB --- 2011-10-24 06:40:46 - cd /src TB --- 2011-10-24 06:40:46 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 06:40:47 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign ! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign ! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign ! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign ! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign ! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign ! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c:40: /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_vfsops.h:43: error: expected specifier-qualifier-list before 'vfs_t' *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/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 --- 2011-10-24 07:06:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-24 07:06:51 - ERROR: failed to build world TB --- 2011-10-24 07:06:51 - 1198.48 user 292.45 system 1583.62 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 12:27:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D793A106566C; Mon, 24 Oct 2011 12:27:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id AD9BC8FC0A; Mon, 24 Oct 2011 12:27:52 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 606B846B2A; Mon, 24 Oct 2011 08:27:52 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 013AC8A02F; Mon, 24 Oct 2011 08:27:52 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 24 Oct 2011 07:59:54 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <20111020114844.GK59810@albert.catwhisker.org> <4EA2EFDD.4020507@gmail.com> In-Reply-To: <4EA2EFDD.4020507@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201110240759.54727.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 24 Oct 2011 08:27:52 -0400 (EDT) Cc: Garrett Cooper , Craig Rodrigues , Doug Barton , "Luchesar V. ILIEV" Subject: Re: sys/conf/newvers.sh vs. subversion-1.7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2011 12:27:52 -0000 On Saturday, October 22, 2011 12:31:25 pm Luchesar V. ILIEV wrote: > Speaking of that, and in the context of the recursion that svnversion > does, something else comes to my mind... > > svnversion is currently executed in ${SRCDIR}/sys, so the revision > number is relevant only to the kernel sources. But FreeBSD is not just a > kernel, unlike Linux, so wouldn't it make more sense to actually check > the revision directly at ${SRCDIR}, thus catching possible different > revisions in other parts of the base system source tree? Please no. That makes svnversion take a _lot_ longer. We used to do that, but changed it. Also, the kernel build does not use any sources outside of sys/, so for the kernel an svnversion of sys/ is perfectly reasonable. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 12:27:54 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37AC2106564A; Mon, 24 Oct 2011 12:27:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0C6F98FC0C; Mon, 24 Oct 2011 12:27:54 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id B7ED446B0C; Mon, 24 Oct 2011 08:27:53 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3AFDD8A037; Mon, 24 Oct 2011 08:27:53 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 24 Oct 2011 08:14:22 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <20111022084931.GD1697@garage.freebsd.pl> <20111023084445.GB50300@deviant.kiev.zoral.com.ua> <20111023155827.GH1697@garage.freebsd.pl> In-Reply-To: <20111023155827.GH1697@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201110240814.22368.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 24 Oct 2011 08:27:53 -0400 (EDT) Cc: Kostik Belousov , Lawrence Stewart , Andre Oppermann , Pawel Jakub Dawidek , freebsd-net@freebsd.org Subject: Re: 9.0-RC1 panic in tcp_input: negative winow. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2011 12:27:54 -0000 On Sunday, October 23, 2011 11:58:28 am Pawel Jakub Dawidek wrote: > On Sun, Oct 23, 2011 at 11:44:45AM +0300, Kostik Belousov wrote: > > On Sun, Oct 23, 2011 at 08:10:38AM +0200, Pawel Jakub Dawidek wrote: > > > My suggestion would be that if we won't be able to fix it before 9.0, > > > we should turn this assertion off, as the system seems to be able to > > > recover. > > > > Shipped kernels have all assertions turned off. > > Yes, I'm aware of that, but many people compile their production kernels > with INVARIANTS/INVARIANT_SUPPORT to fail early instead of eg. > corrupting data. I'd be fine in moving this under DIAGNOSTIC or changing > it into a printf, so it will be visible. No, the kernel is corrupting things in other places when this is true, so if you are running with INVARIANTS, we want to know about it. Specifically, in several places in TCP we assume that rcv_adv >= rcv_nxt, and depend on being able to do 'rcv_adv - rcv_nxt'. In this case, it looks like the difference is consistently less than one frame. I suspect the other end of the connection is sending just beyond the end of the advertised window (it probably assumes it is better to send a full frame if it has that much pending data even though part of it is beyond the window edge vs sending a truncated packet that just fills the window) and that that frame is accepted ok in the header prediction case and it's ACK is delayed, but the next packet to arrive then trips over this assumption. Since 'win' is guaranteed to be non-negative and we explicitly cast 'rcv_adv - rcv_nxt' to (int) in the following line that the assert is checking for: tp->rcv_wnd = imax(win, (int)(tp->rcv_adv - tp->rcv_nxt)); I think we already handle this case ok and perhaps the assertion can just be removed? Not sure if others feel that it warrants a comment to note that this is the case being handled. Also, I'm not sure if this case can "leak" into the timewait code? If so, we will need to fix this case: /* * Recover last window size sent. */ KASSERT(SEQ_GEQ(tp->rcv_adv, tp->rcv_nxt), ("tcp_twstart negative window: tp %p rcv_nxt %u rcv_adv %u", tp, tp->rcv_nxt, tp->rcv_adv)); tw->last_win = (tp->rcv_adv - tp->rcv_nxt) >> tp->rcv_scale; So that it sets last_win to 0 instead of some really huge value. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 12:27:55 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA4BC106566B; Mon, 24 Oct 2011 12:27:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 80FF28FC08; Mon, 24 Oct 2011 12:27:55 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 385F946B45; Mon, 24 Oct 2011 08:27:55 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C9E4C8A02E; Mon, 24 Oct 2011 08:27:54 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Mon, 24 Oct 2011 08:18:43 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <4EA1E3D0.9000300@FreeBSD.org> <4EA1E60C.8040403@FreeBSD.org> In-Reply-To: <4EA1E60C.8040403@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201110240818.43938.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 24 Oct 2011 08:27:54 -0400 (EDT) Cc: Pavel Timofeev , freebsd-current@freebsd.org, Dennis Koegel Subject: Re: Fresh installed Freebsd 9 don't boot from hd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2011 12:27:55 -0000 On Friday, October 21, 2011 5:37:16 pm Andriy Gapon wrote: > on 22/10/2011 00:27 Andriy Gapon said the following: > > on 21/10/2011 23:33 John Baldwin said the following: > >> On Friday, October 21, 2011 4:58:51 am Dennis Koegel wrote: > >>> On Thu, Oct 20, 2011 at 11:28:08AM +0400, Pavel Timofeev wrote: > >>>> I used FreeBSD 9 amd64 on my HP Proliant DL360 G5 (smart array p400i > >> mirror) > >>>> as test. [...] > >>>> It was fresh install and I choose guided partitioning (GPT) > >>>> But after reboot my server don't boot from hd. > >>> > >>> We have the same issue on a DL580 G7. Install runs fine, but when it's > >>> time for the first boot, the bootcode emits a single '-' (where usually > >>> it would be "spinning" for a moment while loading), hangs for about two > >>> seconds, and then reboots. > >> > >> Working offline with Dennis, we found that changing the CFLAGS in > >> sys/boot/i386/gptboot/Makefile from "-O1" to "-Os -mrtd" (partially reverting > >> an earlier commit) fixed gptboot. The next test for someone to do would be to > >> try just adding "-mrtd" and leaving "-O1" as-is to see if that fixes it. > > > > Hmm, this is quite unexpected... Do you have a hypothesis why not using -mrtd > > could cause a problem (a miscompilation?) ? > > I've just got one: maybe the trouble is caused by the sio_putc procedure in > sys/boot/i386/btx/btx/btx.S. It seems to be the only place in the boot code > where 'ret ' instruction is explicitly used. > > A litmus question: do those experiencing the trouble all have BTX_SERIAL defined? No, they all have an HP machine. > P.S. BTW, is BTX_SERIAL documented anywhere? It is not, and I strongly doubt anyone has it enabled. You can't use it with boot2 for example due to size bloat. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 12:27:55 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E75B3106564A for ; Mon, 24 Oct 2011 12:27:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BDECE8FC0A for ; Mon, 24 Oct 2011 12:27:55 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 71E7546B4C; Mon, 24 Oct 2011 08:27:55 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 124658A03C; Mon, 24 Oct 2011 08:27:55 -0400 (EDT) From: John Baldwin To: Arnaud Lacombe Date: Mon, 24 Oct 2011 08:20:22 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <201110211619.45623.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110240820.22431.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 24 Oct 2011 08:27:55 -0400 (EDT) Cc: freebsd-current@freebsd.org Subject: Re: ipmi(4)/isa woes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2011 12:27:56 -0000 On Friday, October 21, 2011 5:31:01 pm Arnaud Lacombe wrote: > Hi, > > On Fri, Oct 21, 2011 at 4:19 PM, John Baldwin wrote: > > On Tuesday, October 11, 2011 6:53:11 pm Arnaud Lacombe wrote: > >> Hi, > >> > >> On Tue, Oct 11, 2011 at 6:34 PM, Arnaud Lacombe wrote: > >> > Hi folks, > >> > > >> > I've got a machine where ipmi(4) seem to be unable to fully attach. > >> > 10-current kernel complains the following way: > >> > > >> > ipmi0: at iomem 0-0x1 on isa0 > >> > ipmi0: KCS mode found at mem 0x0 alignment 0x1 on isa > >> > ipmi0: couldn't configure I/O resource > >> > device_attach: ipmi0 attach returned 6 > > > > Resource 0 is not right and will not work. In this case your BIOS has a buggy > > SMBIOS / DMI table entry for IPMI. > > > >> Actually, I can bypass this issue by enabling acpi(4): > >> > >> ipmi0: port 0xca2,0xca3 on acpi0 > >> ipmi0: KCS mode found at io 0xca2 on acpi > >> ipmi1: on isa0 > >> device_attach: ipmi1 attach returned 16 > >> pmtimer0 on isa0 > >> ipmi1: on isa0 > >> device_attach: ipmi1 attach returned 16 > > > > You can ignore the ipmi1 messages. > > > >> However, the driver fails right after with: > >> > >> ipmi0: Timed out waiting for GET_DEVICE_ID > > > > Are you sure you have working IPMI? The timeouts and the busted DMI table > > is consistent with a machine where IPMI is available via an optional > > daughterboard, but the daughterboard isn't installed. > > > Well, I'm not sure exactly what's the hardware layout looks like[0], > but when ipmi0 is "attached" on isa0, I can access the IPMI > controller, get the various information, set/reset the watchdog. > ipmitool(1) works like a charm. However, at some point, the KCS is > unable to reach the IPMI controller. Typical error is: > > ipmi0: KCS: Reply address mismatch > ipmi0: KCS error: 01 > ipmi0: KCS: Reply address mismatch > ipmi0: KCS error: 01 > ipmi0: Failed to set watchdog > > over an undetermined period of time. Sometimes it stops before the > watchdog triggers, sometimes it [falsely] triggers the watchdog. Ok. I've seen this sometimes where the BMC appears to lockup. The driver follows the protocol defined in the spec for resetting the KCS connection when it detects an error and will retry 3 times before it fails. There's not really much we can do once the hardware locks up however. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 13:41:04 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 122AF106564A; Mon, 24 Oct 2011 13:41:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id DBC288FC12; Mon, 24 Oct 2011 13:41:03 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 7AF9546B46; Mon, 24 Oct 2011 09:41:03 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 046A18A02E; Mon, 24 Oct 2011 09:41:03 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Mon, 24 Oct 2011 09:41:02 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <20111023152754.GA35505@neveragain.de> <4EA455A7.2060301@FreeBSD.org> In-Reply-To: <4EA455A7.2060301@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201110240941.02515.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 24 Oct 2011 09:41:03 -0400 (EDT) Cc: Pavel Timofeev , freebsd-current@freebsd.org, Dennis Koegel Subject: Re: Fresh installed Freebsd 9 don't boot from hd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2011 13:41:04 -0000 On Sunday, October 23, 2011 1:57:59 pm Andriy Gapon wrote: > on 23/10/2011 18:27 Dennis Koegel said the following: > > On Fri, Oct 21, 2011 at 04:33:38PM -0400, John Baldwin wrote: > >> Working offline with Dennis, we found that changing the CFLAGS in > >> sys/boot/i386/gptboot/Makefile from "-O1" to "-Os -mrtd" (partially reverting > >> an earlier commit) fixed gptboot. The next test for someone to do would be to > >> try just adding "-mrtd" and leaving "-O1" as-is to see if that fixes it. > > > > More test results: > > > > gcc -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time \ > > -mno-align-long-strings -mrtd [from before r225530]: Boots OK > > gcc -Os -mrtd: Boots OK > > gcc -O1 -mrtd: Fails > > gcc -O1: Fails > > gcc -O0: Fails > > gcc -Os: Boots OK > > > > clang -O1: Fails > > clang -Os: Fails > > clang -Oz: Fails > > > > I've put some printf()s into gpt{,boot}.c to trace where the reboot is > > triggered. It appears to be in drvsize() (called from gptread()). OTOH > > the debug output may have changed where the problem occurs, I don't > > know about that. > > > > With 9.0R drawing near, CFLAGS should be s/-O1/-Os/, until we can figure > > out what happens. But as for why gcc's magic -Os is required and clang's > > output doesn't work at all, I'm clueless. > > Thank you for your very valuable analysis! > I looked at a difference in assembly code of the drvsize function produced by > gcc -Os and by gcc -O1. One thing that was immediately obvious is that gcc > places the params array and the sectors variable in a different order for > different options. One idea is that if BIOS actually writes beyond the end of > the array, then in one case it could be harmless (overwrites the sector > variable), but in the other case it could be more harmful. > I found a document that suggests a possibility of BIOS writing more bytes to the > array than its current size of 0x42: > http://www.t13.org/documents/UploadedDocuments/docs2008/e08134r1-BIOS_Enhanced_Disk_Drive_Services_4.0.pdf > > Of course, the size of the array is passed to BIOS at the start of the array and > so a _non-buggy_ BIOS should not write beyond the array, but we live in a > non-perfect world. Hmm, I think we've had to do a similar workaround in the past for a different BIOS call (SMAP maybe?). However, I do have one request, can we declare an actual structure instead of a silly char array? Then we can remove the weird casts with offsets into it, etc. Having an actual struct would be far more readable and less bug-prone. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 13:47:45 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2EA81065673; Mon, 24 Oct 2011 13:47: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 C45B38FC0A; Mon, 24 Oct 2011 13:47:44 +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 QAA22840; Mon, 24 Oct 2011 16:47:43 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4EA56C7E.1040005@FreeBSD.org> Date: Mon, 24 Oct 2011 16:47:42 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: John Baldwin References: <20111023152754.GA35505@neveragain.de> <4EA455A7.2060301@FreeBSD.org> <201110240941.02515.jhb@freebsd.org> In-Reply-To: <201110240941.02515.jhb@freebsd.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Pavel Timofeev , freebsd-current@FreeBSD.org, Dennis Koegel Subject: Re: Fresh installed Freebsd 9 don't boot from hd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2011 13:47:45 -0000 on 24/10/2011 16:41 John Baldwin said the following: > On Sunday, October 23, 2011 1:57:59 pm Andriy Gapon wrote: >> on 23/10/2011 18:27 Dennis Koegel said the following: >>> On Fri, Oct 21, 2011 at 04:33:38PM -0400, John Baldwin wrote: >>>> Working offline with Dennis, we found that changing the CFLAGS in >>>> sys/boot/i386/gptboot/Makefile from "-O1" to "-Os -mrtd" (partially reverting >>>> an earlier commit) fixed gptboot. The next test for someone to do would be to >>>> try just adding "-mrtd" and leaving "-O1" as-is to see if that fixes it. >>> >>> More test results: >>> >>> gcc -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time \ >>> -mno-align-long-strings -mrtd [from before r225530]: Boots OK >>> gcc -Os -mrtd: Boots OK >>> gcc -O1 -mrtd: Fails >>> gcc -O1: Fails >>> gcc -O0: Fails >>> gcc -Os: Boots OK >>> >>> clang -O1: Fails >>> clang -Os: Fails >>> clang -Oz: Fails >>> >>> I've put some printf()s into gpt{,boot}.c to trace where the reboot is >>> triggered. It appears to be in drvsize() (called from gptread()). OTOH >>> the debug output may have changed where the problem occurs, I don't >>> know about that. >>> >>> With 9.0R drawing near, CFLAGS should be s/-O1/-Os/, until we can figure >>> out what happens. But as for why gcc's magic -Os is required and clang's >>> output doesn't work at all, I'm clueless. >> >> Thank you for your very valuable analysis! >> I looked at a difference in assembly code of the drvsize function produced by >> gcc -Os and by gcc -O1. One thing that was immediately obvious is that gcc >> places the params array and the sectors variable in a different order for >> different options. One idea is that if BIOS actually writes beyond the end of >> the array, then in one case it could be harmless (overwrites the sector >> variable), but in the other case it could be more harmful. >> I found a document that suggests a possibility of BIOS writing more bytes to the >> array than its current size of 0x42: >> http://www.t13.org/documents/UploadedDocuments/docs2008/e08134r1-BIOS_Enhanced_Disk_Drive_Services_4.0.pdf >> >> Of course, the size of the array is passed to BIOS at the start of the array and >> so a _non-buggy_ BIOS should not write beyond the array, but we live in a >> non-perfect world. > > Hmm, I think we've had to do a similar workaround in the past for a different > BIOS call (SMAP maybe?). However, I do have one request, can we declare an > actual structure instead of a silly char array? Then we can remove the weird > casts with offsets into it, etc. Having an actual struct would be far more > readable and less bug-prone. > I am all for this. Unfortunately. ENOTIME to do this properly at the moment. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 13:55:27 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C676D1065673; Mon, 24 Oct 2011 13:55:27 +0000 (UTC) (envelope-from luchesar.iliev@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 63FC98FC14; Mon, 24 Oct 2011 13:55:27 +0000 (UTC) Received: by ggnq2 with SMTP id q2so5843363ggn.13 for ; Mon, 24 Oct 2011 06:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=NfctXVWUXFobFX4C6Xr0GGt4/uNvvP/W72ns0FXsR/s=; b=R9peyNpE56pS9H++1PXYaqk2WUtmRkKsifTbAIvJkJIYciMPGMbkSAuzbwtByaEF0d dSgJ1Ey2A/b00CylRqFDi+SyeQKxSLMSUbFZlbKA6u2dIjdmlhrLxaFK94O0XRjX/4G/ YPuHTVzgm25SK8CzIP7KN5ZubYetFPoqXFc90= Received: by 10.223.4.215 with SMTP id 23mr43706517fas.8.1319464526335; Mon, 24 Oct 2011 06:55:26 -0700 (PDT) Received: from [79.124.93.41] ([79.124.93.41]) by mx.google.com with ESMTPS id a1sm42735214fab.4.2011.10.24.06.55.24 (version=SSLv3 cipher=OTHER); Mon, 24 Oct 2011 06:55:25 -0700 (PDT) Message-ID: <4EA56E4B.9090802@gmail.com> Date: Mon, 24 Oct 2011 16:55:23 +0300 From: "Luchesar V. ILIEV" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111020 Thunderbird/7.0.1 MIME-Version: 1.0 To: John Baldwin References: <20111020114844.GK59810@albert.catwhisker.org> <4EA2EFDD.4020507@gmail.com> <201110240759.54727.jhb@freebsd.org> In-Reply-To: <201110240759.54727.jhb@freebsd.org> X-Enigmail-Version: undefined OpenPGP: id=9A1FEEFF; url=https://cert.acad.bg/pgp-keys/ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , Craig Rodrigues , freebsd-current@freebsd.org, Doug Barton Subject: Re: sys/conf/newvers.sh vs. subversion-1.7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2011 13:55:27 -0000 On 24/10/2011 14:59, John Baldwin wrote: > On Saturday, October 22, 2011 12:31:25 pm Luchesar V. ILIEV wrote: >> Speaking of that, and in the context of the recursion that svnversion >> does, something else comes to my mind... >> >> svnversion is currently executed in ${SRCDIR}/sys, so the revision >> number is relevant only to the kernel sources. But FreeBSD is not just a >> kernel, unlike Linux, so wouldn't it make more sense to actually check >> the revision directly at ${SRCDIR}, thus catching possible different >> revisions in other parts of the base system source tree? > > Please no. That makes svnversion take a _lot_ longer. We used to do that, > but changed it. Also, the kernel build does not use any sources outside > of sys/, so for the kernel an svnversion of sys/ is perfectly reasonable. > Sorry, it's my fault not noticing that it used to be that way. I also guess that the topic has been discussed, so I'm sure all the pros and cons have been well weighted. Thanks for the clarification. Cheers, Luchesar From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 15:50:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7458E1065775; Mon, 24 Oct 2011 15:50:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 32D128FC15; Mon, 24 Oct 2011 15:50:29 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id BE88146B23; Mon, 24 Oct 2011 11:50:28 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 577FE8A037; Mon, 24 Oct 2011 11:50:28 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Mon, 24 Oct 2011 11:33:23 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <201110240941.02515.jhb@freebsd.org> <4EA56C7E.1040005@FreeBSD.org> In-Reply-To: <4EA56C7E.1040005@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110241133.23397.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 24 Oct 2011 11:50:28 -0400 (EDT) Cc: Pavel Timofeev , freebsd-current@freebsd.org, Dennis Koegel Subject: Re: Fresh installed Freebsd 9 don't boot from hd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2011 15:50:29 -0000 On Monday, October 24, 2011 9:47:42 am Andriy Gapon wrote: > on 24/10/2011 16:41 John Baldwin said the following: > > On Sunday, October 23, 2011 1:57:59 pm Andriy Gapon wrote: > >> on 23/10/2011 18:27 Dennis Koegel said the following: > >>> On Fri, Oct 21, 2011 at 04:33:38PM -0400, John Baldwin wrote: > >>>> Working offline with Dennis, we found that changing the CFLAGS in > >>>> sys/boot/i386/gptboot/Makefile from "-O1" to "-Os -mrtd" (partially reverting > >>>> an earlier commit) fixed gptboot. The next test for someone to do would be to > >>>> try just adding "-mrtd" and leaving "-O1" as-is to see if that fixes it. > >>> > >>> More test results: > >>> > >>> gcc -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time \ > >>> -mno-align-long-strings -mrtd [from before r225530]: Boots OK > >>> gcc -Os -mrtd: Boots OK > >>> gcc -O1 -mrtd: Fails > >>> gcc -O1: Fails > >>> gcc -O0: Fails > >>> gcc -Os: Boots OK > >>> > >>> clang -O1: Fails > >>> clang -Os: Fails > >>> clang -Oz: Fails > >>> > >>> I've put some printf()s into gpt{,boot}.c to trace where the reboot is > >>> triggered. It appears to be in drvsize() (called from gptread()). OTOH > >>> the debug output may have changed where the problem occurs, I don't > >>> know about that. > >>> > >>> With 9.0R drawing near, CFLAGS should be s/-O1/-Os/, until we can figure > >>> out what happens. But as for why gcc's magic -Os is required and clang's > >>> output doesn't work at all, I'm clueless. > >> > >> Thank you for your very valuable analysis! > >> I looked at a difference in assembly code of the drvsize function produced by > >> gcc -Os and by gcc -O1. One thing that was immediately obvious is that gcc > >> places the params array and the sectors variable in a different order for > >> different options. One idea is that if BIOS actually writes beyond the end of > >> the array, then in one case it could be harmless (overwrites the sector > >> variable), but in the other case it could be more harmful. > >> I found a document that suggests a possibility of BIOS writing more bytes to the > >> array than its current size of 0x42: > >> http://www.t13.org/documents/UploadedDocuments/docs2008/e08134r1-BIOS_Enhanced_Disk_Drive_Services_4.0.pdf > >> > >> Of course, the size of the array is passed to BIOS at the start of the array and > >> so a _non-buggy_ BIOS should not write beyond the array, but we live in a > >> non-perfect world. > > > > Hmm, I think we've had to do a similar workaround in the past for a different > > BIOS call (SMAP maybe?). However, I do have one request, can we declare an > > actual structure instead of a silly char array? Then we can remove the weird > > casts with offsets into it, etc. Having an actual struct would be far more > > readable and less bug-prone. > > > > I am all for this. > Unfortunately. ENOTIME to do this properly at the moment. Ugh, it looks like in EDD 4.0 they silently expanded the path field to 16 bytes instead of 8 as in EDD 3.0 which is why the HP BIOS is probably writing an extra four bytes. Ah, so the deal is that the device path bit is variable length and the caller is supposed to set the length on input which we aren't doing. However, we don't care about the device path stuff anyway, so we can set a smaller input value. Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 16:25:13 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 200D4106566B; Mon, 24 Oct 2011 16:25: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 206788FC08; Mon, 24 Oct 2011 16:25:11 +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 TAA24938; Mon, 24 Oct 2011 19:25:10 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4EA59165.1000202@FreeBSD.org> Date: Mon, 24 Oct 2011 19:25:09 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: John Baldwin References: <201110240941.02515.jhb@freebsd.org> <4EA56C7E.1040005@FreeBSD.org> <201110241133.23397.jhb@freebsd.org> In-Reply-To: <201110241133.23397.jhb@freebsd.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Pavel Timofeev , freebsd-current@FreeBSD.org, Dennis Koegel Subject: Re: Fresh installed Freebsd 9 don't boot from hd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2011 16:25:13 -0000 on 24/10/2011 18:33 John Baldwin said the following: > On Monday, October 24, 2011 9:47:42 am Andriy Gapon wrote: >> on 24/10/2011 16:41 John Baldwin said the following: >>> On Sunday, October 23, 2011 1:57:59 pm Andriy Gapon wrote: [snip] >>>> I found a document that suggests a possibility of BIOS writing more bytes to the >>>> array than its current size of 0x42: >>>> http://www.t13.org/documents/UploadedDocuments/docs2008/e08134r1-BIOS_Enhanced_Disk_Drive_Services_4.0.pdf >>>> >>>> Of course, the size of the array is passed to BIOS at the start of the array and >>>> so a _non-buggy_ BIOS should not write beyond the array, but we live in a >>>> non-perfect world. >>> >>> Hmm, I think we've had to do a similar workaround in the past for a different >>> BIOS call (SMAP maybe?). However, I do have one request, can we declare an >>> actual structure instead of a silly char array? Then we can remove the weird >>> casts with offsets into it, etc. Having an actual struct would be far more >>> readable and less bug-prone. >>> >> >> I am all for this. >> Unfortunately. ENOTIME to do this properly at the moment. > > Ugh, it looks like in EDD 4.0 they silently expanded the path field to 16 bytes > instead of 8 as in EDD 3.0 which is why the HP BIOS is probably writing an extra > four bytes. Yes, that's exactly what I meant above, but probably wasn't clear about that. > Ah, so the deal is that the device path bit is variable length and the caller is > supposed to set the length on input which we aren't doing. However, we don't > care about the device path stuff anyway, so we can set a smaller input value. > > Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch > > +struct edd_params { > + uint16_t len; > + uint16_t flags; > + uint32_t cylinders; > + uint32_t heads; > + uint32_t sectors_per_track; > + uint64_t sectors; > + uint32_t sector_size; sector_size should be uint16_t, I think. Ditto for edd_params_v3 and edd_params_v4. sizeof(struct edd_params) should be 30, judging from the specs. > + uint16_t edd_params_seg; > + uint16_t edd_params_off; > +}; Perhaps the structures should be declared __packed (if only just in case)? Also, perhaps edd_params_v3 and edd_params_v4 should inherit edd_params in some "smarter" way to avoid verbatim duplicates. Other than these issues the patch looks great! Perhaps later we could do detailed definitions for things like interface paths for various cases, etc. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 17:14:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C98A51065670; Mon, 24 Oct 2011 17:14:48 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2332F8FC13; Mon, 24 Oct 2011 17:14:47 +0000 (UTC) Received: by bkbzu17 with SMTP id zu17so10926305bkb.13 for ; Mon, 24 Oct 2011 10:14:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=G9UxTO4QxdD6iRypOtNR+n/tpSNfKF+xgFzy8R3cvso=; b=iOZ8OPOYXy/+mVYNDMvUsTuvuoGHNRkVBIR+lbqJpze5YXtMVqu5k8ALUfzjq5NXmp Yout7jqleHOKqE4Jih4eOOyZ+7nLeuxiEHgZVP5ynpgRvYeeHc/9srXKgnm4ycPgiFg+ m5v/bPw3ZLreh7nNY1M1uLVRpXFjxCMXyt/Iw= MIME-Version: 1.0 Received: by 10.204.152.195 with SMTP id h3mr17621856bkw.1.1319476486717; Mon, 24 Oct 2011 10:14:46 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.204.39.12 with HTTP; Mon, 24 Oct 2011 10:14:46 -0700 (PDT) In-Reply-To: <4EA2590B.90008@FreeBSD.org> References: <20111020114844.GK59810@albert.catwhisker.org> <20111020122121.GL59810@albert.catwhisker.org> <201110211636.05917.jhb@freebsd.org> <20111021211221.GV59810@albert.catwhisker.org> <4EA21842.5000808@FreeBSD.org> <4EA2590B.90008@FreeBSD.org> Date: Mon, 24 Oct 2011 10:14:46 -0700 X-Google-Sender-Auth: qtM3uvL5IHiNPqBwRP3OyYD9Do0 Message-ID: From: Craig Rodrigues To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: sys/conf/newvers.sh vs. subversion-1.7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2011 17:14:49 -0000 On Fri, Oct 21, 2011 at 10:47 PM, Doug Barton wrote: > On 10/21/2011 22:42, Craig Rodrigues wrote: >> Hi, >> >> I tried following: >> >> (1) =A0 Run svnversion in non-svn directory: >> >> =A0 =A0return status =3D=3D 0 > > Return status isn't everything. :) > >> =A0 =A0prints out "exported" > > In my case (1.7) it says "Unversioned directory" > > But my point (which perhaps I should have made more explicit) is that > given the fact that svnversion handles non-svn directories gracefully > it's faster (simpler, etc.) to just run foo=3D`svnversion` and then make > sure that $foo is rational than it is to run 2 commands. > > Doug Hi, What logic can we use to make sure svnversion returns a rational value? It looks like the output of svnversion for non-svn directories is inconsistent between versions of Subversion. Running a command seems like a better approach than looking for ".svn" directories. --=20 Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 17:15:47 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF88D106566C; Mon, 24 Oct 2011 17:15:47 +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 9F3F18FC13; Mon, 24 Oct 2011 17:15:47 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9OHFkJ6070902; Mon, 24 Oct 2011 13:15:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9OHFkU2070864; Mon, 24 Oct 2011 17:15:46 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 24 Oct 2011 17:15:46 GMT Message-Id: <201110241715.p9OHFkU2070864@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, 24 Oct 2011 17:15:48 -0000 TB --- 2011-10-24 15:30:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-24 15:30:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-10-24 15:30:00 - cleaning the object tree TB --- 2011-10-24 15:30:57 - cvsupping the source tree TB --- 2011-10-24 15:30:57 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-10-24 15:31:09 - building world TB --- 2011-10-24 15:31:09 - CROSS_BUILD_TESTING=YES TB --- 2011-10-24 15:31:09 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-24 15:31:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-24 15:31:09 - SRCCONF=/dev/null TB --- 2011-10-24 15:31:09 - TARGET=i386 TB --- 2011-10-24 15:31:09 - TARGET_ARCH=i386 TB --- 2011-10-24 15:31:09 - TZ=UTC TB --- 2011-10-24 15:31:09 - __MAKE_CONF=/dev/null TB --- 2011-10-24 15:31:09 - cd /src TB --- 2011-10-24 15:31:09 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 24 15:31:09 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/obj/i386.i386/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libdecnumber -std=gnu89 -fstack-protector -c /src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/gimplify.c cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/obj/i386.i386/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libdecnumber -std=gnu89 -fstack-protector -c /src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/tree-pretty-print.c cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/obj/i386.i386/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libdecnumber -std=gnu89 -fstack-protector -c /src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/tree-into-ssa.c /src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/tree-into-ssa.c: In function 'update_ssa': /src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/tree-into-ssa.c:2949: internal compiler error: in var_ann, at tree-flow-inline.h:128 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop in /src/gnu/usr.bin/cc/cc_int. *** Error code 1 Stop in /src/gnu/usr.bin/cc. *** Error code 1 Stop in /src/gnu/usr.bin. *** Error code 1 Stop in /src/gnu. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-10-24 17:15:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-24 17:15:45 - ERROR: failed to build world TB --- 2011-10-24 17:15:45 - 5141.25 user 861.38 system 6345.43 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 17:55:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9B5E1065677 for ; Mon, 24 Oct 2011 17:55:49 +0000 (UTC) (envelope-from stigberth@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7AF088FC17 for ; Mon, 24 Oct 2011 17:55:49 +0000 (UTC) Received: by gyd8 with SMTP id 8so7788743gyd.13 for ; Mon, 24 Oct 2011 10:55:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=kL9oLv2JbwrX8fvHkN6cWAcp+UoJK7vIYYW0oox4L/I=; b=jQjxnl+5lmyNIzbYu+wEH+n9PgI5GYNNHOW3jdkHrAVafPWSbbWQgRuvHSnwoVBp/l xQHor/qjxllqyhkHUlFHwjYm5FdWvWaQ9hlms8BD+laG0+qzPZo6m4LtdQWRMTjJl+6R NV+W9ajTa/Oq+ObHaatZjF9xhJuPKhcCLRrl0= MIME-Version: 1.0 Received: by 10.223.16.82 with SMTP id n18mr44646765faa.2.1319477593209; Mon, 24 Oct 2011 10:33:13 -0700 (PDT) Received: by 10.152.42.233 with HTTP; Mon, 24 Oct 2011 10:33:13 -0700 (PDT) Date: Mon, 24 Oct 2011 19:33:13 +0200 Message-ID: From: Stig B To: freebsd-current@freebsd.org X-Mailman-Approved-At: Mon, 24 Oct 2011 18:06:56 +0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: FreeBSD 9.0-beta3, cannot boot after succesfull installation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2011 17:55:49 -0000 Hello, list. I've been trying to install FreeBSD 9.0-beta3 amd64 on a machine with the following hardware: Motherboard: MSI K8N Neo2-Platinum CPU: AMD Athlon64 3000+ (1800 MHz) RAM: 1 GB (2 x 512 MB) DDR2 Disk: Western Digital Caviar=AE Green=99 1TB The story is as follows: Before you think it; I disabled IOAPIC in the BIOS as I have an nforce3 chipset for these installation tests (and it's perhaps not even related to this problem). I decided to re-install my "server" box which was running FreeBSD 8.1 x86 after many power outages and corruption on the filesystem. Initially I had only 1x 1TB disk of the model mentioned above. When I, after a succesful installation and using the guided partitioning scheme with GPT, could not boot the machine, I blamed the HDD and went out and bought another 1TB disk= . I plugged it in, ran the installer again, same defaults, and same symptom. The symptom is that the PC freezes at the step where it checks connected devices such as HDDs and CDROM. I can not even enter the BIOS. I took the disks out of the machine, put them into another machine, booted up the newest Ubuntu, and ran the following command to clean the beginning of the disks: dd if=3D/dev/zero of=3D/dev/sda1 /* for the first disk */ and dd if=3D/dev/zero of=3D/dev/sda2 /* for the second disk */ I then put them back into the machine with which I was having problems. It now booted properly, and I could run the installer again. This time, I used MBR partitioning table. I finished the installer, removed the medium and rebooted. Same symptoms as above. PC freezes at the step where it checks connected devices such as HDDs and CDROM. I can not even enter the BIOS. Someone from #bsddev on efnet adviced me to dd-zero-wipe both the start and the end of the disks. To be sure, I ran these dd commands: dd if=3D/dev/zero of=3D/dev/sda1 bs=3D1M /* for the first disk */ dd if=3D/dev/zero of=3D/dev/sda2 bs=3D1M /* for the second disk */ and let them run over the entirety of both the disks; wiping them completel= y with zeroes. This time with totally cleaned disks, I installed FreeBSD 9.0-beta3 amd64 again with MBR. I decided NOT to try with GPT as I wasn't sure my BIOS was compatible with GUID partition table. I finished the installer, removed the medium and rebooted. Same symptoms as above. PC freezes at the step where i= t checks connected devices such as HDDs and CDROM. I can not even enter the BIOS. At this point I gave up and installed FreeBSD 8.2 amd64 with no errors and the machine booted and is running FreeBSD happily now. I have included some output here. Unfortunately I don't have a dd output of a non-working MBR install. ############### putty# dd if=3D/dev/ad4 bs=3D512 count=3D4 |hd 00000000 fc 31 c0 8e c0 8e d8 8e d0 bc 00 7c be 1a 7c bf |.1.........|..|.| 00000010 1a 06 b9 e6 01 f3 a4 e9 00 8a 31 f6 bb be 07 b1 |..........1.....| 00000020 04 38 2f 74 08 7f 75 85 f6 75 71 89 de 80 c3 10 |.8/t..u..uq.....| 00000030 e2 ef 85 f6 75 02 cd 18 80 fa 80 72 0b 8a 36 75 |....u......r..6u| 00000040 04 80 c6 80 38 f2 72 02 8a 14 89 e7 8a 74 01 8b |....8.r......t..| 00000050 4c 02 bb 00 7c f6 06 bd 07 80 74 2d 51 53 bb aa |L...|.....t-QS..| 00000060 55 b4 41 cd 13 72 20 81 fb 55 aa 75 1a f6 c1 01 |U.A..r ..U.u....| 00000070 74 15 5b 66 6a 00 66 ff 74 08 06 53 6a 01 6a 10 |t.[fj.f.t..Sj.j.| 00000080 89 e6 b8 00 42 eb 05 5b 59 b8 01 02 cd 13 89 fc |....B..[Y.......| 00000090 72 0f 81 bf fe 01 55 aa 75 0c ff e3 be b9 06 eb |r.....U.u.......| 000000a0 11 be d1 06 eb 0c be f0 06 eb 07 bb 07 00 b4 0e |................| 000000b0 cd 10 ac 84 c0 75 f4 eb fe 49 6e 76 61 6c 69 64 |.....u...Invalid| 000000c0 20 70 61 72 74 69 74 69 6f 6e 20 74 61 62 6c 65 | partition table| 000000d0 00 45 72 72 6f 72 20 6c 6f 61 64 69 6e 67 20 6f |.Error loading o| 000000e0 70 65 72 61 74 69 6e 67 20 73 79 73 74 65 6d 00 |perating system.| 000000f0 4d 69 73 73 69 6e 67 20 6f 70 65 72 61 74 69 6e |Missing operatin| 00000100 67 20 73 79 73 74 65 6d 00 90 90 90 90 90 90 90 |g system........| 00000110 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 |................| * 000001b0 90 90 90 90 90 90 90 90 90 90 90 90 90 80 80 01 |................| 000001c0 01 00 a5 0f ff ff 3f 00 00 00 71 6d 70 74 00 00 |......?...qmpt..| 000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.| 00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 4+0 records in 4+0 records out 2048 bytes transferred in 0.023271 secs (88007 bytes/sec) 00000800 It's funny how it reads "Invalid partition table" etc, but the machine *doe= s * work fine. putty% cat dmesg.txt Copyright (c) 1992-2011 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 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 Processor 3000+ (1808.26-MHz K8-class CPU) Origin =3D "AuthenticAMD" Id =3D 0x10ff0 Family =3D f Model =3D 1f St= epping =3D 0 Features=3D0x78bfbff AMD Features=3D0xe2500800 AMD Features2=3D0x1 real memory =3D 1073741824 (1024 MB) avail memory =3D 1018232832 (971 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3fef0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff,0xcf0-0xcf3 on acpi0 pci0: on pcib0 agp0: on hostb0 isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) ohci0: mem 0xfe02f000-0xfe02ffff irq 21 at device 2.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ohci1: mem 0xfe02e000-0xfe02efff irq 22 at device 2.1 on pci0 ohci1: [ITHREAD] usbus1: on ohci1 ehci0: mem 0xfe02d000-0xfe02d0ff ir= q 23 at device 2.2 on pci0 ehci0: [ITHREAD] usbus2: EHCI version 1.0 usbus2: on ehci0 nfe0: port 0xf000-0xf007 mem 0xfe02c000-0xfe02cfff irq 21 at device 5.0 on pci0 miibus0: on nfe0 e1000phy0: PHY 1 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow nfe0: Ethernet address: 00:11:09:dd:1b:51 nfe0: [FILTER] pci0: at device 6.0 (no driver attached) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xdc00-0xdc0f at device 8.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xc800-0xc80f,0xc400-0xc47f irq 23 at device 9.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] atapci2: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xb000-0xb00f,0xac00-0xac7f irq 20 at device 10.0 on pci0 atapci2: [ITHREAD] ata4: on atapci2 ata4: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] pcib1: at device 11.0 on pci0 pci1: on pcib1 vgapci0: port 0x9c00-0x9cff mem 0xe8000000-0xefffffff,0xfdff0000-0xfdffffff irq 16 at device 0.0 on pci1 vgapci1: mem 0xe0000000-0xe7ffffff,0xfdfe0000-0xfdfeffff at device 0.1 on pci1 pcib2: at device 14.0 on pci0 pci2: on pcib2 rl0: port 0x8c00-0x8cff mem 0xfdeff000-0xfdeff0ff irq 17 at device 7.0 on pci2 miibus1: on rl0 rlphy0: PHY 0 on miibus1 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:0e:2e:63:9a:4b rl0: [ITHREAD] rl1: port 0x8800-0x88ff mem 0xfdefe000-0xfdefe0ff irq 18 at device 8.0 on pci2 miibus2: on rl1 rlphy1: PHY 0 on miibus2 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl1: Ethernet address: 00:c1:26:10:8f:57 rl1: [ITHREAD] fwohci0: port 0x8400-0x847f mem 0xfdefd000-0xfdefd7f= f irq 19 at device 12.0 on pci2 fwohci0: [ITHREAD] fwohci0: OHCI version 1.0 (ROM=3D1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:10:dc:00:00:7c:88:3b fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x13cc000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:10:dc:7c:88:3b fwe0: Ethernet address: 02:10:dc:7c:88:3b fwip0: on firewire0 fwip0: Firewire address: 00:10:dc:00:00:7c:88:3b @ 0xfffe00000000, S400, maxrec 2048 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=3D0x00000000, SelfID Count=3D1, CYCLEMAS= TER mode re0: port 0x8000-0x80ff mem 0xfdefc000-0xfdefc0ff irq 16 at device 13.0 on pci2 re0: Chip rev. 0x04000000 re0: MAC rev. 0x00000000 miibus3: on re0 rgephy0: PHY 1 on miibus3 rgephy0: 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 00:11:09:dd:1b:50 re0: [FILTER] atrtc0: port 0x70-0x73 irq 8 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] ppc0: port 0x378-0x37f,0x778-0x77b irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] orm0: at iomem 0xc0000-0xccfff,0xd0000-0xd0fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 powernow0: on cpu0 device_attach: powernow0 attach returned 6 Timecounter "TSC" frequency 1808258496 Hz quality 800 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <=3D 0 cable IRM irm(0) (me) firewire0: bus manager 0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 uhub0: 4 ports with 4 removable, self powered uhub1: 4 ports with 4 removable, self powered ad4: 953869MB at ata2-master UDMA100 SATA 1.5Gb/s ad6: 953869MB at ata3-master UDMA100 SATA 1.5Gb/s Root mount waiting for: usbus2 Root mount waiting for: usbus2 uhub2: 8 ports with 8 removable, self powered Trying to mount root from ufs:/dev/ad4s1a From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 18:50:45 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F19C106566C for ; Mon, 24 Oct 2011 18:50:45 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2DF4A8FC12 for ; Mon, 24 Oct 2011 18:50:44 +0000 (UTC) Received: by vcbfo13 with SMTP id fo13so7888432vcb.13 for ; Mon, 24 Oct 2011 11:50:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.90.228 with SMTP id bz4mr11272000vdb.74.1319480869471; Mon, 24 Oct 2011 11:27:49 -0700 (PDT) Received: by 10.220.194.194 with HTTP; Mon, 24 Oct 2011 11:27:49 -0700 (PDT) X-Originating-IP: [93.221.182.160] In-Reply-To: <20111018131353.GA83797@lexx.ifp.tuwien.ac.at> References: <20111008201456.GA3529@lexx.ifp.tuwien.ac.at> <20111017190027.GA9873@lexx.ifp.tuwien.ac.at> <20111018131353.GA83797@lexx.ifp.tuwien.ac.at> Date: Mon, 24 Oct 2011 20:27:49 +0200 Message-ID: From: "C. P. Ghost" To: Alexey Shuvaev Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Panics after AHCI timeouts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2011 18:50:45 -0000 On Tue, Oct 18, 2011 at 3:13 PM, Alexey Shuvaev wrote: > On Tue, Oct 18, 2011 at 06:19:19AM +0800, Adrian Chadd wrote: >> On 18 October 2011 03:00, Alexey Shuvaev >> wrote: >> > On Sat, Oct 08, 2011 at 10:14:56PM +0200, Alexey Shuvaev wrote: >> >> Hello list! >> >> >> > Errr... Replying to myself... Ping? Should I file a PR and put it >> > in the back burner? :) >> >> I think filing a PR is a good move. Then just be proactive and poke >> people about it. It'd be good to get this fixed. :) >> > Done, kern/161768. > > Question to the list: does anybody see successful recovery from AHCI > timeout an a recent CURRENT? Recent means June 2011 or newer, so 9.0 > branch counts also. That is, there are some kernel messages like this: > > ahcich0: Timeout on slot 29 port 0 > ahcich0: is 00000000 cs 00000000 ss ffffffff rs ffffffff tfd 40 serr 00000000 cmd 0000fc17 > > but then AHCI recovers and the system does not panic? I'm seeing these timeouts too on an 8.2-STABLE amd64 r222832 from June 7. The system hangs partially -- or, more precisely, all processes that attempt to access the disk on this channel hang, everything else continues as normal. I suspect a faulty cable, but I don't have physical access to the system to replace parts right now. A panic would be a regression, so I'm holding off updates on that server until AHCI becomes more tolerant and somewhat self-healing. :( > Poking Alexey. -cpghost. -- Cordula's Web. http://www.cordula.ws/ From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 19:46:26 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27134106564A; Mon, 24 Oct 2011 19:46:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id DC03A8FC0A; Mon, 24 Oct 2011 19:46:25 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 77FEC46B0C; Mon, 24 Oct 2011 15:46:25 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 042D68A02F; Mon, 24 Oct 2011 15:46:25 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Mon, 24 Oct 2011 14:23:44 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <201110241133.23397.jhb@freebsd.org> <4EA59165.1000202@FreeBSD.org> In-Reply-To: <4EA59165.1000202@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110241423.44951.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 24 Oct 2011 15:46:25 -0400 (EDT) Cc: Pavel Timofeev , freebsd-current@freebsd.org, Dennis Koegel Subject: Re: Fresh installed Freebsd 9 don't boot from hd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2011 19:46:26 -0000 On Monday, October 24, 2011 12:25:09 pm Andriy Gapon wrote: > on 24/10/2011 18:33 John Baldwin said the following: > > On Monday, October 24, 2011 9:47:42 am Andriy Gapon wrote: > >> on 24/10/2011 16:41 John Baldwin said the following: > >>> On Sunday, October 23, 2011 1:57:59 pm Andriy Gapon wrote: > [snip] > >>>> I found a document that suggests a possibility of BIOS writing more bytes to the > >>>> array than its current size of 0x42: > >>>> http://www.t13.org/documents/UploadedDocuments/docs2008/e08134r1-BIOS_Enhanced_Disk_Drive_Services_4.0.pdf > >>>> > >>>> Of course, the size of the array is passed to BIOS at the start of the array and > >>>> so a _non-buggy_ BIOS should not write beyond the array, but we live in a > >>>> non-perfect world. > >>> > >>> Hmm, I think we've had to do a similar workaround in the past for a different > >>> BIOS call (SMAP maybe?). However, I do have one request, can we declare an > >>> actual structure instead of a silly char array? Then we can remove the weird > >>> casts with offsets into it, etc. Having an actual struct would be far more > >>> readable and less bug-prone. > >>> > >> > >> I am all for this. > >> Unfortunately. ENOTIME to do this properly at the moment. > > > > Ugh, it looks like in EDD 4.0 they silently expanded the path field to 16 bytes > > instead of 8 as in EDD 3.0 which is why the HP BIOS is probably writing an extra > > four bytes. > > Yes, that's exactly what I meant above, but probably wasn't clear about that. > > > Ah, so the deal is that the device path bit is variable length and the caller is > > supposed to set the length on input which we aren't doing. However, we don't > > care about the device path stuff anyway, so we can set a smaller input value. > > > > Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch > > > > > +struct edd_params { > > + uint16_t len; > > + uint16_t flags; > > + uint32_t cylinders; > > + uint32_t heads; > > + uint32_t sectors_per_track; > > + uint64_t sectors; > > + uint32_t sector_size; > > sector_size should be uint16_t, I think. Ditto for edd_params_v3 and edd_params_v4. > sizeof(struct edd_params) should be 30, judging from the specs. Oops, yeah. > > + uint16_t edd_params_seg; > > + uint16_t edd_params_off; > > +}; > > Perhaps the structures should be declared __packed (if only just in case)? > > Also, perhaps edd_params_v3 and edd_params_v4 should inherit edd_params in some > "smarter" way to avoid verbatim duplicates. Yeah, probably so. We will probably never even use them anyway (just as we don't use edd_packet_v3 even though we could probably make use of it to avoid some bounce buffering in the loader). > Other than these issues the patch looks great! > Perhaps later we could do detailed definitions for things like interface paths for > various cases, etc. I doubt we will ever use them. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 21:05:58 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C36521065670; Mon, 24 Oct 2011 21:05:58 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id ED5938FC12; Mon, 24 Oct 2011 21:05:57 +0000 (UTC) Received: by wwi18 with SMTP id 18so9354402wwi.31 for ; Mon, 24 Oct 2011 14:05:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=kbvipacLw8lRihcOLyK7ZUf+k6sikRSc7Gz5+p/WGKo=; b=dP+nXwQnGIHTOz5Y1nv6YcGVX/NXzd8j3rXls025M9c28SUWkD+jHvITzCvp7T5bmf TeJTrvUx3Rg2l0U7eQ8f5Xa2zUEixuvhiNZqvSdTBAbEJNLUvUn6e4wRMmsnfZhgnHKE XAqLyRt8ILzmDzL2TsHsa9IxNJW40GrH9vz/0= Received: by 10.216.54.20 with SMTP id h20mr2956348wec.97.1319490356673; Mon, 24 Oct 2011 14:05:56 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id gd18sm41238063wbb.5.2011.10.24.14.05.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 24 Oct 2011 14:05:55 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 24 Oct 2011 14:04:16 -0700 From: YongHyeon PYUN Date: Mon, 24 Oct 2011 14:04:16 -0700 To: freebsd-current@FreeBSD.org Message-ID: <20111024210416.GE4663@michelle.cdnetworks.com> References: <20111017002213.GB3338@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111017002213.GB3338@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: Call for testers : ALi/ULi M5261/M5263 ethernet controller X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 21:05:58 -0000 On Sun, Oct 16, 2011 at 05:22:13PM -0700, YongHyeon PYUN wrote: > Hi, > > If you have ALi/ULi M5261/M5263 ethernet controller please try the > patch at the following URL and let me know how it works. > http://people.freebsd.org/~yongari/dc/dc.uli562x.diff > > The patch was generated against latest HEAD and it should be > cleanly applied to latest stable/8 and stable/7. > I committed revised version to HEAD(r226699, r226701). > Thanks. From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 21:40:22 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04A19106564A; Mon, 24 Oct 2011 21:40:22 +0000 (UTC) (envelope-from dkmail@mail.neveragain.de) Received: from mail.neveragain.de (mail.neveragain.de [IPv6:2001:aa8:fffc::25]) by mx1.freebsd.org (Postfix) with ESMTP id 99B9A8FC12; Mon, 24 Oct 2011 21:40:21 +0000 (UTC) Received: by mail.neveragain.de (Postfix, from userid 1029) id 9B4AE1703E; Mon, 24 Oct 2011 23:40:20 +0200 (CEST) Date: Mon, 24 Oct 2011 23:40:20 +0200 From: Dennis Koegel To: John Baldwin Message-ID: <20111024214020.GA60109@neveragain.de> References: <201110240941.02515.jhb@freebsd.org> <4EA56C7E.1040005@FreeBSD.org> <201110241133.23397.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201110241133.23397.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Pavel Timofeev , freebsd-current@freebsd.org, Andriy Gapon Subject: Re: Fresh installed Freebsd 9 don't boot from hd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2011 21:40:22 -0000 On Mon, Oct 24, 2011 at 11:33:23AM -0400, John Baldwin wrote: > Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch GCC chokes here in drv.c:{49,50}: "cannot convert to a pointer type": v86.ds = VTOPSEG(params); v86.esi = VTOPOFF(params); Changed this to ¶ms. Also changed sector_size to uint16_t as noted by Andriy. Boots perfectly! (Tested with gcc and clang) Thanks! - D. From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 21:48:40 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 264C9106566C for ; Mon, 24 Oct 2011 21:48:40 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id D3DA014FB6B; Mon, 24 Oct 2011 21:48:39 +0000 (UTC) Message-ID: <4EA5DD37.30902@FreeBSD.org> Date: Mon, 24 Oct 2011 14:48:39 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: Craig Rodrigues References: <20111020114844.GK59810@albert.catwhisker.org> <20111020122121.GL59810@albert.catwhisker.org> <201110211636.05917.jhb@freebsd.org> <20111021211221.GV59810@albert.catwhisker.org> <4EA21842.5000808@FreeBSD.org> <4EA2590B.90008@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: sys/conf/newvers.sh vs. subversion-1.7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2011 21:48:40 -0000 On 10/24/2011 10:14, Craig Rodrigues wrote: > On Fri, Oct 21, 2011 at 10:47 PM, Doug Barton wrote: >> On 10/21/2011 22:42, Craig Rodrigues wrote: >>> Hi, >>> >>> I tried following: >>> >>> (1) Run svnversion in non-svn directory: >>> >>> return status == 0 >> >> Return status isn't everything. :) >> >>> prints out "exported" >> >> In my case (1.7) it says "Unversioned directory" >> >> But my point (which perhaps I should have made more explicit) is that >> given the fact that svnversion handles non-svn directories gracefully >> it's faster (simpler, etc.) to just run foo=`svnversion` and then make >> sure that $foo is rational than it is to run 2 commands. >> >> Doug > > > Hi, > > What logic can we use to make sure svnversion returns a rational value? Make sure that the response starts with a number. > It looks like the output of svnversion for non-svn directories is > inconsistent between versions of Subversion. The non-svn responses vary, the svn responses don't. :) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 22:23:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 435D9106566C for ; Mon, 24 Oct 2011 22:23:41 +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 F2F328FC08 for ; Mon, 24 Oct 2011 22:23:40 +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 <1RISvj-0004iy-Ty>; Tue, 25 Oct 2011 00:23:39 +0200 Received: from e178045140.adsl.alicedsl.de ([85.178.45.140] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RISvj-0002lF-Qc>; Tue, 25 Oct 2011 00:23:39 +0200 Message-ID: <4EA5E56B.6050809@zedat.fu-berlin.de> Date: Tue, 25 Oct 2011 00:23:39 +0200 From: "Hartmann, O." User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111019 Thunderbird/7.0.1 MIME-Version: 1.0 To: Garrett Cooper References: <4EA495BA.7080802@zedat.fu-berlin.de> <87987AB8-BCAA-4CED-8B4F-C6EA5B61C0A5@gmail.com> In-Reply-To: <87987AB8-BCAA-4CED-8B4F-C6EA5B61C0A5@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.45.140 Cc: freebsd-current Subject: Re: "/usr/src/sys/conf/kern.mk", line 10: Malformed conditional (${FREEBSD_GCC}), "/usr/src/sys/conf/kern.mk", line 14: if-less endif X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2011 22:23:41 -0000 On 10/24/11 00:38, Garrett Cooper wrote: > On Oct 23, 2011, at 3:31 PM, Hartmann, O. wrote: > >> Kernel building fails since today when kernel gets compiled via CLANG: >> -------------------------------------------------------------- >>>>> stage 2.1: cleaning up the object tree >> -------------------------------------------------------------- >> cd /usr/obj/usr/src/sys/THOR; MAKEOBJDIRPREFIX=/usr/obj >> MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE=native >> GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin >> GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font >> GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac >> _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp VERSION="FreeBSD 10.0-CURRENT >> amd64 1000000" INSTALL="sh /usr/src/tools/install.sh" >> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/ >> usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr >> /sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbi >> n:/bin:/usr/sbin:/usr/bin /usr/obj/usr/src/make.amd64/make >> KERNEL=kernel cleandir >> "/usr/src/sys/conf/kern.mk", line 10: Malformed conditional >> (${FREEBSD_GCC}) >> "/usr/src/sys/conf/kern.mk", line 14: if-less endif >> make: fatal errors encountered -- cannot continue >> *** Error code 1 >> Stop in /usr/src. >> *** Error code 1 >> Stop in /usr/src. > It was noted not too long ago on the commit list as well; r226665 caused the breakage. > -Garrett_______________________________________________ > So, this is by intention? When does the problem disappear, so folks building FreeBSD with CLANG are again capable of building a world and kernel? Regards, Oliver From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 22:24:46 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4EBC106566B for ; Mon, 24 Oct 2011 22:24:46 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by mx1.freebsd.org (Postfix) with ESMTP id 44AC98FC08 for ; Mon, 24 Oct 2011 22:24:46 +0000 (UTC) X-AuditID: 1209190d-b7f726d0000008d1-ba-4ea5e5ad1410 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 8F.73.02257.DA5E5AE4; Mon, 24 Oct 2011 18:24:45 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id p9OMOj1L012360; Mon, 24 Oct 2011 18:24:45 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p9OMOhjh022275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Oct 2011 18:24:45 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id p9OMOgFV008882; Mon, 24 Oct 2011 18:24:42 -0400 (EDT) Date: Mon, 24 Oct 2011 18:24:41 -0400 (EDT) From: Benjamin Kaduk To: Mehmet Erol Sanliturk In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixCmqrLv26VI/g31nVC0mXPnBZLH/ZJID k8eMT/NZPHbOussewBTFZZOSmpNZllqkb5fAldEyu4Gt4A5Xxd4P3awNjJs5uhg5OSQETCS+ v7jDBmGLSVy4tx7I5uIQEtjHKHF87U5WCGcDo0TL2jVMEM4BJok/R94xQjgNjBLH5hwF62cR 0Jbof36BHcRmE1CRmPlmI1hcRMBY4m3jNTCbWUBTYt+fZ0CTODiEgeJft5mAhDkFAiUeL9kM FuYVsJfo3KgIEhYSCJA43fgUrFNUQEdi9f4pLCA2r4CgxMmZT1ggJlpKnPtznW0Co+AsJKlZ SFILGJlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Rrp5WaW6KWmlG5iBIepJO8OxncHlQ4xCnAw KvHwXlq6xE+INbGsuDL3EKMkB5OSKG/xw6V+QnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR451kD 5XhTEiurUovyYVLSHCxK4ryFOxz8hATSE0tSs1NTC1KLYLIyHBxKErx/ngA1ChalpqdWpGXm lCCkmTg4QYbzAA1nfwoyvLggMbc4Mx0if4pRUUqcVwMkIQCSyCjNg+uFpZFXjOJArwhDtPMA UxBc9yugwUxAg5XZwQaXJCKkpBoYi6ctDD6nezrMs3VltrouX27ZIqXyqpwperEJKqGaVy78 qsyTMPrZvLhbmLtkhwTTQ4uiJUyFK6I02hQleu2u315nwPT95cWfJaVb97wQb/TyK90klp60 v9yoYGpv7pF31xRSE2/xRTaV/RXKMEtQyOyWS/2g+2mCw3FvzrgLGV9v/e2aZanEUpyRaKjF XFScCACMEB6n/gIAAA== Cc: FreeBSD Current Subject: Re: FreeBSD 9.0 RC1 USB Mouse and Keyboard X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2011 22:24:46 -0000 On Sun, 23 Oct 2011, Mehmet Erol Sanliturk wrote: > I have installed FreeBSD 9.0 RC1 . > > During installation and boots , and ( as root ) console mode , both USB > keyboard and mouse are working . > > When a graphical desktop ( Fluxbox , Gnome , or KDE ) is started , both of > them are becoming frozen . > Detach and attach of mouse are detected , but input is not possible . > PS/2 mouse is also not working . > I did not check PS/2 keyboard . > Only Ctrl-Alt-F1 is discontinuing graphical display , and Ctrl-C is > returning to root prompt . > > KDE is staying as it is after displaying of hard disk symbol and then it is > waiting there . > Gnome is displaying all the parts , but no input possibility . > Fluxbox is displaying its window , but no input possibility . > > It seems that X is NOT able to register dbus related parts ( understood from > messages left on the screen after discontinuation ) . > > On the same computer , I have installed Fedora 15 and everything is working > as expected , means there is no any hardware problem . Has this computer successfully run other versions of FreeBSD with X? I seem to recall there can be odd interactions with hald, xorg.conf, and others. Some googling brings up http://www.wonkity.com/~wblock/docs/html/aei.html which seems to cover many of the relevant issues. -Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 23:21:28 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF1E11065670; Mon, 24 Oct 2011 23:21:28 +0000 (UTC) (envelope-from gsfr@stanford.edu) Received: from smtp.stanford.edu (smtp3.Stanford.EDU [171.67.219.83]) by mx1.freebsd.org (Postfix) with ESMTP id 94D248FC08; Mon, 24 Oct 2011 23:21:28 +0000 (UTC) Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 465BFD8451; Mon, 24 Oct 2011 16:21:28 -0700 (PDT) Received: from nimble.stanford.edu (nimble.Stanford.EDU [171.64.204.227]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: gsfr) by smtp.stanford.edu (Postfix) with ESMTPSA id A31B7D8499; Mon, 24 Oct 2011 16:21:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Gunnar Schaefer In-Reply-To: <20111024214020.GA60109@neveragain.de> Date: Mon, 24 Oct 2011 16:21:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201110240941.02515.jhb@freebsd.org> <4EA56C7E.1040005@FreeBSD.org> <201110241133.23397.jhb@freebsd.org> <20111024214020.GA60109@neveragain.de> To: Dennis Koegel X-Mailer: Apple Mail (2.1084) Cc: Pavel Timofeev , freebsd-current@freebsd.org, Andriy Gapon Subject: Re: Fresh installed Freebsd 9 don't boot from hd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2011 23:21:28 -0000 On Oct 24, 2011, at 2:40 PM, Dennis Koegel wrote: > On Mon, Oct 24, 2011 at 11:33:23AM -0400, John Baldwin wrote: >> Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch >=20 > GCC chokes here in drv.c:{49,50}: "cannot convert to a pointer type": >=20 > v86.ds =3D VTOPSEG(params); > v86.esi =3D VTOPOFF(params); >=20 > Changed this to ¶ms. Also changed sector_size to uint16_t as noted > by Andriy. Boots perfectly! (Tested with gcc and clang) I'd like to test these patches on my Supermicro machine as well. = Unfortunately, I don't know how to go about it, but I'm hopeful to be = able to figure it out with some basic instructions. I'm currently = running a fresh RC1 install, and I'm able to boot the system if I set = the BIOS to IDE mode, rather than AHCI. Any help would be much appreciated, Gunnar= From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 23:46:41 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19A6A106566B for ; Mon, 24 Oct 2011 23:46:41 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id C74858FC0A for ; Mon, 24 Oct 2011 23:46:40 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id p9ONkdvT075149; Mon, 24 Oct 2011 17:46:39 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id p9ONkd6k075146; Mon, 24 Oct 2011 17:46:39 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Mon, 24 Oct 2011 17:46:39 -0600 (MDT) From: Warren Block To: Mehmet Erol Sanliturk In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Mon, 24 Oct 2011 17:46:39 -0600 (MDT) Cc: FreeBSD Current Subject: Re: FreeBSD 9.0 RC1 USB Mouse and Keyboard X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Oct 2011 23:46:41 -0000 On Sun, 23 Oct 2011, Mehmet Erol Sanliturk wrote: > I have installed FreeBSD 9.0 RC1 . > > During installation and boots , and ( as root ) console mode , both USB > keyboard and mouse are working . > > When a graphical desktop ( Fluxbox , Gnome , or KDE ) is started , both of > them are becoming frozen . > Detach and attach of mouse are detected , but input is not possible . > PS/2 mouse is also not working . > I did not check PS/2 keyboard . > Only Ctrl-Alt-F1 is discontinuing graphical display , and Ctrl-C is > returning to root prompt . > > KDE is staying as it is after displaying of hard disk symbol and then it is > waiting there . > Gnome is displaying all the parts , but no input possibility . > Fluxbox is displaying its window , but no input possibility . > > It seems that X is NOT able to register dbus related parts ( understood from > messages left on the screen after discontinuation ) . > > On the same computer , I have installed Fedora 15 and everything is working > as expected , means there is no any hardware problem . The same symptoms happen if X is configured to use hald for input device detection but hald is not running. The easy way to test that is to put Option "AutoAddDevices" "Off" in the ServerLayout section. From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 01:19:01 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A640106566C for ; Tue, 25 Oct 2011 01:19:01 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15]) by mx1.freebsd.org (Postfix) with ESMTP id CD8638FC14 for ; Tue, 25 Oct 2011 01:19:00 +0000 (UTC) X-AuditID: 1209190f-b7f6e6d0000008df-41-4ea60e83331a Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 8B.BD.02271.38E06AE4; Mon, 24 Oct 2011 21:19:00 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id p9P1Ix7f027758; Mon, 24 Oct 2011 21:18:59 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p9P1Iv5b023013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Oct 2011 21:18:59 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id p9P1Ivb7020068; Mon, 24 Oct 2011 21:18:57 -0400 (EDT) Date: Mon, 24 Oct 2011 21:18:57 -0400 (EDT) From: Benjamin Kaduk To: "Andrey V. Elsukov" In-Reply-To: <4EA4E6B8.7040108@yandex.ru> Message-ID: References: <81477.1318015137@critter.freebsd.dk> <4E8F55CC.3060302@FreeBSD.org> <4E8F5D47.9070904@yandex.ru> <4EA4E6B8.7040108@yandex.ru> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrNvCt8zP4LC+xfkbL5ks5rz5wOTA 5DHj03wWj8MN/SwBTFFcNimpOZllqUX6dglcGb0/JzEXTGStONXwlbmBsZmli5GTQ0LARGLf tmVsELaYxIV764FsLg4hgX2MEr+uXWOFcDYwSsyaeZcdwjnAJNF15AqU08AocWDzf1aQfhYB bYmLN66AzWUTUJGY+WYj2FwRoPiuSRfAbGYBeYn/Vy4zgdjCAhYSD84sZwaxOQU0Je49ALmD g4NXwF5iwWkVkLCQwHlGia45GSC2qICOxOr9U8DG8woISpyc+YQFYqSlxLk/19kmMArOQpKa hSS1gJFpFaNsSm6Vbm5iZk5xarJucXJiXl5qka6JXm5miV5qSukmRnCgSvLvYPx2UOkQowAH oxIP76WlS/yEWBPLiitzDzFKcjApifIu5F3mJ8SXlJ9SmZFYnBFfVJqTWnyIUYKDWUmEd571 Uj8h3pTEyqrUonyYlDQHi5I4b+MOBz8hgfTEktTs1NSC1CKYrAwHh5IE71OQoYJFqempFWmZ OSUIaSYOTpDhPEDDp4PU8BYXJOYWZ6ZD5E8xKkqJ874ASQiAJDJK8+B6YYnkFaM40CvCvDdB qniASQiu+xXQYCagwcrsIFcXlyQipKQaGDv1th06Oe+Fr/dhEz3Zmz0BkpvUmjQaFvmfnrss IPnohmlTRF/3PtB58N9JuWdGhLaHx0X7M01l8rdzhVkDE+u2n7i8u515UZD8rX/RKdbf727l PLLZgu1O8+uazJ1vm9s7eTJm9sdaqH1/w8u/dFswy8n0vF0tB4x5Dp9b8Wll0NSyf9G725VY ijMSDbWYi4oTAaWIwQj/AgAA Cc: freebsd-current@freebsd.org Subject: Re: aliasing (or renaming) kern.geom.debugflags X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 01:19:01 -0000 On Mon, 24 Oct 2011, Andrey V. Elsukov wrote: > On 24.10.2011 1:54, Arnaud Lacombe wrote: >> NOTE >> Protection mechanisms in the geom(4) subsystem might prevent boot0cfg >> from being able to update the MBR on a mounted disk. Instructions for >> temporarily disabling these protection mechanisms can be found in the >> geom(4) manpage. Specifically, do a >> >> sysctl kern.geom.debugflags=0x10 >> >> to allow writing to the MBR, and restore it to 0 afterwards. > > This is stale message. boot0cfg might work without this. On a *mounted* disk? Surely that qualifies as an "open" for the purposes of the check. -Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 02:48:02 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8814A1065675 for ; Tue, 25 Oct 2011 02:48:02 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1E60C8FC08 for ; Tue, 25 Oct 2011 02:48:01 +0000 (UTC) Received: by wwn22 with SMTP id 22so4487785wwn.1 for ; Mon, 24 Oct 2011 19:48:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=e8YCiEjtxraHJYM5LNk61pAyemfmQJo3KJ+VbYdVCyY=; b=o7gnijDlL/B5wRVrlTDmXxH0IQdCoyZLy9JUFkSK5cdliFqwHxH1iKOVan+yeHxoAa Q7/PJBe9MHYk1uJEm0n9fUGRr5qrKJFSH4Z8sokB2sr7DDBCPwbNjxm+RFyW7VPPpI9X v2WlHlSk/KScEp9p11H18eA0/g3ZC68iu8VIY= MIME-Version: 1.0 Received: by 10.216.82.78 with SMTP id n56mr1817804wee.71.1319510880387; Mon, 24 Oct 2011 19:48:00 -0700 (PDT) Received: by 10.180.105.162 with HTTP; Mon, 24 Oct 2011 19:48:00 -0700 (PDT) In-Reply-To: <4EA5E56B.6050809@zedat.fu-berlin.de> References: <4EA495BA.7080802@zedat.fu-berlin.de> <87987AB8-BCAA-4CED-8B4F-C6EA5B61C0A5@gmail.com> <4EA5E56B.6050809@zedat.fu-berlin.de> Date: Mon, 24 Oct 2011 22:48:00 -0400 Message-ID: From: Arnaud Lacombe To: "Hartmann, O." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Garrett Cooper , freebsd-current Subject: Re: "/usr/src/sys/conf/kern.mk", line 10: Malformed conditional (${FREEBSD_GCC}), "/usr/src/sys/conf/kern.mk", line 14: if-less endif X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 02:48:02 -0000 Hi, On Mon, Oct 24, 2011 at 6:23 PM, Hartmann, O. wrote: > On 10/24/11 00:38, Garrett Cooper wrote: >> On Oct 23, 2011, at 3:31 PM, Hartmann, O. wrote: >> >>> =A0 Kernel building fails since today when kernel gets compiled via CLA= NG: >>> =A0 -------------------------------------------------------------- >>>>>> stage 2.1: cleaning up the object tree >>> =A0 -------------------------------------------------------------- >>> =A0 cd /usr/obj/usr/src/sys/THOR; MAKEOBJDIRPREFIX=3D/usr/obj >>> =A0 MACHINE_ARCH=3Damd64 =A0MACHINE=3Damd64 =A0CPUTYPE=3Dnative >>> =A0 GROFF_BIN_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/bin >>> =A0 GROFF_FONT_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/groff_font >>> =A0 GROFF_TMAC_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/tmac >>> =A0 _SHLIBDIRPREFIX=3D/usr/obj/usr/src/tmp =A0VERSION=3D"FreeBSD 10.0-C= URRENT >>> =A0 amd64 1000000" =A0INSTALL=3D"sh /usr/src/tools/install.sh" >>> =A0 PATH=3D/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/le= gacy/ >>> =A0 usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/= usr >>> =A0 /sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/= sbi >>> =A0 n:/bin:/usr/sbin:/usr/bin /usr/obj/usr/src/make.amd64/make >>> =A0 KERNEL=3Dkernel cleandir >>> =A0 "/usr/src/sys/conf/kern.mk", line 10: Malformed conditional >>> =A0 (${FREEBSD_GCC}) >>> =A0 "/usr/src/sys/conf/kern.mk", line 14: if-less endif >>> =A0 make: fatal errors encountered -- cannot continue >>> =A0 *** Error code 1 >>> =A0 Stop in /usr/src. >>> =A0 *** Error code 1 >>> =A0 Stop in /usr/src. >> It was noted not too long ago on the commit list as well; r226665 caused= the breakage. >> -Garrett_______________________________________________ >> > > So, this is by intention? > When does the problem disappear, so folks building FreeBSD with CLANG > are again capable of building a world and kernel? > seemed to have been "fixed" by dim@: commit 2286e401073a60babb3cc8efce52657f6fa92f7e Author: dim Date: Mon Oct 24 18:35:16 2011 +0000 Put in a temporary band-aid to fix kernel builds when CC=3Dclang, after r226665. Thanks dim@! - Arnaud From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 03:59:22 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DCB4106564A for ; Tue, 25 Oct 2011 03:59:22 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 56CF28FC0A for ; Tue, 25 Oct 2011 03:59:22 +0000 (UTC) Received: by qadz32 with SMTP id z32so52953qad.13 for ; Mon, 24 Oct 2011 20:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e8TBhe2O9cMF5SLrMuRiO6BXsIb6vSeLrs+eSP1hVUA=; b=U8QxitHfC0pZqukxwi5Ndueyo6ZBCQvA8W3fHB36zZHAu0zKVgw2qyi3Ipa7Uao2+f nSwpoAJoaY0YVsiXVlXeL/IOQSHp5MuVWRzp8GTzXgWgQ947gXww+ytrIEh2WQ3G8NnC A7ssqKL3LMe5RXbfiZQAo9lX7EtCVNnGzb1vA= MIME-Version: 1.0 Received: by 10.224.205.68 with SMTP id fp4mr20790528qab.63.1319515160768; Mon, 24 Oct 2011 20:59:20 -0700 (PDT) Received: by 10.224.19.212 with HTTP; Mon, 24 Oct 2011 20:59:20 -0700 (PDT) In-Reply-To: References: Date: Mon, 24 Oct 2011 23:59:20 -0400 Message-ID: From: Mehmet Erol Sanliturk To: Warren Block Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Current Subject: Re: FreeBSD 9.0 RC1 USB Mouse and Keyboard X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 03:59:22 -0000 On Mon, Oct 24, 2011 at 7:46 PM, Warren Block wrote: > On Sun, 23 Oct 2011, Mehmet Erol Sanliturk wrote: > > I have installed FreeBSD 9.0 RC1 . >> >> During installation and boots , and ( as root ) console mode , both USB >> keyboard and mouse are working . >> >> When a graphical desktop ( Fluxbox , Gnome , or KDE ) is started , both of >> them are becoming frozen . >> Detach and attach of mouse are detected , but input is not possible . >> PS/2 mouse is also not working . >> I did not check PS/2 keyboard . >> Only Ctrl-Alt-F1 is discontinuing graphical display , and Ctrl-C is >> returning to root prompt . >> >> KDE is staying as it is after displaying of hard disk symbol and then it >> is >> waiting there . >> Gnome is displaying all the parts , but no input possibility . >> Fluxbox is displaying its window , but no input possibility . >> >> It seems that X is NOT able to register dbus related parts ( understood >> from >> messages left on the screen after discontinuation ) . >> >> On the same computer , I have installed Fedora 15 and everything is >> working >> as expected , means there is no any hardware problem . >> > > The same symptoms happen if X is configured to use hald for input device > detection but hald is not running. The easy way to test that is to put > Option "AutoAddDevices" "Off" > in the ServerLayout section. > And also : Has this computer successfully run other versions of FreeBSD with X? I seem to recall there can be odd interactions with hald, xorg.conf, and others. Some googling brings up http://www.wonkity.com/~wblock/docs/html/aei.html which seems to cover many of the relevant issues. -Ben Kaduk ---------------------------- Unfortunately , ( 9.0 RC1 amd64 ) is overwritten by Fedora 15 . On the same computer , from another hard disk : FreeBSD 9.0-Current #13 r220539M Mon Apr 11 Generic amd4 : root : Fluxbox : USB Keyboard and mouse is working . user : KDE 3.5 : USB Keyboard and mouse is working . /etc/rc.conf contains : moused_type = "auto" moused_enable = "YES" hald_enable = "YES" dbus_enable = "YES" This FreeBSD is from http://people.freebsd.org/~nwhitehorn/bsdinstall-amd64-20110411/ The 9.0 RC1 amd64 contained the same statements listed above . Both of them listed starting of hald and dbus without error during booting . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 04:21:19 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A288C1065673 for ; Tue, 25 Oct 2011 04:21:19 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 29EA48FC14 for ; Tue, 25 Oct 2011 04:21:18 +0000 (UTC) Received: by bkbzu17 with SMTP id zu17so104044bkb.13 for ; Mon, 24 Oct 2011 21:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:newsgroups:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=bCoSievPYOd0u5AwIzaxsyA0bjSpI6een1l5gDb/svI=; b=dewWTgwgaGJIffS40bmN+gnyXF/BGl35LCYEwQ18SPiENZgSZQ3zMta6s1oX9061p5 bEuJrOwcCj7gVTRyFlXx5T8nbynxyQURuurU+SWjQlzAfZB+MVfMRHWXdmN5P9ewlU2J HiDQYLRlcXW/QhHVOzoEODy/Iu6pNRibtEXbE= Received: by 10.204.152.68 with SMTP id f4mr18028697bkw.59.1319516477797; Mon, 24 Oct 2011 21:21:17 -0700 (PDT) Received: from limbo.lan ([195.225.157.86]) by mx.google.com with ESMTPS id rc12sm25991139bkb.10.2011.10.24.21.21.14 (version=SSLv3 cipher=OTHER); Mon, 24 Oct 2011 21:21:15 -0700 (PDT) Message-ID: <4EA63938.3030201@gmail.com> Date: Tue, 25 Oct 2011 07:21:12 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:7.0.1) Gecko/20111002 Thunderbird/7.0.1 MIME-Version: 1.0 Newsgroups: gmane.os.freebsd.current To: Eugene Dzhurinsky References: <20111022103623.GA73764@devbox> <42AC5043-6760-401E-B911-CA567853F4E0@cran.org.uk> <20111022152107.GA1994@devbox> <4EA32EC1.9060601@cran.org.uk> <20111023081203.GA3698@devbox> In-Reply-To: <20111023081203.GA3698@devbox> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Bruce Cran , "freebsd-current@freebsd.org" Subject: Re: replacement of ataidle for freebsd 9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 04:21:19 -0000 23.10.2011 11:12, Eugene Dzhurinsky wrote: > In the mentime, can you please advice how can I use camcontrol in order to > disable APM for my HDD? @reboot camcontrol idle ada0 -t 300 ; camcontrol idle ada1 -t 300 -- Sphinx of black quartz judge my vow. From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 04:21:28 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F079F1065678 for ; Tue, 25 Oct 2011 04:21:28 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id A98E08FC08 for ; Tue, 25 Oct 2011 04:21:28 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RIYVz-00019X-1R for freebsd-current@freebsd.org; Tue, 25 Oct 2011 06:21:27 +0200 Received: from 195.225.157.86 ([195.225.157.86]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Oct 2011 06:21:27 +0200 Received: from c.kworr by 195.225.157.86 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Oct 2011 06:21:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Volodymyr Kostyrko Date: Tue, 25 Oct 2011 07:21:12 +0300 Lines: 8 Message-ID: <4EA63938.3030201@gmail.com> References: <20111022103623.GA73764@devbox> <42AC5043-6760-401E-B911-CA567853F4E0@cran.org.uk> <20111022152107.GA1994@devbox> <4EA32EC1.9060601@cran.org.uk> <20111023081203.GA3698@devbox> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 195.225.157.86 User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:7.0.1) Gecko/20111002 Thunderbird/7.0.1 In-Reply-To: <20111023081203.GA3698@devbox> Cc: Bruce Cran , "freebsd-current@freebsd.org" Subject: Re: replacement of ataidle for freebsd 9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 04:21:29 -0000 23.10.2011 11:12, Eugene Dzhurinsky wrote: > In the mentime, can you please advice how can I use camcontrol in order to > disable APM for my HDD? @reboot camcontrol idle ada0 -t 300 ; camcontrol idle ada1 -t 300 -- Sphinx of black quartz judge my vow. From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 04:34:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83D87106566C for ; Tue, 25 Oct 2011 04:34:08 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward4.mail.yandex.net (forward4.mail.yandex.net [IPv6:2a02:6b8:0:602::4]) by mx1.freebsd.org (Postfix) with ESMTP id ED2928FC16 for ; Tue, 25 Oct 2011 04:34:07 +0000 (UTC) Received: from smtp2.mail.yandex.net (smtp2.mail.yandex.net [77.88.46.102]) by forward4.mail.yandex.net (Yandex) with ESMTP id 6627A502993; Tue, 25 Oct 2011 08:34:06 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1319517246; bh=kfNUSK8+AO9qRVHr0sfO6nAYiw3r89lGndvXNu1QtbE=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=T1fAMXZOE66nEHX93eRJisac/7pQ1ZPq5zO0EN6Q+ejAQ7FrzM/t4GItf6YycWQVR 9p9dEC5krmGm9g1ok2JOfO/YBORUqWROQhkQHD+Aw2MlKB+1TTv4V0ud2wXaL8U3dc fGs/mImlpMuA0OcjvYRYd9YJbnSOEx8D/AjGxZmo= Received: from smtp2.mail.yandex.net (localhost [127.0.0.1]) by smtp2.mail.yandex.net (Yandex) with ESMTP id 43805E20343; Tue, 25 Oct 2011 08:34:06 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1319517246; bh=kfNUSK8+AO9qRVHr0sfO6nAYiw3r89lGndvXNu1QtbE=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=T1fAMXZOE66nEHX93eRJisac/7pQ1ZPq5zO0EN6Q+ejAQ7FrzM/t4GItf6YycWQVR 9p9dEC5krmGm9g1ok2JOfO/YBORUqWROQhkQHD+Aw2MlKB+1TTv4V0ud2wXaL8U3dc fGs/mImlpMuA0OcjvYRYd9YJbnSOEx8D/AjGxZmo= Received: from ns.kirov.so-ups.ru (ns.kirov.so-ups.ru [178.74.170.1]) by smtp2.mail.yandex.net (nwsmtp/Yandex) with ESMTP id Y3KCa3Ua-Y5KCsJZC; Tue, 25 Oct 2011 08:34:05 +0400 X-Yandex-Spam: 1 Message-ID: <4EA63C3A.90304@yandex.ru> Date: Tue, 25 Oct 2011 08:34:02 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Benjamin Kaduk References: <81477.1318015137@critter.freebsd.dk> <4E8F55CC.3060302@FreeBSD.org> <4E8F5D47.9070904@yandex.ru> <4EA4E6B8.7040108@yandex.ru> In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig168F78B250FF0A9813A0AE55" Cc: freebsd-current@freebsd.org Subject: Re: aliasing (or renaming) kern.geom.debugflags X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 04:34:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig168F78B250FF0A9813A0AE55 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 25.10.2011 5:18, Benjamin Kaduk wrote: >>> to allow writing to the MBR, and restore it to 0 afterwards. >> >> This is stale message. boot0cfg might work without this. >=20 > On a *mounted* disk? Surely that qualifies as an "open" for the purpose= s of the check. Yes. boot0cfg uses GEOM_PART' control interface and it may write bootcode= to the "open" disk. Actually i found bug here and now it is fixed in r226714. --=20 WBR, Andrey V. Elsukov --------------enig168F78B250FF0A9813A0AE55 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) iQEcBAEBAgAGBQJOpjw6AAoJEAHF6gQQyKF6JpcIAKr7sg8vBAEC9243BEpQVwm8 ycvr9GOTC9eMTiFq4HiaRFlZj3+9n/HzhBp/3pKxXM1tu5kjsnfMDzcdvDlPO3UL +UdYMMozgEcz+lu3/Bg4O2x0MalU9vPmrZt2JJ24laUVYgl6MKpdCXAEgCBat2jN gIEcCSU4RZZp3yxGz0K47RLFnzR4O+PJ6Wd1grXJ3ffbhu2A6VHI9L0OdRKnDBlp KHzwCuAfm8hxT5ZlDUGimPDYitgedkagsNbgg0Z31lfLmkTwXfu1E6w6FhLDn0pt kRZy0GfkPAddh1B1P2JMO1ZVH5Q3XYvZ/+dSSDBBvmeF5sx3a3bqZWULFuOV59Y= =pF4w -----END PGP SIGNATURE----- --------------enig168F78B250FF0A9813A0AE55-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 04:53:38 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCA1E106564A for ; Tue, 25 Oct 2011 04:53:38 +0000 (UTC) (envelope-from jkuczewski@bnl.gov) Received: from smtpgw.bnl.gov (smtpgw.bnl.gov [130.199.3.132]) by mx1.freebsd.org (Postfix) with ESMTP id 939518FC08 for ; Tue, 25 Oct 2011 04:53:38 +0000 (UTC) X-BNL-policy-q: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIBAJw4pk6Cx8Kg/2dsb2JhbAAMN6xIKBQEPQ0BCBgDAgECATcBFAwIAQGIBLRehS8BgxMEpgI X-IronPort-AV: E=Sophos;i="4.69,402,1315195200"; d="scan'208";a="149167571" Received: from blc.nsls.bnl.gov (HELO [127.0.0.1]) ([130.199.194.160]) by smtpgw.sec.bnl.local with ESMTP; 25 Oct 2011 00:24:22 -0400 Message-ID: <4EA63A1B.9040407@bnl.gov> Date: Tue, 25 Oct 2011 00:24:59 -0400 From: "J. Kuczewski" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org, eadler@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Slow load time to /boot/loader (3rd stage loader) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 04:53:38 -0000 Hi all, I have recently installed 9.0-RC1 on my Thinkpad X201 and have noticed severe (~20 mins) latency to get to the third stage bootloader (/boot/loader). This is system triple booted with Windows 7 and Arch Linux using the GRUB 2 bootmanager. FreeBSD is not on a extended partition, if it matters. I have tested two BIOS disk configurations, one with AHCI and the other with IDE compatibility mode. IDE mode is comparatively faster, but still slower than expected (~3 mins). To see if this was a regression, I installed 8.2, and it has the same exact effect. Booting off of USB stick loads fine (e.g. the installer). The following is my notes with the different BIOS configurations with a link to the verbose dmesgs for each... With AHCI enabled: o dmesg output: http://dl.dropbox.com/u/45307545/dmesg_logs/dmesg_ahci.log o Timeline: ~05 mins - Loading /boot/default/loader.conf appears. ~16 mins - /boot/kernel/kernel displayed. ~20 mins - Welcome to FreeBSD boot prompt. With IDE compatibility enabled: o dmesg output: http://dl.dropbox.com/u/45307545/dmesg_logs/dmesg_ide.log o Timeline: ~02 mins - Loading /boot/default/loader.conf and /boot/kernel/kernel is displayed at once. ~03 mins - Welcome to FreeBSD boot prompt is displayed. After the boot prompt, startup is normal with no slowdowns to the login prompt. --- Current BIOS and ECP versions (output from Linux): --- # dmidecode -s bios-version 6QET52WW (1.22) # dmidecode -t 11 # dmidecode 2.11 SMBIOS 2.6 present. Handle 0x0027, DMI type 11, 5 bytes OEM Strings String 1: IBM ThinkPad Embedded Controller -[6QHT30WW-1.11 ]- --- FreeBSD GRUB2 entry: --- menuentry "FreeBSD 9.0-RC1" { insmod ufs2 set root=(hd0,3) chainloader +1 } Any guidance to determine the slow down of this loading problem would be great. Thank you for your time... Cheers, -John Kuczewski From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 05:17:11 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB00A106566B for ; Tue, 25 Oct 2011 05:17:11 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6C1578FC15 for ; Tue, 25 Oct 2011 05:17:11 +0000 (UTC) Received: by gyd8 with SMTP id 8so176622gyd.13 for ; Mon, 24 Oct 2011 22:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=UkGl5YMH+z404D3EJUG5nPehKPAt6Xmafr0gEIJSzWA=; b=wt6F8CLChW52gCKWxrgwwCWmXgR1HobaCN2zzHD0q3y4KpK17ju9ZXY574AOrg9Brq PVB27wj25oXfSwrLBvmTW2A9Qi18BUXzG3b7DZ0+kpf28j0/MIOia10SX9TPqy0texWN Hg6jFAFTaCjMMRb/hvO9TTjcgUgi5oun+hIJw= MIME-Version: 1.0 Received: by 10.236.108.225 with SMTP id q61mr7078562yhg.66.1319519830727; Mon, 24 Oct 2011 22:17:10 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.109.39 with HTTP; Mon, 24 Oct 2011 22:17:10 -0700 (PDT) In-Reply-To: References: Date: Tue, 25 Oct 2011 13:17:10 +0800 X-Google-Sender-Auth: DcaWU8YRJ5li_BLUgi15okQ3_ho Message-ID: From: Adrian Chadd To: Stig B Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 9.0-beta3, cannot boot after succesfull installation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 05:17:11 -0000 Hi, Just because I'd like to ensure this doesn't get lost, would you please do an MBR install of 9.0-RELEASE on another disk, and then plug that in as a slave to the 8.x install? Do you have a USB<->SATA adapter, so you can attach the disk after boot? What I think will help the developers; * getting a copy of the first couple of kilobytes of the 9.0 MBR disk, so the 9.0 and 8.x MBR/boot/partition table stuff can be compared; * Does the system hang when it's the first disk, or _any_ disk? * If we're lucky, the disk will only hang if its the first disk - so we can try installing 8.x bootblocks on the 9.x disk and see if it works; * If we're unlucky and the 9.0 installed disk hangs when plugged in whether it's the boot disk or not - if it attaches as a USB disk (after the 8.x install is done) you can try putting the 8.x bootblocks on and see if the system boots. I doubt you'll be the only person with this problem so thankyou for bringing it to the FreeBSD lists - I bet for every one of you there's 99 others who would try, see it fail and give up without telling the rest of the FreeBSD community. :) Adrian From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 06:08:19 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0D9C106566B for ; Tue, 25 Oct 2011 06:08:19 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 87CD48FC0C for ; Tue, 25 Oct 2011 06:08:17 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 3EF2A5DAD; Tue, 25 Oct 2011 06:08:15 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id p9P68ELn067821; Tue, 25 Oct 2011 06:08:14 GMT (envelope-from phk@phk.freebsd.dk) To: Benjamin Kaduk From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 24 Oct 2011 21:18:57 -0400." Content-Type: text/plain; charset=ISO-8859-1 Date: Tue, 25 Oct 2011 06:08:14 +0000 Message-ID: <67820.1319522894@critter.freebsd.dk> Cc: "Andrey V. Elsukov" , freebsd-current@freebsd.org Subject: Re: aliasing (or renaming) kern.geom.debugflags X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 06:08:20 -0000 In message , Benjamin Kaduk writes: >On Mon, 24 Oct 2011, Andrey V. Elsukov wrote: >> This is stale message. boot0cfg might work without this. > >On a *mounted* disk? Surely that qualifies as an "open" for the purposes >of the check. The way this used to work before gpart, is that boot0cfg would send a GEOM ctl-message to the MBR-geom asking "Would you please write this boot code ?" Since the MBR-geom was the "owner" of the whole disk, and the one who had it open for writing, it could obviously do so, if it saw fit, and after it had edited its idea about the mbr-partition table into that boot-code. Gpart appearantly does not implement such a ctl message. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 06:19:43 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1527A106566B for ; Tue, 25 Oct 2011 06:19:43 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward5.mail.yandex.net (forward5.mail.yandex.net [IPv6:2a02:6b8:0:602::5]) by mx1.freebsd.org (Postfix) with ESMTP id 81AB18FC08 for ; Tue, 25 Oct 2011 06:19:42 +0000 (UTC) Received: from smtp3.mail.yandex.net (smtp3.mail.yandex.net [77.88.46.103]) by forward5.mail.yandex.net (Yandex) with ESMTP id DABBB120306D; Tue, 25 Oct 2011 10:19:40 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1319523580; bh=i4QtVNpsXqe3DLI4hqyrihxLkqPBMcclkdkUIwhJ31A=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=nSHXZ2wuR/xC4ZH/mj2p5OKdT/3/yY/511hwlDcFcGTcs45Rlgd2W0He/O1KyKArO KxnBxfE2iDCdSwD2oR8quugAX37SUp0lo68q9rUdgB6jiuSpzHdmofA0CVJuEKv5w5 UjmrQHOuUhlAPo97eLaUKcqF+vcvlVgCk3Rwnupo= Received: from smtp3.mail.yandex.net (localhost [127.0.0.1]) by smtp3.mail.yandex.net (Yandex) with ESMTP id A78EB1BA04B9; Tue, 25 Oct 2011 10:19:40 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1319523580; bh=i4QtVNpsXqe3DLI4hqyrihxLkqPBMcclkdkUIwhJ31A=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=nSHXZ2wuR/xC4ZH/mj2p5OKdT/3/yY/511hwlDcFcGTcs45Rlgd2W0He/O1KyKArO KxnBxfE2iDCdSwD2oR8quugAX37SUp0lo68q9rUdgB6jiuSpzHdmofA0CVJuEKv5w5 UjmrQHOuUhlAPo97eLaUKcqF+vcvlVgCk3Rwnupo= Received: from ns.kirov.so-ups.ru (ns.kirov.so-ups.ru [178.74.170.1]) by smtp3.mail.yandex.net (nwsmtp/Yandex) with ESMTP id JdFWBkfH-JeF8MM1e; Tue, 25 Oct 2011 10:19:40 +0400 X-Yandex-Spam: 1 Message-ID: <4EA654F6.1060309@yandex.ru> Date: Tue, 25 Oct 2011 10:19:34 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Poul-Henning Kamp References: <67820.1319522894@critter.freebsd.dk> In-Reply-To: <67820.1319522894@critter.freebsd.dk> X-Enigmail-Version: 1.3.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1B092FDF9A756BE78BC74C01" Cc: freebsd-current@freebsd.org, Benjamin Kaduk Subject: Re: aliasing (or renaming) kern.geom.debugflags X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 06:19:43 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1B092FDF9A756BE78BC74C01 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 25.10.2011 10:08, Poul-Henning Kamp wrote: > The way this used to work before gpart, is that boot0cfg would send > a GEOM ctl-message to the MBR-geom asking "Would you please write this > boot code ?" >=20 > Since the MBR-geom was the "owner" of the whole disk, and the one > who had it open for writing, it could obviously do so, if it saw fit, > and after it had edited its idea about the mbr-partition table into > that boot-code. >=20 > Gpart appearantly does not implement such a ctl message. gpart does it in the same way. --=20 WBR, Andrey V. Elsukov --------------enig1B092FDF9A756BE78BC74C01 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) iQEcBAEBAgAGBQJOplT7AAoJEAHF6gQQyKF6fYYH/1BVvhC1qgwTteOGI761mge5 g5UI6oJEG7jQRUnarLji4XLsBVSSfV0nknazZ5miLhrwlj45rLH2uDUHs/ZTkRXP JtZLavl42GB4SY1Fnqe1DfzkFhr4nWoCGXoO++1PsVm/PFYL7sphYJh+xm20EbGs 5POmWAO8e7bScTMrpCWl/fvSBRZgbMQEWCjvn2fpSYMRxHTb5T+iflBzP4AdJrSg 4ue0AOd6nlwuEnj3tRp1DtpV72eTW4ECri1IgE02YAjY2KfOTItFbk7EDbNME/jI eyeVTq1AM+ys/2obau3IvctxJHnpzw8109TcsvNy6hlyTG9okD+Jfpig7ao8muM= =wKYX -----END PGP SIGNATURE----- --------------enig1B092FDF9A756BE78BC74C01-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 06:32:34 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FCCE106564A for ; Tue, 25 Oct 2011 06:32:34 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 0F60F8FC08 for ; Tue, 25 Oct 2011 06:32:33 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 689575DAF; Tue, 25 Oct 2011 06:32:32 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id p9P6WWeq067923; Tue, 25 Oct 2011 06:32:32 GMT (envelope-from phk@phk.freebsd.dk) To: "Andrey V. Elsukov" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 25 Oct 2011 10:19:34 +0400." <4EA654F6.1060309@yandex.ru> Content-Type: text/plain; charset=ISO-8859-1 Date: Tue, 25 Oct 2011 06:32:32 +0000 Message-ID: <67922.1319524352@critter.freebsd.dk> Cc: freebsd-current@freebsd.org, Benjamin Kaduk Subject: Re: aliasing (or renaming) kern.geom.debugflags X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 06:32:34 -0000 In message <4EA654F6.1060309@yandex.ru>, "Andrey V. Elsukov" writes: >This is an OpenPGP/MIME signed message (RFC 2440 and 3156) >--------------enig1B092FDF9A756BE78BC74C01 >Content-Type: text/plain; charset=KOI8-R >Content-Transfer-Encoding: quoted-printable > >On 25.10.2011 10:08, Poul-Henning Kamp wrote: >> The way this used to work before gpart, is that boot0cfg would send >> a GEOM ctl-message to the MBR-geom asking "Would you please write this >> boot code ?" >>=20 >> Since the MBR-geom was the "owner" of the whole disk, and the one >> who had it open for writing, it could obviously do so, if it saw fit, >> and after it had edited its idea about the mbr-partition table into >> that boot-code. >>=20 >> Gpart appearantly does not implement such a ctl message. > >gpart does it in the same way. So why doesn't boot0cfg work ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 06:34:38 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B63491065678 for ; Tue, 25 Oct 2011 06:34:38 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7660E8FC16 for ; Tue, 25 Oct 2011 06:34:38 +0000 (UTC) Received: by qadz32 with SMTP id z32so132025qad.13 for ; Mon, 24 Oct 2011 23:34:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nPcU4GhS7dqGKtUPuCufRlXJ0Gi7D2WxpEOnp8HGQBA=; b=EUWQpNzDF51q2JNQScEOuMzG9zI3BJzCtdQbIQA0W/JeFnHgWKcVbLcz6egZc48JFy mxqbOwQ6G8hK72ubQZBtNbAOiLFXYX+LwoFWVVq1atXkChD+g0sRF/Hwy3Pwg2N18jdk 6rMu4BFvE+OUSNCVmrw+9TI47TdEtWIYH6sJI= MIME-Version: 1.0 Received: by 10.224.183.11 with SMTP id ce11mr20628549qab.52.1319524476392; Mon, 24 Oct 2011 23:34:36 -0700 (PDT) Received: by 10.224.19.212 with HTTP; Mon, 24 Oct 2011 23:34:36 -0700 (PDT) In-Reply-To: References: Date: Tue, 25 Oct 2011 02:34:36 -0400 Message-ID: From: Mehmet Erol Sanliturk To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Current Subject: Re: FreeBSD 9.0 RC1 USB Mouse and Keyboard X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 06:34:38 -0000 On Mon, Oct 24, 2011 at 6:24 PM, Benjamin Kaduk wrote: > On Sun, 23 Oct 2011, Mehmet Erol Sanliturk wrote: > > I have installed FreeBSD 9.0 RC1 . >> >> During installation and boots , and ( as root ) console mode , both USB >> keyboard and mouse are working . >> >> When a graphical desktop ( Fluxbox , Gnome , or KDE ) is started , both of >> them are becoming frozen . >> Detach and attach of mouse are detected , but input is not possible . >> PS/2 mouse is also not working . >> I did not check PS/2 keyboard . >> Only Ctrl-Alt-F1 is discontinuing graphical display , and Ctrl-C is >> returning to root prompt . >> >> KDE is staying as it is after displaying of hard disk symbol and then it >> is >> waiting there . >> Gnome is displaying all the parts , but no input possibility . >> Fluxbox is displaying its window , but no input possibility . >> >> It seems that X is NOT able to register dbus related parts ( understood >> from >> messages left on the screen after discontinuation ) . >> >> On the same computer , I have installed Fedora 15 and everything is >> working >> as expected , means there is no any hardware problem . >> > > Has this computer successfully run other versions of FreeBSD with X? > I seem to recall there can be odd interactions with hald, xorg.conf, and > others. Some googling brings up > http://www.wonkity.com/~wblock/docs/html/aei.html which seems to cover > many of the relevant issues. > > -Ben Kaduk > The above problem has occurred in 9.0 RC1 amd64 . In the same computer , I have installed 9.0 i386 . USB Mouse and Keyboard are working very well in console mode and in Fluxbox . In both ( amd64 and i386 ) of the installations , /etc/rc.conf contain the following statements : moused_type = "auto" moused_enable = "YES" hald_enable = "YES" dbus_enable = "YES" There are no any generated X configuration file . Both of them listed starting of hald and dbus without error during booting . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 07:52:19 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB0C81065670; Tue, 25 Oct 2011 07:52:19 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 246408FC1A; Tue, 25 Oct 2011 07:52:18 +0000 (UTC) Received: by wwi18 with SMTP id 18so281369wwi.31 for ; Tue, 25 Oct 2011 00:52:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=CkmGJh6P7gjua6Rq9lfOA+7azGk1z5jffaHTfOVmebk=; b=aEOsGvaOPqgJsMBZhKPI8zkhfEd0lA9dOlu/QjmAVAcXlX1jV1VW26VeuhbCbbrxgn L43VDXzcosU9ZdnE+4d+czrA3sDJ4p7Yty1F8caGgfMcxCYoL8fxOI35apHtLYGpki6c 6HZlXmSjMNKyzhScq6iJp1YAvGBUDMY9uxM+E= MIME-Version: 1.0 Received: by 10.216.230.101 with SMTP id i79mr4321462weq.65.1319529138037; Tue, 25 Oct 2011 00:52:18 -0700 (PDT) Sender: r.c.ladan@gmail.com Received: by 10.180.83.130 with HTTP; Tue, 25 Oct 2011 00:52:18 -0700 (PDT) Date: Tue, 25 Oct 2011 09:52:18 +0200 X-Google-Sender-Auth: zEy9kCO8O9qJOr9XBzAoAoKbBBU Message-ID: From: =?ISO-8859-1?Q?Ren=E9_Ladan?= To: Colin Percival , FreeBSD current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: freebsd-update not checking disk space? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 07:52:19 -0000 Hi, I tried to upgrade a server at work from 8.2-RELEASE-i386 to 9.0-RC1-i386 using freebsd-update.When running 'freebsd-update install' to install the n= ew kernel, but that failed because there was insufficient disk space. This res= ulted in freebsd-update thinking everything is ok but left the kernel unbootable. >From the screen capture: > 10G# freebsd-update install > Installing updates... > /: write failed, filesystem is full > install: ///boot/kernel/INS@SmmC: No space left on device > install: ///boot/kernel/INS@lMJN: No space left on device > install: ///boot/kernel/INS@ez1L: No space left on device > install: ///boot/kernel/INS@D78d: No space left on device [... more patch files ..] > install: ///boot/kernel/ng_bt3c.ko.symbols: No space left on device > install: ///boot/kernel/ng_btsocket.ko: No space left on device [.. more destination files ..] These two types of messages are interleaved. It ends with: > install: ///boot/INS@yqYd: No space left on device > rmdir: ///boot/kernel: Directory not empty > > Kernel updates have been installed. Please reboot and run > "/usr/sbin/freebsd-update install" again to finish installing updates. > 10G# df > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/ad0s1a 507630 502860 -35840 108% / So in reality the update never finished properly. More logs on request. Regards, Ren=E9 -- http://www.rene-ladan.nl/ GPG fingerprint =3D E738 5471 D185 7013 0EE0=A0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 08:13:07 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16276106566B for ; Tue, 25 Oct 2011 08:13:07 +0000 (UTC) (envelope-from bounces+73574-dfb6-freebsd-current=freebsd.org@sendgrid.me) Received: from o1.shared.sendgrid.net (o1.shared.sendgrid.net [74.63.231.244]) by mx1.freebsd.org (Postfix) with SMTP id C23CD8FC0A for ; Tue, 25 Oct 2011 08:13:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h= message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; s=smtpapi; bh=hv98bZqOSo5mP5iwsAukiol4kjk=; b=fvbeH51m/EM6/JhtPSeIjR4MtVuE 9zVhX+gAtHrorx4tpSH/ktFyGR+xzatt/FBFi5a3VcdfpL1pxHZKyFrcwLHlQnIl Cq0z/czhW18PJ7473IvSSSiyWDC7Yj8yoJDJTc9sXZ4pmsOU3SdEZ/V3QytGMY7T EUYtbbl13/c2nYo= Received: by 10.36.109.132 with SMTP id mf29.4422.4EA66B6D1 Tue, 25 Oct 2011 02:55:25 -0500 (CDT) Received: from mail.tarsnap.com (unknown [10.9.180.5]) by mi9 (SG) with ESMTP id 4ea66b6d.1ee2.ba49442 for ; Tue, 25 Oct 2011 02:55:25 -0500 (CST) Received: (qmail 51466 invoked from network); 25 Oct 2011 07:52:44 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by mail.tarsnap.com with ESMTP; 25 Oct 2011 07:52:44 -0000 Received: (qmail 26954 invoked from network); 25 Oct 2011 07:54:40 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 25 Oct 2011 07:54:40 -0000 Message-ID: <4EA66B40.8060700@freebsd.org> Date: Tue, 25 Oct 2011 00:54:40 -0700 From: Colin Percival User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111024 Thunderbird/7.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ren=E9_Ladan?= References: In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 content-transfer-encoding: quoted-printable X-Sendgrid-EID: XhyBwObMhraAR+zdwMupjQ6BIqbhdEfc+6p+uBxS7S/by8ezOpMfohVsve+C/IPSe7DdM17tvXXYAwwGfubGQOLW4cB6Pfm9W4FOBnEGuKr1qGQbC+W5CQj4cxwxK+9B3htiLSoTZzQMbzbqfhIWDMPVDQwDPrQa5QJsJESuWNU= X-SendGrid-Contentd-ID: {"test_id":1319529326} Cc: FreeBSD current Subject: Re: freebsd-update not checking disk space? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 08:13:07 -0000 On 10/25/11 00:52, Ren=E9 Ladan wrote:=0D > I tried to upgrade a server at work from 8.2-RELEASE-i386 to 9.0-RC1-i386= =0D > using freebsd-update.When running 'freebsd-update install' to install the= new=0D > kernel, but that failed because there was insufficient disk space. This r= esulted=0D > in freebsd-update thinking everything is ok but left the kernel unbootabl= e.=0D =0D Yes, this is a known issue in freebsd-update -- it needs to be much smarter= =0D about detecting and handling errors. Unfortunately I haven't had time to=0D deal with this (and it's a lot of work).=0D =0D -- =0D Colin Percival=0D Security Officer, FreeBSD | freebsd.org | The power to serve=0D Founder / author, Tarsnap | tarsnap.com | Online backups for the truly para= noid From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 10:42:51 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09AFF106566C for ; Tue, 25 Oct 2011 10:42:51 +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 B7AE18FC08 for ; Tue, 25 Oct 2011 10:42:50 +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 <1RIeT3-000298-KW>; Tue, 25 Oct 2011 12:42:49 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RIeT3-00050X-Ib>; Tue, 25 Oct 2011 12:42:49 +0200 Message-ID: <4EA692A9.5010508@zedat.fu-berlin.de> Date: Tue, 25 Oct 2011 12:42:49 +0200 From: "O. Hartmann" Organization: Freie =?ISO-8859-1?Q?Universit=E4t_Berlin?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: Arnaud Lacombe References: <4EA495BA.7080802@zedat.fu-berlin.de> <87987AB8-BCAA-4CED-8B4F-C6EA5B61C0A5@gmail.com> <4EA5E56B.6050809@zedat.fu-berlin.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: Garrett Cooper , freebsd-current Subject: Re: "/usr/src/sys/conf/kern.mk", line 10: Malformed conditional (${FREEBSD_GCC}), "/usr/src/sys/conf/kern.mk", line 14: if-less endif X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 10:42:51 -0000 On 10/25/11 04:48, Arnaud Lacombe wrote: > Hi, > > On Mon, Oct 24, 2011 at 6:23 PM, Hartmann, O. > wrote: >> On 10/24/11 00:38, Garrett Cooper wrote: >>> On Oct 23, 2011, at 3:31 PM, Hartmann, O. wrote: >>> >>>> Kernel building fails since today when kernel gets compiled via CLANG: >>>> -------------------------------------------------------------- >>>>>>> stage 2.1: cleaning up the object tree >>>> -------------------------------------------------------------- >>>> cd /usr/obj/usr/src/sys/THOR; MAKEOBJDIRPREFIX=/usr/obj >>>> MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE=native >>>> GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin >>>> GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font >>>> GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac >>>> _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp VERSION="FreeBSD 10.0-CURRENT >>>> amd64 1000000" INSTALL="sh /usr/src/tools/install.sh" >>>> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/ >>>> usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr >>>> /sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbi >>>> n:/bin:/usr/sbin:/usr/bin /usr/obj/usr/src/make.amd64/make >>>> KERNEL=kernel cleandir >>>> "/usr/src/sys/conf/kern.mk", line 10: Malformed conditional >>>> (${FREEBSD_GCC}) >>>> "/usr/src/sys/conf/kern.mk", line 14: if-less endif >>>> make: fatal errors encountered -- cannot continue >>>> *** Error code 1 >>>> Stop in /usr/src. >>>> *** Error code 1 >>>> Stop in /usr/src. >>> It was noted not too long ago on the commit list as well; r226665 caused the breakage. >>> -Garrett_______________________________________________ >>> >> >> So, this is by intention? >> When does the problem disappear, so folks building FreeBSD with CLANG >> are again capable of building a world and kernel? >> > seemed to have been "fixed" by dim@: > > commit 2286e401073a60babb3cc8efce52657f6fa92f7e > Author: dim > Date: Mon Oct 24 18:35:16 2011 +0000 > > Put in a temporary band-aid to fix kernel builds when CC=clang, after > r226665. > > > Thanks dim@! > > - Arnaud I was yesterday too fast. After a couple of minutes after I posted, the patch rushed in and everything ran smooth as before and expected. Thanks! Regards, Oliver From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 10:45:42 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6EC9106566B for ; Tue, 25 Oct 2011 10:45:42 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from smtp.smtpout.orange.fr (smtp02.smtpout.orange.fr [80.12.242.124]) by mx1.freebsd.org (Postfix) with ESMTP id 8DB038FC14 for ; Tue, 25 Oct 2011 10:45:41 +0000 (UTC) Received: from localhost ([92.162.133.50]) by mwinf5d04 with ME id oyFb1h00E15Q9dY03yFcT2; Tue, 25 Oct 2011 12:15:39 +0200 X-ME-engine: default Message-ID: <4EA68C47.2070908@orange.fr> Date: Tue, 25 Oct 2011 12:15:35 +0200 From: Claude Buisson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.23) Gecko/20110928 Thunderbird/3.1.15 MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: can audio CDs be played with ATA_CAM ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 10:45:43 -0000 Hi, When upgrading a system to 8.2-STABLE, I switched my kernel from atapicam to ATA_CAM, and found that vlc could not play audio CDs anymore. Reverting to atapicam (and reverting from cdN to acdN of course), vlc was OK again. It seems that I am not the only one having this kind of problem, as I found (for example) this message on questions@ (for releng9): http://lists.freebsd.org/pipermail/freebsd-questions/2011-October/234737.html Is this a known problem ? Is somebody working on it ? Thanks, Claude Buisson From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 10:48:14 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05DE410656A3; Tue, 25 Oct 2011 10:48:14 +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 B85708FC1D; Tue, 25 Oct 2011 10:48:13 +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 <1RIeYG-0003O9-M9>; Tue, 25 Oct 2011 12:48:12 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RIeYG-0005Vy-JW>; Tue, 25 Oct 2011 12:48:12 +0200 Message-ID: <4EA693EC.1070602@zedat.fu-berlin.de> Date: Tue, 25 Oct 2011 12:48:12 +0200 From: "O. Hartmann" Organization: Freie =?ISO-8859-1?Q?Universit=E4t_Berlin?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-questions@FreeBSD.ORG, FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: Subject: The future of FreeBSD at Yahoo! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 10:48:14 -0000 The press in Germania is full of some statements, that Google is about to overtake Yahoo!. As far as I know, Yahoo! is one of the more popular and bigger, if not the biggest and last stronghold of a FreeBSD driven infrastructure. Despite the fact that even Google funded lots of coding for FreeBSD, I had the impression that Yahoo! might be one of the biggest contributor. And not to mention the psychological effect of hearing that such a company is utilizing a project like FreeBSD for potential newcomers in the business. So, what is about the future of FreeBSD? Does FreeBSD have a site where all the goods that has been first invented by the FreeBSD/BSD folks or all the things that are thought about to come in future are shown/listed? Crawling the mailing lists is a really nasty work. Thanks for having patience, Oliver From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 10:52:18 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 636751065676; Tue, 25 Oct 2011 10:52:18 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id DDE0C8FC0A; Tue, 25 Oct 2011 10:52:17 +0000 (UTC) Received: from ur.dons.net.au (ppp118-210-211-94.lns20.adl6.internode.on.net [118.210.211.94]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id p9PAq6b4029987 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Oct 2011 21:22:12 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: "Daniel O'Connor" In-Reply-To: <4EA68C47.2070908@orange.fr> Date: Tue, 25 Oct 2011 21:22:06 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EA68C47.2070908@orange.fr> To: Claude Buisson X-Mailer: Apple Mail (2.1251.1) X-Spam-Score: 2.162 (**) BAYES_00,KHOP_DYNAMIC,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: FreeBSD Current , freebsd-stable@freebsd.org Subject: Re: can audio CDs be played with ATA_CAM ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 10:52:18 -0000 On 25/10/2011, at 20:45, Claude Buisson wrote: > When upgrading a system to 8.2-STABLE, I switched my kernel from = atapicam to > ATA_CAM, and found that vlc could not play audio CDs anymore. = Reverting to > atapicam (and reverting from cdN to acdN of course), vlc was OK again. >=20 > It seems that I am not the only one having this kind of problem, as I = found (for > example) this message on questions@ (for releng9): >=20 > = http://lists.freebsd.org/pipermail/freebsd-questions/2011-October/234737.h= tml >=20 > Is this a known problem ? Is somebody working on it ? Have you tried pointing VLC at /dev/cd0 when using ATA_CAM? It may be trying old style ATA ioctls based on the device name. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 10:59:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A960F106564A for ; Tue, 25 Oct 2011 10:59:53 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (wrz3028.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id 5E2C18FC18 for ; Tue, 25 Oct 2011 10:59:52 +0000 (UTC) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id BCC1D5AC65; Tue, 25 Oct 2011 12:59:51 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id BADE65AC42; Tue, 25 Oct 2011 12:59:51 +0200 (CEST) X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 9DEE05CC2A; Tue, 25 Oct 2011 12:59:51 +0200 (CEST) Received: from lexx.ifp.tuwien.ac.at ([128.131.127.223]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.5.3) with ESMTP id 2011102512595054-32879 ; Tue, 25 Oct 2011 12:59:50 +0200 Date: Tue, 25 Oct 2011 12:59:49 +0200 From: Alexey Shuvaev To: "C. P. Ghost" Message-ID: <20111025105949.GA2853@lexx.ifp.tuwien.ac.at> References: <20111008201456.GA3529@lexx.ifp.tuwien.ac.at> <20111017190027.GA9873@lexx.ifp.tuwien.ac.at> <20111018131353.GA83797@lexx.ifp.tuwien.ac.at> MIME-Version: 1.0 In-Reply-To: Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.21 (2010-09-15) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.5.3|September 15, 2011) at 10/25/2011 12:59:50 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.5.3|September 15, 2011) at 10/25/2011 12:59:50 PM, Serialize complete at 10/25/2011 12:59:50 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cc: freebsd-current@freebsd.org Subject: Re: Panics after AHCI timeouts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 10:59:53 -0000 On Mon, Oct 24, 2011 at 08:27:49PM +0200, C. P. Ghost wrote: > On Tue, Oct 18, 2011 at 3:13 PM, Alexey Shuvaev > wrote: > > On Tue, Oct 18, 2011 at 06:19:19AM +0800, Adrian Chadd wrote: > >> On 18 October 2011 03:00, Alexey Shuvaev > >> wrote: > >> > On Sat, Oct 08, 2011 at 10:14:56PM +0200, Alexey Shuvaev wrote: > >> >> Hello list! > >> >> > >> > Errr... Replying to myself... Ping? Should I file a PR and put it > >> > in the back burner? :) > >> > >> I think filing a PR is a good move. Then just be proactive and poke > >> people about it. It'd be good to get this fixed. :) > >> > > Done, kern/161768. > > > > Question to the list: does anybody see successful recovery from AHCI > > timeout an a recent CURRENT? Recent means June 2011 or newer, so 9.0 > > branch counts also. That is, there are some kernel messages like this: > > > > ahcich0: Timeout on slot 29 port 0 > > ahcich0: is 00000000 cs 00000000 ss ffffffff rs ffffffff tfd 40 serr 00000000 cmd 0000fc17 > > > > but then AHCI recovers and the system does not panic? > > I'm seeing these timeouts too on an 8.2-STABLE amd64 r222832 > from June 7. The system hangs partially -- or, more precisely, all > processes that attempt to access the disk on this channel hang, > everything else continues as normal. > > I suspect a faulty cable, but I don't have physical access to the system > to replace parts right now. A panic would be a regression, so I'm holding > off updates on that server until AHCI becomes more tolerant and somewhat > self-healing. :( > In a communication not on the list mav has said he has done some tests not so long ago by injecting artificial failures in the AHCI code. He has not observed any panics and it is not clear if the problem is generic / hardware related / or purely local. I would not have any time to investigate further till November. So, Your Mileage May Vary :) 0.02$, Alexey. From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 07:14:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C3D2106564A for ; Tue, 25 Oct 2011 07:14:08 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8A89F8FC17 for ; Tue, 25 Oct 2011 07:14:07 +0000 (UTC) Received: by faar19 with SMTP id r19so293139faa.13 for ; Tue, 25 Oct 2011 00:14:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6BJiUQPygvP/Eam0jxYquz4NXY65G6awLQGxiP8HG/0=; b=W80CyxnKATSt6DFRO3VhqOBPFfkvyuVyid8g1Tjm1lQqdTQO4z0DWnKTf0GjOwSJBL 72f9F876OjnhHhB8hlGXYg9icIvDf45QIf4xzyzSp3Dm2gTYpU6ERs9YKrhC84uajSGt DVg1s2M06YOGV6qq8qOQbrvAhXprYiKndhjmI= MIME-Version: 1.0 Received: by 10.223.77.77 with SMTP id f13mr41358868fak.19.1319526846274; Tue, 25 Oct 2011 00:14:06 -0700 (PDT) Received: by 10.152.24.67 with HTTP; Tue, 25 Oct 2011 00:14:06 -0700 (PDT) In-Reply-To: <4EA47446.5060405@FreeBSD.org> References: <20111021085851.GA51368@neveragain.de> <201110211633.38764.jhb@freebsd.org> <20111023152754.GA35505@neveragain.de> <4EA455A7.2060301@FreeBSD.org> <20111023195615.GB35505@neveragain.de> <4EA47446.5060405@FreeBSD.org> Date: Tue, 25 Oct 2011 11:14:06 +0400 Message-ID: From: Pavel Timofeev To: Dimitry Andric X-Mailman-Approved-At: Tue, 25 Oct 2011 11:09:00 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, Andriy Gapon , Dennis Koegel Subject: Re: Fresh installed Freebsd 9 don't boot from hd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 07:14:08 -0000 2011/10/24 Dimitry Andric > On 2011-10-23 21:56, Dennis Koegel wrote: > >> On Sun, Oct 23, 2011 at 08:57:59PM +0300, Andriy Gapon wrote: >> >>> I found a document that suggests a possibility of BIOS writing more bytes >>> to the >>> array than its current size of 0x42: [...] >>> Could you please test this hypothesis by trying the following patch? >>> >> >> With -O1 and this patch, it boots. Thank you! >> > > If you have some time, can you also re-check the other cases you listed > before? E.g.: > > > gcc -Os -fno-guess-branch-probability -fomit-frame-pointer > -fno-unit-at-a-time \ > -mno-align-long-strings -mrtd [from before r225530]: > gcc -Os -mrtd: > gcc -O1 -mrtd: > gcc -O1: > gcc -O0: > gcc -Os: > > clang -O1: > clang -Os: > clang -Oz: > My 5 cents: tested on my HP Proliant DL360 G5 with Andriy's patch clang -O1: ok (VirtualBox with ahci boots too) clang -Os: ok clang -Oz: ok > > Thanks. :) > From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 11:18:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC91C106564A for ; Tue, 25 Oct 2011 11:18:52 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) by mx1.freebsd.org (Postfix) with ESMTP id 61F318FC1A for ; Tue, 25 Oct 2011 11:18:51 +0000 (UTC) Received: from localhost ([92.162.133.50]) by mwinf5d12 with ME id ozJn1h00415Q9dY03zJnYC; Tue, 25 Oct 2011 13:18:50 +0200 X-ME-engine: default Message-ID: <4EA69B17.6020607@orange.fr> Date: Tue, 25 Oct 2011 13:18:47 +0200 From: Claude Buisson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.23) Gecko/20110928 Thunderbird/3.1.15 MIME-Version: 1.0 To: Daniel O'Connor References: <4EA68C47.2070908@orange.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , freebsd-stable@freebsd.org Subject: Re: can audio CDs be played with ATA_CAM ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 11:18:52 -0000 On 10/25/2011 12:52, Daniel O'Connor wrote: > > On 25/10/2011, at 20:45, Claude Buisson wrote: >> When upgrading a system to 8.2-STABLE, I switched my kernel from atapicam to >> ATA_CAM, and found that vlc could not play audio CDs anymore. Reverting to >> atapicam (and reverting from cdN to acdN of course), vlc was OK again. >> >> It seems that I am not the only one having this kind of problem, as I found (for >> example) this message on questions@ (for releng9): >> >> http://lists.freebsd.org/pipermail/freebsd-questions/2011-October/234737.html >> >> Is this a known problem ? Is somebody working on it ? > > Have you tried pointing VLC at /dev/cd0 when using ATA_CAM? > Of course yes ! (I even configured WITH_CDROM_DEVICE=/dev/cd1 when building VLC) > It may be trying old style ATA ioctls based on the device name. > VLC recognize the tracks and jump quickly from one to the following, without playing it, and with a flow of messages: [0x2caf2a3c] cdda access error: Could not set block size [0x2caf2a3c] cdda access error: cannot read sector nnnnn where the sector number is incremented, and then emit (2 times if I remenber): [0x2af28bc] es demux error: cannot peek Sorry for having ommited these messages in the previous mail. I found a PR 161760 about cdparanoia needing to be patched for 9.0 with CAM, a proposal by avg@ related to libxine: http://lists.freebsd.org/pipermail/freebsd-multimedia/2010-December/011414.html These may not be the same problem, but I think they are related (a not so well documented change in the kerm interface). > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > > > > > > > Claude Buisson From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 11:26:34 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B333A106567A; Tue, 25 Oct 2011 11:26:34 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D29178FC12; Tue, 25 Oct 2011 11:26:33 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA12382; Tue, 25 Oct 2011 14:26:31 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4EA69CE6.5070601@FreeBSD.org> Date: Tue, 25 Oct 2011 14:26:30 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: John Baldwin References: <201110241133.23397.jhb@freebsd.org> <4EA59165.1000202@FreeBSD.org> <201110241423.44951.jhb@freebsd.org> In-Reply-To: <201110241423.44951.jhb@freebsd.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Fresh installed Freebsd 9 don't boot from hd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 11:26:34 -0000 on 24/10/2011 21:23 John Baldwin said the following: > On Monday, October 24, 2011 12:25:09 pm Andriy Gapon wrote: >> Also, perhaps edd_params_v3 and edd_params_v4 should inherit edd_params in some >> "smarter" way to avoid verbatim duplicates. > > Yeah, probably so. We will probably never even use them anyway (just as we don't > use edd_packet_v3 even though we could probably make use of it to avoid some > bounce buffering in the loader). > >> Other than these issues the patch looks great! >> Perhaps later we could do detailed definitions for things like interface paths for >> various cases, etc. > > I doubt we will ever use them. In theory we could pass that information from loader to kernel, so that in a booted system we could try to build a mapping between kernel disks and bios disks, with the boot disk potentially being of the most interest. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 12:38:38 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2571A106564A for ; Tue, 25 Oct 2011 12:38:38 +0000 (UTC) (envelope-from egypcio@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id E4C9D8FC12 for ; Tue, 25 Oct 2011 12:38:37 +0000 (UTC) Received: by iaky10 with SMTP id y10so771861iak.13 for ; Tue, 25 Oct 2011 05:38:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hcxdxTVrn/AzgkZtK3RQ7Ztq0MSbfruYOtGQ8H/b6Q8=; b=fMrJlNk8LCLRem7KcBnQ9paLgfEiCHRxXKBEGX6ZPx7iCoEDZeh5AW//w1fFHjfJQ+ dv6CzSF8B2eXZxUZ/Uztk8nIskBSEM0MbNEZT5MibEU0+IBdBNObdMCG2RNvtv4c+7Ir ivNiBnaPSk/PwyxTrlXLsBh5zfFvdBJ59dL/w= MIME-Version: 1.0 Received: by 10.42.147.197 with SMTP id o5mr43981146icv.54.1319544903272; Tue, 25 Oct 2011 05:15:03 -0700 (PDT) Sender: egypcio@gmail.com Received: by 10.50.212.5 with HTTP; Tue, 25 Oct 2011 05:15:03 -0700 (PDT) In-Reply-To: <4EA63A1B.9040407@bnl.gov> References: <4EA63A1B.9040407@bnl.gov> Date: Tue, 25 Oct 2011 09:15:03 -0300 X-Google-Sender-Auth: YKqHqzTSEKDnYCmuCyFP8lBJ_8U Message-ID: From: =?ISO-8859-1?Q?Vin=EDcius_Zavam?= To: "J. Kuczewski" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current Subject: Re: Slow load time to /boot/loader (3rd stage loader) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 12:38:38 -0000 2011/10/25 J. Kuczewski : > Hi all, > > I have recently installed 9.0-RC1 on my Thinkpad X201 and have noticed > severe (~20 mins) latency to get to the third stage bootloader > (/boot/loader). This is system triple booted with Windows 7 and Arch Linu= x > using the GRUB 2 bootmanager. FreeBSD is not on a extended partition, if = it > matters. I have tested two BIOS disk configurations, one with AHCI and th= e > other with IDE compatibility mode. IDE mode is comparatively faster, but > still slower than expected (~3 mins). To see if this was a regression, I > installed 8.2, and it has the same exact effect. Booting off of USB stick > loads fine (e.g. the installer). The following is my notes with the > different BIOS configurations with a link to the verbose dmesgs for each.= .. > > With AHCI enabled: > =A0 =A0o =A0dmesg output: > http://dl.dropbox.com/u/45307545/dmesg_logs/dmesg_ahci.log > =A0 =A0o =A0Timeline: > =A0 =A0 =A0 =A0~05 mins - Loading /boot/default/loader.conf appears. > =A0 =A0 =A0 =A0~16 mins - /boot/kernel/kernel displayed. > =A0 =A0 =A0 =A0~20 mins - Welcome to FreeBSD boot prompt. > > With IDE compatibility enabled: > =A0 =A0o =A0dmesg output: > http://dl.dropbox.com/u/45307545/dmesg_logs/dmesg_ide.log > =A0 =A0o =A0Timeline: > =A0 =A0 =A0 =A0~02 mins - Loading /boot/default/loader.conf and /boot/ker= nel/kernel > is displayed at once. > =A0 =A0 =A0 =A0~03 mins - Welcome to FreeBSD boot prompt is displayed. > > After the boot prompt, startup is normal with no slowdowns to the login > prompt. > > --- > Current BIOS and ECP versions (output from Linux): > --- > # dmidecode -s bios-version > 6QET52WW (1.22) > # dmidecode -t 11 > # dmidecode 2.11 > SMBIOS 2.6 present. > > Handle 0x0027, DMI type 11, 5 bytes > OEM Strings > =A0 =A0 =A0 =A0String 1: IBM ThinkPad Embedded Controller -[6QHT30WW-1.11= =A0 =A0]- > > --- > FreeBSD GRUB2 entry: > --- > menuentry "FreeBSD 9.0-RC1" { > =A0 =A0insmod ufs2 > =A0 =A0set root=3D(hd0,3) > =A0 =A0chainloader +1 > } > > Any guidance to determine the slow down of this loading problem would be > great. > > Thank you for your time... > > Cheers, > =A0 =A0-John Kuczewski i've got something like this. check it out: http://lists.freebsd.org/pipermail/freebsd-stable/2010-January/054551.html i remembered this issue when reading your e-mail this morning. unfortunately i couldn't fix the issue. just saw the answer from Paulo[1] today (LOL).. but you, John, are using "the same" entry with grub2.. so.... sadness ;-( nowadays i'm using 10.0current with my asus 1005pe (eeepc) and everything runs like a charm. i still have the same pavilion; maybe one day it will run freebsd again (even if it needs 30min to boot) <3 [1] http://lists.freebsd.org/pipermail/freebsd-stable/2010-March/055733.htm= l --=20 Vin=EDcius Zavam profiles.google.com/egypcio From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 13:08:30 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA6171065670; Tue, 25 Oct 2011 13:08:30 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 323EC8FC0C; Tue, 25 Oct 2011 13:08:29 +0000 (UTC) Received: from ur.dons.net.au (ppp118-210-211-94.lns20.adl6.internode.on.net [118.210.211.94]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id p9PD8JjH036638 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Oct 2011 23:38:24 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: <20111025125423.GA88097@icarus.home.lan> Date: Tue, 25 Oct 2011 23:38:18 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EA68C47.2070908@orange.fr> <4EA69B17.6020607@orange.fr> <20111025125423.GA88097@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1251.1) X-Spam-Score: 2.162 (**) BAYES_00,KHOP_DYNAMIC,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: Claude Buisson , FreeBSD Current , freebsd-stable@freebsd.org Subject: Re: can audio CDs be played with ATA_CAM ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 13:08:30 -0000 On 25/10/2011, at 23:24, Jeremy Chadwick wrote: >> These may not be the same problem, but I think they are related (a = not so well >> documented change in the kerm interface). >=20 > You want atapicam(4). This is not the same thing as "options = ATA_CAM". > See /sys/conf/NOTES. >=20 > Whether or not it works with audio CDs is unknown to me. atapicam is a bridge for the old ATA code to put ATAPI devices _only_ on = CAM (as well as the ATA infrastructure). Hence they appear as /dev/cd0 = and so on. ATA_CAM puts _all_ ATA devices on CAM, so you should be able to access = your audio CD that way.=20 I just tried and it ripped a CD fine using cdparanoia and cdcontrol = seemed to play it OK (although I don't have the analogue output of this = drive hooked up to the audio system). This is not to say that there isn't a bug in the ATA_CAM code :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 13:18:31 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79161106566B for ; Tue, 25 Oct 2011 13:18:31 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr [80.12.242.127]) by mx1.freebsd.org (Postfix) with ESMTP id EDBA18FC19 for ; Tue, 25 Oct 2011 13:18:30 +0000 (UTC) Received: from localhost ([92.162.133.50]) by mwinf5d09 with ME id p1JT1h00X15Q9dY031JUDe; Tue, 25 Oct 2011 15:18:29 +0200 X-ME-engine: default Message-ID: <4EA6B723.7090501@orange.fr> Date: Tue, 25 Oct 2011 15:18:27 +0200 From: Claude Buisson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.23) Gecko/20110928 Thunderbird/3.1.15 MIME-Version: 1.0 To: Jeremy Chadwick References: <4EA68C47.2070908@orange.fr> <4EA69B17.6020607@orange.fr> <20111025125423.GA88097@icarus.home.lan> In-Reply-To: <20111025125423.GA88097@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , freebsd-stable@freebsd.org Subject: Re: can audio CDs be played with ATA_CAM ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 13:18:31 -0000 On 10/25/2011 14:54, Jeremy Chadwick wrote: > On Tue, Oct 25, 2011 at 01:18:47PM +0200, Claude Buisson wrote: >> On 10/25/2011 12:52, Daniel O'Connor wrote: >>> >>> On 25/10/2011, at 20:45, Claude Buisson wrote: >>>> When upgrading a system to 8.2-STABLE, I switched my kernel from atapicam to >>>> ATA_CAM, and found that vlc could not play audio CDs anymore. Reverting to >>>> atapicam (and reverting from cdN to acdN of course), vlc was OK again. >>>> >>>> It seems that I am not the only one having this kind of problem, as I found (for >>>> example) this message on questions@ (for releng9): >>>> >>>> http://lists.freebsd.org/pipermail/freebsd-questions/2011-October/234737.html >>>> >>>> Is this a known problem ? Is somebody working on it ? >>> >>> Have you tried pointing VLC at /dev/cd0 when using ATA_CAM? >>> >> >> Of course yes ! (I even configured WITH_CDROM_DEVICE=/dev/cd1 when building VLC) >> >> >>> It may be trying old style ATA ioctls based on the device name. >>> >> >> VLC recognize the tracks and jump quickly from one to the following, without >> playing it, and with a flow of messages: >> >> [0x2caf2a3c] cdda access error: Could not set block size >> [0x2caf2a3c] cdda access error: cannot read sector nnnnn >> >> where the sector number is incremented, and then emit (2 times if I remenber): >> >> [0x2af28bc] es demux error: cannot peek >> >> Sorry for having ommited these messages in the previous mail. >> >> I found a PR 161760 about cdparanoia needing to be patched for 9.0 with CAM, a >> proposal by avg@ related to libxine: >> >> http://lists.freebsd.org/pipermail/freebsd-multimedia/2010-December/011414.html >> >> These may not be the same problem, but I think they are related (a not so well >> documented change in the kerm interface). > > You want atapicam(4). This is not the same thing as "options ATA_CAM". > See /sys/conf/NOTES. > > Whether or not it works with audio CDs is unknown to me. > I *know* the difference between atapicam and ATA_CAM ;-) I have done other tests on 8.X and 7.X, and found that audio CDs cannot be played with atapicam. BUT, I understood (wrongly ?) that ATA_CAM was the way to go starting with 9.X, which imply that the traditionnal acdN interface will disappear. A valid answer to my question may be: "we - kernel developpers - know about it, but we don't care, and the problem must be solved by the userland/applications developpers". With some obvious consequences on the upgrading or not upgrading of end users systems. Claude Buisson From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 13:07:40 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A15861065675 for ; Tue, 25 Oct 2011 13:07:40 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by mx1.freebsd.org (Postfix) with ESMTP id 61ADC8FC14 for ; Tue, 25 Oct 2011 13:07:40 +0000 (UTC) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta05.westchester.pa.mail.comcast.net with comcast id p0QD1h00727AodY550uRkZ; Tue, 25 Oct 2011 12:54:25 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta19.westchester.pa.mail.comcast.net with comcast id p0uQ1h01Z1t3BNj3f0uQfJ; Tue, 25 Oct 2011 12:54:25 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 0C6B3102C31; Tue, 25 Oct 2011 05:54:23 -0700 (PDT) Date: Tue, 25 Oct 2011 05:54:23 -0700 From: Jeremy Chadwick To: Claude Buisson Message-ID: <20111025125423.GA88097@icarus.home.lan> References: <4EA68C47.2070908@orange.fr> <4EA69B17.6020607@orange.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EA69B17.6020607@orange.fr> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Tue, 25 Oct 2011 13:27:11 +0000 Cc: FreeBSD Current , freebsd-stable@freebsd.org Subject: Re: can audio CDs be played with ATA_CAM ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 13:07:40 -0000 On Tue, Oct 25, 2011 at 01:18:47PM +0200, Claude Buisson wrote: > On 10/25/2011 12:52, Daniel O'Connor wrote: > > > >On 25/10/2011, at 20:45, Claude Buisson wrote: > >>When upgrading a system to 8.2-STABLE, I switched my kernel from atapicam to > >>ATA_CAM, and found that vlc could not play audio CDs anymore. Reverting to > >>atapicam (and reverting from cdN to acdN of course), vlc was OK again. > >> > >>It seems that I am not the only one having this kind of problem, as I found (for > >>example) this message on questions@ (for releng9): > >> > >>http://lists.freebsd.org/pipermail/freebsd-questions/2011-October/234737.html > >> > >>Is this a known problem ? Is somebody working on it ? > > > >Have you tried pointing VLC at /dev/cd0 when using ATA_CAM? > > > > Of course yes ! (I even configured WITH_CDROM_DEVICE=/dev/cd1 when building VLC) > > > >It may be trying old style ATA ioctls based on the device name. > > > > VLC recognize the tracks and jump quickly from one to the following, without > playing it, and with a flow of messages: > > [0x2caf2a3c] cdda access error: Could not set block size > [0x2caf2a3c] cdda access error: cannot read sector nnnnn > > where the sector number is incremented, and then emit (2 times if I remenber): > > [0x2af28bc] es demux error: cannot peek > > Sorry for having ommited these messages in the previous mail. > > I found a PR 161760 about cdparanoia needing to be patched for 9.0 with CAM, a > proposal by avg@ related to libxine: > > http://lists.freebsd.org/pipermail/freebsd-multimedia/2010-December/011414.html > > These may not be the same problem, but I think they are related (a not so well > documented change in the kerm interface). You want atapicam(4). This is not the same thing as "options ATA_CAM". See /sys/conf/NOTES. Whether or not it works with audio CDs is unknown to me. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 14:00:01 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 744541065677; Tue, 25 Oct 2011 14:00:01 +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 237418FC17; Tue, 25 Oct 2011 14:00:00 +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 p9PE00hL008671; Tue, 25 Oct 2011 07:00:00 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id p9PE00gR008670; Tue, 25 Oct 2011 07:00:00 -0700 (PDT) (envelope-from david) Date: Tue, 25 Oct 2011 07:00:00 -0700 From: David Wolfskill To: John Baldwin Message-ID: <20111025140000.GA8559@albert.catwhisker.org> References: <20111020114844.GK59810@albert.catwhisker.org> <20111020122121.GL59810@albert.catwhisker.org> <201110211636.05917.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline In-Reply-To: <201110211636.05917.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: sys/conf/newvers.sh vs. subversion-1.7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 14:00:01 -0000 --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 21, 2011 at 04:36:05PM -0400, John Baldwin wrote: > ... > > > Well, as of subversion-1.7, we don't have a ".svn" directory in > > > ${SYSDIR} any more -- it's only at the root of the working copy > > > (/usr/src, in this case). So "svnversion" is never invoked. > > >=20 > > > So I've just hacked my copy to parallel the "git" stanza & look for > > > ${SYSDIR}/../.svn, Not sure that's ideal, but there appears to be > > > precedent.... :-} > > >=20 > > > It might be handy to resolve this prior to 9.0-RELEASE, I think. > > > ... > ... > Hmm, that won't always work, the problem is if someone just checks out a= =20 > kernel tree then .svn will be in SYSDIR. Alternatively, if you have a tr= ee=20 > like mine which has work/freebsd/svn/ with various subdirs (head/, stable= /=20 > with subdirs for 7, 8, 9) but all rooted at the upperlevel, just looking = two=20 > levels up won't work. OK... How about (untested) something like: Index: sys/conf/newvers.sh =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/conf/newvers.sh (revision 226724) +++ sys/conf/newvers.sh (working copy) @@ -88,7 +88,7 @@ i=3D`${MAKE:-make} -V KERN_IDENT` =20 for dir in /bin /usr/bin /usr/local/bin; do - if [ -d "${SYSDIR}/.svn" -a -x "${dir}/svnversion" ] ; then + if [ ( -d "${SYSDIR}/.svn" -o -d "${SYSDIR}/../.svn" ) -a -x "${dir}/svnv= ersion" ] ; then svnversion=3D${dir}/svnversion break fi then? That should preserve current behavior for the case you & Jilles expressed concern about, while repairing the currently-broken default case. I believe it's in the interest of the project to have that default case working again (at least) in time for 9.0-RELEASE. Please. > .... I'm staying out of the "svnversion vs. svn info" branch of the thread. 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. --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk6mwN8ACgkQmprOCmdXAD0J3QCfZ9jBdAwMpeqfa++MvnDKpLK6 pY8Ani2IdkwZ0dIGhfjirpdEEwajsU05 =KfxJ -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 14:04:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 127D2106564A for ; Tue, 25 Oct 2011 14:04:49 +0000 (UTC) (envelope-from sub.mesa@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id CB34F8FC16 for ; Tue, 25 Oct 2011 14:04:48 +0000 (UTC) Received: by ywt32 with SMTP id 32so691929ywt.13 for ; Tue, 25 Oct 2011 07:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=GJu4VOhsYTIUuv6MSN8vmcd1YjyARyRqU0QEA88ax/g=; b=hR8Zat5GvHyoanrHNv5Jkkiv7iF7jGJER3bh1SvTdnHhXn2CSaYCF08bJ3RBFW85fF eA3i1B6FQpxTuOXHc0d8Cj6bfiU97S9w+aYdoWMfLgOms3oaBlrO1Z0czMWNLxP4avPw e/Y0/QvEQyFeb9tcECtW9xQa4FMXNDgCfy0js= MIME-Version: 1.0 Received: by 10.236.129.141 with SMTP id h13mr41200046yhi.120.1319549888083; Tue, 25 Oct 2011 06:38:08 -0700 (PDT) Received: by 10.236.179.67 with HTTP; Tue, 25 Oct 2011 06:38:08 -0700 (PDT) Date: Tue, 25 Oct 2011 15:38:08 +0200 Message-ID: From: Jason Edwards To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Problems with "ada0: Previously was known as ad6" functionality X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 14:04:49 -0000 Hello list, I'm working on ZFSguru, a FreeNAS-like distribution based on FreeBSD that focuses on NAS or Network Attached Storage functionality, sporting a web-interface et al. I've been building FreeBSD 9.0-RC1, and put together a LiveCD using my own scripts. It works, and boots fine in Virtualbox just like the other LiveCDs. Though I discovered a problem. It appears that some new functionality was put in 9.x to 'symlink' the new 'ada' devices using AHCI driver to the old-fashioned 'ad' (ATA) device names, probably to make migration of ATA to AHCI driver more convenient for users still using hardcoded devices in /etc/fstab (shame on you!). However, I suspect this is causing a nasty side-effect, because after having created a GPT partition with a ZFS pool on it, I cannot import it once I reboot fresh from the LiveCD, with 'zpool import' showing a corrupt pool. I've seen this before and generally it means that ZFS cannot read data or that GEOM does funny things. In this case, it could be that ad6 and ada0 both contain the same metadata, which somehow causes ZFS to go beserk. I would like to debug this issue, but for that I need to disable the 'ada0 to ad6' symlinking functionality. I've searched for a sysctl variable which can disable this behavior, but have not found it. Anyone can enlighten me how I can disable this behavior, so that I only get /dev/ada0 and no ad6? If the zpool import works again after that change, this would confirm my suspicions that this behavior is causing the zpool import command to fail. I'm using FreeBSD 9.0-RC1 fetched this morning as RELENG_9, uname: # uname -a FreeBSD zfsguru.bsd 9.0-RC1 FreeBSD 9.0-RC1 #0: Tue Oct 25 07:13:52 UTC 2011 ssh@zfsguru:/usr/obj/usr/src/sys/GENERIC amd64 Relevant command output: # dmesg | grep ad (..) ada0: Previously was known as ad6 # ls -l /dev/ad* lrwxr-xr-x 1 root wheel 4 Oct 25 13:21 /dev/ad6 -> ada0 lrwxr-xr-x 1 root wheel 6 Oct 25 13:21 /dev/ad6p1 -> ada0p1 crw-r----- 1 root operator 0, 73 Oct 25 13:20 /dev/ada0 crw-r----- 1 root operator 0, 75 Oct 25 13:20 /dev/ada0p1 # glabel status Name Status Components (..) gpt/testdisk N/A ada0p1 # zpool import pool: tank id: 17935188179790554412 state: FAULTED status: One or more devices contains corrupted data. action: The pool cannot be imported due to damaged devices or data. The pool may be active on another system, but can be imported using the '-f' flag. see: http://www.sun.com/msg/ZFS-8000-5E config: tank FAULTED corrupted data 15830803292687600194 UNAVAIL corrupted data Regards, Jason / sub.mesa From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 14:35:12 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0FA9106564A for ; Tue, 25 Oct 2011 14:35:12 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 598C28FC08 for ; Tue, 25 Oct 2011 14:35:12 +0000 (UTC) Received: by faar19 with SMTP id r19so828690faa.13 for ; Tue, 25 Oct 2011 07:35:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=G6XkcWY1d0isj/zxBewIjqSnZJF6jSud2x9f/79w/2M=; b=jnFIhWW6TXqWUMZkYoEzb7SKtyIVcxoVx2SliFLYpNDT//O1gZvjppcunakfjcQ2G6 ElbUtvAB2tZmeF740muEqZCKHtGgTeuo2IbzmVtGrHUjYFSD2XJPUpieoKUppJwnhXB1 Eyt+IqAUxwJoC0dG5wgLeyJAYcUB8V9rEfZQQ= Received: by 10.223.15.13 with SMTP id i13mr15168895faa.36.1319553311340; Tue, 25 Oct 2011 07:35:11 -0700 (PDT) Received: from ndenevsa.sf.moneybookers.net (g1.moneybookers.com. [217.18.249.148]) by mx.google.com with ESMTPS id t19sm2261120fac.0.2011.10.25.07.35.08 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 25 Oct 2011 07:35:09 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Nikolay Denev In-Reply-To: Date: Tue, 25 Oct 2011 17:35:08 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7FE0AE74-7C29-4DD0-8EBA-F2BB70F3CB97@gmail.com> References: To: Jason Edwards X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-current@freebsd.org Subject: Re: Problems with "ada0: Previously was known as ad6" functionality X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 14:35:13 -0000 On Oct 25, 2011, at 4:38 PM, Jason Edwards wrote: > Hello list, >=20 > I'm working on ZFSguru, a FreeNAS-like distribution based on FreeBSD > that focuses on NAS or Network Attached Storage functionality, > sporting a web-interface et al. >=20 > I've been building FreeBSD 9.0-RC1, and put together a LiveCD using my > own scripts. It works, and boots fine in Virtualbox just like the > other LiveCDs. Though I discovered a problem. >=20 > It appears that some new functionality was put in 9.x to 'symlink' the > new 'ada' devices using AHCI driver to the old-fashioned 'ad' (ATA) > device names, probably to make migration of ATA to AHCI driver more > convenient for users still using hardcoded devices in /etc/fstab > (shame on you!). However, I suspect this is causing a nasty > side-effect, because after having created a GPT partition with a ZFS > pool on it, I cannot import it once I reboot fresh from the LiveCD, > with 'zpool import' showing a corrupt pool. I've seen this before and > generally it means that ZFS cannot read data or that GEOM does funny > things. In this case, it could be that ad6 and ada0 both contain the > same metadata, which somehow causes ZFS to go beserk. >=20 > I would like to debug this issue, but for that I need to disable the > 'ada0 to ad6' symlinking functionality. I've searched for a sysctl > variable which can disable this behavior, but have not found it. > Anyone can enlighten me how I can disable this behavior, so that I > only get /dev/ada0 and no ad6? If the zpool import works again after > that change, this would confirm my suspicions that this behavior is > causing the zpool import command to fail. >=20 > I'm using FreeBSD 9.0-RC1 fetched this morning as RELENG_9, uname: > # uname -a > FreeBSD zfsguru.bsd 9.0-RC1 FreeBSD 9.0-RC1 #0: Tue Oct 25 07:13:52 > UTC 2011 ssh@zfsguru:/usr/obj/usr/src/sys/GENERIC amd64 >=20 >=20 > Relevant command output: >=20 > # dmesg | grep ad > (..) > ada0: Previously was known as ad6 >=20 > # ls -l /dev/ad* > lrwxr-xr-x 1 root wheel 4 Oct 25 13:21 /dev/ad6 -> ada0 > lrwxr-xr-x 1 root wheel 6 Oct 25 13:21 /dev/ad6p1 -> = ada0p1 > crw-r----- 1 root operator 0, 73 Oct 25 13:20 /dev/ada0 > crw-r----- 1 root operator 0, 75 Oct 25 13:20 /dev/ada0p1 >=20 > # glabel status > Name Status Components > (..) > gpt/testdisk N/A ada0p1 >=20 > # zpool import > pool: tank > id: 17935188179790554412 > state: FAULTED > status: One or more devices contains corrupted data. > action: The pool cannot be imported due to damaged devices or data. > The pool may be active on another system, but can be imported = using > the '-f' flag. > see: http://www.sun.com/msg/ZFS-8000-5E > config: >=20 > tank FAULTED corrupted data > 15830803292687600194 UNAVAIL corrupted data >=20 >=20 > Regards, > Jason / sub.mesa Hello Jason, I was struck with this problem too yesterday. I was able to import the pool by specifying the directory where zpool = should look for devices. Like : zpool import -d /dev/gptid Alternatively you can try putting kern.cam.ada.legacy_aliases=3D0 in = your /boot/loader.conf Regards, Nikolay From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 15:01:33 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 596CD1065675 for ; Tue, 25 Oct 2011 15:01:33 +0000 (UTC) (envelope-from sub.mesa@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0DAFE8FC12 for ; Tue, 25 Oct 2011 15:01:32 +0000 (UTC) Received: by vws11 with SMTP id 11so786839vws.13 for ; Tue, 25 Oct 2011 08:01:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=oLKxevUAFcpCp0tZ2OFgnCxNoJon27LTfW7KXOaoqCw=; b=L2Jjn8AOhlgcCzozb63cZ8hbyau0ODjVdBUBrHfncVUnxXO3E2pga52HuWl0yo5VKY BsNSbXyU8jZUFlKNm3O5P7zAYm/nbr3Q2NuxpZJn9pOyQqeGmBO4AxNA9OA4lDUZL38b rawOr+JqElnalf6QJVX1Ce+A72za0w8yfXorI= MIME-Version: 1.0 Received: by 10.182.110.1 with SMTP id hw1mr4400819obb.38.1319554892008; Tue, 25 Oct 2011 08:01:32 -0700 (PDT) Received: by 10.182.55.164 with HTTP; Tue, 25 Oct 2011 08:01:31 -0700 (PDT) In-Reply-To: <7FE0AE74-7C29-4DD0-8EBA-F2BB70F3CB97@gmail.com> References: <7FE0AE74-7C29-4DD0-8EBA-F2BB70F3CB97@gmail.com> Date: Tue, 25 Oct 2011 17:01:31 +0200 Message-ID: From: Jason Edwards To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: Problems with "ada0: Previously was known as ad6" functionality X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 15:01:33 -0000 On Tue, Oct 25, 2011 at 4:35 PM, Nikolay Denev wrote: > I was struck with this problem too yesterday. > I was able to import the pool by specifying the directory where zpool should look for devices. > Like : zpool import -d /dev/gptid > Alternatively you can try putting kern.cam.ada.legacy_aliases=0 in your /boot/loader.conf Hello Nikolay, Thanks for your reply! The kern.cam.ada.legacy_aliases=0 indeed makes the /dev/ad6 device go away. However, unlike I suspected, it did not solve the zpool import problem. It still lists my pool as corrupted. If I use the zpool import -d /dev/gpt as you suggested, the pool displays as ONLINE and I can import it just fine. Using -d /dev works too, so I guess this works fine as a workaround. Still, can I assume this is a bug that will be fixed in time before 9.0-RELEASE ? Regards, Jason From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 15:01:34 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D73EF1065673 for ; Tue, 25 Oct 2011 15:01:34 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from smtp.smtpout.orange.fr (smtp02.smtpout.orange.fr [80.12.242.124]) by mx1.freebsd.org (Postfix) with ESMTP id 527648FC14 for ; Tue, 25 Oct 2011 15:01:33 +0000 (UTC) Received: from localhost ([92.162.133.50]) by mwinf5d56 with ME id p31V1h00F15Q9dY0331Vtc; Tue, 25 Oct 2011 17:01:33 +0200 X-ME-engine: default Message-ID: <4EA6CF49.7030603@orange.fr> Date: Tue, 25 Oct 2011 17:01:29 +0200 From: Claude Buisson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.23) Gecko/20110928 Thunderbird/3.1.15 MIME-Version: 1.0 To: Daniel O'Connor References: <4EA68C47.2070908@orange.fr> <4EA69B17.6020607@orange.fr> <20111025125423.GA88097@icarus.home.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: can audio CDs be played with ATA_CAM ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 15:01:34 -0000 On 10/25/2011 15:08, Daniel O'Connor wrote: > > On 25/10/2011, at 23:24, Jeremy Chadwick wrote: >>> These may not be the same problem, but I think they are related (a not so well >>> documented change in the kerm interface). >> >> You want atapicam(4). This is not the same thing as "options ATA_CAM". >> See /sys/conf/NOTES. >> >> Whether or not it works with audio CDs is unknown to me. > > atapicam is a bridge for the old ATA code to put ATAPI devices _only_ on CAM (as well as the ATA infrastructure). Hence they appear as /dev/cd0 and so on. > As I said: I know it (after 16 years of FreeBSD use ...) > ATA_CAM puts _all_ ATA devices on CAM, so you should be able to access your audio CD that way. > > I just tried and it ripped a CD fine using cdparanoia and cdcontrol seemed to play it OK (although I don't have the analogue output of this drive hooked up to the audio system). > I just played a CD with cdcontrol on a ATA_CAMed 9.0 system from Sept 25 (hooked to the audio), but do not know what is proven that way: VLC see the tracks of the audio CD and may even identifiy them with cddb, but cannot play them (see the error messages). So my current conclusion (?) is that the problem lies with the userland librairies (cdda, ..) > This is not to say that there isn't a bug in the ATA_CAM code :) > I will do another test on 9.0 (after rebuilding the ports), and eventually get rid of ATA_CAM and wait (im)patiently for a knowledgeable one to have a look at the problem. If this is a real problem, I may hope that it will appear after the release of 9.0 and its use in the real world. > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > Claude Buisson From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 15:06:55 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A86D106566B for ; Tue, 25 Oct 2011 15:06:55 +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 CAFDE8FC19 for ; Tue, 25 Oct 2011 15:06:54 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 84D027300A; Tue, 25 Oct 2011 17:06:22 +0200 (CEST) Date: Tue, 25 Oct 2011 17:06:22 +0200 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20111025150622.GA7462@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: getting the cpuid for a userspace process ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 15:06:55 -0000 as the subject says... is there any way to get the current CPU id for a userspace process (of course, valid only at the time the function is called as the process might be arbitrarily moved while it runs) thanks luigi From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 16:26:00 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EEA4106566C; Tue, 25 Oct 2011 16:26:00 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id D17A28FC13; Tue, 25 Oct 2011 16:25:59 +0000 (UTC) Received: from mart.js.berklix.net (pD9FBECF9.dip.t-dialin.net [217.251.236.249]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id p9PG9qCv078754; Tue, 25 Oct 2011 16:09:54 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id p9PG9bvC069855; Tue, 25 Oct 2011 18:09:39 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id p9PG9P8R035866; Tue, 25 Oct 2011 16:09:31 GMT (envelope-from jhs@fire.js.berklix.net) Message-Id: <201110251609.p9PG9P8R035866@fire.js.berklix.net> To: "O. Hartmann" From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Tue, 25 Oct 2011 12:48:12 +0200." <4EA693EC.1070602@zedat.fu-berlin.de> Date: Tue, 25 Oct 2011 18:09:25 +0200 Sender: jhs@berklix.com Cc: FreeBSD Current , freebsd-questions@freebsd.org Subject: Re: The future of FreeBSD at Yahoo! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 16:26:00 -0000 Hi, Reference: > From: "O. Hartmann" > Date: Tue, 25 Oct 2011 12:48:12 +0200 > Message-id: <4EA693EC.1070602@zedat.fu-berlin.de> "O. Hartmann" wrote: > The press in Germania is full of some statements, that Google is about > to overtake Yahoo!. As far as I know, Yahoo! is one of the more popular > and bigger, if not the biggest and last stronghold of a FreeBSD driven > infrastructure. Despite the fact that even Google funded lots of coding > for FreeBSD, I had the impression that Yahoo! might be one of the > biggest contributor. And not to mention the psychological effect of > hearing that such a company is utilizing a project like FreeBSD for > potential newcomers in the business. > > So, what is about the future of FreeBSD? Does FreeBSD have a site where > all the goods that has been first invented by the FreeBSD/BSD folks or > all the things that are thought about to come in future are > shown/listed? Crawling the mailing lists is a really nasty work. > > Thanks for having patience, Try advocacy@freebsd.org Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; Indent with "> "; Cumulative like a play script. Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 17:54:00 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 475C0106566B for ; Tue, 25 Oct 2011 17:54:00 +0000 (UTC) (envelope-from rdeiriar@spock.cl) Received: from mail.spock.cl (enteljoven2.enteljoven.cl [164.77.63.23]) by mx1.freebsd.org (Postfix) with ESMTP id AD9058FC19 for ; Tue, 25 Oct 2011 17:53:59 +0000 (UTC) Received: from t61.deiriarte.local (190-21-139-32.baf.movistar.cl [190.21.139.32]) (AUTH: PLAIN rdeiriar@spock.cl, TLS: TLSv1/SSLv3, 256bits, CAMELLIA256-SHA) by mail.spock.cl with ESMTPSA; Tue, 25 Oct 2011 14:44:04 -0300 id 000001AB.000000004EA6F564.000159EE Message-ID: <4EA6F4EC.3010403@spock.cl> Date: Tue, 25 Oct 2011 14:42:04 -0300 From: Roberto de Iriarte User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0) Gecko/20110930 Thunderbird/7.0 MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: LSI 9240-8i (IBM M1015) MegaRaid support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 17:54:00 -0000 Hi, Is there any expectancy of getting this piece of hardware (or it's IBM silbing, the M1015) working in MegaRaid mode, without having to reflash the card to IT mode. The reason of this request is that the UEFI Bios on the IBM XSeries 3550M3 refuses to properly initialize the controller if reflashed with the IT mode firmware, thus making it unusable. A search on LSI's website for a driver that supports 8-Stable or 9 did not produce any results Many thanks and best regards, Roberto From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 18:05:47 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C48DF106564A for ; Tue, 25 Oct 2011 18:05:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9D22D8FC18 for ; Tue, 25 Oct 2011 18:05:47 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 53A5646B0D; Tue, 25 Oct 2011 14:05:47 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DF7128A02E; Tue, 25 Oct 2011 14:05:46 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 25 Oct 2011 13:42:45 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <20111025150622.GA7462@onelab2.iet.unipi.it> In-Reply-To: <20111025150622.GA7462@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110251342.45194.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 25 Oct 2011 14:05:47 -0400 (EDT) Cc: Luigi Rizzo Subject: Re: getting the cpuid for a userspace process ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 18:05:47 -0000 On Tuesday, October 25, 2011 11:06:22 am Luigi Rizzo wrote: > as the subject says... is there any way to get the current > CPU id for a userspace process (of course, > valid only at the time the function is called as the > process might be arbitrarily moved while it runs) Not from userland, no. On x86 you can use cpuid to fetch the APIC ID, but that does not map 1:1 to FreeBSD cpu IDs. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 18:09:14 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 366031065676; Tue, 25 Oct 2011 18:09:14 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id E7F5B8FC0A; Tue, 25 Oct 2011 18:09:13 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id CF48E5DAD; Tue, 25 Oct 2011 18:09:12 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id p9PI9C0R099484; Tue, 25 Oct 2011 18:09:12 GMT (envelope-from phk@phk.freebsd.dk) To: John Baldwin From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 25 Oct 2011 13:42:45 -0400." <201110251342.45194.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Date: Tue, 25 Oct 2011 18:09:12 +0000 Message-ID: <99483.1319566152@critter.freebsd.dk> Cc: freebsd-current@freebsd.org, Luigi Rizzo Subject: Re: getting the cpuid for a userspace process ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 18:09:14 -0000 In message <201110251342.45194.jhb@freebsd.org>, John Baldwin writes: >On Tuesday, October 25, 2011 11:06:22 am Luigi Rizzo wrote: >> as the subject says... is there any way to get the current >> CPU id for a userspace process (of course, >> valid only at the time the function is called as the >> process might be arbitrarily moved while it runs) > >Not from userland, no. On x86 you can use cpuid to fetch the APIC ID, but >that does not map 1:1 to FreeBSD cpu IDs. How does JEmalloc do it ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 18:20:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF25010656A8; Tue, 25 Oct 2011 18:20:25 +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 580408FC13; Tue, 25 Oct 2011 18:20:25 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p9PIK05Z012116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Oct 2011 21:20:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id p9PIK0kv094645; Tue, 25 Oct 2011 21:20:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id p9PIK0VT094644; Tue, 25 Oct 2011 21:20:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 25 Oct 2011 21:20:00 +0300 From: Kostik Belousov To: John Baldwin Message-ID: <20111025182000.GU50300@deviant.kiev.zoral.com.ua> References: <20111025150622.GA7462@onelab2.iet.unipi.it> <201110251342.45194.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1vbNym9KGxCl/IZ3" Content-Disposition: inline In-Reply-To: <201110251342.45194.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org, Luigi Rizzo Subject: Re: getting the cpuid for a userspace process ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 18:20:26 -0000 --1vbNym9KGxCl/IZ3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 25, 2011 at 01:42:45PM -0400, John Baldwin wrote: > On Tuesday, October 25, 2011 11:06:22 am Luigi Rizzo wrote: > > as the subject says... is there any way to get the current > > CPU id for a userspace process (of course, > > valid only at the time the function is called as the > > process might be arbitrarily moved while it runs) >=20 > Not from userland, no. On x86 you can use cpuid to fetch the APIC ID, bu= t=20 > that does not map 1:1 to FreeBSD cpu IDs. Not quite so. The kern.proc sysctls do provide oncpu and lastcpu information, which, I believe, is used by top. But this is very slow way to get cpu id. --1vbNym9KGxCl/IZ3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk6m/c8ACgkQC3+MBN1Mb4j1dgCg6hOi9CjFs6lPOrYRDQ84Ti5z BGgAoNh8CTsfH2Jw+7JXvGg4/dzyzkXz =pMon -----END PGP SIGNATURE----- --1vbNym9KGxCl/IZ3-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 18:43:29 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E3B01065674; Tue, 25 Oct 2011 18:43:29 +0000 (UTC) (envelope-from miwi.freebsd@googlemail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id 2231B8FC1C; Tue, 25 Oct 2011 18:43:28 +0000 (UTC) Received: by pzk4 with SMTP id 4so4664580pzk.3 for ; Tue, 25 Oct 2011 11:43:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=sender:from:content-type:content-transfer-encoding:subject:date :message-id:cc:to:mime-version:x-mailer; bh=aMX/c+kyGF3ezo8Lw0JLCwpOBDH2fx/cq4OJry4PmqI=; b=IX8SyvmQqMUUqdAmnuqEyJ/4RkLQyWinAmyzxfkJalLCxKaC++IKzwxiWm4wko6dgH lOZ2vHWt4Kp8W/ncuNa8NiowB/wBWq92alP+46V9AmvKJh+0Borgc748eYgxvk/cjeMl BBAnGj1V4dCcZFEpSMCFADTAranGpF2qYguY0= Received: by 10.68.39.231 with SMTP id s7mr58288759pbk.33.1319566636113; Tue, 25 Oct 2011 11:17:16 -0700 (PDT) Received: from [192.168.0.103] ([175.139.105.2]) by mx.google.com with ESMTPS id g1sm9012015pbv.2.2011.10.25.11.17.12 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 25 Oct 2011 11:17:14 -0700 (PDT) Sender: Martin Wilke From: Martin Wilke Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Oct 2011 02:15:09 +0800 Message-Id: <8453E2A2-3219-4FAA-98CE-2F9D66EA1C39@FreeBSD.org> To: antik@bsd.ee Mime-Version: 1.0 (Apple Message framework v1251) X-Mailer: Apple Mail (2.1251) Cc: current@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: gmirror 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, 25 Oct 2011 18:43:29 -0000 Hi, I face the same error since upgrade from 8.2 to 9.0RC1, is there any way = to fix that? thx Martin= From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 19:15:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 410A8106566B for ; Tue, 25 Oct 2011 19:15:08 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email2.allantgroup.com (email2.emsphone.com [199.67.51.116]) by mx1.freebsd.org (Postfix) with ESMTP id 9542D8FC12 for ; Tue, 25 Oct 2011 19:15:07 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email2.allantgroup.com (8.14.4/8.14.4) with ESMTP id p9PJ3beH096992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 25 Oct 2011 14:03:38 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.5/8.14.5) with ESMTP id p9PJ3bcX092540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 25 Oct 2011 14:03:37 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.5/8.14.5/Submit) id p9PIhOLr011636; Tue, 25 Oct 2011 13:43:24 -0500 (CDT) (envelope-from dan) Date: Tue, 25 Oct 2011 13:43:24 -0500 From: Dan Nelson To: Poul-Henning Kamp Message-ID: <20111025184323.GH93709@dan.emsphone.com> References: <201110251342.45194.jhb@freebsd.org> <99483.1319566152@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <99483.1319566152@critter.freebsd.dk> X-OS: FreeBSD 8.2-STABLE User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.2 at email2.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (email2.allantgroup.com [199.67.51.78]); Tue, 25 Oct 2011 14:03:38 -0500 (CDT) X-Scanned-By: MIMEDefang 2.68 on 199.67.51.78 Cc: freebsd-current@freebsd.org, Luigi Rizzo Subject: Re: getting the cpuid for a userspace process ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 19:15:08 -0000 In the last episode (Oct 25), Poul-Henning Kamp said: > In message <201110251342.45194.jhb@freebsd.org>, John Baldwin writes: > >On Tuesday, October 25, 2011 11:06:22 am Luigi Rizzo wrote: > >> as the subject says... is there any way to get the current CPU id for a > >> userspace process (of course, valid only at the time the function is > >> called as the process might be arbitrarily moved while it runs) > > > >Not from userland, no. On x86 you can use cpuid to fetch the APIC ID, > >but that does not map 1:1 to FreeBSD cpu IDs. > > How does JEmalloc do it ? Looking at the source, it just determines the number of CPUs, creates a number of arenas proportional to that, and assigns threads to an arena. If contention on a particular arena gets bad, the thread gets moved to another areana (see everything inside "#ifdef MALLOC_BALANCE" blocks). -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 19:27:15 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E52CD106566B; Tue, 25 Oct 2011 19:27:15 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5C59B8FC18; Tue, 25 Oct 2011 19:27:14 +0000 (UTC) Received: by eyd10 with SMTP id 10so1162894eyd.13 for ; Tue, 25 Oct 2011 12:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ujs16e0o+mvx6c0enn/0EI9etMYUuSgEHGd0HPkmvao=; b=AygFQXRaf9cK4gg5fjzPyvgQk+ZaEd5UTIu9xBgv5+WsfcJuhk5gmgyz6p/dmrFNTl Y2f30dBQOhuCJlID6UPRDc0Sfa31TyJSnMiqG9zrCw8YE09iQtalRlUzljkfSw771AHA khgy+kFF4R2c4i1b02wLa8z6X/xVKO12jaOA8= MIME-Version: 1.0 Received: by 10.182.111.70 with SMTP id ig6mr4608725obb.6.1319570833436; Tue, 25 Oct 2011 12:27:13 -0700 (PDT) Received: by 10.182.122.33 with HTTP; Tue, 25 Oct 2011 12:27:13 -0700 (PDT) In-Reply-To: <8453E2A2-3219-4FAA-98CE-2F9D66EA1C39@FreeBSD.org> References: <8453E2A2-3219-4FAA-98CE-2F9D66EA1C39@FreeBSD.org> Date: Tue, 25 Oct 2011 12:27:13 -0700 Message-ID: From: Garrett Cooper To: Martin Wilke Content-Type: text/plain; charset=ISO-8859-1 Cc: antik@bsd.ee, current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: gmirror 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, 25 Oct 2011 19:27:16 -0000 On Tue, Oct 25, 2011 at 11:15 AM, Martin Wilke wrote: > Hi, > > I face the same error since upgrade from 8.2 to 9.0RC1, is there any way to fix that? errno == 19 => ENODEV -- so the question is, what device is missing? -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 19:43:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6E40106564A; Tue, 25 Oct 2011 19:43:49 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by mx1.freebsd.org (Postfix) with ESMTP id 446C78FC08; Tue, 25 Oct 2011 19:43:48 +0000 (UTC) Received: by bkas6 with SMTP id s6so1367524bka.17 for ; Tue, 25 Oct 2011 12:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0eRWoQQ7XxGDmGQE78aSqU7BzkC9KQV3Usbj0s7H9dw=; b=jNYCBN181i1rLDezKYVEh4AWpwB1ihuidL8mxucUyQFMDQSYpBr51Bpafii6bUDylu Y5dtwGiY7Gx44Fgr/jMLsD+XdS/3KMfnv/F+y9qKdjSfdBWIaTc5BU0P5rr3y6imzfN2 kk5e90GGgq3HbnfrXE1jkDm54JZeO6336qwMc= MIME-Version: 1.0 Received: by 10.204.7.199 with SMTP id e7mr21572747bke.40.1319571827833; Tue, 25 Oct 2011 12:43:47 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.204.39.12 with HTTP; Tue, 25 Oct 2011 12:43:47 -0700 (PDT) In-Reply-To: <20111025140000.GA8559@albert.catwhisker.org> References: <20111020114844.GK59810@albert.catwhisker.org> <20111020122121.GL59810@albert.catwhisker.org> <201110211636.05917.jhb@freebsd.org> <20111025140000.GA8559@albert.catwhisker.org> Date: Tue, 25 Oct 2011 12:43:47 -0700 X-Google-Sender-Auth: mApIoKEwOyvA-XaxO-mY_z0Q_Fo Message-ID: From: Craig Rodrigues To: David Wolfskill Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: sys/conf/newvers.sh vs. subversion-1.7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 19:43:50 -0000 On Tue, Oct 25, 2011 at 7:00 AM, David Wolfskill wro= te: > Index: sys/conf/newvers.sh > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/conf/newvers.sh (revision 226724) > +++ sys/conf/newvers.sh (working copy) > @@ -88,7 +88,7 @@ > =A0i=3D`${MAKE:-make} -V KERN_IDENT` > > =A0for dir in /bin /usr/bin /usr/local/bin; do > - =A0 =A0 =A0 if [ -d "${SYSDIR}/.svn" -a -x "${dir}/svnversion" ] ; then > + =A0 =A0 =A0 if [ ( -d "${SYSDIR}/.svn" -o -d "${SYSDIR}/../.svn" ) -a -= x "${dir}/svnversion" ] ; then > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0svnversion=3D${dir}/svnversion > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break > =A0 =A0 =A0 =A0fi > > then? =A0That should preserve current behavior for the case you & Jilles > expressed concern about, while repairing the currently-broken default > case. > > I believe it's in the interest of the project to have that default > case working again (at least) in time for 9.0-RELEASE. > > Please. > >> .... > > I'm staying out of the "svnversion vs. svn info" branch of the thread. > > Peace, > david > -- > David H. Wolfskill =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0david@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. Hi, I know that Doug disagreed with me on this, but I think this would be easier to implement in the short term: for dir in /bin /usr/bin /usr/local/bin; do if [ -x "${dir}/svnversion" -a -x "${dir}/svn" ]; then ${dir}/svn info ${SRCDIR}/sys > /dev/null 2>&1 if [ $? -eq 0 ]; then svnversion=3D${dir}/svnversion fi fi done The alternative would be to run ${dir}/svnversion, and check the output of that command, making sure that the output starts with a number. --=20 Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 19:59:13 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9FA01065673 for ; Tue, 25 Oct 2011 19:59:13 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5C0A78FC15 for ; Tue, 25 Oct 2011 19:59:13 +0000 (UTC) Received: by qadz32 with SMTP id z32so1121948qad.13 for ; Tue, 25 Oct 2011 12:59:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3ss7MHvYpOLoMxjx04EXwF9yJQVYC5DXOuuZIWw9bsY=; b=RYaFEDsa27PGU07+rUbH7pHYPdvBSscGlU8SqWAXqjrEBuRtPzsUjhsZ4ODqLronmE 9GDGQiX9M0DOmO3On6Ow4W2PZ1S1h+/LVS4840pcs10IOvhKV4bWDfn7++SKs+5K/eBg qHEBC6reqUg3uKncOIQoiLEcwS3p2Q/ayoYgs= MIME-Version: 1.0 Received: by 10.224.173.148 with SMTP id p20mr22823723qaz.76.1319572752646; Tue, 25 Oct 2011 12:59:12 -0700 (PDT) Received: by 10.224.19.212 with HTTP; Tue, 25 Oct 2011 12:59:12 -0700 (PDT) In-Reply-To: References: Date: Tue, 25 Oct 2011 15:59:12 -0400 Message-ID: From: Mehmet Erol Sanliturk To: Warren Block Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Current Subject: Re: FreeBSD 9.0 RC1 USB Mouse and Keyboard X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 19:59:13 -0000 On Mon, Oct 24, 2011 at 7:46 PM, Warren Block wrote: > On Sun, 23 Oct 2011, Mehmet Erol Sanliturk wrote: > > I have installed FreeBSD 9.0 RC1 . >> >> During installation and boots , and ( as root ) console mode , both USB >> keyboard and mouse are working . >> >> When a graphical desktop ( Fluxbox , Gnome , or KDE ) is started , both of >> them are becoming frozen . >> Detach and attach of mouse are detected , but input is not possible . >> PS/2 mouse is also not working . >> I did not check PS/2 keyboard . >> Only Ctrl-Alt-F1 is discontinuing graphical display , and Ctrl-C is >> returning to root prompt . >> >> KDE is staying as it is after displaying of hard disk symbol and then it >> is >> waiting there . >> Gnome is displaying all the parts , but no input possibility . >> Fluxbox is displaying its window , but no input possibility . >> >> It seems that X is NOT able to register dbus related parts ( understood >> from >> messages left on the screen after discontinuation ) . >> >> On the same computer , I have installed Fedora 15 and everything is >> working >> as expected , means there is no any hardware problem . >> > > The same symptoms happen if X is configured to use hald for input device > detection but hald is not running. The easy way to test that is to put > Option "AutoAddDevices" "Off" > in the ServerLayout section. > Also by Benjamin Kaduk : Has this computer successfully run other versions of FreeBSD with X? I seem to recall there can be odd interactions with hald, xorg.conf, and others. Some googling brings up http://www.wonkity.com/~wblock/docs/html/aei.html which seems to cover many of the relevant issues. -Ben Kaduk -------------------------- After the above messages , on the same computer , I have installed the FreeBSD 9.0 RC1 amd64 again . I have generated an xorg.conf file . Into the xorg.conf file and ServerLayout part , I have inserted Option "AutoAddDevices" "Off" The USB Mouse and Keyboard , Fluxbox started to work as expected in the graphical mode under X . Without the above statement about Option , the error message is : (EE) config/hal : couldn't initialise context . unknown error (null) In FreeBSD 9.0 RC1 i386 , such a step is NOT necessary . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 20:07:50 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id D7175106564A for ; Tue, 25 Oct 2011 20:07:50 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 8D6AE2008B7; Tue, 25 Oct 2011 20:07:47 +0000 (UTC) Message-ID: <4EA71713.3020404@FreeBSD.org> Date: Tue, 25 Oct 2011 13:07:47 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: Craig Rodrigues References: <20111020114844.GK59810@albert.catwhisker.org> <20111020122121.GL59810@albert.catwhisker.org> <201110211636.05917.jhb@freebsd.org> <20111025140000.GA8559@albert.catwhisker.org> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: multipart/mixed; boundary="------------090502000102020509020606" Cc: freebsd-current@freebsd.org Subject: Re: sys/conf/newvers.sh vs. subversion-1.7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 20:07:50 -0000 This is a multi-part message in MIME format. --------------090502000102020509020606 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/25/2011 12:43, Craig Rodrigues wrote: > I know that Doug disagreed with me on this, I didn't "disagree" with you. I pointed out that there is absolutely no reason to run 2 separate commands. To put it more bluntly, I pointed out why your suggestion is a bad idea. I'm sorry to be so blunt but I'm getting really tired of people who can't let go of bad ideas even when it's demonstrated conclusively why they are bad. :) > The alternative would be to run ${dir}/svnversion, and check the output > of that command, making sure that the output starts with a number. The attached implements that, and is almost certainly the right way to go. It would be nice if someone could test it, and better if someone else could commit it. I swore after the last time that I'd stay away from that file precisely because of all the bikeshed stupidity that this issue creates. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ --------------090502000102020509020606 Content-Type: text/plain; name="newvers.sh.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="newvers.sh.diff" Index: newvers.sh =================================================================== --- newvers.sh (revision 226474) +++ newvers.sh (working copy) @@ -88,7 +88,7 @@ i=`${MAKE:-make} -V KERN_IDENT` for dir in /bin /usr/bin /usr/local/bin; do - if [ -d "${SYSDIR}/.svn" -a -x "${dir}/svnversion" ] ; then + if [ -x "${dir}/svnversion" ] ; then svnversion=${dir}/svnversion break fi @@ -99,8 +99,12 @@ done if [ -n "$svnversion" ] ; then - echo "$svnversion" - svn=" r`cd ${SYSDIR} && $svnversion`" + echo "$svnversion" + svn=`cd ${SYSDIR} && $svnversion` + case "$svn" in + [0-9]*) svn=" r${svn}" ;; + *) unset svn ;; + esac fi if [ -n "$git_cmd" ] ; then --------------090502000102020509020606-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 20:17:56 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 041B21065670 for ; Tue, 25 Oct 2011 20:17:56 +0000 (UTC) (envelope-from jkuczewski@bnl.gov) Received: from smtpgw.bnl.gov (smtpgw.bnl.gov [130.199.3.132]) by mx1.freebsd.org (Postfix) with ESMTP id BB7DF8FC18 for ; Tue, 25 Oct 2011 20:17:55 +0000 (UTC) X-BNL-policy-q: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAIkYp06Cx8Kg/2dsb2JhbAAMN6wQAQEBBAECLwEFKBQEARALGAkNAQgPCQMCAQIBFiEBDQYNAQUCAQGIBLRehUIBgxMEkW+UFQ X-IronPort-AV: E=Sophos;i="4.69,405,1315195200"; d="scan'208";a="149297517" Received: from blc.nsls.bnl.gov (HELO [127.0.0.1]) ([130.199.194.160]) by smtpgw.sec.bnl.local with ESMTP; 25 Oct 2011 16:17:54 -0400 Message-ID: <4EA71997.3040508@bnl.gov> Date: Tue, 25 Oct 2011 16:18:31 -0400 From: "J. Kuczewski" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Vin=EDcius_Zavam?= References: <4EA63A1B.9040407@bnl.gov> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current Subject: Re: Slow load time to /boot/loader (3rd stage loader) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 20:17:56 -0000 On 10/25/2011 08:15 AM, Vinícius Zavam wrote: > 2011/10/25 J. Kuczewski: >> Hi all, >> >> I have recently installed 9.0-RC1 on my Thinkpad X201 and have noticed >> severe (~20 mins) latency to get to the third stage bootloader >> (/boot/loader). This is system triple booted with Windows 7 and Arch Linux >> using the GRUB 2 bootmanager. FreeBSD is not on a extended partition, if it >> matters. I have tested two BIOS disk configurations, one with AHCI and the >> other with IDE compatibility mode. IDE mode is comparatively faster, but >> still slower than expected (~3 mins). To see if this was a regression, I >> installed 8.2, and it has the same exact effect. Booting off of USB stick >> loads fine (e.g. the installer). The following is my notes with the >> different BIOS configurations with a link to the verbose dmesgs for each... >> >> With AHCI enabled: >> o dmesg output: >> http://dl.dropbox.com/u/45307545/dmesg_logs/dmesg_ahci.log >> o Timeline: >> ~05 mins - Loading /boot/default/loader.conf appears. >> ~16 mins - /boot/kernel/kernel displayed. >> ~20 mins - Welcome to FreeBSD boot prompt. >> >> With IDE compatibility enabled: >> o dmesg output: >> http://dl.dropbox.com/u/45307545/dmesg_logs/dmesg_ide.log >> o Timeline: >> ~02 mins - Loading /boot/default/loader.conf and /boot/kernel/kernel >> is displayed at once. >> ~03 mins - Welcome to FreeBSD boot prompt is displayed. >> >> After the boot prompt, startup is normal with no slowdowns to the login >> prompt. >> >> --- >> Current BIOS and ECP versions (output from Linux): >> --- >> # dmidecode -s bios-version >> 6QET52WW (1.22) >> # dmidecode -t 11 >> # dmidecode 2.11 >> SMBIOS 2.6 present. >> >> Handle 0x0027, DMI type 11, 5 bytes >> OEM Strings >> String 1: IBM ThinkPad Embedded Controller -[6QHT30WW-1.11 ]- >> >> --- >> FreeBSD GRUB2 entry: >> --- >> menuentry "FreeBSD 9.0-RC1" { >> insmod ufs2 >> set root=(hd0,3) >> chainloader +1 >> } >> >> Any guidance to determine the slow down of this loading problem would be >> great. >> >> Thank you for your time... >> >> Cheers, >> -John Kuczewski > i've got something like this. check it out: > http://lists.freebsd.org/pipermail/freebsd-stable/2010-January/054551.html > > i remembered this issue when reading your e-mail this morning. > unfortunately i couldn't fix the issue. > just saw the answer from Paulo[1] today (LOL).. but you, John, are > using "the same" entry with grub2.. so.... sadness ;-( > > nowadays i'm using 10.0current with my asus 1005pe (eeepc) and > everything runs like a charm. i still have the same pavilion; maybe > one day it will run freebsd again (even if it needs 30min to boot)<3 > > [1] http://lists.freebsd.org/pipermail/freebsd-stable/2010-March/055733.html > > Thanks for the links. I have a spare disk that I'll make just for FreeBSD, just to see if this is a partitioning problem with the BTX loader, or something BIOS related. Just to note, it doesn't matter if I use GRUB2 or FreeBSD's boot manager, both were tested. Thanks for the idea. Cheers, -John Kuczewski From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 20:23:56 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 394B8106564A; Tue, 25 Oct 2011 20:23:56 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 95DDE8FC15; Tue, 25 Oct 2011 20:23:55 +0000 (UTC) Received: by bkbzt4 with SMTP id zt4so1021444bkb.13 for ; Tue, 25 Oct 2011 13:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=FyjqL8YI7OPXqAt4Tc0LsxMuUTD3G6DF5Iyrs9ZQd9M=; b=te8QumCCsM6jbhOqityfBtacKaS66kVyQjPqBofVfwNXJ8R8eLo8xvEVGG977a5Kut OOogquX2X7gZUZdUQVi7hmNTkLuXR142khVG9L9EywxUCPFndAVUC1F8lWyxcoJlTVlR FHZNKRCH2sZruWjqiaulLx1qPVBeASI6JHITA= MIME-Version: 1.0 Received: by 10.204.50.88 with SMTP id y24mr22127349bkf.53.1319574234557; Tue, 25 Oct 2011 13:23:54 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.204.39.12 with HTTP; Tue, 25 Oct 2011 13:23:53 -0700 (PDT) In-Reply-To: <4EA71713.3020404@FreeBSD.org> References: <20111020114844.GK59810@albert.catwhisker.org> <20111020122121.GL59810@albert.catwhisker.org> <201110211636.05917.jhb@freebsd.org> <20111025140000.GA8559@albert.catwhisker.org> <4EA71713.3020404@FreeBSD.org> Date: Tue, 25 Oct 2011 13:23:53 -0700 X-Google-Sender-Auth: jcrSj7wLUYgu4NGo1njs4bscdS0 Message-ID: From: Craig Rodrigues To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: sys/conf/newvers.sh vs. subversion-1.7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 20:23:56 -0000 On Tue, Oct 25, 2011 at 1:07 PM, Doug Barton wrote: > > I didn't "disagree" with you. I pointed out that there is absolutely no > reason to run 2 separate commands. To put it more bluntly, I pointed out > why your suggestion is a bad idea. Hmmm, sounds like a disagreement to me. I have read your concerns, but I don't fully understand why invoking "svn info ${SRCDIR}/sys", ignoring the output of "svn info", and then just checking its return status is a bad idea. Using "svnversion" further down in the script if "svn info" succeeds is all that I was recommending. Anyways, I am fine with the patch which you propose. The only possible issue could be in future, if svn switches from using decimal revision numbers to numbers which are in hexadecimal, base64, etc. However, that is not currently the case, and if it does happen in future, we can change the script accordingly. -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 20:41:34 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31242106564A for ; Tue, 25 Oct 2011 20:41:34 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id DC97D8FC1A for ; Tue, 25 Oct 2011 20:41:33 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id p9PKfWBL082206; Tue, 25 Oct 2011 14:41:32 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id p9PKfWAp082203; Tue, 25 Oct 2011 14:41:32 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Tue, 25 Oct 2011 14:41:32 -0600 (MDT) From: Warren Block To: Mehmet Erol Sanliturk In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-902635197-1364886086-1319575292=:82199" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Tue, 25 Oct 2011 14:41:33 -0600 (MDT) Cc: FreeBSD Current Subject: Re: FreeBSD 9.0 RC1 USB Mouse and Keyboard X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 20:41:34 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---902635197-1364886086-1319575292=:82199 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT On Tue, 25 Oct 2011, Mehmet Erol Sanliturk wrote: > Also by Benjamin Kaduk : > > > Has this computer successfully run other versions of FreeBSD with X? > I seem to recall there can be odd interactions with hald, xorg.conf, and others. Some googling brings up http://www.wonkity.com/~wblock/docs/html/aei.html which seems to cover many of > the relevant issues. > > -Ben Kaduk > > > -------------------------- > > After the above messages ,  > on the same computer , I have installed the FreeBSD 9.0 RC1 amd64 again . > > I have generated an xorg.conf file . > > Into the xorg.conf  file and ServerLayout part , I have inserted  > >  Option "AutoAddDevices"  "Off" > > The USB Mouse and Keyboard , Fluxbox  started to work as expected in the graphical mode  under X . > > > Without the above statement about Option , the error message is : > > (EE) config/hal : couldn't initialise context . unknown error (null) This line appears if x11-servers/xorg-server was built with the HAL option enabled. > In FreeBSD 9.0 RC1 i386 , such a step is NOT necessary . They should be the same. On i386, maybe xorg-server was built with the HAL option disabled? ---902635197-1364886086-1319575292=:82199-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 20:45:50 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB9BE1065674 for ; Tue, 25 Oct 2011 20:45:50 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C3D178FC1A for ; Tue, 25 Oct 2011 20:45:50 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 5B6A946B0C; Tue, 25 Oct 2011 16:45:50 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DB9568A02F; Tue, 25 Oct 2011 16:45:49 -0400 (EDT) From: John Baldwin To: "Poul-Henning Kamp" Date: Tue, 25 Oct 2011 14:54:00 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <99483.1319566152@critter.freebsd.dk> In-Reply-To: <99483.1319566152@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110251454.00471.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 25 Oct 2011 16:45:50 -0400 (EDT) Cc: freebsd-current@freebsd.org, Luigi Rizzo Subject: Re: getting the cpuid for a userspace process ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 20:45:51 -0000 On Tuesday, October 25, 2011 2:09:12 pm Poul-Henning Kamp wrote: > In message <201110251342.45194.jhb@freebsd.org>, John Baldwin writes: > >On Tuesday, October 25, 2011 11:06:22 am Luigi Rizzo wrote: > >> as the subject says... is there any way to get the current > >> CPU id for a userspace process (of course, > >> valid only at the time the function is called as the > >> process might be arbitrarily moved while it runs) > > > >Not from userland, no. On x86 you can use cpuid to fetch the APIC ID, but > >that does not map 1:1 to FreeBSD cpu IDs. > > How does JEmalloc do it ? I don't think it does on FreeBSD. The only thing malloc() knows on FreeBSD is the total number of CPUs. I believe Linux has a system call that returns this though (sched_getcpu() is the public interface which is a wrapper around a getcpu() system call). From the manpage it would seem that sched_getcpu() uses a per-thread shared page of some sort so that it doesn't actually have to enter the kernel to get the CPU ID. Alternatively, you could imagine it on x86 at least exporting a table mapping APIC IDs to CPU IDs and then using cpuid and that table to do the lookup purely in userland. That would only necessitate a global shared page and not one per-thread. You could still fall back to a system call for other architectures that simply returned curthread->td_oncpu. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 20:45:51 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 675FC106564A; Tue, 25 Oct 2011 20:45:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3CD308FC14; Tue, 25 Oct 2011 20:45:51 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id E46B446B2A; Tue, 25 Oct 2011 16:45:50 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7BBB38A037; Tue, 25 Oct 2011 16:45:50 -0400 (EDT) From: John Baldwin To: Gunnar Schaefer Date: Tue, 25 Oct 2011 15:55:23 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <20111024214020.GA60109@neveragain.de> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110251555.23066.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 25 Oct 2011 16:45:50 -0400 (EDT) Cc: Pavel Timofeev , freebsd-current@freebsd.org, Andriy Gapon , Dennis Koegel Subject: Re: Fresh installed Freebsd 9 don't boot from hd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 20:45:51 -0000 On Monday, October 24, 2011 7:21:27 pm Gunnar Schaefer wrote: > On Oct 24, 2011, at 2:40 PM, Dennis Koegel wrote: > > > On Mon, Oct 24, 2011 at 11:33:23AM -0400, John Baldwin wrote: > >> Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch > > > > GCC chokes here in drv.c:{49,50}: "cannot convert to a pointer type": > > > > v86.ds = VTOPSEG(params); > > v86.esi = VTOPOFF(params); > > > > Changed this to ¶ms. Also changed sector_size to uint16_t as noted > > by Andriy. Boots perfectly! (Tested with gcc and clang) > > I'd like to test these patches on my Supermicro machine as well. Unfortunately, I don't know how to go about it, but I'm hopeful to be able to figure it out with some basic instructions. I'm currently running a fresh RC1 install, and I'm able to boot the system if I set the BIOS to IDE mode, rather than AHCI. > > Any help would be much appreciated, I just committed them to HEAD (226748 along with a cleanup in 226746). They should backport to 9. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 20:52:12 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE21E106564A for ; Tue, 25 Oct 2011 20:52:12 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9531B8FC1E for ; Tue, 25 Oct 2011 20:52:12 +0000 (UTC) Received: by qadz32 with SMTP id z32so1183768qad.13 for ; Tue, 25 Oct 2011 13:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ueECXiyd1UNaXwjMHYQUMH0FYYRxj2NiXHL1l99LoGg=; b=jnrajQFn3mO08N9s7CLHI1lU56fPEdByS2x9KPF3cHkGe/1KB7Bql3D/gQF1P7hGTC wEVa+29/suvWStdLInsNXxBBQFcwJq66EZVPX8Y5vHo/HPIw7IFi2YfxQQDtmGNfCKiN G9419848E9GvG9aEGguCBKQizURSpJ3Oioxi4= MIME-Version: 1.0 Received: by 10.224.9.81 with SMTP id k17mr23059440qak.24.1319575931883; Tue, 25 Oct 2011 13:52:11 -0700 (PDT) Received: by 10.224.19.212 with HTTP; Tue, 25 Oct 2011 13:52:11 -0700 (PDT) In-Reply-To: References: Date: Tue, 25 Oct 2011 16:52:11 -0400 Message-ID: From: Mehmet Erol Sanliturk To: Warren Block Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Current Subject: Re: FreeBSD 9.0 RC1 USB Mouse and Keyboard X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 20:52:13 -0000 On Tue, Oct 25, 2011 at 4:41 PM, Warren Block wrote: > On Tue, 25 Oct 2011, Mehmet Erol Sanliturk wrote: > > Also by Benjamin Kaduk : >> >> >> Has this computer successfully run other versions of FreeBSD with X? >> I seem to recall there can be odd interactions with hald, xorg.conf, and >> others. Some googling brings up >> http://www.wonkity.com/~wblock/docs/html/aei.html which seems to cover >> many of >> the relevant issues. >> >> -Ben Kaduk >> >> >> -------------------------- >> >> After the above messages , >> on the same computer , I have installed the FreeBSD 9.0 RC1 amd64 again . >> >> I have generated an xorg.conf file . >> >> Into the xorg.conf file and ServerLayout part , I have inserted >> >> Option "AutoAddDevices" "Off" >> >> The USB Mouse and Keyboard , Fluxbox started to work as expected in the >> graphical mode under X . >> >> >> Without the above statement about Option , the error message is : >> >> (EE) config/hal : couldn't initialise context . unknown error (null) >> > > This line appears if x11-servers/xorg-server was built with the HAL option > enabled. > > In FreeBSD 9.0 RC1 i386 , such a step is NOT necessary . >> > > They should be the same. On i386, maybe xorg-server was built with the HAL > option disabled? I do not know because I am using downloaded .iso files as they are supplied in mirrors without any modification . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 20:55:33 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 124D31065690 for ; Tue, 25 Oct 2011 20:55:33 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 2E173162D65; Tue, 25 Oct 2011 20:54:10 +0000 (UTC) Message-ID: <4EA721F2.3010804@FreeBSD.org> Date: Tue, 25 Oct 2011 13:54:10 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: Craig Rodrigues References: <20111020114844.GK59810@albert.catwhisker.org> <20111020122121.GL59810@albert.catwhisker.org> <201110211636.05917.jhb@freebsd.org> <20111025140000.GA8559@albert.catwhisker.org> <4EA71713.3020404@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: sys/conf/newvers.sh vs. subversion-1.7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 20:55:33 -0000 On 10/25/2011 13:23, Craig Rodrigues wrote: > On Tue, Oct 25, 2011 at 1:07 PM, Doug Barton wrote: >> >> I didn't "disagree" with you. I pointed out that there is absolutely no >> reason to run 2 separate commands. To put it more bluntly, I pointed out >> why your suggestion is a bad idea. > > Hmmm, sounds like a disagreement to me. "Disagreement" implies that you and I both have equally valid ideas, and that we cannot agree on which one to use. > I have read your concerns, but I don't fully > understand why invoking "svn info ${SRCDIR}/sys", > ignoring the output of "svn info", and then just > checking its return status is a bad idea. As I tried to explain previously, running one command, testing the outcome, and then running another command if the first succeeded is a bad idea if you can simply run the command you need to run in the first place and parse *its* output. Obviously running 'svn info' first isn't overwhelmingly expensive, so this isn't the most horrible idea ever suggested for FreeBSD. However as a general principle we should be trying to do the best we can, not only for its own sake, but as an example to those who read and copy the code. BTW, the rest of my analysis in my previous post is relevant here too. If a bare 'svnversion' took a long time to return in a non-svn directory then obviously we'd have to give your solution a better look. However, given that it returns nearly instantaneously, there's no point. > Using "svnversion" further down in the script > if "svn info" succeeds is all that I was recommending. Yes, I understood what you were suggesting. :) > Anyways, I am fine with the patch which you propose. Awesome! > The only possible issue could be in future, > if svn switches from using decimal revision numbers > to numbers which are in hexadecimal, base64, etc. > > However, that is not currently the case, and if > it does happen in future, we can change the script > accordingly. Actually hex would still work since 0x.... would match. :) In any case I just tested the svn case, and it worked. If someone else could test the non-svn case then we can get this fixed and move on. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 21:01:14 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42818106566B for ; Tue, 25 Oct 2011 21:01:14 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-dy0-f54.google.com (mail-dy0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id CBBC68FC14 for ; Tue, 25 Oct 2011 21:01:13 +0000 (UTC) Received: by dye36 with SMTP id 36so76458dye.13 for ; Tue, 25 Oct 2011 14:01:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=cD7UCBm0+s15qEFva2BsjvvzaQcUFqh52hWJqF0QFR8=; b=YJdx/bXkeFSs7iRKaa4r40vf353kjWzgQefBNg7aOrvH2d3GaRfz3hlwV01IBkBOal BBoXcS3CCOs4ZNojuzVNo7GQMQuwTCCy3/0GZhcjbgYPnE3t46w7v5IO99VHoMPFjakv PpD9d04kZU7+E3FPCKIKTdJJC/NDoXb5CBImE= MIME-Version: 1.0 Received: by 10.182.51.103 with SMTP id j7mr4663800obo.36.1319576472569; Tue, 25 Oct 2011 14:01:12 -0700 (PDT) Received: by 10.182.122.33 with HTTP; Tue, 25 Oct 2011 14:01:12 -0700 (PDT) In-Reply-To: References: Date: Tue, 25 Oct 2011 14:01:12 -0700 Message-ID: From: Garrett Cooper To: Mehmet Erol Sanliturk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Warren Block , FreeBSD Current Subject: Re: FreeBSD 9.0 RC1 USB Mouse and Keyboard X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 21:01:14 -0000 On Tue, Oct 25, 2011 at 1:52 PM, Mehmet Erol Sanliturk wrote: > On Tue, Oct 25, 2011 at 4:41 PM, Warren Block wrote: > >> On Tue, 25 Oct 2011, Mehmet Erol Sanliturk wrote: >> >> =A0Also by Benjamin Kaduk : >>> >>> >>> Has this computer successfully run other versions of FreeBSD with X? >>> I seem to recall there can be odd interactions with hald, xorg.conf, an= d >>> others. Some googling brings up >>> http://www.wonkity.com/~wblock/docs/html/aei.html which seems to cover >>> many of >>> the relevant issues. >>> >>> -Ben Kaduk >>> >>> >>> -------------------------- >>> >>> After the above messages , >>> on the same computer , I have installed the FreeBSD 9.0 RC1 amd64 again= . >>> >>> I have generated an xorg.conf file . >>> >>> Into the xorg.conf =A0file and ServerLayout part , I have inserted >>> >>> =A0Option "AutoAddDevices" =A0"Off" >>> >>> The USB Mouse and Keyboard , Fluxbox =A0started to work as expected in = the >>> graphical mode =A0under X . >>> >>> >>> Without the above statement about Option , the error message is : >>> >>> (EE) config/hal : couldn't initialise context . unknown error (null) >>> >> >> This line appears if x11-servers/xorg-server was built with the HAL opti= on >> enabled. >> >> =A0In FreeBSD 9.0 RC1 i386 , such a step is NOT necessary . >>> >> >> They should be the same. =A0On i386, maybe xorg-server was built with th= e HAL >> option disabled? > > > > I do not know because I am using downloaded .iso files as they are suppli= ed > in mirrors without any modification . The default is WITH_HAL: OPTIONS+=3D HAL "Compile with HAL config support" on Why WITHOUT_HAL would be defined with i386 and not amd64, I have no idea, but if the build environments are consistently then it should be on for both. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 21:45:54 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89C031065700; Tue, 25 Oct 2011 21:45:54 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 266728FC13; Tue, 25 Oct 2011 21:45:53 +0000 (UTC) Received: by qyk35 with SMTP id 35so4526465qyk.13 for ; Tue, 25 Oct 2011 14:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=+V7UiJQQdFs3PB7nnmFMzBkWVqsxNladiLpxms11aFo=; b=M2/pvnDQe4MeV2xcD03eF3tvLkzyigmI0uTX2cZuZ7l2FkitWJyFMlueWlr3g9z+HM InS63LfQMKCiEm0wOdJOHT7xcfeidKJGfn7PyCKGWmHzWyWZr6494+EURIegaDn7cqTe Lbv5wpVts9r6aTbMqH/BuGXKBenvqRS7md7FQ= MIME-Version: 1.0 Received: by 10.229.218.201 with SMTP id hr9mr6084039qcb.226.1319579153360; Tue, 25 Oct 2011 14:45:53 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.229.250.12 with HTTP; Tue, 25 Oct 2011 14:45:53 -0700 (PDT) In-Reply-To: <4EA721F2.3010804@FreeBSD.org> References: <20111020114844.GK59810@albert.catwhisker.org> <20111020122121.GL59810@albert.catwhisker.org> <201110211636.05917.jhb@freebsd.org> <20111025140000.GA8559@albert.catwhisker.org> <4EA71713.3020404@FreeBSD.org> <4EA721F2.3010804@FreeBSD.org> Date: Tue, 25 Oct 2011 14:45:53 -0700 X-Google-Sender-Auth: 8c1p1n3kGsOqvI_R7cBnH7z4C5E Message-ID: From: Craig Rodrigues To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: sys/conf/newvers.sh vs. subversion-1.7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 21:45:54 -0000 On Tue, Oct 25, 2011 at 1:54 PM, Doug Barton > Actually hex would still work since 0x.... would match. :) Yes, but if in the future, a revision number format is ever chosen that doesn't include 0x at the beginning, and is something like: a23728ea7d592acc69b36875a482cdf3fd5c8d then this check would fail. However, none of this exists yet in SVN, so it is not worth worry about right now. It would have been nice if svnversion had a different return status in non-SVN directories. Checking svnversion output is fine, but it looks like a lot of things are changing around in SVN-land, including the output of commands. -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Tue Oct 25 23:04:20 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 4027D106564A for ; Tue, 25 Oct 2011 23:04:20 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id A55AB14E45D; Tue, 25 Oct 2011 23:04:19 +0000 (UTC) Message-ID: <4EA74073.7070206@FreeBSD.org> Date: Tue, 25 Oct 2011 16:04:19 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: Craig Rodrigues References: <20111020114844.GK59810@albert.catwhisker.org> <20111020122121.GL59810@albert.catwhisker.org> <201110211636.05917.jhb@freebsd.org> <20111025140000.GA8559@albert.catwhisker.org> <4EA71713.3020404@FreeBSD.org> <4EA721F2.3010804@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: sys/conf/newvers.sh vs. subversion-1.7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Oct 2011 23:04:20 -0000 On 10/25/2011 14:45, Craig Rodrigues wrote: > On Tue, Oct 25, 2011 at 1:54 PM, Doug Barton >> Actually hex would still work since 0x.... would match. :) > > Yes, but if in the future, a revision number format is ever chosen > that doesn't include > 0x at the beginning, and is something like: > a23728ea7d592acc69b36875a482cdf3fd5c8d > > then this check would fail. However, none of this > exists yet in SVN, so it is not worth worry about > right now. Yes, that was what the smiley at the end of my sentence above was intending to convey. Sorry I wasn't more clear. :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Wed Oct 26 00:58:14 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10208106566C for ; Wed, 26 Oct 2011 00:58:14 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id B740F8FC08 for ; Wed, 26 Oct 2011 00:58:13 +0000 (UTC) Received: by vws11 with SMTP id 11so1547742vws.13 for ; Tue, 25 Oct 2011 17:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; bh=UDdF+EIRehsLymbkacGl6CAkIULTxGVr/W3vQap+PNk=; b=oC9K3XRxUUn7mfLB/Gt3Bc7/vzpAvDpJBV97KUy/rvngHIKqr/v/tpolKM3FTYPJTG SjWuiqicyv6GhuwIao89NHpxmOKlfQwVHX8TedxO5LNL416n4QQABmA3ClqbUWP+nZEe Tdanaf3BwEjt4ZbIKP8pmcXr85ZwdlyZtI6/o= Received: by 10.52.74.162 with SMTP id u2mr14869400vdv.69.1319588896008; Tue, 25 Oct 2011 17:28:16 -0700 (PDT) Received: from kan.dyndns.org (c-24-63-226-98.hsd1.ma.comcast.net. [24.63.226.98]) by mx.google.com with ESMTPS id bu10sm1966vdb.3.2011.10.25.17.28.07 (version=SSLv3 cipher=OTHER); Tue, 25 Oct 2011 17:28:09 -0700 (PDT) Date: Tue, 25 Oct 2011 20:27:55 -0400 From: Alexander Kabaev To: "Alexey Shuvaev" Message-ID: <20111025202755.4243ae74@kan.dyndns.org> In-Reply-To: <649509EEAEBA42D4A3DCC1FDF5DA72E5@multiplay.co.uk> References: <20111008201456.GA3529@lexx.ifp.tuwien.ac.at> <20111017190027.GA9873@lexx.ifp.tuwien.ac.at> <20111018131353.GA83797@lexx.ifp.tuwien.ac.at> <649509EEAEBA42D4A3DCC1FDF5DA72E5@multiplay.co.uk> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/2RWuK30BG+OyUpX2_SDnE9k"; protocol="application/pgp-signature" Cc: freebsd-current@freebsd.org Subject: Re: Panics after AHCI timeouts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Oct 2011 00:58:14 -0000 --Sig_/2RWuK30BG+OyUpX2_SDnE9k Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 18 Oct 2011 14:28:07 +0100 "Steven Hartland" wrote: >=20 > ----- Original Message -----=20 > From: "Alexey Shuvaev" > To: > Sent: Tuesday, October 18, 2011 2:13 PM > Subject: Re: Panics after AHCI timeouts >=20 >=20 > > On Tue, Oct 18, 2011 at 06:19:19AM +0800, Adrian Chadd wrote: > > Done, kern/161768. > >=20 > > Question to the list: does anybody see successful recovery from AHCI > > timeout an a recent CURRENT? Recent means June 2011 or newer, so 9.0 > > branch counts also. That is, there are some kernel messages like > > this: > >=20 > > ahcich0: Timeout on slot 29 port 0 > > ahcich0: is 00000000 cs 00000000 ss ffffffff rs ffffffff tfd 40 > > serr 00000000 cmd 0000fc17 > >=20 > > but then AHCI recovers and the system does not panic? >=20 > Not a recent CURRENT but on 8.2-RELEASE we have seen recovery on > secondary ssd drives without a panic, but it does generally > drop the disk and need a power off, power on to recover the > disk properly; although we believe that's a firmware bug on > the ssds >=20 > Regards > Steve >=20 I do see timeouts on one of my Samsung ST3750330A disks and they definitely do not cause any panics. The weird part in my case is that disk then immediately reappears as online and mirror zpool can be rebuilt by just onlining the disk with 'zpool online ' command. It seems to be happening once system has accumulated some uptime. If rebooted, it keeps running for a week or two with no issues, but then timeouts start to happen more or less reliably every single 24 hours. =20 --=20 Alexander Kabaev --Sig_/2RWuK30BG+OyUpX2_SDnE9k Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iD8DBQFOp1QRQ6z1jMm+XZYRAhjTAJ9gDhB2nZrzp0xevvMFb2ZfTfYdnQCeLZg7 tkcPOLKfkT9HtmSvxESxXW8= =ZipY -----END PGP SIGNATURE----- --Sig_/2RWuK30BG+OyUpX2_SDnE9k-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 26 01:28:31 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE6AA106568B for ; Wed, 26 Oct 2011 01:28:31 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3DC8C8FC15 for ; Wed, 26 Oct 2011 01:28:30 +0000 (UTC) Received: by bkbzt4 with SMTP id zt4so1255151bkb.13 for ; Tue, 25 Oct 2011 18:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ADD9hi/LSB4anBLaaDctCSkoFlDbOT4vFbtqqXx9G9s=; b=rpgvT/exwDm3q2UAaVZ4SkT5PeoGdeI0FudQGjyycQxaSfGLojjuDcrpGspuMTpD37 KrZlAhpB5fgz5Z5qrwPQr496u4H1+A6nGY8aAFeFpXAriKwsjsMkD1quTTebCYDqt3JA UnBIdkvYLnwkO65GDByVjNeXt0a2LXLhjRs9s= MIME-Version: 1.0 Received: by 10.204.7.199 with SMTP id e7mr22235867bke.40.1319592509793; Tue, 25 Oct 2011 18:28:29 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.204.39.12 with HTTP; Tue, 25 Oct 2011 18:28:29 -0700 (PDT) In-Reply-To: <4EA68C47.2070908@orange.fr> References: <4EA68C47.2070908@orange.fr> Date: Tue, 25 Oct 2011 18:28:29 -0700 X-Google-Sender-Auth: 778NmCsu1WBCwUrBeMD9kn6VSAY Message-ID: From: Craig Rodrigues To: Claude Buisson Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current , freebsd-stable@freebsd.org Subject: Re: can audio CDs be played with ATA_CAM ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Oct 2011 01:28:31 -0000 On Tue, Oct 25, 2011 at 3:15 AM, Claude Buisson wrote: > Hi, > > When upgrading a system to 8.2-STABLE, I switched my kernel from atapicam to > ATA_CAM, and found that vlc could not play audio CDs anymore. Reverting to > atapicam (and reverting from cdN to acdN of course), vlc was OK again. Hi, Would vlc have worked if, while ATA_CAM was enabled, there was a symlink so that /dev/acd0 -> cd0 ? -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Wed Oct 26 01:32:48 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C1981065673 for ; Wed, 26 Oct 2011 01:32:48 +0000 (UTC) (envelope-from rdeiriar@spock.cl) Received: from mail.spock.cl (enteljoven2.enteljoven.cl [164.77.63.23]) by mx1.freebsd.org (Postfix) with ESMTP id 704578FC17 for ; Wed, 26 Oct 2011 01:32:47 +0000 (UTC) Received: from t61.deiriarte.local (190-21-139-32.baf.movistar.cl [190.21.139.32]) (AUTH: PLAIN rdeiriar@spock.cl, TLS: TLSv1/SSLv3, 256bits, CAMELLIA256-SHA) by mail.spock.cl with ESMTPSA; Tue, 25 Oct 2011 22:32:57 -0300 id 000007C5.000000004EA76349.00016C40 Message-ID: <4EA76311.5000704@spock.cl> Date: Tue, 25 Oct 2011 22:32:01 -0300 From: Roberto de Iriarte User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0) Gecko/20110930 Thunderbird/7.0 MIME-Version: 1.0 To: FreeBSD Current References: <4EA6F4EC.3010403@spock.cl> In-Reply-To: <4EA6F4EC.3010403@spock.cl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: LSI 9240-8i (IBM M1015) MegaRaid support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Oct 2011 01:32:48 -0000 I have to rectify myself It is possible to install FreeBSD 9-Beta3 amd64 (9-RC1 boots correctly as well, i will upgrade in a couple of hours) on the X3550 M3 with a reflashed M1015 SAS controller, using the mps driver It is only extremely tiresome (and not because of FreeBSD!) I will document the procedure asap, as i've seen in the forums that others have had problems with this machine. Best regards Roberto P.S. Many thanks to Scott Long for the mps driver! > Hi, > > Is there any expectancy of getting this piece of hardware (or it's IBM > silbing, the M1015) working in MegaRaid mode, without having to > reflash the card to IT mode. > > The reason of this request is that the UEFI Bios on the IBM XSeries > 3550M3 refuses to properly initialize the controller if reflashed with > the IT mode firmware, thus making it unusable. > > A search on LSI's website for a driver that supports 8-Stable or 9 did > not produce any results > > Many thanks and best regards, > Roberto > _______________________________________________ > 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 Oct 26 07:25:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A86AB106564A for ; Wed, 26 Oct 2011 07:25:24 +0000 (UTC) (envelope-from dk@mail.neveragain.de) Received: from mail.neveragain.de (mail.neveragain.de [IPv6:2001:aa8:fffc::25]) by mx1.freebsd.org (Postfix) with ESMTP id 7600B8FC12 for ; Wed, 26 Oct 2011 07:25:24 +0000 (UTC) Received: by mail.neveragain.de (Postfix, from userid 1002) id 6C94017028; Wed, 26 Oct 2011 09:25:23 +0200 (CEST) Date: Wed, 26 Oct 2011 09:25:23 +0200 From: Dennis Koegel To: freebsd-current@freebsd.org Message-ID: <20111026072523.GA89177@neveragain.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: isp(4) WWNs / ISP2532 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Oct 2011 07:25:24 -0000 Cheers, we have a "Qlogic ISP 2532 PCI FC-AL Adapter" here, on 9.0-RC1, which seems to work fine with isp(4). But: We had some trouble finding the WWNs -- per man page, there should be sysctl entries like dev.isp.N.{wwnn,wwpn}, but they ain't here. dmesg didn't show them either. Booting verbose does print them. Is the man page outdated, or a strange behaviour because this chip isn't explicitly supported? Thanks, - D. From owner-freebsd-current@FreeBSD.ORG Wed Oct 26 07:55:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EABC6106566B; Wed, 26 Oct 2011 07:55:16 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 4AC0C8FC14; Wed, 26 Oct 2011 07:55:16 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id 177781E2; Wed, 26 Oct 2011 09:55:14 +0200 (CEST) Date: Wed, 26 Oct 2011 09:54:31 +0200 From: Pawel Jakub Dawidek To: John Baldwin Message-ID: <20111026075431.GB1672@garage.freebsd.pl> References: <20111022084931.GD1697@garage.freebsd.pl> <20111023084445.GB50300@deviant.kiev.zoral.com.ua> <20111023155827.GH1697@garage.freebsd.pl> <201110240814.22368.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0eh6TmSyL6TZE2Uz" Content-Disposition: inline In-Reply-To: <201110240814.22368.jhb@freebsd.org> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Kostik Belousov , Lawrence Stewart , freebsd-current@freebsd.org, Andre Oppermann , freebsd-net@freebsd.org Subject: Re: 9.0-RC1 panic in tcp_input: negative winow. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Oct 2011 07:55:17 -0000 --0eh6TmSyL6TZE2Uz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 24, 2011 at 08:14:22AM -0400, John Baldwin wrote: > On Sunday, October 23, 2011 11:58:28 am Pawel Jakub Dawidek wrote: > > On Sun, Oct 23, 2011 at 11:44:45AM +0300, Kostik Belousov wrote: > > > On Sun, Oct 23, 2011 at 08:10:38AM +0200, Pawel Jakub Dawidek wrote: > > > > My suggestion would be that if we won't be able to fix it before 9.= 0, > > > > we should turn this assertion off, as the system seems to be able to > > > > recover. > > >=20 > > > Shipped kernels have all assertions turned off. > >=20 > > Yes, I'm aware of that, but many people compile their production kernels > > with INVARIANTS/INVARIANT_SUPPORT to fail early instead of eg. > > corrupting data. I'd be fine in moving this under DIAGNOSTIC or changing > > it into a printf, so it will be visible. >=20 > No, the kernel is corrupting things in other places when this is true, so > if you are running with INVARIANTS, we want to know about it. Specifica= lly, > in several places in TCP we assume that rcv_adv >=3D rcv_nxt, and depend = on > being able to do 'rcv_adv - rcv_nxt'. >=20 > In this case, it looks like the difference is consistently less than one= =20 > frame. I suspect the other end of the connection is sending just beyond = the=20 > end of the advertised window (it probably assumes it is better to send a = full=20 > frame if it has that much pending data even though part of it is beyond t= he=20 > window edge vs sending a truncated packet that just fills the window) and= that > that frame is accepted ok in the header prediction case and it's ACK is= =20 > delayed, but the next packet to arrive then trips over this assumption. >=20 > Since 'win' is guaranteed to be non-negative and we explicitly cast > 'rcv_adv - rcv_nxt' to (int) in the following line that the assert is che= cking > for: >=20 > tp->rcv_wnd =3D imax(win, (int)(tp->rcv_adv - tp->rcv_nxt)); >=20 > I think we already handle this case ok and perhaps the assertion can just= be > removed? Not sure if others feel that it warrants a comment to note that= this > is the case being handled. I added debug to the places where rcv_adv and rcv_nxt are modified. Here is what happens before the panic occurs: tcp_do_segment:1722 negative window: tp 0xfffffe000dab1b70 rcv_nxt 40223615= 48 rcv_adv 4022360100 diff -1448 tcp_do_segment:2847 negative window: tp 0xfffffe000dab1b70 rcv_nxt 40223622= 98 rcv_adv 4022361548 diff -750 tcp_do_segment:1722 negative window: tp 0xfffffe000dab1b70 rcv_nxt 40223637= 46 rcv_adv 4022362298 diff -1448 tcp_do_segment:2847 negative window: tp 0xfffffe000dab1b70 rcv_nxt 40223648= 36 rcv_adv 4022363746 diff -1090 tcp_do_segment:1722 negative window: tp 0xfffffe000dab1b70 rcv_nxt 40223662= 84 rcv_adv 4022364836 diff -1448 tcp_do_segment:1722 negative window: tp 0xfffffe000dab1b70 rcv_nxt 40223706= 28 rcv_adv 4022369690 diff -938 tcp_do_segment:1722 negative window: tp 0xfffffe000dab1b70 rcv_nxt 40223791= 40 rcv_adv 4022377692 diff -1448 tcp_do_segment:1722 negative window: tp 0xfffffe000dab1b70 rcv_nxt 40223877= 92 rcv_adv 4022386344 diff -1448 tcp_do_segment:2847 negative window: tp 0xfffffe000dab1b70 rcv_nxt 40223888= 90 rcv_adv 4022387792 diff -1098 tcp_do_segment:1722 negative window: tp 0xfffffe000dab1b70 rcv_nxt 40223903= 38 rcv_adv 4022388890 diff -1448 tcp_do_segment:2847 negative window: tp 0xfffffe000dab1b70 rcv_nxt 40223945= 63 rcv_adv 4022394342 diff -221 panic: tcp_input negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022394563 = rcv_adv 4022394342 win=3D0 diff -221 I can send you the full log if you want, I've plenty of messages where rcv_adv < rcv_nxt, not all of them trigger this assertion. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --0eh6TmSyL6TZE2Uz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk6nvLYACgkQForvXbEpPzS/igCgh6TcluOieBa/tfP90xC4Gy1t 5GMAoNQG1Mc8LyevKm/3rQFJoC02DriH =LzuI -----END PGP SIGNATURE----- --0eh6TmSyL6TZE2Uz-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 26 08:33:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8257E106566C for ; Wed, 26 Oct 2011 08:33:16 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from smtp.smtpout.orange.fr (smtp03.smtpout.orange.fr [80.12.242.125]) by mx1.freebsd.org (Postfix) with ESMTP id 20CB98FC15 for ; Wed, 26 Oct 2011 08:33:15 +0000 (UTC) Received: from localhost ([92.136.19.77]) by mwinf5d05 with ME id pLZD1h0091fmhbQ03LZDpP; Wed, 26 Oct 2011 10:33:14 +0200 X-ME-engine: default Message-ID: <4EA7C5C9.8010903@orange.fr> Date: Wed, 26 Oct 2011 10:33:13 +0200 From: Claude Buisson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.23) Gecko/20110928 Thunderbird/3.1.15 MIME-Version: 1.0 To: Craig Rodrigues References: <4EA68C47.2070908@orange.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , freebsd-stable@freebsd.org Subject: Re: can audio CDs be played with ATA_CAM ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Oct 2011 08:33:16 -0000 On 10/26/2011 03:28, Craig Rodrigues wrote: > On Tue, Oct 25, 2011 at 3:15 AM, Claude Buisson wrote: >> Hi, >> >> When upgrading a system to 8.2-STABLE, I switched my kernel from atapicam to >> ATA_CAM, and found that vlc could not play audio CDs anymore. Reverting to >> atapicam (and reverting from cdN to acdN of course), vlc was OK again. > > Hi, > > Would vlc have worked if, while ATA_CAM was enabled, > there was a symlink so that /dev/acd0 -> cd0 ? Just to be sure, I just made the test, and the answer is: NO I have already written that vlc writes a susccession of messages [0x2caf2a3c] cdda access error: Could not set block size [0x2caf2a3c] cdda access error: cannot read sector nnnnn incrementing each time the sector number. So I infer that vlc cannot set the correct (audio specific) sector size for the cam device. Thanks for your attention. Claude Buisson P.S. As I can see reading GENERIC, ATA_CAM will be the default for 9.X so there is a risk of complaints from FreeBSD workstation users (who cares ?) after the release.. From owner-freebsd-current@FreeBSD.ORG Wed Oct 26 09:09:48 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B890E106564A for ; Wed, 26 Oct 2011 09:09:48 +0000 (UTC) (envelope-from dk@mail.neveragain.de) Received: from mail.neveragain.de (mail.neveragain.de [IPv6:2001:aa8:fffc::25]) by mx1.freebsd.org (Postfix) with ESMTP id 8587C8FC08 for ; Wed, 26 Oct 2011 09:09:48 +0000 (UTC) Received: by mail.neveragain.de (Postfix, from userid 1002) id 6AA8F1703C; Wed, 26 Oct 2011 11:09:47 +0200 (CEST) Date: Wed, 26 Oct 2011 11:09:47 +0200 From: Dennis Koegel To: freebsd-current@freebsd.org Message-ID: <20111026090947.GA90384@neveragain.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: gmultipath: act/act, path checking? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Oct 2011 09:09:48 -0000 Cheers, are there any plans to have gmultipath support for active/active? Also, is there any way to check available paths periodically? As far as I unterstand, once gmultipath kicks a certain path due to failure, it will never come back automatically. (And it won't ever be used if it isn't working at boot time) I've found some discussion about this from 2008, but nothing since... Thanks, - D. From owner-freebsd-current@FreeBSD.ORG Wed Oct 26 09:22:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05A72106566C; Wed, 26 Oct 2011 09:22:52 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 7D23E8FC0A; Wed, 26 Oct 2011 09:22:51 +0000 (UTC) Received: from ur.dons.net.au (ppp118-210-211-94.lns20.adl6.internode.on.net [118.210.211.94]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id p9Q9MQpo059374 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 26 Oct 2011 19:52:32 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: "Daniel O'Connor" In-Reply-To: <4EA7C5C9.8010903@orange.fr> Date: Wed, 26 Oct 2011 19:52:25 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EA68C47.2070908@orange.fr> <4EA7C5C9.8010903@orange.fr> To: Claude Buisson X-Mailer: Apple Mail (2.1251.1) X-Spam-Score: 2.162 (**) BAYES_00,KHOP_DYNAMIC,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: Craig Rodrigues , FreeBSD Current , freebsd-stable@freebsd.org Subject: Re: can audio CDs be played with ATA_CAM ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Oct 2011 09:22:52 -0000 On 26/10/2011, at 19:03, Claude Buisson wrote: >=20 > [0x2caf2a3c] cdda access error: Could not set block size > [0x2caf2a3c] cdda access error: cannot read sector nnnnn >=20 > incrementing each time the sector number. >=20 > So I infer that vlc cannot set the correct (audio specific) sector = size for the > cam device. >=20 > Thanks for your attention. >=20 > Claude Buisson >=20 > P.S. As I can see reading GENERIC, ATA_CAM will be the default for 9.X = so there > is a risk of complaints from FreeBSD workstation users (who cares ?) = after the > release.. Does cdparanoia work for you? -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-current@FreeBSD.ORG Wed Oct 26 10:20:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 704991065678 for ; Wed, 26 Oct 2011 10:20:41 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from smtp.smtpout.orange.fr (smtp03.smtpout.orange.fr [80.12.242.125]) by mx1.freebsd.org (Postfix) with ESMTP id 127858FC19 for ; Wed, 26 Oct 2011 10:20:40 +0000 (UTC) Received: from localhost ([92.136.19.77]) by mwinf5d58 with ME id pNLb1h00A1fmhbQ03NLb9f; Wed, 26 Oct 2011 12:20:39 +0200 X-ME-engine: default Message-ID: <4EA7DEF3.7030807@orange.fr> Date: Wed, 26 Oct 2011 12:20:35 +0200 From: Claude Buisson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.23) Gecko/20110928 Thunderbird/3.1.15 MIME-Version: 1.0 To: Daniel O'Connor References: <4EA68C47.2070908@orange.fr> <4EA7C5C9.8010903@orange.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Craig Rodrigues , FreeBSD Current , freebsd-stable@freebsd.org Subject: Re: can audio CDs be played with ATA_CAM ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Oct 2011 10:20:41 -0000 On 10/26/2011 11:22, Daniel O'Connor wrote: > > On 26/10/2011, at 19:03, Claude Buisson wrote: >> >> [0x2caf2a3c] cdda access error: Could not set block size >> [0x2caf2a3c] cdda access error: cannot read sector nnnnn >> >> incrementing each time the sector number. >> >> So I infer that vlc cannot set the correct (audio specific) sector size for the >> cam device. >> >> Thanks for your attention. >> >> Claude Buisson >> >> P.S. As I can see reading GENERIC, ATA_CAM will be the default for 9.X so there >> is a risk of complaints from FreeBSD workstation users (who cares ?) after the >> release.. > > > Does cdparanoia work for you? > With cdparanoia-3.9.8_9: YES tested on 8.2 (from Sep 18) and 9.0 (from Sep 25) both with ATA_CAM Claude Buisson From owner-freebsd-current@FreeBSD.ORG Wed Oct 26 11:50:32 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFC77106564A; Wed, 26 Oct 2011 11:50:32 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 71DD68FC1E; Wed, 26 Oct 2011 11:50:32 +0000 (UTC) Received: from ur.dons.net.au (ppp118-210-211-94.lns20.adl6.internode.on.net [118.210.211.94]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id p9QBoHVV072931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 26 Oct 2011 22:20:24 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: "Daniel O'Connor" In-Reply-To: <4EA7DEF3.7030807@orange.fr> Date: Wed, 26 Oct 2011 22:20:17 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: <7334F735-D217-471E-B5AA-151DD9204B65@gsoft.com.au> References: <4EA68C47.2070908@orange.fr> <4EA7C5C9.8010903@orange.fr> <4EA7DEF3.7030807@orange.fr> To: Claude Buisson X-Mailer: Apple Mail (2.1251.1) X-Spam-Score: 2.162 (**) BAYES_00,KHOP_DYNAMIC,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: Craig Rodrigues , FreeBSD Current , freebsd-stable@freebsd.org Subject: Re: can audio CDs be played with ATA_CAM ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Oct 2011 11:50:33 -0000 On 26/10/2011, at 20:50, Claude Buisson wrote: >>> P.S. As I can see reading GENERIC, ATA_CAM will be the default for = 9.X so there >>> is a risk of complaints from FreeBSD workstation users (who cares ?) = after the >>> release.. >>=20 >>=20 >> Does cdparanoia work for you? >>=20 >=20 > With cdparanoia-3.9.8_9: YES >=20 > tested on 8.2 (from Sep 18) and 9.0 (from Sep 25) both with ATA_CAM Strange, I would have thought VLC would use the same sort of access = method as VLC.. I don't know what it's trying so it's hard to know why it doesn't work = :( -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-current@FreeBSD.ORG Wed Oct 26 11:53:40 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92EEE106567F; Wed, 26 Oct 2011 11:53:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 565178FC2A; Wed, 26 Oct 2011 11:53:40 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 4BACF46B1A; Wed, 26 Oct 2011 07:53:39 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9F0BE8A037; Wed, 26 Oct 2011 07:53:38 -0400 (EDT) From: John Baldwin To: Pawel Jakub Dawidek Date: Wed, 26 Oct 2011 07:53:36 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <20111022084931.GD1697@garage.freebsd.pl> <201110240814.22368.jhb@freebsd.org> <20111026075431.GB1672@garage.freebsd.pl> In-Reply-To: <20111026075431.GB1672@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201110260753.37264.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 26 Oct 2011 07:53:38 -0400 (EDT) Cc: Kostik Belousov , Lawrence Stewart , freebsd-current@freebsd.org, Andre Oppermann , freebsd-net@freebsd.org Subject: Re: 9.0-RC1 panic in tcp_input: negative winow. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Oct 2011 11:53:40 -0000 On Wednesday, October 26, 2011 3:54:31 am Pawel Jakub Dawidek wrote: > On Mon, Oct 24, 2011 at 08:14:22AM -0400, John Baldwin wrote: > > On Sunday, October 23, 2011 11:58:28 am Pawel Jakub Dawidek wrote: > > > On Sun, Oct 23, 2011 at 11:44:45AM +0300, Kostik Belousov wrote: > > > > On Sun, Oct 23, 2011 at 08:10:38AM +0200, Pawel Jakub Dawidek wrote: > > > > > My suggestion would be that if we won't be able to fix it before 9.0, > > > > > we should turn this assertion off, as the system seems to be able to > > > > > recover. > > > > > > > > Shipped kernels have all assertions turned off. > > > > > > Yes, I'm aware of that, but many people compile their production kernels > > > with INVARIANTS/INVARIANT_SUPPORT to fail early instead of eg. > > > corrupting data. I'd be fine in moving this under DIAGNOSTIC or changing > > > it into a printf, so it will be visible. > > > > No, the kernel is corrupting things in other places when this is true, so > > if you are running with INVARIANTS, we want to know about it. Specifically, > > in several places in TCP we assume that rcv_adv >= rcv_nxt, and depend on > > being able to do 'rcv_adv - rcv_nxt'. > > > > In this case, it looks like the difference is consistently less than one > > frame. I suspect the other end of the connection is sending just beyond the > > end of the advertised window (it probably assumes it is better to send a full > > frame if it has that much pending data even though part of it is beyond the > > window edge vs sending a truncated packet that just fills the window) and that > > that frame is accepted ok in the header prediction case and it's ACK is > > delayed, but the next packet to arrive then trips over this assumption. > > > > Since 'win' is guaranteed to be non-negative and we explicitly cast > > 'rcv_adv - rcv_nxt' to (int) in the following line that the assert is checking > > for: > > > > tp->rcv_wnd = imax(win, (int)(tp->rcv_adv - tp->rcv_nxt)); > > > > I think we already handle this case ok and perhaps the assertion can just be > > removed? Not sure if others feel that it warrants a comment to note that this > > is the case being handled. > > I added debug to the places where rcv_adv and rcv_nxt are modified. Here > is what happens before the panic occurs: > > tcp_do_segment:1722 negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022361548 rcv_adv 4022360100 diff -1448 > tcp_do_segment:2847 negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022362298 rcv_adv 4022361548 diff -750 > tcp_do_segment:1722 negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022363746 rcv_adv 4022362298 diff -1448 > tcp_do_segment:2847 negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022364836 rcv_adv 4022363746 diff -1090 > tcp_do_segment:1722 negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022366284 rcv_adv 4022364836 diff -1448 > tcp_do_segment:1722 negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022370628 rcv_adv 4022369690 diff -938 > tcp_do_segment:1722 negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022379140 rcv_adv 4022377692 diff -1448 > tcp_do_segment:1722 negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022387792 rcv_adv 4022386344 diff -1448 > tcp_do_segment:2847 negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022388890 rcv_adv 4022387792 diff -1098 > tcp_do_segment:1722 negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022390338 rcv_adv 4022388890 diff -1448 > tcp_do_segment:2847 negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022394563 rcv_adv 4022394342 diff -221 > panic: tcp_input negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022394563 rcv_adv 4022394342 win=0 diff -221 > > I can send you the full log if you want, I've plenty of messages where > rcv_adv < rcv_nxt, not all of them trigger this assertion. The assertion would be triggered when the next packet arrives (as I said above). Try modifying your debugging output to also log if the ACK is delayed. I suspect it is not delayed until the last one. (Pushing out an ACK will reset rcv_adv to be beyond rcv_nxt in tcp_output(), so in the case of an immediate ACK, rcv_nxt > rcv_adv is only a transient condition all under a single lock invocation so never visible to other consumers of the protocol control block.) If that is what you see, then that confirms what I guessed above and I will likely just remove the assertion in tcp_input() and patch the timewait code to handle this case. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Oct 26 13:48:22 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C7E51065688 for ; Wed, 26 Oct 2011 13:48:22 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.server1.bsdforen.de (bsdforen.de [82.193.243.81]) by mx1.freebsd.org (Postfix) with ESMTP id ADC808FC1E for ; Wed, 26 Oct 2011 13:48:21 +0000 (UTC) Received: from mobileKamikaze.norad (HSI-KBW-091-089-161-008.hsi2.kabel-badenwuerttemberg.de [91.89.161.8]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.server1.bsdforen.de (Postfix) with ESMTPSA id F3C3286068 for ; Wed, 26 Oct 2011 15:32:03 +0200 (CEST) Message-ID: <4EA80BD3.7000202@bsdforen.de> Date: Wed, 26 Oct 2011 15:32:03 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111006 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: 7bit Subject: 9.0 RC1 linking problem with i386 libs on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 13:48:22 -0000 I haven't tried to dig into this. Only "unusual" properties of the system are my non-default MAKEOBJDIRPREFIX and the use of ccache. # uname -a FreeBSD AryaStark.norad 9.0-RC1 FreeBSD 9.0-RC1 #0: Wed Oct 26 13:46:13 CEST 2011 root@AryaStark.norad:/usr/obj/GENERIC/amd64/usr/src/sys/GENERIC amd64 # make -VCC -VCPUTYPE -VCFLAGS /usr/local/bin/ccache clang athlon64-sse3 -O2 -pipe -march=athlon64-sse3 ... ===> lib/csu/i386-elf (obj,depend,all,install) ld -m elf_i386_fbsd -Y P,/usr/obj/GENERIC/amd64/usr/src/lib32/usr/lib32 -o gcrt1.o -r crt1_s.o gcrt1_c.o ld: Relocatable linking with relocations from format elf64-x86-64-freebsd (crt1_s.o) to format elf32-i386-freebsd (gcrt1.o) is not supported *** Error code 1 Stop in /usr/src/lib/csu/i386-elf. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-current@FreeBSD.ORG Wed Oct 26 13:54:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D70AE1065670 for ; Wed, 26 Oct 2011 13:54:08 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id A2C4F8FC17 for ; Wed, 26 Oct 2011 13:54:08 +0000 (UTC) Received: from [192.168.135.103] (c-24-7-47-62.hsd1.ca.comcast.net [24.7.47.62]) (authenticated bits=0) by ns1.feral.com (8.14.4/8.14.4) with ESMTP id p9QDs2Gs006877 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 26 Oct 2011 06:54:07 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4EA810F8.6050805@feral.com> Date: Wed, 26 Oct 2011 06:54:00 -0700 From: Matthew Jacob User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20111026090947.GA90384@neveragain.de> In-Reply-To: <20111026090947.GA90384@neveragain.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (ns1.feral.com [192.67.166.1]); Wed, 26 Oct 2011 06:54:07 -0700 (PDT) Subject: Re: gmultipath: act/act, path checking? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Oct 2011 13:54:08 -0000 On 10/26/2011 2:09 AM, Dennis Koegel wrote: > Cheers, > > are there any plans to have gmultipath support for active/active? I was given patches but have lacked motivation to do it. > > Also, is there any way to check available paths periodically? As far as > I unterstand, once gmultipath kicks a certain path due to failure, it > will never come back automatically. (And it won't ever be used if it > isn't working at boot time) That is something that should have been fixed. I might be confused with the changes I did for Panasas that didn't make it back here, but I certainly had a rolling test where I ran for several days periodically failing one path and then then the other. > > I've found some discussion about this from 2008, but nothing since... > > Thanks, > - D. > _______________________________________________ > 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 Oct 26 13:56:18 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92ED8106566C for ; Wed, 26 Oct 2011 13:56:18 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 24FE58FC14 for ; Wed, 26 Oct 2011 13:56:18 +0000 (UTC) Received: from [192.168.135.103] (c-24-7-47-62.hsd1.ca.comcast.net [24.7.47.62]) (authenticated bits=0) by ns1.feral.com (8.14.4/8.14.4) with ESMTP id p9QDuFmA006908 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 26 Oct 2011 06:56:17 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4EA8117D.3050909@feral.com> Date: Wed, 26 Oct 2011 06:56:13 -0700 From: Matthew Jacob User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20111026072523.GA89177@neveragain.de> In-Reply-To: <20111026072523.GA89177@neveragain.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (ns1.feral.com [192.67.166.1]); Wed, 26 Oct 2011 06:56:17 -0700 (PDT) Subject: Re: isp(4) WWNs / ISP2532 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Oct 2011 13:56:18 -0000 > Cheers, > > we have a "Qlogic ISP 2532 PCI FC-AL Adapter" here, on 9.0-RC1, which > seems to work fine with isp(4). > > But: We had some trouble finding the WWNs -- per man page, there should > be sysctl entries like dev.isp.N.{wwnn,wwpn}, but they ain't here. dmesg > didn't show them either. > > Booting verbose does print them. > > Is the man page outdated, or a strange behaviour because this chip > isn't explicitly supported? This question would be better answered on freebsd-scsi. It's a bug, and it's easy to fix, but because of the impending 9.0 release I haven't done it. There's an ioctl you can use to do the same thing and some tools in http://people.freebsd.org/~mjacob/isp_tools.tgz that can solve what you need. From owner-freebsd-current@FreeBSD.ORG Wed Oct 26 14:00:56 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0EBA1065679 for ; Wed, 26 Oct 2011 14:00:56 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id B25BB8FC0A for ; Wed, 26 Oct 2011 14:00:56 +0000 (UTC) Received: by vcbfo13 with SMTP id fo13so2223830vcb.13 for ; Wed, 26 Oct 2011 07:00:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.153.12 with SMTP id i12mr352694vcw.7.1319637656073; Wed, 26 Oct 2011 07:00:56 -0700 (PDT) Received: by 10.220.194.194 with HTTP; Wed, 26 Oct 2011 07:00:55 -0700 (PDT) X-Originating-IP: [93.221.182.5] In-Reply-To: <20111025202755.4243ae74@kan.dyndns.org> References: <20111008201456.GA3529@lexx.ifp.tuwien.ac.at> <20111017190027.GA9873@lexx.ifp.tuwien.ac.at> <20111018131353.GA83797@lexx.ifp.tuwien.ac.at> <649509EEAEBA42D4A3DCC1FDF5DA72E5@multiplay.co.uk> <20111025202755.4243ae74@kan.dyndns.org> Date: Wed, 26 Oct 2011 16:00:55 +0200 Message-ID: From: "C. P. Ghost" To: Alexander Kabaev Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexey Shuvaev , freebsd-current@freebsd.org Subject: Re: Panics after AHCI timeouts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Oct 2011 14:00:57 -0000 On Wed, Oct 26, 2011 at 2:27 AM, Alexander Kabaev wrote: > I do see timeouts on one of my Samsung ST3750330A disks and they > definitely do not cause any panics. The weird part in my case is that > disk then immediately reappears as online and mirror zpool can be > rebuilt by just onlining the disk with 'zpool online ' > command. > > It seems to be happening once system has accumulated some uptime. If > rebooted, it keeps running for a week or two with no issues, but then > timeouts start to happen more or less reliably every single 24 hours. Does it correlate with high disk activity, i.e. with periodic(8)? On my machine, I have a feeling that timeouts occur more often at that point, than normally... and that they also occur when multiple processes access the disk simultaneously. If it's only one process, the machine (usually) doesn't hang, even when that process is copying big files back and forth for a long period of time (it's a backup process). But interleave that process with another one accessing the same disk, and poof!, almost immediately ahci timeouts. occur. Very strange... Maybe a race condition of some sort after all? > -- > Alexander Kabaev Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ From owner-freebsd-current@FreeBSD.ORG Wed Oct 26 14:39:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9262A106566C for ; Wed, 26 Oct 2011 14:39:17 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 524878FC14 for ; Wed, 26 Oct 2011 14:39:17 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:71f2:ea38:61d2:e6cf] (unknown [IPv6:2001:7b8:3a7:0:71f2:ea38:61d2:e6cf]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 89AB75C37; Wed, 26 Oct 2011 16:39:15 +0200 (CEST) Message-ID: <4EA81B90.60501@FreeBSD.org> Date: Wed, 26 Oct 2011 16:39:12 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111019 Thunderbird/8.0 MIME-Version: 1.0 To: Dominic Fandrey References: <4EA80BD3.7000202@bsdforen.de> In-Reply-To: <4EA80BD3.7000202@bsdforen.de> Content-Type: multipart/mixed; boundary="------------090406000000070806080300" Cc: freebsd-current@freebsd.org Subject: Re: 9.0 RC1 linking problem with i386 libs on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 14:39:17 -0000 This is a multi-part message in MIME format. --------------090406000000070806080300 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit On 2011-10-26 15:32, Dominic Fandrey wrote: > I haven't tried to dig into this. Only "unusual" properties of the system > are my non-default MAKEOBJDIRPREFIX and the use of ccache. > > # uname -a > FreeBSD AryaStark.norad 9.0-RC1 FreeBSD 9.0-RC1 #0: Wed Oct 26 13:46:13 CEST 2011 root@AryaStark.norad:/usr/obj/GENERIC/amd64/usr/src/sys/GENERIC amd64 > > # make -VCC -VCPUTYPE -VCFLAGS > /usr/local/bin/ccache clang > athlon64-sse3 > -O2 -pipe -march=athlon64-sse3 How are you setting CC and/or CFLAGS, precisely? Depending on how you do it, the settings might not be propagated correctly to the build32 stage. Also, if you force CFLAGS to have -march=athlon64-sse3, I'm not sure if the build32 stage can even work correctly. Just specify CPUTYPE, that should be enough. In any case, you can try out the attached patch, which should take care of passing CC to the build32 stage correctly. I would really like to have this in head, and even stable/9. It makes it possible to just set CC in make.conf, without .ifdef trickery. Works nicely for clang, too. :) --------------090406000000070806080300 Content-Type: text/x-diff; name="build32-override-cc-cxx-as-ld-1.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="build32-override-cc-cxx-as-ld-1.diff" Index: Makefile.inc1 =================================================================== --- Makefile.inc1 (revision 224934) +++ Makefile.inc1 (working copy) @@ -313,7 +313,8 @@ LIB32WMAKE= ${LIB32WMAKEENV} ${MAKE} -DNO_CPU_CFLAGS -DCOMPAT_32BIT \ -DWITHOUT_BIND -DWITHOUT_MAN -DWITHOUT_INFO \ - -DWITHOUT_HTML -DNO_CTF -DNO_LINT DESTDIR=${LIB32TMP} + -DWITHOUT_HTML -DNO_CTF -DNO_LINT -ECC -ECXX -EAS -ELD \ + DESTDIR=${LIB32TMP} LIB32IMAKE= ${LIB32WMAKE:NINSTALL=*:NDESTDIR=*} -DNO_INCS .endif --------------090406000000070806080300-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 26 15:00:43 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 871C6106564A for ; Wed, 26 Oct 2011 15:00:43 +0000 (UTC) (envelope-from lab@gta.com) Received: from mailgate.gta.com (mailgate.gta.com [199.120.225.20]) by mx1.freebsd.org (Postfix) with SMTP id 210908FC08 for ; Wed, 26 Oct 2011 15:00:42 +0000 (UTC) Received: (qmail 31097 invoked by uid 1000); 26 Oct 2011 14:34:01 -0000 Date: 26 Oct 2011 14:34:01 -0000 Message-ID: <20111026143401.31096.qmail@mailgate.gta.com> From: Larry Baird To: freebsd-current@freebsd.org Organization: Global Technology Associates In-Reply-To: <111926.10138.25387@localhost> User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.3-PRERELEASE (i386)) Subject: Re: Panics after AHCI timeouts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Oct 2011 15:00:43 -0000 In article <111926.10138.25387@localhost> you wrote: > On Wed, Oct 26, 2011 at 2:27 AM, Alexander Kabaev wrote: > > I do see timeouts on one of my Samsung ST3750330A disks and they > > definitely do not cause any panics. The weird part in my case is that > > disk then immediately reappears as online and mirror zpool can be > > rebuilt by just onlining the disk with 'zpool online ' > > command. > > > > It seems to be happening once system has accumulated some uptime. If > > rebooted, it keeps running for a week or two with no issues, but then > > timeouts start to happen more or less reliably every single 24 hours. > > Does it correlate with high disk activity, i.e. with periodic(8)? > > On my machine, I have a feeling that timeouts occur more often > at that point, than normally... and that they also occur when multiple > processes access the disk simultaneously. I have seen a panic once last week under 9 stable. I had multiple virtual boxes running different FreeBSD versions. Each virtual host was building kernels with -j4. The host became very slow and the FreeBSD 9 virtual host paniced. I have not been able to to duplicate the panic. Larry -- ------------------------------------------------------------------------ Larry Baird | http://www.gta.com Global Technology Associates, Inc. | Orlando, FL Email: lab@gta.com | TEL 407-380-0220, FAX 407-380-6080 From owner-freebsd-current@FreeBSD.ORG Wed Oct 26 16:57:32 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35FF9106566C for ; Wed, 26 Oct 2011 16:57:32 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) by mx1.freebsd.org (Postfix) with ESMTP id C9FBC8FC18 for ; Wed, 26 Oct 2011 16:57:31 +0000 (UTC) Received: from localhost ([92.162.5.199]) by mwinf5d12 with ME id pUxS1h0034HeVn803UxSyf; Wed, 26 Oct 2011 18:57:30 +0200 X-ME-engine: default Message-ID: <4EA83BF5.4090201@orange.fr> Date: Wed, 26 Oct 2011 18:57:25 +0200 From: Claude Buisson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.23) Gecko/20110928 Thunderbird/3.1.15 MIME-Version: 1.0 To: Daniel O'Connor References: <4EA68C47.2070908@orange.fr> <4EA7C5C9.8010903@orange.fr> <4EA7DEF3.7030807@orange.fr> <7334F735-D217-471E-B5AA-151DD9204B65@gsoft.com.au> In-Reply-To: <7334F735-D217-471E-B5AA-151DD9204B65@gsoft.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , freebsd-stable@freebsd.org Subject: Re: can audio CDs be played with ATA_CAM ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Oct 2011 16:57:32 -0000 On 10/26/2011 13:50, Daniel O'Connor wrote: > > On 26/10/2011, at 20:50, Claude Buisson wrote: >>>> P.S. As I can see reading GENERIC, ATA_CAM will be the default for 9.X so there >>>> is a risk of complaints from FreeBSD workstation users (who cares ?) after the >>>> release.. >>> >>> >>> Does cdparanoia work for you? >>> >> >> With cdparanoia-3.9.8_9: YES >> >> tested on 8.2 (from Sep 18) and 9.0 (from Sep 25) both with ATA_CAM > > > Strange, I would have thought VLC would use the same sort of access method as VLC.. > > I don't know what it's trying so it's hard to know why it doesn't work :( Doing my home work step by step: I found only 1 place in VLC where the first message: [0x2caf2a3c] cdda access error: Could not set block size is emitted, after an: ioctl( p_vcddev->i_device_handle, CDRIOCSETBLOCKSIZE, &i_size ) CDRIOCSETBLOCKSIZE is defined in sys/cdrio.h, and in the kernel used in: sys/dev/ata/atapi-cd.c which is a brought into the kernel by: device atapicd So the natural question is: Is this ioctl supported with ATA_CAM (and atapicam) ? If not, what is to be used instead ? Claude Buisson From owner-freebsd-current@FreeBSD.ORG Wed Oct 26 17:04:52 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84CFB10656D0 for ; Wed, 26 Oct 2011 17:04:52 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 15B448FC14 for ; Wed, 26 Oct 2011 17:04:51 +0000 (UTC) Received: by eyd10 with SMTP id 10so2261425eyd.13 for ; Wed, 26 Oct 2011 10:04:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=OchUTJ8ZwAPh4w0iCgTuqN4hxa38mvDbUODAM1LzN8M=; b=lkG+rPIofr+YPqW1fUVkjVzvDBhzq/vPJOWIiTgJs4b2jC5WMjsOcCEUPRoz9WbeV+ QxHVlO79OKo81kK8O6sfk3M4hOKp5qN13jsYKa3BEjOuIL/pvLHf2jGJezl1m9hWDPIT MWJcM1TFr8fdyKGlGGOvOl5y6NmUfwYsKsdXg= Received: by 10.14.4.129 with SMTP id 1mr3877849eej.228.1319648690809; Wed, 26 Oct 2011 10:04:50 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id e62sm7022427eee.10.2011.10.26.10.04.49 (version=SSLv3 cipher=OTHER); Wed, 26 Oct 2011 10:04:49 -0700 (PDT) Sender: Alexander Motin Message-ID: <4EA83DB1.4070602@FreeBSD.org> Date: Wed, 26 Oct 2011 20:04:49 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.2) Gecko/20110910 Thunderbird/6.0.2 MIME-Version: 1.0 To: Dennis Koegel References: In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: current Subject: Re: gmultipath: act/act, path checking? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Oct 2011 17:04:52 -0000 Hi. On 26.10.2011 12:09, Dennis Koegel wrote: > are there any plans to have gmultipath support for active/active? > > Also, is there any way to check available paths periodically? As far as > I unterstand, once gmultipath kicks a certain path due to failure, it > will never come back automatically. (And it won't ever be used if it > isn't working at boot time) I haven't tested it, but if gmultipath behaves same as other GEOM classes with on-disk metadata, new paths should be connected automatically when detected. Boot time in GEOM is not different from later operation. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Oct 26 17:37:09 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BE5E1065673; Wed, 26 Oct 2011 17:37:09 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 44E288FC1B; Wed, 26 Oct 2011 17:37:09 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p9QHb4aN057563 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 26 Oct 2011 10:37:07 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4EA8453B.2090808@freebsd.org> Date: Wed, 26 Oct 2011 10:36:59 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20111022084931.GD1697@garage.freebsd.pl> <20111023084445.GB50300@deviant.kiev.zoral.com.ua> <20111023155827.GH1697@garage.freebsd.pl> <201110240814.22368.jhb@freebsd.org> <20111026075431.GB1672@garage.freebsd.pl> In-Reply-To: <20111026075431.GB1672@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andre Oppermann , freebsd-net@freebsd.org, freebsd-current@freebsd.org, Kostik Belousov , Lawrence Stewart Subject: Re: 9.0-RC1 panic in tcp_input: negative winow. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Oct 2011 17:37:09 -0000 On 10/26/11 12:54 AM, Pawel Jakub Dawidek wrote: > On Mon, Oct 24, 2011 at 08:14:22AM -0400, John Baldwin wrote: >> On Sunday, October 23, 2011 11:58:28 am Pawel Jakub Dawidek wrote: >>> On Sun, Oct 23, 2011 at 11:44:45AM +0300, Kostik Belousov wrote: >>>> On Sun, Oct 23, 2011 at 08:10:38AM +0200, Pawel Jakub Dawidek wrote: >>>>> My suggestion would be that if we won't be able to fix it before 9.0, >>>>> we should turn this assertion off, as the system seems to be able to >>>>> recover. >>>> Shipped kernels have all assertions turned off. >>> Yes, I'm aware of that, but many people compile their production kernels >>> with INVARIANTS/INVARIANT_SUPPORT to fail early instead of eg. >>> corrupting data. I'd be fine in moving this under DIAGNOSTIC or changing >>> it into a printf, so it will be visible. >> No, the kernel is corrupting things in other places when this is true, so >> if you are running with INVARIANTS, we want to know about it. Specifically, >> in several places in TCP we assume that rcv_adv>= rcv_nxt, and depend on >> being able to do 'rcv_adv - rcv_nxt'. >> >> In this case, it looks like the difference is consistently less than one >> frame. I suspect the other end of the connection is sending just beyond the >> end of the advertised window (it probably assumes it is better to send a full >> frame if it has that much pending data even though part of it is beyond the >> window edge vs sending a truncated packet that just fills the window) and that >> that frame is accepted ok in the header prediction case and it's ACK is >> delayed, but the next packet to arrive then trips over this assumption. >> >> Since 'win' is guaranteed to be non-negative and we explicitly cast >> 'rcv_adv - rcv_nxt' to (int) in the following line that the assert is checking >> for: >> >> tp->rcv_wnd = imax(win, (int)(tp->rcv_adv - tp->rcv_nxt)); >> >> I think we already handle this case ok and perhaps the assertion can just be >> removed? Not sure if others feel that it warrants a comment to note that this >> is the case being handled. > I added debug to the places where rcv_adv and rcv_nxt are modified. Here > is what happens before the panic occurs: > > tcp_do_segment:1722 negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022361548 rcv_adv 4022360100 diff -1448 > tcp_do_segment:2847 negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022362298 rcv_adv 4022361548 diff -750 > tcp_do_segment:1722 negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022363746 rcv_adv 4022362298 diff -1448 > tcp_do_segment:2847 negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022364836 rcv_adv 4022363746 diff -1090 > tcp_do_segment:1722 negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022366284 rcv_adv 4022364836 diff -1448 > tcp_do_segment:1722 negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022370628 rcv_adv 4022369690 diff -938 > tcp_do_segment:1722 negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022379140 rcv_adv 4022377692 diff -1448 > tcp_do_segment:1722 negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022387792 rcv_adv 4022386344 diff -1448 > tcp_do_segment:2847 negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022388890 rcv_adv 4022387792 diff -1098 > tcp_do_segment:1722 negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022390338 rcv_adv 4022388890 diff -1448 > tcp_do_segment:2847 negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022394563 rcv_adv 4022394342 diff -221 > panic: tcp_input negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022394563 rcv_adv 4022394342 win=0 diff -221 > > I can send you the full log if you want, I've plenty of messages where > rcv_adv< rcv_nxt, not all of them trigger this assertion. > Might be a good place to use the new sifter tool. From owner-freebsd-current@FreeBSD.ORG Wed Oct 26 17:48:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83648106566C for ; Wed, 26 Oct 2011 17:48:53 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.7]) by mx1.freebsd.org (Postfix) with ESMTP id 14CE58FC12 for ; Wed, 26 Oct 2011 17:48:52 +0000 (UTC) Received: from [78.34.144.218] (helo=fabiankeil.de) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1RJ7as-00086F-Mc for freebsd-current@freebsd.org; Wed, 26 Oct 2011 19:48:50 +0200 Date: Wed, 26 Oct 2011 19:45:17 +0200 From: Fabian Keil To: freebsd-current@freebsd.org Message-ID: <20111026194517.1d20472a@fabiankeil.de> In-Reply-To: <20111019230915.041aa981@fabiankeil.de> References: <20110927220015.375ac343@fabiankeil.de> <20111019230915.041aa981@fabiankeil.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/z3sbf5bJWAHfeVhd+7lMDg+"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Subject: Re: Fatal trap 12: page fault while in kernel mode -- Stopped at atomic_subtract_int+0x4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Oct 2011 17:48:53 -0000 --Sig_/z3sbf5bJWAHfeVhd+7lMDg+ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Fabian Keil wrote: > Fabian Keil wrote: >=20 > > I pretty reproducible get the following (handtranscribed) panic > > when sending an zfs snapshot to geli provider based on an USB > > stick that disappears (due to a bug, or because it's unplugged):=20 > >=20 > > Fatal trap 12: page fault while in kernel mode > > cpuid =3D 0: apic id =3D 00 > > fault virtual address =3D 0x288 > > fault code =3D supervisor write data, page not present > > instruction pointer =3D 0x20:0xffffffff808e2984 > > stack pointer =3D 0x28:0xffffff800023fba0 > > frame pointer =3D 0x28:0xffffff800023fbb0 > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > > current process =3D 13 (g_up) > > [ thread pid 13 tid 100010 ] > > Stopped at atomic_subtract_int+0x4: lock subl %esi,(%rdi) > Here's another one, again with recent HEAD. >=20 > This time the USB stick disappeared while the pool was > being scrubbed and dumping actually worked. The stick > seems to reproducibly disappear after scrubbing it for > a while and the panic seems to be reproducible as well. >=20 > The stack trace looks a bit different, but I'm not sure if > this is because it's a slightly different situation or because > of changes in HEAD. They are different and can be reproduced independently. I filed PRs for them: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D162010 http://www.freebsd.org/cgi/query-pr.cgi?pr=3D162036 Fabian --Sig_/z3sbf5bJWAHfeVhd+7lMDg+ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk6oRzIACgkQBYqIVf93VJ0V8ACfZsjtLSPiDd6kapKu/cCp1AH/ lqUAoJHA43DCK7aieEDwao9PTbzDzE+n =sSNJ -----END PGP SIGNATURE----- --Sig_/z3sbf5bJWAHfeVhd+7lMDg+-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 26 18:37:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E6101065680 for ; Wed, 26 Oct 2011 18:37:25 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 3217F8FC16 for ; Wed, 26 Oct 2011 18:37:24 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 77E153FC; Wed, 26 Oct 2011 20:37:22 +0200 (CEST) Date: Wed, 26 Oct 2011 20:36:38 +0200 From: Pawel Jakub Dawidek To: Jason Edwards Message-ID: <20111026183638.GA1676@garage.freebsd.pl> References: <7FE0AE74-7C29-4DD0-8EBA-F2BB70F3CB97@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: Re: Problems with "ada0: Previously was known as ad6" functionality X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Oct 2011 18:37:25 -0000 --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 25, 2011 at 05:01:31PM +0200, Jason Edwards wrote: > On Tue, Oct 25, 2011 at 4:35 PM, Nikolay Denev wrote: > > I was struck with this problem too yesterday. > > I was able to import the pool by specifying the directory where zpool s= hould look for devices. > > Like : zpool import -d /dev/gptid > > Alternatively you can try putting kern.cam.ada.legacy_aliases=3D0 in yo= ur /boot/loader.conf >=20 > Hello Nikolay, >=20 > Thanks for your reply! >=20 > The kern.cam.ada.legacy_aliases=3D0 indeed makes the /dev/ad6 device go > away. However, unlike I suspected, it did not solve the zpool import > problem. It still lists my pool as corrupted. If I use the zpool > import -d /dev/gpt as you suggested, the pool displays as ONLINE and I > can import it just fine. Using -d /dev works too, so I guess this > works fine as a workaround. Hmm, that's really strange. 'zpool import -d /dev ' works, but 'zpool import ' doesn't? Does, eg. 'geom disk status' work or returns an error? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk6oUzUACgkQForvXbEpPzTwtgCfbLa22XHqIh6MUfX4z8k9KxxS YKgAoKcDKWqUXy6GhhMp9muTtLsm3/SW =IjpE -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 26 18:58:46 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18840106564A for ; Wed, 26 Oct 2011 18:58:46 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by mx1.freebsd.org (Postfix) with SMTP id 842C98FC14 for ; Wed, 26 Oct 2011 18:58:45 +0000 (UTC) Received: (qmail invoked by alias); 26 Oct 2011 18:32:03 -0000 Received: from 85-127-76-245.dynamic.xdsl-line.inode.at (EHLO walrus.pepperland) [85.127.76.245] by mail.gmx.net (mp026) with SMTP; 26 Oct 2011 20:32:03 +0200 X-Authenticated: #16703784 X-Provags-ID: V01U2FsdGVkX19u0zEMnu5ueylgWTthMESc13xaBQPin5JEzaoMYu Ukhix/8haOSx2S From: Stefan Ehmann To: freebsd-current@freebsd.org Date: Wed, 26 Oct 2011 20:32:02 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.0-RC1; KDE/4.7.2; i386; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201110262032.02894.shoesoft@gmx.net> X-Y-GMX-Trusted: 0 Subject: usbus seen as network devices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Oct 2011 18:58:46 -0000 I've noticed that with 9.0-RC1, usbus[0-9] are seen as network interfaces. I figured this is need for usbdump to work. (This isuue has been raised before [1], but no helpful replies were given). I find this behavior rather annoying: 1) usbus0 is the default interface (in 8.2, my primary network interface was default) # tcpdump tcpdump: WARNING: usbus0: That device doesn't support promiscuous mode (BIOCPROMISC: Operation not supported) tcpdump: WARNING: usbus0: no IPv4 address assigned tcpdump: packet printing is not supported for link type USB: use -w 2) Various tools (netstat, tcpdump, wireshark, my network monotoring dockapp) now list 8 additional interfaces: # netstat -i Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll usbus 0 0 0 0 0 0 0 usbus 0 0 0 0 0 0 0 ... 3) I can do rather silly things, that at best will do nothing: # ifconfig usbus0 10.0.0.1 # usbdump -i lo0 Some applications seem to check the link type, so that unsupported interfaces are not shown. But the behavior isn't even consistent in the base system: - ifconfig -a doesn't show usbus interfaces, but lets you happily configure them - tcpdump -D shows the interfaces, but bails out if you actually start capturing - netstat shows them - systat -ifstat only lists real interfaces Do all these applications need to be patched, or can this be fixed in a single place (in the kernel)? Is there a kernel option/sysctl/etc. to disable this behavior? I'm most likely not going to need usbdump in the foreseeable future. [1] http://lists.freebsd.org/pipermail/freebsd-stable/2011- September/063941.html -- Stefan From owner-freebsd-current@FreeBSD.ORG Wed Oct 26 19:37:48 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9497D106564A; Wed, 26 Oct 2011 19:37:48 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id E8F888FC16; Wed, 26 Oct 2011 19:37:47 +0000 (UTC) Received: by mail-bw0-f54.google.com with SMTP id zt4so2328756bkb.13 for ; Wed, 26 Oct 2011 12:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=P4/77/2YJkIkFJ5QEeJz4k0yMhqS2MYF6lL0zwPKLUc=; b=s1aS8+4vKW/lml8j/SfRgVZwolGoQj/LS3BiBG8MM4eRF6ypNexCi83MIDUf9xXhJW 5OII3d+iBlVDljtE9Eqo6PvuQfByTRzb0xKsRTpBQCZLkSPhgF/LmIZNEoLlN4av7fi4 oAxtdLEaxnXjtpQG/mbm3XKuSxc+E5CT5TaQA= MIME-Version: 1.0 Received: by 10.204.38.16 with SMTP id z16mr13873082bkd.66.1319657867513; Wed, 26 Oct 2011 12:37:47 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.204.39.12 with HTTP; Wed, 26 Oct 2011 12:37:47 -0700 (PDT) In-Reply-To: <4EA83BF5.4090201@orange.fr> References: <4EA68C47.2070908@orange.fr> <4EA7C5C9.8010903@orange.fr> <4EA7DEF3.7030807@orange.fr> <7334F735-D217-471E-B5AA-151DD9204B65@gsoft.com.au> <4EA83BF5.4090201@orange.fr> Date: Wed, 26 Oct 2011 12:37:47 -0700 X-Google-Sender-Auth: r3EkPNEtyD_PdJAA4Ws36AMEWMo Message-ID: From: Craig Rodrigues To: Claude Buisson Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current , freebsd-stable@freebsd.org Subject: Re: can audio CDs be played with ATA_CAM ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Oct 2011 19:37:48 -0000 On Wed, Oct 26, 2011 at 9:57 AM, Claude Buisson wrote: > > Doing my home work step by step: > > I found only 1 place in VLC where the first message: > > [0x2caf2a3c] cdda access error: Could not set block size > > is emitted, after an: > > ioctl( p_vcddev->i_device_handle, CDRIOCSETBLOCKSIZE, &i_size ) > > CDRIOCSETBLOCKSIZE is defined in sys/cdrio.h, and in the kernel used in: > > sys/dev/ata/atapi-cd.c > > which is a brought into the kernel by: > > device atapicd > > So the natural question is: > > Is this ioctl supported with ATA_CAM (and atapicam) ? > > If not, what is to be used instead ? Claude, Thanks for digging into this a bit. I just added some code to make it easier for applications to detect at runtime if ATA_CAM has been configured in the kernel: http://lists.freebsd.org/pipermail/svn-src-stable-9/2011-October/000114.html I am not 100% sure how the CD driver works with ATA_CAM. I think you might need to look at: src/sys/cam/scsi/scsi_cd.c and also read the cd(4) man page. We may need to extend scsi_cd.c, but I'm not sure. -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Wed Oct 26 23:09:26 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96472106564A for ; Wed, 26 Oct 2011 23:09:26 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 566F78FC1A for ; Wed, 26 Oct 2011 23:09:26 +0000 (UTC) Received: by qyg14 with SMTP id 14so2881282qyg.13 for ; Wed, 26 Oct 2011 16:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=Z+ErzC8hUodPGWsUshUfTURqFI8rr1CTs9wnVK0vcgo=; b=rJDUrFS89Xt6xxsVyHa5/V974Sm9BTZET4MjbQMVyEb5gM1/N2Fd3SG7CVhd5K+DHW UKDpNX6gkvScdb6lFUeaO5vK5/zqurlZsS79NNrDSYuCptL3/rWGcHARExQijHttYLtO nrvjS7PGqVC1RLkaKGj8ESzFUSSxbKtzl9BwY= MIME-Version: 1.0 Received: by 10.182.111.33 with SMTP id if1mr1536900obb.29.1319670565506; Wed, 26 Oct 2011 16:09:25 -0700 (PDT) Received: by 10.182.42.167 with HTTP; Wed, 26 Oct 2011 16:09:25 -0700 (PDT) Date: Wed, 26 Oct 2011 19:09:25 -0400 Message-ID: From: Mehmet Erol Sanliturk To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: FreeBSD 9.0 amd64 RC1 and KDE4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Oct 2011 23:09:26 -0000 The KDE4 in FreeBSD 9.0 RC1 amd64 is generating enormous amount of error messages during usage ( not visible on screen , but seen after Ctrl-Alt-F1 discontinuation of X ) . This is making it extremely slow which may be considered to be practically unusable . Actually parts are working generally but every step is waiting so much that such a usage is not practically applicable . The KDE4 in FreeBSD 9.0 RC1 i386 is working satisfactorily , but for memory requirements , it is not an alternative . There are important usability differences between both architectures with respect to KDE4 execution . One alternative is mentioned as PC-BSD , but installation of PC-BSD is NOT possible : In PC-BSD 8.2 amd64 Release and following snapshot(s) , within 18 ( eighteen ) hours , only a small percent ( less than % 10 ) could be installed . Now , in PC-BSD 9.0 RC1 amd64 , I am still waiting : In 4 ( four ) hours it could come to "Installing Meta Package : base-system" . Such an installation structure is really unusable . I will discontinue it because it seems that complete install will require many days with that speed . I am continuously installing many other distributions which mostly they are consuming time around thirty minutes ( except upgrade during installation , if it is selected ) . Thirty minutes may be considered an acceptable duration for installation , let's say , time less than one hour as endurable . It should not be forgotten that , the task is copy of approximately 4 Giga Bytes to hard disk from a DVD-Rom with an additional decompressing of files . Therefore , for the KDE4 users in the amd64 platform , there is a big problem . This was also the case for 8.2 amd64 Release . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Wed Oct 26 23:47:08 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 197A9106564A for ; Wed, 26 Oct 2011 23:47:08 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 9F3428FC0C for ; Wed, 26 Oct 2011 23:47:07 +0000 (UTC) Received: by wwi18 with SMTP id 18so3164225wwi.31 for ; Wed, 26 Oct 2011 16:47:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Wyz10GBy6oO2cdA/Q4e//I5UClA8NxZp5Z1re0t3c1w=; b=I8N0BV5PoDhctHHni9L2NuiHKQx2TRiJBPE9LT4FQWgEF+uJIbWjQnwh1LIcoDq26G SH4x9FRnv76U5HLgq6VntNMCKYEiiIMLHQdOK2DSF/pgDHwhhBcdg/ymltRAEFifge57 2h9R+JgdAAvzqBmVffv5D5XJOirkXa9tcNoW8= MIME-Version: 1.0 Received: by 10.227.199.5 with SMTP id eq5mr13041000wbb.2.1319672826578; Wed, 26 Oct 2011 16:47:06 -0700 (PDT) Received: by 10.180.105.162 with HTTP; Wed, 26 Oct 2011 16:47:06 -0700 (PDT) In-Reply-To: References: Date: Wed, 26 Oct 2011 19:47:06 -0400 Message-ID: From: Arnaud Lacombe To: Mehmet Erol Sanliturk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: FreeBSD 9.0 amd64 RC1 and KDE4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Oct 2011 23:47:08 -0000 Hi, On Wed, Oct 26, 2011 at 7:09 PM, Mehmet Erol Sanliturk wrote: > The KDE4 in FreeBSD 9.0 RC1 amd64 is generating enormous amount of error > messages during usage ( not visible on screen , but seen after Ctrl-Alt-F= 1 > discontinuation of X ) . This is making it extremely slow which may be > considered to be practically unusable . Actually parts are working genera= lly > but every step is waiting so much that such a usage is not practically > applicable . > What are the message(s) ? Thanks, - Arnaud > The KDE4 in FreeBSD 9.0 RC1 i386 is working satisfactorily , but for memo= ry > requirements , it is not an alternative . > > There are important usability differences between both architectures with > respect to KDE4 execution . > > > One alternative is mentioned as PC-BSD , but installation of PC-BSD is NO= T > possible : > > In PC-BSD 8.2 amd64 Release and following snapshot(s) , within 18 ( eight= een > ) hours , only a small percent ( less than % 10 ) could be installed . > Now , in PC-BSD 9.0 RC1 amd64 , I am still waiting : In 4 ( four ) hours = it > could come to "Installing Meta Package : base-system" . > Such an installation structure is really unusable . I will discontinue it > because it seems that complete install will require many days with that > speed =A0. > > I am continuously installing many other distributions which mostly they a= re > consuming time around thirty minutes ( except upgrade during installation= , > if it is selected ) =A0. > > Thirty minutes may be considered an acceptable duration for installation = , > let's say , time less than one hour as endurable . > It should not be forgotten that , the task is copy of approximately 4 Gig= a > Bytes to hard disk from a DVD-Rom with an additional decompressing of fil= es > . > > Therefore , for the KDE4 users in the amd64 platform , there is a big > problem . > > This was also the case for 8.2 amd64 Release . > > > > Thank you very much . > > > Mehmet Erol Sanliturk > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Thu Oct 27 00:03:35 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B421106568A; Thu, 27 Oct 2011 00:03:35 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 845468FC08; Thu, 27 Oct 2011 00:03:35 +0000 (UTC) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 59D90D2DC; Wed, 26 Oct 2011 17:03:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1319673815; bh=oOWZni+TkwydR2k/Gvot9y0cyFTVOGQUxEpHTIm1zgQ=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: Content-Type:Content-Transfer-Encoding; b=DqLKRRIXktKVFPti1TVTxntl+9SFko47nv6bhjfw/FrpoFYVjdgqm2MV/rz3z/4NH 2Ii54ZicbycvwKxlbrTvxyp0y91GDT3jFeG4UyIXm5Ujh/pJepbbdmSUMGP7gtjUlj PhBLohMq5DnVTCf2A9mwHeDzMzmTi/tHsdlkNHCo= Message-ID: <4EA89FD6.4010900@delphij.net> Date: Wed, 26 Oct 2011 17:03:34 -0700 From: Xin LI Organization: The FreeBSD Project MIME-Version: 1.0 To: FreeBSD Current OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: alc@FreeBSD.org Subject: Should process in STOP state be swapped out? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 00:03:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I've noticed that if I kill -STOP a process, the in-core size does not change even when there is memory pressure (what I'm expecting is that if there is memory pressure, the process's in-core part gets swapped out from time to time). Is this behavior intentional? Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJOqJ/WAAoJEATO+BI/yjfBRSIIAMeAhK/IeHHiPQUDQ6mBpilT IyA5AjnI8Gcx4XubgR7vD5Wh29X/fTakj0GIIRDX9b6ooVsr0WjCeg+xnl4LDTn1 oxw6ba42jZq1PVbgUoTS5X8n8XnfDIocCDLh2yVxaaOYMFrpS6gqYTkhMYU3GwwM uxoUxRDRiLbJ5KTTYOsBj32ZB/JF7HoUmZtWZcfUX+6oIXnM777DVc52TpCH7six prDMcX5PRmWyAIzjmuxuGrc0KrLLH/QemYW11tlFM/TRLbtCtq0oIynB1PI6aIg7 Z1K0RAgOtvAroUAm5FchFYTFsPm01GhWOZe57gGKgoF4TlnzkM2Es0Vo27w9wP8= =saI5 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Oct 27 00:04:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E14AC106568A for ; Thu, 27 Oct 2011 00:04:17 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 65F848FC23 for ; Thu, 27 Oct 2011 00:04:17 +0000 (UTC) Received: by faar19 with SMTP id r19so2945217faa.13 for ; Wed, 26 Oct 2011 17:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:from:organization:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=dJf1ERhSYGc09AuwqUGpZqQIS0nihVV63dsd7CGNkoM=; b=mW+LHE2sd9sA6UFqnvWhtf7nYRyhQBcmjS6KKQiuAWoNvKNTRWBWDmRKyORkg6WK79 8pC4yaBcGnrf+raLfjr9nwsGk/HgBcl4X3NJYiCmvf34KHx4FwOkJxQM3ZJxBxYpjoNS AYqICnHcB288GbawYY/6gDJ1TRaxGD1x7mOq8= Received: by 10.223.58.146 with SMTP id g18mr36008271fah.13.1319672026619; Wed, 26 Oct 2011 16:33:46 -0700 (PDT) Received: from woodstock.peanuts (host9-68-dynamic.10-188-r.retail.telecomitalia.it. [188.10.68.9]) by mx.google.com with ESMTPS id t19sm7070390fac.0.2011.10.26.16.33.45 (version=SSLv3 cipher=OTHER); Wed, 26 Oct 2011 16:33:45 -0700 (PDT) Sender: Alberto Villa From: Alberto Villa Organization: The FreeBSD Project To: freebsd-current@freebsd.org Date: Thu, 27 Oct 2011 01:33:40 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.0-RC1; KDE/4.7.2; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart77630565.P7x90MYyp9"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201110270133.44259.avilla@freebsd.org> Cc: kde@freebsd.org Subject: Re: FreeBSD 9.0 amd64 RC1 and KDE4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2011 00:04:18 -0000 --nextPart77630565.P7x90MYyp9 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thursday 27 October 2011 01:09:25 Mehmet Erol Sanliturk wrote: > The KDE4 in FreeBSD 9.0 RC1 amd64 is generating enormous amount of=20 error > messages during usage ( not visible on screen , but seen after Ctrl- Alt-F1 > discontinuation of X ) . This is making it extremely slow which may be > considered to be practically unusable . Actually parts are working > generally but every step is waiting so much that such a usage is not > practically applicable . You didn't say anything about those error messages, though. It might=20 come useful. We keep trying to improve the situation thanks to reports=20 from our users. > Therefore , for the KDE4 users in the amd64 platform , there is a big > problem . >=20 > This was also the case for 8.2 amd64 Release . Actually, you're the first one to report such a problem. If this "was also= =20 the case for 8.2" you could have said it earlier. Any chance to get some=20 help from you to investigate the issue? =2D-=20 Alberto Villa, FreeBSD committer http://people.FreeBSD.org/~avilla Man who arrives at party two hours late will find he has been beaten to the punch. --nextPart77630565.P7x90MYyp9 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iJwEAAECAAYFAk6omNgACgkQ3xiC6kQ1CovJdwP/fmDZB6m6f9wgSLF4jpoY0qCU SF68zy2p1P+HWQnqqjOoEla4h1IEPq0O9HTPXBexGXQDiodbxLAC0lTpDWzmuB/W EENnYoM94Oxqmj+5rVUpbmOXuNldAb2S+UCnaoQNNG2n9H1+x6Wx8rDEsyhd8TIq EkHEsEkeNp3Xp+z67Hc= =Y62t -----END PGP SIGNATURE----- --nextPart77630565.P7x90MYyp9-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 27 01:01:48 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 273E71065673; Thu, 27 Oct 2011 01:01:48 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id BF07E8FC0C; Thu, 27 Oct 2011 01:01:47 +0000 (UTC) Received: by qyg14 with SMTP id 14so2995922qyg.13 for ; Wed, 26 Oct 2011 18:01:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dJnQatSo9nYn06v8D4Vf32iMmCVIr9BtHUiLQTXrLJc=; b=DfVegSfCjjVfPyAESspZFVpq0oqrXDUpLLgoMESPckJUSKC9DMc2rzDC7hvD4PuvvD iNuIxkmxYd512nvFe2+a3TeCxTTQbh6mevuydF2ZzA89/jor5bYrEjrGNS5reul7PEeu cLAE3DDRjR/e/K/iw1LBRQuJFQkdmkykg+2EY= MIME-Version: 1.0 Received: by 10.182.136.68 with SMTP id py4mr5864849obb.39.1319675651649; Wed, 26 Oct 2011 17:34:11 -0700 (PDT) Received: by 10.182.42.167 with HTTP; Wed, 26 Oct 2011 17:34:11 -0700 (PDT) In-Reply-To: <201110270133.44259.avilla@freebsd.org> References: <201110270133.44259.avilla@freebsd.org> Date: Wed, 26 Oct 2011 20:34:11 -0400 Message-ID: From: Mehmet Erol Sanliturk To: Alberto Villa Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, kde@freebsd.org Subject: Re: FreeBSD 9.0 amd64 RC1 and KDE4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2011 01:01:48 -0000 On Wed, Oct 26, 2011 at 7:33 PM, Alberto Villa wrote: > On Thursday 27 October 2011 01:09:25 Mehmet Erol Sanliturk wrote: > > The KDE4 in FreeBSD 9.0 RC1 amd64 is generating enormous amount of > error > > messages during usage ( not visible on screen , but seen after Ctrl- > Alt-F1 > > discontinuation of X ) . This is making it extremely slow which may be > > considered to be practically unusable . Actually parts are working > > generally but every step is waiting so much that such a usage is not > > practically applicable . > > You didn't say anything about those error messages, though. It might > come useful. We keep trying to improve the situation thanks to reports > from our users. > > > Therefore , for the KDE4 users in the amd64 platform , there is a big > > problem . > > > > This was also the case for 8.2 amd64 Release . > > Actually, you're the first one to report such a problem. If this "was also > the case for 8.2" you could have said it earlier. Any chance to get some > help from you to investigate the issue? > -- > Alberto Villa, FreeBSD committer > http://people.FreeBSD.org/~avilla > > Man who arrives at party two hours late > will find he has been beaten to the punch. > In a message previously I mentioned the KDE4 problem for 8.2 amd64 Release , but that message even did not receive a single reply . Always I may help with pleasure , but I do not know how . I think the problem is not related to hardware because i386 KDE4 is working very well . On the same computer , there are four hard disks , and each disk has a different operating system , mostly 64 bit ones . All of them using KDE4 and working very well . If you consider useful , my ideas are following : During start-up of KDE4 , screen is painted with its wall paper only . Since X is already running , it is possible to open a window and display messages on it with possible saving to a text file . This file may be transmitted to experts for possible studies . At present , monitors are cheap . I want to install multiple monitors on the same computer to watch serial console output on a regular ( VGA ) monitor ( because in market , there is NO any serial console on sale in computer shops ( I am in Turkey )) . Really , I do not know how to implement a regular ( VGA ) computer instead of a serial console . A very good application in FreeBSD may be to allow such a multiple monitor definition during install and use them for virtual terminals simultaneously . Using a second computer for serial console is not very practical due to software and hardware problems . If you know my actual problem , you may understand me better . I am writing a multimedia information management system as continuation of my PhD thesis feasibility demonstration program . Due to health problems it is progressing very slowly . My primary aim is to base it on a free , permissive , open source operating system . My program , with a freely usable version , will be closed source ( for sale , if I can do ) . I need a permissive ( BSD like licensed ) operating system , because a data base without operating system support can not be secure in itself . Unfortunately , I am using Pascal only , Fortran for scientific programming and very rarely C , ( with a knowledge of other many programming languages ) . I want to start on working internal structure of an operating system . Linux is NOT usable due to GPL . Minix ( does not have a capable Pascal ) , Haiku , are not sufficiently mature . NetBSD , OpenBSD , DragonFlyBSD are not better than FreeBSD . OpenSolaris died , OpenIndiana is using copyright dependent parts . The most viable selection is FreeBSD for 64 bits ... In such an environment , usability of multiple terminals ( monitors ) simultaneously as distinct display areas with output direction possibility via parameter files would be very useful . Assume values are written into distinct files , where files are monitors . Not only for my own benefits , also for contribution to humanity ( My main hobby was to write mathematical analysis programs to support researches , with very hard work : Conclusion : My wife had divorced me with a complaint that I am studying very much , occupying home with computers , etc. ) , I always wish to make contributions to FreeBSD because of its very good license ( even commercial companies may use it freely which is a very good decision for me ) and its high quality . To test the KDE4 in FreeBSD 9.0 amd64 RC1 , you can do the following : Install X . Install KDE4 . Login to console . Without an .xinitrc file , and unmodified /etc/ttys file , execute startx . ( Do not start KDE4 directly . ) In right xterm window of X , execute /usr/local/kde4/bin/startkde ( /usr/local/kde4/bin is not in path definition ) . In that terminal , you will see a lot of messages . After display of messages , a form will appear to display KDE4 . Then , I do not know , but , even this will supply much information about what is going problematic . Correction of first displayed errors and continuing in that way , will solve the problems one by one . If KDE4 is starting directly , during waiting after display of hard disk symbol , discontinuation of X with Ctrl-Alt-F1 will reveal some messages , but last ones . Therefore , the above method is better than that second method . If xterm buffer keeps all of the messages , no one of them will be lost . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Thu Oct 27 01:07:44 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B08C41065670 for ; Thu, 27 Oct 2011 01:07:44 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 686208FC12 for ; Thu, 27 Oct 2011 01:07:44 +0000 (UTC) Received: by qadz32 with SMTP id z32so2880651qad.13 for ; Wed, 26 Oct 2011 18:07:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XAVrWUhJ52Ysf9+s41yxcRRBbkS2BWl2ArVCxxR/u0k=; b=vo42Al9LqG9hZ3xdfseUfwzgBmf3fTixbQHnHF3XDFxBKvAcTFovIpBb9fpfRxbdLx Ou/AUf6Sv0ERCnxBicYBiH3bXu6yw7aKQ5NDsAMAfVz19n5g3YzWhRPn7JmGBTtClLzc lw9Ym644LEWj9Sa7qn18SQISsiB2PUQDDrV5Y= MIME-Version: 1.0 Received: by 10.224.52.131 with SMTP id i3mr27256087qag.11.1319677663514; Wed, 26 Oct 2011 18:07:43 -0700 (PDT) Received: by 10.224.19.212 with HTTP; Wed, 26 Oct 2011 18:07:43 -0700 (PDT) In-Reply-To: References: Date: Wed, 26 Oct 2011 21:07:43 -0400 Message-ID: From: Mehmet Erol Sanliturk To: Arnaud Lacombe Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Current Subject: Re: FreeBSD 9.0 amd64 RC1 and KDE4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2011 01:07:44 -0000 On Wed, Oct 26, 2011 at 7:47 PM, Arnaud Lacombe wrote: > Hi, > > On Wed, Oct 26, 2011 at 7:09 PM, Mehmet Erol Sanliturk > wrote: > > The KDE4 in FreeBSD 9.0 RC1 amd64 is generating enormous amount of error > > messages during usage ( not visible on screen , but seen after > Ctrl-Alt-F1 > > discontinuation of X ) . This is making it extremely slow which may be > > considered to be practically unusable . Actually parts are working > generally > > but every step is waiting so much that such a usage is not practically > > applicable . > > > What are the message(s) ? > > Thanks, > - Arnaud > > > The KDE4 in FreeBSD 9.0 RC1 i386 is working satisfactorily , but for > memory > > requirements , it is not an alternative . > > > > There are important usability differences between both architectures with > > respect to KDE4 execution . > > > > > > One alternative is mentioned as PC-BSD , but installation of PC-BSD is > NOT > > possible : > > > > In PC-BSD 8.2 amd64 Release and following snapshot(s) , within 18 ( > eighteen > > ) hours , only a small percent ( less than % 10 ) could be installed . > > Now , in PC-BSD 9.0 RC1 amd64 , I am still waiting : In 4 ( four ) hours > it > > could come to "Installing Meta Package : base-system" . > > Such an installation structure is really unusable . I will discontinue it > > because it seems that complete install will require many days with that > > speed . > > > > I am continuously installing many other distributions which mostly they > are > > consuming time around thirty minutes ( except upgrade during installation > , > > if it is selected ) . > > > > Thirty minutes may be considered an acceptable duration for installation > , > > let's say , time less than one hour as endurable . > > It should not be forgotten that , the task is copy of approximately 4 > Giga > > Bytes to hard disk from a DVD-Rom with an additional decompressing of > files > > . > > > > Therefore , for the KDE4 users in the amd64 platform , there is a big > > problem . > > > > This was also the case for 8.2 amd64 Release . > > > > > > > > Thank you very much . > > > > > > Mehmet Erol Sanliturk > Please see my reply to Alberto Villa . ( I am installing onto a single hard disk , I am NOT using any virtual machine . I consider using virtual machine in final testing an important error because at the end the distribution will be installed onto a bare metal . ) On that hard disk , I was trying to install PC-BSD 9.0 amd64 RC1 , to check its KDE4 usage , but due to its very long install time , I have discontinued it and I have Installed Scientific Linux . It is using KDE4 and it is working very well . Therefore , I will not be able to supply any error message at present . My opinion is that , the error messages are not directly related to my computer , but inconsistencies between compiled parts . For example , one message was about : kcheckrunning is not found . This was in /usr/local/kde4/bin directory . By thinking PATH is not properly defined , I have included /usr/local/kde4/bin into PATH , but that did not solve any problem . I have checked the 9.0 i386 RC1 PATH . It does not contain /usr/local/kde4/bin . I have studied /usr/local/kde4/bin/startkde script ( without much understanding ) of 9.0 amd64 RC1 . It seems that , it is defining path itself . I do not know whether its definition is correct or not . Perhaps the problem is in those definitions . Additionally there was "...?... crashed" messages . I do not know . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Thu Oct 27 02:51:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFADA106564A; Thu, 27 Oct 2011 02:51:37 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 374D18FC13; Thu, 27 Oct 2011 02:51:36 +0000 (UTC) Received: by vws11 with SMTP id 11so3089089vws.13 for ; Wed, 26 Oct 2011 19:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=2Y13/4sJM551POC800SxeCYv3q2sMGhQ2oE6bYj9DbI=; b=hX+igjf+3PZ9G60V06kviQnbNYPeVKf97Gv+xOCQPHhvgMewNgKCxDFh/Dksi9xJsk 6swB1sJjUWtB6/qxeMv1i1sdL+8InQWJbKHhjWijxz9me28zlt4XGwiA4k1yzcExBAYn fWl7zFaQDr+7iKfoXuwiv4duXJQsRN6hxneNw= MIME-Version: 1.0 Received: by 10.52.37.167 with SMTP id z7mr470656vdj.112.1319683896460; Wed, 26 Oct 2011 19:51:36 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.52.176.1 with HTTP; Wed, 26 Oct 2011 19:51:36 -0700 (PDT) In-Reply-To: References: <201110270133.44259.avilla@freebsd.org> Date: Thu, 27 Oct 2011 10:51:36 +0800 X-Google-Sender-Auth: xPASo_RY5UgM89PJJK1knKECvvc Message-ID: From: Adrian Chadd To: Mehmet Erol Sanliturk Content-Type: text/plain; charset=ISO-8859-1 Cc: Alberto Villa , freebsd-current@freebsd.org, kde@freebsd.org Subject: Re: FreeBSD 9.0 amd64 RC1 and KDE4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2011 02:51:37 -0000 You could try something like: script startx Then exit X when it's done, and the script command should've put the output into a text file for you. adrian From owner-freebsd-current@FreeBSD.ORG Thu Oct 27 08:24:01 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66D66106566B; Thu, 27 Oct 2011 08:24:01 +0000 (UTC) (envelope-from etnapierala@googlemail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id C52858FC12; Thu, 27 Oct 2011 08:24:00 +0000 (UTC) Received: by wyi40 with SMTP id 40so3356616wyi.13 for ; Thu, 27 Oct 2011 01:23:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=yc5syw1bH4szGCjuQGKKv8sgvpYUyyUqF5j0iqJfSec=; b=DN6bYP3juU+VKd+b2YdC0ukWi/nHuaLHTpNGdSlyDLfH4A/Y/HL4FnSb17hdntnaPW oJQhxLoaQESnpukaUPgXAvuG2LHLNVF6cgQGZNyQ3ikriihTpiuMfg+9kE0f0ikCT175 mubP/hVQbGgTNlVJ04wJNyvWpBFqjtImMQ3EE= Received: by 10.216.14.89 with SMTP id c67mr14558wec.32.1319702088630; Thu, 27 Oct 2011 00:54:48 -0700 (PDT) Received: from enapierala.whl (58.wheelsystems.com. [83.12.187.58]) by mx.google.com with ESMTPS id a27sm7698147wbp.16.2011.10.27.00.54.47 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 27 Oct 2011 00:54:47 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <4EA89FD6.4010900@delphij.net> Date: Thu, 27 Oct 2011 09:54:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <490668A9-95A0-42FF-9B59-57FFBC73F020@FreeBSD.org> References: <4EA89FD6.4010900@delphij.net> To: d@delphij.net X-Mailer: Apple Mail (2.1251.1) Cc: alc@FreeBSD.org, FreeBSD Current Subject: Re: Should process in STOP state be swapped out? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2011 08:24:01 -0000 Wiadomo=B6=E6 napisana przez Xin LI w dniu 27 pa=BC 2011, o godz. 02:03: > I've noticed that if I kill -STOP a process, the in-core size does not > change even when there is memory pressure (what I'm expecting is that > if there is memory pressure, the process's in-core part gets swapped > out from time to time). Is this behavior intentional? Which version is this? I've fixed a very similar problem in r220387. --=20 If you cut off my head, what would I say? Me and my head, or me and my = body? From owner-freebsd-current@FreeBSD.ORG Thu Oct 27 10:21:06 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 505E21065670; Thu, 27 Oct 2011 10:21:06 +0000 (UTC) (envelope-from erwin@mail.droso.net) Received: from mail.droso.net (grizzly.droso.net [IPv6:2a01:4f8:100:9424::3]) by mx1.freebsd.org (Postfix) with ESMTP id E0F438FC13; Thu, 27 Oct 2011 10:21:05 +0000 (UTC) Received: by mail.droso.net (Postfix, from userid 1001) id 83E5C8742A; Thu, 27 Oct 2011 12:21:04 +0200 (CEST) Date: Thu, 27 Oct 2011 12:21:04 +0200 From: Erwin Lansing To: freebsd-ports@freebsd.org Message-ID: <20111027102104.GZ27932@droso.net> References: <20111011063602.GO68552@droso.net> <20111017153551.23281532@tetcu.info> <20111017135130.d9caa4f1.stas@FreeBSD.org> <20111018223146.GA93539@server.vk2pj.dyndns.org> <20111019105938.5aa842a4@FreeBSD.org> <20111019010420.646c0938.stas@FreeBSD.org> <20111019113136.316cb665@FreeBSD.org> <20111021124434.07c96389@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20111021124434.07c96389@FreeBSD.org> X-Operating-System: FreeBSD/amd64 8.2-RELEASE-p3 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@FreeBSD.org Subject: Re: [UPDATE] Re: Update on ports on 10.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, 27 Oct 2011 10:21:06 -0000 On Fri, Oct 21, 2011 at 12:44:34PM +0300, Ion-Mihai Tetcu wrote: > > > > What, on the other hand, makes sense is to have the fix that > > > > should include: > > > > a) a KNOB (WITH_FBSD10_FIX or similar), > > > > b) that only is run from bsd.port.mk when OSVERSION>1000000 > > > > c) runs the latest version of the above patch. > > > > The KNOB's existence allow us to turn on the fix only for broken > > > > ports, and easily know what these broken ports are -- so we can > > > > poke maintainers from time to time about upstream fixes, ... > > > > > Erwin is currently running a build on i386-10 with this and the > following patches: > - bsd.port.mk patch from beat (based on ed@, jilles@ and stas@ patches) > - python patch from beat > - python patch from linimon > - WITH_FBSD10_FIX in: > - textproc/expat2 > - devel/pcre > - devel/libtool > - audio/libogg > Results by Monday. > These patches have now been committed to the tree, notably with lang/python27 missing in the above list but was included as well. There have been some proposals already and we can now incrementally improve the workaround and, more importantly, start fixing individual ports. Please note that the patch tries to balance between being a general enough fix to make it easy to get a working system running while not just swiping the whole issue under the rug and forget about it until the next release cycle. Make sure to send any fixes upstream to the hack can be removed from the ports again. Thanks for all your patience and thanks for all those involved, especially beat who sent many patches and improvements. Erwin -- Erwin Lansing http://droso.org Prediction is very difficult especially about the future erwin@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Oct 27 10:22:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88BFB106564A for ; Thu, 27 Oct 2011 10:22:08 +0000 (UTC) (envelope-from mueller6727@bellsouth.net) Received: from fmailhost04.isp.att.net (fmailhost04.isp.att.net [204.127.217.104]) by mx1.freebsd.org (Postfix) with ESMTP id 789838FC0A for ; Thu, 27 Oct 2011 10:22:08 +0000 (UTC) Date: Thu, 27 Oct 2011 10:22:05 +0000 (GMT) X-Comment: Sending client does not conform to RFC822 minimum requirements X-Comment: Date has been added by Maillennium Received: from localhost (adsl-68-18-76-138.sdf.bellsouth.net[68.18.76.138]) by isp.att.net (frfwmhc04) with SMTP id <20111027102205H0400ism2ae>; Thu, 27 Oct 2011 10:22:05 +0000 X-Originating-IP: [68.18.76.138] From: "Thomas Mueller" To: freebsd-current@freebsd.org Message-Id: <20111027102208.88BFB106564A@hub.freebsd.org> Subject: 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: Thu, 27 Oct 2011 10:22:08 -0000 I just finished the upgrade from source from 9.0-BETA2 to RC1, and I find two problems. First, I lost my users; nonroot user names are not recognized, if for instance I type passwd arlene I already tried to login as arlene with old password, no good. I copied the /etc directory to a backup on another disk cp -Rp /etc /media/etcbackup-BETA2 and then copied back /media/etcbackup-BETA2/passwd (and group) to /etc but that didn't help. Do I have to recreate nonroot users from scratch? Also, I got a warning about DBUS not starting. When I tried to startx as root, I got into X, but mouse and keyboard were nonfunctional; I did type Ctrl-Alt-F1 and Ctrl-C to get out of X. I think it was the second mergemaster part. Should I, as root and X not running, do mv /etc /etcbackup-RC1 and cp -Rp /media/etcbackup-BETA2 /etc where /media would be mount point for backup partition on USB 3.0 hard drive? The second invocation of mergemaster (after booting single-user) can wreak havoc on /etc . As I type this, I am in my older installation of FreeBSD 9.0-BETA1 but have access to RC1 partition. By the way, /etc/rc.conf remained intact, showing that hald_enable and dbus_enable are still there: hostname="amelia2" keymap=us.iso.kbd ifconfig_re0="DHCP" ifconfig_re0_ipv6="inet6 accept_rtadv" sshd_enable="YES" moused_enable="YES" ntpd_enable="YES" hald_enable="YES" dbus_enable="YES" Tom From owner-freebsd-current@FreeBSD.ORG Thu Oct 27 11:06:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D2E9106564A for ; Thu, 27 Oct 2011 11:06:24 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id CD3B78FC08 for ; Thu, 27 Oct 2011 11:06:23 +0000 (UTC) Received: by vws11 with SMTP id 11so3489451vws.13 for ; Thu, 27 Oct 2011 04:06:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lcvpW/s2NJt1ieirpaEUUVszioW41kXsXNru2oNTTtw=; b=tvLh/pEhEPccwRvp0qZrTcUw1rZkLLpV/U1kDh2WutVkH0+gGTYiocnVQTS/edP4jC ow9q2AKqvg1fwdJLHFERAaY5S8fhUsRVqJjDrQifHpx7ZWXhFE00FnaqVUzlRGvJzvpW 57HLz1TeZxWqypTZcbzGvHJhVwwHHFN+dmNQk= MIME-Version: 1.0 Received: by 10.52.30.47 with SMTP id p15mr882771vdh.79.1319713582819; Thu, 27 Oct 2011 04:06:22 -0700 (PDT) Received: by 10.52.182.40 with HTTP; Thu, 27 Oct 2011 04:06:22 -0700 (PDT) In-Reply-To: <20111027102208.88BFB106564A@hub.freebsd.org> References: <20111027102208.88BFB106564A@hub.freebsd.org> Date: Thu, 27 Oct 2011 12:06:22 +0100 Message-ID: From: Tom Evans To: Thomas Mueller Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org 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: Thu, 27 Oct 2011 11:06:24 -0000 On Thu, Oct 27, 2011 at 11:22 AM, Thomas Mueller wrote: > I just finished the upgrade from source from 9.0-BETA2 to RC1, and I find= two problems. > > First, I lost my users; nonroot user names are not recognized, if for ins= tance I type > > passwd arlene > > I already tried to login as arlene with old password, no good. > > I copied the /etc directory to a backup on another disk > > cp -Rp /etc =C2=A0/media/etcbackup-BETA2 > > and then copied back /media/etcbackup-BETA2/passwd (and group) to /etc > > but that didn't help. > > Do I have to recreate nonroot users from scratch? > > Also, I got a warning about DBUS not starting. > > When I tried to startx as root, I got into X, but mouse and keyboard were= nonfunctional; > I did type Ctrl-Alt-F1 and Ctrl-C to get out of X. > > I think it was the second mergemaster part. > > Should I, as root and X not running, do > > mv /etc /etcbackup-RC1 > > and > > cp -Rp /media/etcbackup-BETA2 /etc > > where /media would be mount point for backup partition on USB 3.0 hard dr= ive? > > The second invocation of mergemaster (after booting single-user) can wrea= k havoc on /etc . > > As I type this, I am in my older installation of FreeBSD 9.0-BETA1 but ha= ve access to RC1 partition. > > By the way, /etc/rc.conf remained intact, showing that hald_enable and db= us_enable are still there: > > > hostname=3D"amelia2" > keymap=3Dus.iso.kbd > ifconfig_re0=3D"DHCP" > ifconfig_re0_ipv6=3D"inet6 accept_rtadv" > sshd_enable=3D"YES" > moused_enable=3D"YES" > ntpd_enable=3D"YES" > hald_enable=3D"YES" > dbus_enable=3D"YES" > > Tom > I have had this happen before, the PEBKAC. When running mergemaster, it will prompt you to install new passwd, master.passwd and group files - if you have added local users you must not say yes to this, you must either merge the changes in or keep your local one. If you still have a backup, you are probably missing just master.passwd. hald, dbus would fail to start since their users are no longer there. Once you've done this to your system once, you never want to do it again! Cheers Tom From owner-freebsd-current@FreeBSD.ORG Thu Oct 27 11:14:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FC001065675 for ; Thu, 27 Oct 2011 11:14:52 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id EFDAD8FC14 for ; Thu, 27 Oct 2011 11:14:51 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 320742A28CDB; Thu, 27 Oct 2011 13:14:51 +0200 (CEST) Date: Thu, 27 Oct 2011 13:14:51 +0200 From: Ed Schouten To: Tom Evans Message-ID: <20111027111451.GO63910@hoeg.nl> References: <20111027102208.88BFB106564A@hub.freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MmQIYbZiCoQ2kDro" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Thomas Mueller , freebsd-current@freebsd.org 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: Thu, 27 Oct 2011 11:14:52 -0000 --MmQIYbZiCoQ2kDro Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Tom Evans , 20111027 13:06: > I have had this happen before, the PEBKAC. When running mergemaster, > it will prompt you to install new passwd, master.passwd and group > files - if you have added local users you must not say yes to this, > you must either merge the changes in or keep your local one. It would have been so awesome if our /etc/master.passwd and /etc/group included an #include directive. --=20 Ed Schouten WWW: http://80386.nl/ --MmQIYbZiCoQ2kDro Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJOqT0rAAoJEG5e2P40kaK7HEQP/irCPLk3a12qYKIfokBv+d8C FcNtCk5Hj9m+KAvkdSOeTn3k1DJcqwvXrao5FaP5u95abvxsapOyEKjilYB7nxoQ KDNLPL2wJlGzu6oOx0DqRfxeBXWkBuSRxXPwZ2fdGWKRmlVtMkezSShQYtoUO3Me /y+n3bYAkUwDHyTCo+y5hO0Qc1rY4hem5PacNQSHZ0/wZssFCANm3U931UVQ6gJN OJVXG2z7Al1AB+kXWvoHePwYpZE8Xg7uyFyIXqHj/FQWUoQl6nPprxbxIgG0KIZs SshmBtLMTan6quEqsPCPNxmaP9hx5vC3oB5/OikRJMcv/GtX8Wvavs+x5yyVKeBa f/CTUrJOun6yzHFWfFgRl389vWUDe63NU1rRiJM5gHEy6h4Ew1gQ5v3pxz4RCu5z l976+jgtovx9Peb8UDlbs91t15bkZQA5VllhQRyYMOrm1aJKgHvltMwLxMWUSN/Y VCpMCztamxIf9RgU4q7cQkJh8x4zCms5UA1oYic7lMr3rQ3pzf/Qxl6J5cXVRHsK Zr3YVbaEYm8FysBW+mbgoELelJ1AgfRPtUVFULOE54triLyBdk/nVwYRmAKefN0h UXLjSbPfgbblFL3tOp7cF9BzO57nww2OhrAM8W8soIKfLJ4Tpi2ciC1ShWrHFG3G 6uzQRwejeox80x0kakJb =9zGz -----END PGP SIGNATURE----- --MmQIYbZiCoQ2kDro-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 27 11:26:07 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2896106564A for ; Thu, 27 Oct 2011 11:26:07 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1DC458FC08 for ; Thu, 27 Oct 2011 11:26:06 +0000 (UTC) Received: from vhoffman.lon.namesco.net (lon.namesco.net [195.7.254.102]) (authenticated bits=0) by unsane.co.uk (8.14.4/8.14.4) with ESMTP id p9RBQ3ox000565 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 27 Oct 2011 12:26:04 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <4EA93FCB.7090109@unsane.co.uk> Date: Thu, 27 Oct 2011 12:26:03 +0100 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Thomas Mueller References: <20111027102208.88BFB106564A@hub.freebsd.org> In-Reply-To: <20111027102208.88BFB106564A@hub.freebsd.org> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org 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: Thu, 27 Oct 2011 11:26:08 -0000 On 27/10/2011 11:22, Thomas Mueller wrote: > I just finished the upgrade from source from 9.0-BETA2 to RC1, and I find two problems. > > First, I lost my users; nonroot user names are not recognized, if for instance I type > > passwd arlene > > I already tried to login as arlene with old password, no good. > > I copied the /etc directory to a backup on another disk > > cp -Rp /etc /media/etcbackup-BETA2 > > and then copied back /media/etcbackup-BETA2/passwd (and group) to /etc > > but that didn't help. Other people have suggested what you have done to loose them. To get them back you need /etc/passwd /etc/master.passwd possibly /etc/group There should be a handy backup in /var/backups Also you will need to remake the db files, see man pwd_mkdb Vince > > Do I have to recreate nonroot users from scratch? > > Also, I got a warning about DBUS not starting. > > When I tried to startx as root, I got into X, but mouse and keyboard were nonfunctional; > I did type Ctrl-Alt-F1 and Ctrl-C to get out of X. > > I think it was the second mergemaster part. > > Should I, as root and X not running, do > > mv /etc /etcbackup-RC1 > > and > > cp -Rp /media/etcbackup-BETA2 /etc > > where /media would be mount point for backup partition on USB 3.0 hard drive? > > The second invocation of mergemaster (after booting single-user) can wreak havoc on /etc . > > As I type this, I am in my older installation of FreeBSD 9.0-BETA1 but have access to RC1 partition. > > By the way, /etc/rc.conf remained intact, showing that hald_enable and dbus_enable are still there: > > > hostname="amelia2" > keymap=us.iso.kbd > ifconfig_re0="DHCP" > ifconfig_re0_ipv6="inet6 accept_rtadv" > sshd_enable="YES" > moused_enable="YES" > ntpd_enable="YES" > hald_enable="YES" > dbus_enable="YES" > > Tom > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Oct 27 11:31:43 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55091106566B for ; Thu, 27 Oct 2011 11:31:43 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id 293D08FC15 for ; Thu, 27 Oct 2011 11:31:42 +0000 (UTC) Received: by pzk4 with SMTP id 4so14226981pzk.3 for ; Thu, 27 Oct 2011 04:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=wCAawR04NnTvdbVJE+9OkJPElEVACsWSaRq19QzBERg=; b=fZJvR6kdG8IV3LTkywdGgxR0phQoq8IMkA3MhUtrlR/VKGyUaAvXBHd3xOU4dtHAfJ o2r0gqYOl5F7PZH6ndurUR6UW6xWOwJK3Ojmx1NFyDQ1hnCoZ2wlnBSkSo7OUqC+x5TV Qn/B6Wgjq5P91hIrGbe+WzWEAE7vZYM9ccb+w= Received: by 10.68.74.4 with SMTP id p4mr73261769pbv.47.1319714649635; Thu, 27 Oct 2011 04:24:09 -0700 (PDT) Received: from [192.168.20.5] (c-24-6-49-154.hsd1.ca.comcast.net. [24.6.49.154]) by mx.google.com with ESMTPS id i10sm5908296pbn.10.2011.10.27.04.24.08 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 27 Oct 2011 04:24:08 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <20111027111451.GO63910@hoeg.nl> Date: Thu, 27 Oct 2011 04:24:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111027102208.88BFB106564A@hub.freebsd.org> <20111027111451.GO63910@hoeg.nl> To: Ed Schouten X-Mailer: Apple Mail (2.1084) Cc: Tom Evans , Thomas Mueller , freebsd-current@freebsd.org 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: Thu, 27 Oct 2011 11:31:43 -0000 On Oct 27, 2011, at 4:14 AM, Ed Schouten wrote: > * Tom Evans , 20111027 13:06: >> I have had this happen before, the PEBKAC. When running mergemaster, >> it will prompt you to install new passwd, master.passwd and group >> files - if you have added local users you must not say yes to this, >> you must either merge the changes in or keep your local one. >=20 > It would have been so awesome if our /etc/master.passwd and /etc/group > included an #include directive. Or a tool like etcupdate, which provides 3-way diff functionality, was = available in base.. -Garrett= From owner-freebsd-current@FreeBSD.ORG Thu Oct 27 11:42:11 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54DFB1065670; Thu, 27 Oct 2011 11:42:11 +0000 (UTC) (envelope-from cvs-src@yandex.ru) Received: from forward15.mail.yandex.net (forward15.mail.yandex.net [IPv6:2a02:6b8:0:801::5]) by mx1.freebsd.org (Postfix) with ESMTP id 6C56F8FC15; Thu, 27 Oct 2011 11:42:10 +0000 (UTC) Received: from smtp14.mail.yandex.net (smtp14.mail.yandex.net [95.108.131.192]) by forward15.mail.yandex.net (Yandex) with ESMTP id 59EBA9E339E; Thu, 27 Oct 2011 15:42:09 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1319715729; bh=kv0V1J2oPAJlO1x+U5lacrl4phlmnggP09RfYnApZb4=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=LuqFdjv8sndFZz37F3D2HVotxyelwk3vviYYw+pUOP9XmK9wppdaU+QjttIwi6q2M qzrR2vb6VDkrADbBTs89CHub56yq47t5pbnZfgDUBrVUoQDKOXMMWB09hpuOT8Tlzf ma4Yr5k5WAgUmVHIbmgf7OXs/y/UWaqtfYxdodA4= Received: from smtp14.mail.yandex.net (localhost [127.0.0.1]) by smtp14.mail.yandex.net (Yandex) with ESMTP id 270B11B603D0; Thu, 27 Oct 2011 15:42:09 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1319715729; bh=kv0V1J2oPAJlO1x+U5lacrl4phlmnggP09RfYnApZb4=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=LuqFdjv8sndFZz37F3D2HVotxyelwk3vviYYw+pUOP9XmK9wppdaU+QjttIwi6q2M qzrR2vb6VDkrADbBTs89CHub56yq47t5pbnZfgDUBrVUoQDKOXMMWB09hpuOT8Tlzf ma4Yr5k5WAgUmVHIbmgf7OXs/y/UWaqtfYxdodA4= Received: from unknown (unknown [213.27.65.65]) by smtp14.mail.yandex.net (nwsmtp/Yandex) with ESMTP id g8l8pv0C-g8liDRBV; Thu, 27 Oct 2011 15:42:08 +0400 X-Yandex-Spam: 1 Message-ID: <4EA94388.1080906@yandex.ru> Date: Thu, 27 Oct 2011 15:42:00 +0400 From: Ruslan Mahmatkhanov User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: Erwin Lansing References: <20111011063602.GO68552@droso.net> <20111017153551.23281532@tetcu.info> <20111017135130.d9caa4f1.stas@FreeBSD.org> <20111018223146.GA93539@server.vk2pj.dyndns.org> <20111019105938.5aa842a4@FreeBSD.org> <20111019010420.646c0938.stas@FreeBSD.org> <20111019113136.316cb665@FreeBSD.org> <20111021124434.07c96389@FreeBSD.org> <20111027102104.GZ27932@droso.net> In-Reply-To: <20111027102104.GZ27932@droso.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 27 Oct 2011 12:07:22 +0000 Cc: current@FreeBSD.org, freebsd-ports@freebsd.org Subject: Re: [UPDATE] Re: Update on ports on 10.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, 27 Oct 2011 11:42:11 -0000 Erwin Lansing wrote on 27.10.2011 14:21: > On Fri, Oct 21, 2011 at 12:44:34PM +0300, Ion-Mihai Tetcu wrote: >>>>> What, on the other hand, makes sense is to have the fix that >>>>> should include: >>>>> a) a KNOB (WITH_FBSD10_FIX or similar), >>>>> b) that only is run from bsd.port.mk when OSVERSION>1000000 >>>>> c) runs the latest version of the above patch. >>>>> The KNOB's existence allow us to turn on the fix only for broken >>>>> ports, and easily know what these broken ports are -- so we can >>>>> poke maintainers from time to time about upstream fixes, ... >>>> >> >> Erwin is currently running a build on i386-10 with this and the >> following patches: >> - bsd.port.mk patch from beat (based on ed@, jilles@ and stas@ patches) >> - python patch from beat >> - python patch from linimon >> - WITH_FBSD10_FIX in: >> - textproc/expat2 >> - devel/pcre >> - devel/libtool >> - audio/libogg >> Results by Monday. >> > > These patches have now been committed to the tree, notably with > lang/python27 missing in the above list but was included as well. There > have been some proposals already and we can now incrementally improve > the workaround and, more importantly, start fixing individual ports. Please > note that the patch tries to balance between being a general enough fix > to make it easy to get a working system running while not just swiping > the whole issue under the rug and forget about it until the next release > cycle. Make sure to send any fixes upstream to the hack can be removed > from the ports again. > > Thanks for all your patience and thanks for all those involved, > especially beat who sent many patches and improvements. > > Erwin About devel/libtool fix. Why to not update it to 2.4.2 where this was fixed upstream? I mean http://bugs.freebsd.org/162012 -- Regards, Ruslan Tinderboxing kills... the drives. From owner-freebsd-current@FreeBSD.ORG Thu Oct 27 17:08:28 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4F72106566B for ; Thu, 27 Oct 2011 17:08:28 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 3DA678FC08 for ; Thu, 27 Oct 2011 17:08:24 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 5E97D804; Thu, 27 Oct 2011 19:08:23 +0200 (CEST) Date: Thu, 27 Oct 2011 19:07:38 +0200 From: Pawel Jakub Dawidek To: freebsd-current@FreeBSD.org Message-ID: <20111027170738.GB1667@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="H+4ONPRPur6+Ovig" Content-Disposition: inline X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hps@FreeBSD.org, freebsd-usb@FreeBSD.org Subject: umass(4) regression in 9.0-RC1. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2011 17:08:28 -0000 --H+4ONPRPur6+Ovig Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. My SDHC card (via adapter) is no longer being detected after upgrade to 9.0-RC1. The same card with this adapter works on my laptop with older HEAD. usbus0: EHCI version 1.0 usbus0: on ehci0 usbus0: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 uhub0: 10 ports with 10 removable, self powered # usbdevs -v usbdevs: no USB controllers found ehci0@pci0:0:10:1: class=3D0x0c0320 card=3D0x81fb1043 chip=3D0x036d10= de rev=3D0xa2 hdr=3D0x00 vendor =3D 'nVidia Corporation' device =3D 'MCP55 USB Controller' class =3D serial bus subclass =3D USB After connecting the adapter with the card inside: kernel: ugen0.2: at usbus0 --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --H+4ONPRPur6+Ovig Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk6pj9oACgkQForvXbEpPzTwAwCfaXfOjpzh2JDhgMTryjDr6W++ +z4An0lhCOfm28C4fv4MWu8+XGOsiFV6 =WeIt -----END PGP SIGNATURE----- --H+4ONPRPur6+Ovig-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 27 17:52:38 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C63C01065673 for ; Thu, 27 Oct 2011 17:52:38 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id A856A8FC15 for ; Thu, 27 Oct 2011 17:52:38 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 27 Oct 2011 10:23:51 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id p9RHNrab082785; Thu, 27 Oct 2011 10:23:53 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id p9RHNqVX082784; Thu, 27 Oct 2011 10:23:52 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <201110271723.p9RHNqVX082784@ambrisko.com> In-Reply-To: <4EA6F4EC.3010403@spock.cl> To: Roberto de Iriarte Date: Thu, 27 Oct 2011 10:23:52 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL124d (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Cc: FreeBSD Current Subject: Re: LSI 9240-8i (IBM M1015) MegaRaid support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2011 17:52:38 -0000 Roberto de Iriarte writes: | Hi, | | Is there any expectancy of getting this piece of hardware (or it's IBM | silbing, the M1015) working in MegaRaid mode, without having to reflash | the card to IT mode. | | The reason of this request is that the UEFI Bios on the IBM XSeries | 3550M3 refuses to properly initialize the controller if reflashed with | the IT mode firmware, thus making it unusable. | | A search on LSI's website for a driver that supports 8-Stable or 9 did | not produce any results I have driver changes from LSI to support the 9240 and newer ThunderBolt based cards. I have the cards working but need to do a bunch more work to get this into shape to commit to FreeBSD. I also need to look at how they are dealing with their JBOD configuration and attachment. I have cards to test this stuff out but my time is limited to work on it. One thing I should start working on is merging in the LSI changes into the FreeBSD version since the LSI code drop has removed a bunch of features that the FreeBSD version has. Then I can have a smaller change. There are some architectural changes that I need to figure out. They started to use 64 bit addressing. Then there are style issues. Probably the best thing for me to do is add the new HW support to FreeBSD as a small diff then work on improving that and maybe others can also help with that. Doug A. From owner-freebsd-current@FreeBSD.ORG Thu Oct 27 18:15:16 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30119106567A; Thu, 27 Oct 2011 18:15:16 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 142EE8FC0C; Thu, 27 Oct 2011 18:15:16 +0000 (UTC) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 7CE9AD0FB; Thu, 27 Oct 2011 11:15:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1319739315; bh=/7bKJkI/SUug/gw9LNARtSGTs++nZ4uKUvUP9iJnymA=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Lnml7tQ+We7CqanbWkewX1aZ4XJKjsZjoz8+MYkHaQqsoaRany6TrdQAH7AP47iGu V4a3Q2pZe8VcftjQuieGq0tCG9QdVV7ERssoZuYdi59qzm7/0U1p2cQ3iRiIr/mAa9 CqJQoGF5v4WAY36WqRPEfmifKp4OU7maVchb1Sc8= Message-ID: <4EA99FB2.4040007@delphij.net> Date: Thu, 27 Oct 2011 11:15:14 -0700 From: Xin LI Organization: The FreeBSD Project MIME-Version: 1.0 To: =?ISO-8859-2?Q?Edward_Tomasz_Napiera=B3a?= References: <4EA89FD6.4010900@delphij.net> <490668A9-95A0-42FF-9B59-57FFBC73F020@FreeBSD.org> In-Reply-To: <490668A9-95A0-42FF-9B59-57FFBC73F020@FreeBSD.org> OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit Cc: alc@FreeBSD.org, FreeBSD Current , d@delphij.net Subject: Re: Should process in STOP state be swapped out? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 18:15:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 10/27/11 00:54, Edward Tomasz Napiera³a wrote: > Wiadomo¶æ napisana przez Xin LI w dniu 27 pa¼ 2011, o godz. 02:03: >> I've noticed that if I kill -STOP a process, the in-core size >> does not change even when there is memory pressure (what I'm >> expecting is that if there is memory pressure, the process's >> in-core part gets swapped out from time to time). Is this >> behavior intentional? > > Which version is this? I've fixed a very similar problem in > r220387. Thanks, I think that's the problem I hit. The version is a heavily patched 8.2-RELEASE. I'll run some tests to make sure that the problem was fixed. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJOqZ+yAAoJEATO+BI/yjfBLgsIANdL7NkXPdG6c+zHH0GHX7sY X6W34AXkQ5TGfAeiI2jpdamI3rOscQZiChJ9othR5CztunU7TM/nHcVdIIMyeSCT 8IDwvquvEodh+Un1ybGRUp7p08/Xr3hyNJsxFfucEKF14kH9oSqMmWdIlxHFthP2 4VrrUnZDoNvS4GLZYBDWj/gXzmhavsFvdD7UvPxbI2gtjiM/mwpCRnlHZxhfiGzS tQkceVudRkeHJfaH+7k27p1WcjK4eBicm/WKUz/iR82vA1tNLQ1+LgPr5875mT1l oZJbncdnI6K9Fau7owe+7MJNt+XBYXJFM6u89Tbe8pxLAj+fdIXZzxToT/GeHoQ= =I5Wy -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Oct 27 18:33:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20947106564A; Thu, 27 Oct 2011 18:33:52 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.c2i.net [212.247.154.98]) by mx1.freebsd.org (Postfix) with ESMTP id 3B75D8FC16; Thu, 27 Oct 2011 18:33:50 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 196106193; Thu, 27 Oct 2011 20:33:49 +0200 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Thu, 27 Oct 2011 20:30:44 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <20111027170738.GB1667@garage.freebsd.pl> In-Reply-To: <20111027170738.GB1667@garage.freebsd.pl> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201110272030.44262.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, Pawel Jakub Dawidek Subject: Re: umass(4) regression in 9.0-RC1. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2011 18:33:52 -0000 On Thursday 27 October 2011 19:07:38 Pawel Jakub Dawidek wrote: > Hi. > > My SDHC card (via adapter) is no longer being detected after upgrade to > 9.0-RC1. The same card with this adapter works on my laptop with older > HEAD. > > usbus0: EHCI version 1.0 > usbus0: on ehci0 > usbus0: 480Mbps High Speed USB v2.0 > ugen0.1: at usbus0 > uhub0: on usbus0 > uhub0: 10 ports with 10 removable, self powered > > # usbdevs -v > usbdevs: no USB controllers found > > ehci0@pci0:0:10:1: class=0x0c0320 card=0x81fb1043 chip=0x036d10de > rev=0xa2 hdr=0x00 vendor = 'nVidia Corporation' > device = 'MCP55 USB Controller' > class = serial bus > subclass = USB > > After connecting the adapter with the card inside: > > kernel: ugen0.2: at usbus0 What does usbconfig dump_device_desc, say about this device? --HPS From owner-freebsd-current@FreeBSD.ORG Thu Oct 27 18:41:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16834106566C; Thu, 27 Oct 2011 18:41:24 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id BF7BE8FC0C; Thu, 27 Oct 2011 18:41:23 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 6719587A; Thu, 27 Oct 2011 20:41:21 +0200 (CEST) Date: Thu, 27 Oct 2011 20:40:37 +0200 From: Pawel Jakub Dawidek To: Hans Petter Selasky Message-ID: <20111027184035.GC1667@garage.freebsd.pl> References: <20111027170738.GB1667@garage.freebsd.pl> <201110272030.44262.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="f+W+jCU1fRNres8c" Content-Disposition: inline In-Reply-To: <201110272030.44262.hselasky@c2i.net> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: umass(4) regression in 9.0-RC1. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2011 18:41:24 -0000 --f+W+jCU1fRNres8c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 27, 2011 at 08:30:44PM +0200, Hans Petter Selasky wrote: > What does usbconfig dump_device_desc, say about this device? ugen0.1: at usbus0, cfg=3D0 md=3DHOST spd=3DHIGH (48= 0Mbps) pwr=3DSAVE bLength =3D 0x0012 bDescriptorType =3D 0x0001 bcdUSB =3D 0x0200 bDeviceClass =3D 0x0009 bDeviceSubClass =3D 0x0000 bDeviceProtocol =3D 0x0001 bMaxPacketSize0 =3D 0x0040 idVendor =3D 0x0000 idProduct =3D 0x0000 bcdDevice =3D 0x0100 iManufacturer =3D 0x0001 iProduct =3D 0x0002 iSerialNumber =3D 0x0000 bNumConfigurations =3D 0x0001 --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --f+W+jCU1fRNres8c Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk6ppaIACgkQForvXbEpPzTGRgCeMYU699f60MlVFjVpBrQJEPm1 19IAoJfkMc3i4G3SDNjikaE96Q+ttC49 =6sSD -----END PGP SIGNATURE----- --f+W+jCU1fRNres8c-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 27 18:45:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C50B106566C; Thu, 27 Oct 2011 18:45:17 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.c2i.net [212.247.154.162]) by mx1.freebsd.org (Postfix) with ESMTP id 31F1E8FC13; Thu, 27 Oct 2011 18:45:15 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 195800736; Thu, 27 Oct 2011 20:45:14 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Thu, 27 Oct 2011 20:42:09 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <20111027170738.GB1667@garage.freebsd.pl> <201110272030.44262.hselasky@c2i.net> <20111027184035.GC1667@garage.freebsd.pl> In-Reply-To: <20111027184035.GC1667@garage.freebsd.pl> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201110272042.09238.hselasky@c2i.net> Cc: Pawel Jakub Dawidek , freebsd-usb@freebsd.org Subject: Re: umass(4) regression in 9.0-RC1. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2011 18:45:17 -0000 On Thursday 27 October 2011 20:40:37 Pawel Jakub Dawidek wrote: > On Thu, Oct 27, 2011 at 08:30:44PM +0200, Hans Petter Selasky wrote: > > What does usbconfig dump_device_desc, say about this device? > > ugen0.1: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) > pwr=SAVE > > bLength = 0x0012 > bDescriptorType = 0x0001 > bcdUSB = 0x0200 > bDeviceClass = 0x0009 > bDeviceSubClass = 0x0000 > bDeviceProtocol = 0x0001 > bMaxPacketSize0 = 0x0040 > idVendor = 0x0000 > idProduct = 0x0000 > bcdDevice = 0x0100 > iManufacturer = 0x0001 > iProduct = 0x0002 > iSerialNumber = 0x0000 > bNumConfigurations = 0x0001 This is the root HUB. Can you also show the actual device? --HPS From owner-freebsd-current@FreeBSD.ORG Thu Oct 27 18:52:02 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B0F11065674; Thu, 27 Oct 2011 18:52:02 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id E406F8FC19; Thu, 27 Oct 2011 18:52:01 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id E009C888; Thu, 27 Oct 2011 20:51:59 +0200 (CEST) Date: Thu, 27 Oct 2011 20:51:15 +0200 From: Pawel Jakub Dawidek To: Hans Petter Selasky Message-ID: <20111027185115.GD1667@garage.freebsd.pl> References: <20111027170738.GB1667@garage.freebsd.pl> <201110272030.44262.hselasky@c2i.net> <20111027184035.GC1667@garage.freebsd.pl> <201110272042.09238.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eheScQNz3K90DVRs" Content-Disposition: inline In-Reply-To: <201110272042.09238.hselasky@c2i.net> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: umass(4) regression in 9.0-RC1. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2011 18:52:02 -0000 --eheScQNz3K90DVRs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 27, 2011 at 08:42:09PM +0200, Hans Petter Selasky wrote: > This is the root HUB. Can you also show the actual device? Sorry, it wasn't connected, here it goes: ugen0.2: at usbus0, cfg=3D255 md=3DHOST spd=3DHIGH (48= 0Mbps) pwr=3DON bLength =3D 0x0012 bDescriptorType =3D 0x0001 bcdUSB =3D 0x0200 bDeviceClass =3D 0x0000 bDeviceSubClass =3D 0x0000 bDeviceProtocol =3D 0x0000 bMaxPacketSize0 =3D 0x0008 idVendor =3D 0x0bda idProduct =3D 0x0119 bcdDevice =3D 0x1981 iManufacturer =3D 0x0001 iProduct =3D 0x0002 iSerialNumber =3D 0x0003 bNumConfigurations =3D 0x0001 --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --eheScQNz3K90DVRs Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk6pqCMACgkQForvXbEpPzTUHQCeIkHx2HrLxzqURXVUIhUYmPUx EqsAn0JuqSXywvAy/BDyexulFSbzyqhq =cmtO -----END PGP SIGNATURE----- --eheScQNz3K90DVRs-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 27 19:02:24 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 579A7106566C; Thu, 27 Oct 2011 19:02:24 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 3D8F68FC0C; Thu, 27 Oct 2011 19:02:24 +0000 (UTC) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 8E216D516; Thu, 27 Oct 2011 12:02:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1319742143; bh=3dBmUcPavfHRu8nnPVf4TnHaQhiu8DnFFqWrS4gjdwM=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject: Content-Type; b=ApfMwST2DN5zJm+H2mPZfdRMPWUrFxbsP/tFNvO+5PBLJ2FEl/tSvdBkPtiwsy23E yVSZ2n7k10SeybUMooq4iW7yVXUHG3ttslj4l0+5g5UdLchDHXZ0FZtQCbQG6/LTEJ uy/gEg+tnZ7BqZR85EvyyEVWjJ7jGBPYXAIL8YN8= Message-ID: <4EA9AABE.4000803@delphij.net> Date: Thu, 27 Oct 2011 12:02:22 -0700 From: Xin LI Organization: The FreeBSD Project MIME-Version: 1.0 To: FreeBSD Current , netchild@FreeBSD.ORG OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: multipart/mixed; boundary="------------040504090104030803020609" Cc: Subject: [PATCH] Default scrub interval to whole weeks X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 19:02:24 -0000 This is a multi-part message in MIME format. --------------040504090104030803020609 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I think it might be better if we set scrub interval to whole weeks (proposed changeset changes it to 5 weeks). The reason for this is to make it easier for system administrators to estimate when the scrub happens, for instance, if a scrub was done on Saturday, it always happen on Saturdays. On large zpools, scrub can consume a lot of time and I/O bandwidth, and having it happen on random weekday is not a good idea. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJOqaq+AAoJEATO+BI/yjfBNq8IALxm6vrtIIbnklv+WM9hc1ek Os3DpIf12UNA52v02Gglqz3fyuff4wQ4iHQBi1gvZRzEkY9pVTQgInFi2F5MlBxF DC474RLyOShS2SMBmHZQPxlRcGhG6e9OY75XLu0HzbPl3Ah7+HiPcckEgEZ7NjhL 3CKYikvaXerE+Iee+dzrhP9wN+JaG4/RjW4fvHCkWCuIcDemKyebUyqb1O+A35P0 lXjComE1SnYtJSjVWobgGJm9tgJ8CV8fPMd6KcEohwOdDoq6YSaesA1/CAYirZT7 i65FGpT7Eep3K6rV6XJvZUg2bMQcRL/HmqJekowHsMmxDZ8+lLQ001t5QU0jFY4= =9caN -----END PGP SIGNATURE----- --------------040504090104030803020609 Content-Type: text/plain; name="scrub-5week.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="scrub-5week.diff" SW5kZXg6IGRlZmF1bHRzL3BlcmlvZGljLmNvbmYKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gZGVmYXVs dHMvcGVyaW9kaWMuY29uZgkocmV2aXNpb24gMjI2ODUwKQorKysgZGVmYXVsdHMvcGVyaW9k aWMuY29uZgkod29ya2luZyBjb3B5KQpAQCAtMTUwLDggKzE1MCw4IEBACiAjIDgwMC5zY3J1 Yi16ZnMKIGRhaWx5X3NjcnViX3pmc19lbmFibGU9Ik5PIgogZGFpbHlfc2NydWJfemZzX3Bv b2xzPSIiCQkJIyBlbXB0eSBzdHJpbmcgc2VsZWN0cyBhbGwgcG9vbHMKLWRhaWx5X3NjcnVi X3pmc19kZWZhdWx0X3RocmVzaG9sZD0iMzAiCQkjIGRheXMgYmV0d2VlbiBzY3J1YnMKLSNk YWlseV9zY3J1Yl96ZnNfJHtwb29sbmFtZX1fdGhyZXNob2xkPSIzMCIJIyBwb29sIHNwZWNp ZmljIHRocmVzaG9sZAorZGFpbHlfc2NydWJfemZzX2RlZmF1bHRfdGhyZXNob2xkPSIzNSIJ CSMgZGF5cyBiZXR3ZWVuIHNjcnVicworI2RhaWx5X3NjcnViX3pmc18ke3Bvb2xuYW1lfV90 aHJlc2hvbGQ9IjM1IgkjIHBvb2wgc3BlY2lmaWMgdGhyZXNob2xkCiAKICMgOTk5LmxvY2Fs CiBkYWlseV9sb2NhbD0iL2V0Yy9kYWlseS5sb2NhbCIJCQkJIyBMb2NhbCBzY3JpcHRzCklu ZGV4OiBwZXJpb2RpYy9kYWlseS84MDAuc2NydWItemZzCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHBl cmlvZGljL2RhaWx5LzgwMC5zY3J1Yi16ZnMJKHJldmlzaW9uIDIyNjg1MCkKKysrIHBlcmlv ZGljL2RhaWx5LzgwMC5zY3J1Yi16ZnMJKHdvcmtpbmcgY29weSkKQEAgLTE1LDcgKzE1LDcg QEAKICAgICBzb3VyY2VfcGVyaW9kaWNfY29uZnMKIGZpCiAKLTogJHtkYWlseV9zY3J1Yl96 ZnNfZGVmYXVsdF90aHJlc2hvbGQ9MzB9Cis6ICR7ZGFpbHlfc2NydWJfemZzX2RlZmF1bHRf dGhyZXNob2xkPTM1fQogCiBjYXNlICIkZGFpbHlfc2NydWJfemZzX2VuYWJsZSIgaW4KICAg ICBbWXldW0VlXVtTc10pCg== --------------040504090104030803020609-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 27 19:05:42 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29684106566B; Thu, 27 Oct 2011 19:05:42 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 761C98FC08; Thu, 27 Oct 2011 19:05:41 +0000 (UTC) Received: by bkbzs2 with SMTP id zs2so185714bkb.13 for ; Thu, 27 Oct 2011 12:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=e8+g9RKpA03KBAlEM3wzO5zQ8AWtG2KzZ6I7mOa7wpI=; b=rNjp9Ve+RNgOAQYl8Vcli9SXscxT5I4yC9U44RNajnM2Jt9Magyh84wI0VaasDx5MO xugSjUh4lyhMal+SJHqyu0eN+1HFgo6MRPXRD91VzMR+6ZUzLZXpKil0eoHx6VD+AlxW 3KLuji3Pfrj+BUWhMHprwRMN1FkyVfp1vD/Ms= MIME-Version: 1.0 Received: by 10.204.50.88 with SMTP id y24mr493515bkf.53.1319742339902; Thu, 27 Oct 2011 12:05:39 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.204.39.12 with HTTP; Thu, 27 Oct 2011 12:05:39 -0700 (PDT) In-Reply-To: <4EA71713.3020404@FreeBSD.org> References: <20111020114844.GK59810@albert.catwhisker.org> <20111020122121.GL59810@albert.catwhisker.org> <201110211636.05917.jhb@freebsd.org> <20111025140000.GA8559@albert.catwhisker.org> <4EA71713.3020404@FreeBSD.org> Date: Thu, 27 Oct 2011 12:05:39 -0700 X-Google-Sender-Auth: nmy0mhDO8EdNgzqv_lRQsAEPkJ4 Message-ID: From: Craig Rodrigues To: Doug Barton Content-Type: multipart/mixed; boundary=00032555767a5d6ce504b04c7555 Cc: freebsd-current@freebsd.org Subject: Re: sys/conf/newvers.sh vs. subversion-1.7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2011 19:05:42 -0000 --00032555767a5d6ce504b04c7555 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 25, 2011 at 1:07 PM, Doug Barton wrote: > The attached implements that, and is almost certainly the right way to > go. It would be nice if someone could test it, and better if someone > else could commit it. I swore after the last time that I'd stay away > from that file precisely because of all the bikeshed stupidity that this > issue creates. Hi, I tested your patch and it works. I am attaching vers.c files which I generated in trees which were under svn control, and not under svn control. -- Craig Rodrigues rodrigc@crodrigues.org --00032555767a5d6ce504b04c7555 Content-Type: text/plain; charset=US-ASCII; name="newvers.sh.diff" Content-Disposition: attachment; filename="newvers.sh.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: 61458144b41871ad_0.1 SW5kZXg6IG5ld3ZlcnMuc2gKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gbmV3dmVycy5zaAkocmV2aXNpb24gMjI2 NDc0KQorKysgbmV3dmVycy5zaAkod29ya2luZyBjb3B5KQpAQCAtODgsNyArODgsNyBAQAogaT1g JHtNQUtFOi1tYWtlfSAtViBLRVJOX0lERU5UYAogCiBmb3IgZGlyIGluIC9iaW4gL3Vzci9iaW4g L3Vzci9sb2NhbC9iaW47IGRvCi0JaWYgWyAtZCAiJHtTWVNESVJ9Ly5zdm4iIC1hIC14ICIke2Rp cn0vc3ZudmVyc2lvbiIgXSA7IHRoZW4KKwlpZiBbIC14ICIke2Rpcn0vc3ZudmVyc2lvbiIgXSA7 IHRoZW4KIAkJc3ZudmVyc2lvbj0ke2Rpcn0vc3ZudmVyc2lvbgogCQlicmVhawogCWZpCkBAIC05 OSw4ICs5OSwxMiBAQAogZG9uZQogCiBpZiBbIC1uICIkc3ZudmVyc2lvbiIgXSA7IHRoZW4KLSAg ICBlY2hvICIkc3ZudmVyc2lvbiIKLQlzdm49IiByYGNkICR7U1lTRElSfSAmJiAkc3ZudmVyc2lv bmAiCisJZWNobyAiJHN2bnZlcnNpb24iCisJc3ZuPWBjZCAke1NZU0RJUn0gJiYgJHN2bnZlcnNp b25gCisJY2FzZSAiJHN2biIgaW4KKwlbMC05XSopCXN2bj0iIHIke3N2bn0iIDs7CisJKikJdW5z ZXQgc3ZuIDs7CisJZXNhYwogZmkKIAogaWYgWyAtbiAiJGdpdF9jbWQiIF0gOyB0aGVuCg== --00032555767a5d6ce504b04c7555 Content-Type: text/plain; charset=US-ASCII; name="vers.c.with_svn.txt" Content-Disposition: attachment; filename="vers.c.with_svn.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gua4gnen1 LyotCiAqIENvcHlyaWdodCAoYykgMTk5Mi0yMDExIFRoZSBGcmVlQlNEIFByb2plY3QuCiAqIEFs bCByaWdodHMgcmVzZXJ2ZWQuCiAqCiAqIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNl IGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAogKiBtb2RpZmljYXRpb24sIGFyZSBw ZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMKICogYXJlIG1l dDoKICogMS4gUmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBh Ym92ZSBjb3B5cmlnaHQKICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQg dGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyLgogKiAyLiBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5 IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAogKiAgICBub3RpY2UsIHRo aXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4gdGhl CiAqICAgIGRvY3VtZW50YXRpb24gYW5kL29yIG90aGVyIG1hdGVyaWFscyBwcm92aWRlZCB3aXRo IHRoZSBkaXN0cmlidXRpb24uCiAqCiAqIFRISVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkgVEhF IEFVVEhPUiBBTkQgQ09OVFJJQlVUT1JTIGBgQVMgSVMnJyBBTkQKICogQU5ZIEVYUFJFU1MgT1Ig SU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFCiAq IElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEg UEFSVElDVUxBUiBQVVJQT1NFCiAqIEFSRSBESVNDTEFJTUVELiAgSU4gTk8gRVZFTlQgU0hBTEwg VEhFIEFVVEhPUiBPUiBDT05UUklCVVRPUlMgQkUgTElBQkxFCiAqIEZPUiBBTlkgRElSRUNULCBJ TkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFM CiAqIERBTUFHRVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBP RiBTVUJTVElUVVRFIEdPT0RTCiAqIE9SIFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFUQSwgT1Ig UFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9OKQogKiBIT1dFVkVSIENBVVNFRCBBTkQg T04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVAog KiBMSUFCSUxJVFksIE9SIFRPUlQgKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkg QVJJU0lORyBJTiBBTlkgV0FZCiAqIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUsIEVW RU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YKICogU1VDSCBEQU1BR0UuCiAqCiAq LwoKI2RlZmluZSBTQ0NTU1RSICJAKCMpRnJlZUJTRCA5LjAtQkVUQTIgIzAgcjIyNTM2ODoyMjYx NzlNOiBUdWUgT2N0IDI1IDIzOjM1OjExIFBEVCAyMDExIgojZGVmaW5lIFZFUlNUUiAiRnJlZUJT RCA5LjAtQkVUQTIgIzAgcjIyNTM2ODoyMjYxNzlNOiBUdWUgT2N0IDI1IDIzOjM1OjExIFBEVCAy MDExXG4gICAgcm9kcmlnY0BkaWJibGVyLmNyb2RyaWd1ZXMub3JnOi91c3Ivb2JqL29wdDIvYnJh bmNoZXMvaGVhZC9zcmMvc3lzL01ZS0VSTkVMMVxuIgojZGVmaW5lIFJFTFNUUiAiOS4wLUJFVEEy IgoKY2hhciBzY2NzW3NpemVvZihTQ0NTU1RSKSA+IDEyOCA/IHNpemVvZihTQ0NTU1RSKSA6IDEy OF0gPSBTQ0NTU1RSOwpjaGFyIHZlcnNpb25bc2l6ZW9mKFZFUlNUUikgPiAyNTYgPyBzaXplb2Yo VkVSU1RSKSA6IDI1Nl0gPSBWRVJTVFI7CmNoYXIgb3N0eXBlW10gPSAiRnJlZUJTRCI7CmNoYXIg b3NyZWxlYXNlW3NpemVvZihSRUxTVFIpID4gMzIgPyBzaXplb2YoUkVMU1RSKSA6IDMyXSA9IFJF TFNUUjsKaW50IG9zcmVsZGF0ZSA9IDkwMDA0MzsKY2hhciBrZXJuX2lkZW50W10gPSAiR0VORVJJ QyI7Cg== --00032555767a5d6ce504b04c7555 Content-Type: text/plain; charset=US-ASCII; name="vers.c.without_svn.txt" Content-Disposition: attachment; filename="vers.c.without_svn.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gua4gz0b2 LyotCiAqIENvcHlyaWdodCAoYykgMTk5Mi0yMDExIFRoZSBGcmVlQlNEIFByb2plY3QuCiAqIEFs bCByaWdodHMgcmVzZXJ2ZWQuCiAqCiAqIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNl IGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAogKiBtb2RpZmljYXRpb24sIGFyZSBw ZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMKICogYXJlIG1l dDoKICogMS4gUmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBh Ym92ZSBjb3B5cmlnaHQKICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQg dGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyLgogKiAyLiBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5 IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAogKiAgICBub3RpY2UsIHRo aXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4gdGhl CiAqICAgIGRvY3VtZW50YXRpb24gYW5kL29yIG90aGVyIG1hdGVyaWFscyBwcm92aWRlZCB3aXRo IHRoZSBkaXN0cmlidXRpb24uCiAqCiAqIFRISVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkgVEhF IEFVVEhPUiBBTkQgQ09OVFJJQlVUT1JTIGBgQVMgSVMnJyBBTkQKICogQU5ZIEVYUFJFU1MgT1Ig SU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFCiAq IElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEg UEFSVElDVUxBUiBQVVJQT1NFCiAqIEFSRSBESVNDTEFJTUVELiAgSU4gTk8gRVZFTlQgU0hBTEwg VEhFIEFVVEhPUiBPUiBDT05UUklCVVRPUlMgQkUgTElBQkxFCiAqIEZPUiBBTlkgRElSRUNULCBJ TkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFM CiAqIERBTUFHRVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBP RiBTVUJTVElUVVRFIEdPT0RTCiAqIE9SIFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFUQSwgT1Ig UFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9OKQogKiBIT1dFVkVSIENBVVNFRCBBTkQg T04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVAog KiBMSUFCSUxJVFksIE9SIFRPUlQgKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkg QVJJU0lORyBJTiBBTlkgV0FZCiAqIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUsIEVW RU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YKICogU1VDSCBEQU1BR0UuCiAqCiAq LwoKI2RlZmluZSBTQ0NTU1RSICJAKCMpRnJlZUJTRCA5LjAtQkVUQTIgIzU6IFR1ZSBPY3QgMjUg MjM6MDc6NTEgUERUIDIwMTEiCiNkZWZpbmUgVkVSU1RSICJGcmVlQlNEIDkuMC1CRVRBMiAjNTog VHVlIE9jdCAyNSAyMzowNzo1MSBQRFQgMjAxMVxuICAgIHJvZHJpZ2NAZGliYmxlci5jcm9kcmln dWVzLm9yZzovdXNyL29iai9vcHQyL2JyYW5jaGVzL2hlYWQvc3JjL3N5cy9NWUtFUk5FTDFcbiIK I2RlZmluZSBSRUxTVFIgIjkuMC1CRVRBMiIKCmNoYXIgc2Njc1tzaXplb2YoU0NDU1NUUikgPiAx MjggPyBzaXplb2YoU0NDU1NUUikgOiAxMjhdID0gU0NDU1NUUjsKY2hhciB2ZXJzaW9uW3NpemVv ZihWRVJTVFIpID4gMjU2ID8gc2l6ZW9mKFZFUlNUUikgOiAyNTZdID0gVkVSU1RSOwpjaGFyIG9z dHlwZVtdID0gIkZyZWVCU0QiOwpjaGFyIG9zcmVsZWFzZVtzaXplb2YoUkVMU1RSKSA+IDMyID8g c2l6ZW9mKFJFTFNUUikgOiAzMl0gPSBSRUxTVFI7CmludCBvc3JlbGRhdGUgPSA5MDAwNDM7CmNo YXIga2Vybl9pZGVudFtdID0gIkdFTkVSSUMiOwo= --00032555767a5d6ce504b04c7555-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 27 20:46:05 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F2701065673 for ; Thu, 27 Oct 2011 20:46:05 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id AF7C58FC24 for ; Thu, 27 Oct 2011 20:46:04 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 910798EE; Thu, 27 Oct 2011 22:46:02 +0200 (CEST) Date: Thu, 27 Oct 2011 22:45:18 +0200 From: Pawel Jakub Dawidek To: d@delphij.net Message-ID: <20111027204517.GE1667@garage.freebsd.pl> References: <4EA9AABE.4000803@delphij.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tMbDGjvJuJijemkf" Content-Disposition: inline In-Reply-To: <4EA9AABE.4000803@delphij.net> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Current , netchild@FreeBSD.ORG Subject: Re: [PATCH] Default scrub interval to whole weeks X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2011 20:46:05 -0000 --tMbDGjvJuJijemkf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 27, 2011 at 12:02:22PM -0700, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > Hi, >=20 > I think it might be better if we set scrub interval to whole weeks > (proposed changeset changes it to 5 weeks). >=20 > The reason for this is to make it easier for system administrators to > estimate when the scrub happens, for instance, if a scrub was done on > Saturday, it always happen on Saturdays. [...] Sounds reasonable. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --tMbDGjvJuJijemkf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk6pwt0ACgkQForvXbEpPzTHoACgvFDu3omJfy4iyDs5sgyxgnQ3 6/gAmwbRFHJ7zh7mJy03FtXnwLUb2/VI =Ccqe -----END PGP SIGNATURE----- --tMbDGjvJuJijemkf-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 27 20:46:09 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 81229106564A for ; Thu, 27 Oct 2011 20:46:09 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 7E5F1156DB8; Thu, 27 Oct 2011 20:46:08 +0000 (UTC) Message-ID: <4EA9C310.7010301@FreeBSD.org> Date: Thu, 27 Oct 2011 13:46:08 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: Craig Rodrigues References: <20111020114844.GK59810@albert.catwhisker.org> <20111020122121.GL59810@albert.catwhisker.org> <201110211636.05917.jhb@freebsd.org> <20111025140000.GA8559@albert.catwhisker.org> <4EA71713.3020404@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: sys/conf/newvers.sh vs. subversion-1.7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2011 20:46:09 -0000 On 10/27/2011 12:05, Craig Rodrigues wrote: > On Tue, Oct 25, 2011 at 1:07 PM, Doug Barton wrote: >> The attached implements that, and is almost certainly the right way to >> go. It would be nice if someone could test it, and better if someone >> else could commit it. I swore after the last time that I'd stay away >> from that file precisely because of all the bikeshed stupidity that this >> issue creates. > > Hi, > > I tested your patch and it works. I am attaching vers.c files which I > generated in trees which were under svn control, and not under svn control. Thanks for testing the non-svn case. I just committed the patch. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Thu Oct 27 23:00:13 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3932106564A for ; Thu, 27 Oct 2011 23:00:11 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9972A8FC14 for ; Thu, 27 Oct 2011 23:00:11 +0000 (UTC) Received: by qadz32 with SMTP id z32so4269006qad.13 for ; Thu, 27 Oct 2011 16:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; bh=4aOEHDlG896wTCVdttcssB4auLRC+ioiVGic7rnDOIM=; b=neZ9Lj8/lWczdOSfewuNrwWl1O1FoZp2LzokK5aZh2EKoyanpdYugXh6i76SXOGuW3 OrRvNwzyYllibm6VfwJCPRo7aK5wy3asWHa67pK5x5qK6/qJKMe5PnuirQrdC+iTDa8+ PYBNtwoegKgMIxT5pW2ouCic4IZekcSmt07gA= Received: by 10.229.187.202 with SMTP id cx10mr13341qcb.197.1319756410891; Thu, 27 Oct 2011 16:00:10 -0700 (PDT) Received: from kan.dyndns.org (c-24-63-226-98.hsd1.ma.comcast.net. [24.63.226.98]) by mx.google.com with ESMTPS id en3sm10805378qab.22.2011.10.27.16.00.04 (version=SSLv3 cipher=OTHER); Thu, 27 Oct 2011 16:00:05 -0700 (PDT) Date: Thu, 27 Oct 2011 18:59:57 -0400 From: Alexander Kabaev To: "C. P. Ghost" Message-ID: <20111027185957.54ece0ad@kan.dyndns.org> In-Reply-To: References: <20111008201456.GA3529@lexx.ifp.tuwien.ac.at> <20111017190027.GA9873@lexx.ifp.tuwien.ac.at> <20111018131353.GA83797@lexx.ifp.tuwien.ac.at> <649509EEAEBA42D4A3DCC1FDF5DA72E5@multiplay.co.uk> <20111025202755.4243ae74@kan.dyndns.org> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/_ehfTFplfGyk.y.4CYlV8t2"; protocol="application/pgp-signature" Cc: Alexey Shuvaev , freebsd-current@freebsd.org Subject: Re: Panics after AHCI timeouts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2011 23:00:13 -0000 --Sig_/_ehfTFplfGyk.y.4CYlV8t2 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 26 Oct 2011 16:00:55 +0200 "C. P. Ghost" wrote: > On Wed, Oct 26, 2011 at 2:27 AM, Alexander Kabaev > wrote: > > I do see timeouts on one of my Samsung ST3750330A disks and they > > definitely do not cause any panics. The weird part in my case is > > that disk then immediately reappears as online and mirror zpool can > > be rebuilt by just onlining the disk with 'zpool online > > ' command. > > > > It seems to be happening once system has accumulated some uptime. If > > rebooted, it keeps running for a week or two with no issues, but > > then timeouts start to happen more or less reliably every single 24 > > hours. >=20 > Does it correlate with high disk activity, i.e. with periodic(8)? >=20 > On my machine, I have a feeling that timeouts occur more often > at that point, than normally... and that they also occur when multiple > processes access the disk simultaneously. >=20 > If it's only one process, the machine (usually) doesn't hang, even > when that process is copying big files back and forth for a long > period of time (it's a backup process). But interleave that process > with another one accessing the same disk, and poof!, almost > immediately ahci timeouts. occur. Very strange... Maybe a race > condition of some sort after all? >=20 No, I cannot say there is any specific correlation to IO load of the machine, timeouts I saw happen randomly and seem almost always happen as system uptime crosses two weeks boundary. I am suspecting Samsung firmware at this point. --=20 Alexander Kabaev --Sig_/_ehfTFplfGyk.y.4CYlV8t2 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iD8DBQFOqeJzQ6z1jMm+XZYRAnb/AJ4haF0NaxrpT1w3T5iHNwdNe6N/OQCfSSxf XCk/Nu1y9lrJXV+7hO/Mpvo= =miJa -----END PGP SIGNATURE----- --Sig_/_ehfTFplfGyk.y.4CYlV8t2-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 27 23:19:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B1B3106564A for ; Thu, 27 Oct 2011 23:19:52 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from hercules.mthelicon.com (unknown [IPv6:2001:49f0:2023::2]) by mx1.freebsd.org (Postfix) with ESMTP id 30B5C8FC08 for ; Thu, 27 Oct 2011 23:19:52 +0000 (UTC) Received: from PortaPegIII (hydra.fletchermoorland.co.uk [78.33.209.59]) (authenticated bits=0) by hercules.mthelicon.com (8.14.5/8.14.3) with ESMTP id p9RNJO0C008557; Thu, 27 Oct 2011 23:19:25 GMT (envelope-from ken@mthelicon.com) From: "Pegasus Mc Cleaft" To: "'Alexander Kabaev'" , "'C. P. Ghost'" References: <20111008201456.GA3529@lexx.ifp.tuwien.ac.at> <20111017190027.GA9873@lexx.ifp.tuwien.ac.at> <20111018131353.GA83797@lexx.ifp.tuwien.ac.at> <649509EEAEBA42D4A3DCC1FDF5DA72E5@multiplay.co.uk> <20111025202755.4243ae74@kan.dyndns.org> <20111027185957.54ece0ad@kan.dyndns.org> In-Reply-To: <20111027185957.54ece0ad@kan.dyndns.org> Date: Fri, 28 Oct 2011 00:19:26 +0100 Message-ID: <005e01cc94fe$dfbe3390$9f3a9ab0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcyU/Fg95Bo3loPLTbqK0RFUzIBBHAAANXrg Content-Language: en-gb X-Spam-Status: No, score=0.9 required=15.0 tests=BAYES_00,DOS_OUTLOOK_TO_MX, FSL_HELO_NON_FQDN_1 autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on hercules.mthelicon.com Cc: 'Alexey Shuvaev' , freebsd-current@freebsd.org Subject: RE: Panics after AHCI timeouts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Oct 2011 23:19:52 -0000 >> If it's only one process, the machine (usually) doesn't hang, even >> when that process is copying big files back and forth for a long >> period of time (it's a backup process). But interleave that process >> with another one accessing the same disk, and poof!, almost >> immediately ahci timeouts. occur. Very strange... Maybe a race >> condition of some sort after all? >> > >No, I cannot say there is any specific correlation to IO load of the machine, >timeouts I saw happen randomly and seem almost always happen as system uptime >crosses two weeks boundary. I am suspecting Samsung firmware at this point. Now that's interesting as I use a mixture of Samsung, WD, and Seagate.. And I do believe the Samsungs tend to do this more. I see ACHI timeouts from time to time on my machine (10-Current AMD64) but normally only when I am doing something like a scrub. The machine has never panicked as a result of this, it normally just FAULTS the drive in the pool and keeps on going. At that point, doing a camcontrol rescan all does not bring the drive back into existence (it will normally just hang on that bus for 15-20 seconds and then carry on without identifying a drive). I have to pull the drive, let it spin down and then reinsert it. Once its reinserted, the drive comes back on the bus and I can online it again. The weird thing is this.. For me, it only ever seems to be when I am writing to the pool/disk. Pure reads don't seem to bother it. I don't really know at this point if the SATA ports have gone wonkey on the motherboard, or if the processor on the HD has crashed. I almost tend to believe it's the drive because camcontrol stops on that port almost as it if knows there is a link there, but can't talk to it. Peg From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 00:29:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2C061065672; Fri, 28 Oct 2011 00:29:37 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 55BCB8FC08; Fri, 28 Oct 2011 00:29:37 +0000 (UTC) Received: from lstewart1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id 147097E820; Fri, 28 Oct 2011 11:29:35 +1100 (EST) Message-ID: <4EA9F76E.9010008@freebsd.org> Date: Fri, 28 Oct 2011 11:29:34 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111016 Thunderbird/7.0.1 MIME-Version: 1.0 To: John Baldwin References: <20111022084931.GD1697@garage.freebsd.pl> <201110240814.22368.jhb@freebsd.org> <20111026075431.GB1672@garage.freebsd.pl> <201110260753.37264.jhb@freebsd.org> In-Reply-To: <201110260753.37264.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: Kostik Belousov , Andre Oppermann , freebsd-current@freebsd.org, Pawel Jakub Dawidek , freebsd-net@freebsd.org Subject: Re: 9.0-RC1 panic in tcp_input: negative winow. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2011 00:29:38 -0000 On 10/26/11 22:53, John Baldwin wrote: > On Wednesday, October 26, 2011 3:54:31 am Pawel Jakub Dawidek wrote: >> On Mon, Oct 24, 2011 at 08:14:22AM -0400, John Baldwin wrote: >>> On Sunday, October 23, 2011 11:58:28 am Pawel Jakub Dawidek wrote: >>>> On Sun, Oct 23, 2011 at 11:44:45AM +0300, Kostik Belousov wrote: >>>>> On Sun, Oct 23, 2011 at 08:10:38AM +0200, Pawel Jakub Dawidek wrote: >>>>>> My suggestion would be that if we won't be able to fix it before 9.0, >>>>>> we should turn this assertion off, as the system seems to be able to >>>>>> recover. >>>>> >>>>> Shipped kernels have all assertions turned off. >>>> >>>> Yes, I'm aware of that, but many people compile their production kernels >>>> with INVARIANTS/INVARIANT_SUPPORT to fail early instead of eg. >>>> corrupting data. I'd be fine in moving this under DIAGNOSTIC or changing >>>> it into a printf, so it will be visible. >>> >>> No, the kernel is corrupting things in other places when this is true, so >>> if you are running with INVARIANTS, we want to know about it. Specifically, >>> in several places in TCP we assume that rcv_adv>= rcv_nxt, and depend on >>> being able to do 'rcv_adv - rcv_nxt'. >>> >>> In this case, it looks like the difference is consistently less than one >>> frame. I suspect the other end of the connection is sending just beyond the >>> end of the advertised window (it probably assumes it is better to send a full >>> frame if it has that much pending data even though part of it is beyond the >>> window edge vs sending a truncated packet that just fills the window) and that >>> that frame is accepted ok in the header prediction case and it's ACK is >>> delayed, but the next packet to arrive then trips over this assumption. >>> >>> Since 'win' is guaranteed to be non-negative and we explicitly cast >>> 'rcv_adv - rcv_nxt' to (int) in the following line that the assert is checking >>> for: >>> >>> tp->rcv_wnd = imax(win, (int)(tp->rcv_adv - tp->rcv_nxt)); >>> >>> I think we already handle this case ok and perhaps the assertion can just be >>> removed? Not sure if others feel that it warrants a comment to note that this >>> is the case being handled. >> >> I added debug to the places where rcv_adv and rcv_nxt are modified. Here >> is what happens before the panic occurs: >> >> tcp_do_segment:1722 negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022361548 rcv_adv 4022360100 diff -1448 >> tcp_do_segment:2847 negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022362298 rcv_adv 4022361548 diff -750 >> tcp_do_segment:1722 negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022363746 rcv_adv 4022362298 diff -1448 >> tcp_do_segment:2847 negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022364836 rcv_adv 4022363746 diff -1090 >> tcp_do_segment:1722 negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022366284 rcv_adv 4022364836 diff -1448 >> tcp_do_segment:1722 negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022370628 rcv_adv 4022369690 diff -938 >> tcp_do_segment:1722 negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022379140 rcv_adv 4022377692 diff -1448 >> tcp_do_segment:1722 negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022387792 rcv_adv 4022386344 diff -1448 >> tcp_do_segment:2847 negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022388890 rcv_adv 4022387792 diff -1098 >> tcp_do_segment:1722 negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022390338 rcv_adv 4022388890 diff -1448 >> tcp_do_segment:2847 negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022394563 rcv_adv 4022394342 diff -221 >> panic: tcp_input negative window: tp 0xfffffe000dab1b70 rcv_nxt 4022394563 rcv_adv 4022394342 win=0 diff -221 >> >> I can send you the full log if you want, I've plenty of messages where >> rcv_adv< rcv_nxt, not all of them trigger this assertion. > > The assertion would be triggered when the next packet arrives (as I said > above). Try modifying your debugging output to also log if the ACK is > delayed. I suspect it is not delayed until the last one. (Pushing out an > ACK will reset rcv_adv to be beyond rcv_nxt in tcp_output(), so in the case > of an immediate ACK, rcv_nxt> rcv_adv is only a transient condition all > under a single lock invocation so never visible to other consumers of the > protocol control block.) If that is what you see, then that confirms what > I guessed above and I will likely just remove the assertion in tcp_input() > and patch the timewait code to handle this case. > Pawel, have you been able to confirm John's hypothesis? What I don't quite get is why we haven't had a lot more reports of this issue... Cheers, Lawrence From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 01:42:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F333F1065740 for ; Fri, 28 Oct 2011 01:42:24 +0000 (UTC) (envelope-from dan@sunsaturn.com) Received: from sunsaturn.com (mail1.sunsaturn.com [IPv6:2001:49f0:4004::2]) by mx1.freebsd.org (Postfix) with ESMTP id C0C598FC17 for ; Fri, 28 Oct 2011 01:42:24 +0000 (UTC) Received: by sunsaturn.com (Postfix, from userid 1001) id 350FF119C96; Thu, 27 Oct 2011 20:42:24 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sunsaturn.com; s=gamma; t=1319766144; bh=OXVH5fwcg4yV/95/jeoAXHjGBBAJD29IzB68UdwTlvk=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; b=k86HnHpSmobNl8WWu8bBS1PKjJiuxeOV6UBZQLEgX/GX2P2IgpjhlhOXTEeGrpp7Q 5n24RKGcQ5sS8xlDaQG2MU4qKmj3gr62bge4bW/ile1fr7YC4/CxWhQgUpKWo87P7j sK9dzNMYuCGOUSndL4A36yqCXHZLs1z/JMvTRJLs= Received: from localhost (localhost [127.0.0.1]) by sunsaturn.com (Postfix) with ESMTP id 2FBDB119C56 for ; Thu, 27 Oct 2011 20:42:24 -0500 (CDT) Date: Thu, 27 Oct 2011 20:42:24 -0500 (CDT) From: Dan To: freebsd-current@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: samba+zfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2011 01:42:25 -0000 Updated from 9.0 beta3 to RC1 and using mkvmerge over samba/zfs its taking over an hour to just mux in things like DTS english, where it was 15 minutes on beta3. Dan. ------------------------- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: Dan@SunSaturn.com From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 03:15:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 451B21065670 for ; Fri, 28 Oct 2011 03:15:17 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 076AF8FC19 for ; Fri, 28 Oct 2011 03:15:16 +0000 (UTC) Received: by ywt32 with SMTP id 32so4335641ywt.13 for ; Thu, 27 Oct 2011 20:15:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; bh=NYGBAvrEhyle+278sM0DI6c8l/99qAVzDT9ui5Qut/c=; b=v8jnS+L4slsD63CTjy5l8HDS5pvlRx6DGXUEwt4Rrw9zG81t6xaUPlEXiJsMc/jVW2 phImDcV/byIGiDMuQGq5rMRotqkmzMwi2XxYl459a/g00Aic3+tXBVRBuXOcmLtF4OrB oP2WCioxhE1hzUhEmjYr9108wwf9ezPTMuUfo= Received: by 10.236.76.102 with SMTP id a66mr702476yhe.25.1319770119809; Thu, 27 Oct 2011 19:48:39 -0700 (PDT) Received: from beastiefree.localnet (c-98-230-65-110.hsd1.al.comcast.net. [98.230.65.110]) by mx.google.com with ESMTPS id 36sm20654169anz.2.2011.10.27.19.48.39 (version=SSLv3 cipher=OTHER); Thu, 27 Oct 2011 19:48:39 -0700 (PDT) From: Chuck Burns To: freebsd-current@freebsd.org Date: Thu, 27 Oct 2011 21:48:15 -0500 User-Agent: KMail/1.13.7 (FreeBSD/9.0-RC1; KDE/4.7.2; amd64; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201110272148.15459.break19@gmail.com> Subject: make installworld fails on releng9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2011 03:15:17 -0000 I had some issues while running make installworld after I sync'd to the latest releng9, on my RC1 install. Now, it appears to failed, while trying to create some links, chfn chsh ypchpass ypchfn ypchsh. These are supposed to be hardlinked to /usr/bin/chpass, except that, since the other files already exist, and are immutable, make installworld was unable to do anything, so I wound up removing the immutable flag on these files and re- running make installworld. I didn't see any mention of this little.. issue, in UPDATING, or in the - current mailing list (yes, I know, 9.0 is no longer technically, current, but since it isn't released yet, I figure it's close enough) -- Chuck Burns From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 04:15:59 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E326B1065673 for ; Fri, 28 Oct 2011 04:15:59 +0000 (UTC) (envelope-from coco@executive-computing.de) Received: from mail.moehre.org (mail.moehre.org [195.96.35.7]) by mx1.freebsd.org (Postfix) with ESMTP id 9C7168FC17 for ; Fri, 28 Oct 2011 04:15:59 +0000 (UTC) Received: from mail.moehre.org (unknown [195.96.35.7]) by mail.moehre.org (Postfix) with ESMTP id 88C928B143B for ; Fri, 28 Oct 2011 06:00:00 +0200 (CEST) X-Spam-Flag: NO X-Spam-Score: -100.888 X-Spam-Level: X-Spam-Status: No, score=-100.888 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, AWL=-0.042, TW_HF=0.077, TW_YP=0.077, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mail.moehre.org ([195.96.35.7]) by mail.moehre.org (mail.moehre.org [195.96.35.7]) (amavisd-new, port 10024) with ESMTP id bz4+wzBbsCiB for ; Fri, 28 Oct 2011 05:59:58 +0200 (CEST) Received: from s560x.c0c0.intra (p54B0C97B.dip.t-dialin.net [84.176.201.123]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: coco@executive-computing.de) by mail.moehre.org (Postfix) with ESMTPSA id 9F8708B141B for ; Fri, 28 Oct 2011 05:59:58 +0200 (CEST) Date: Fri, 28 Oct 2011 05:59:57 +0200 (CEST) From: Marco Steinbach X-X-Sender: coco@s560x.c0c0.intra To: freebsd-current@freebsd.org In-Reply-To: <201110272148.15459.break19@gmail.com> Message-ID: References: <201110272148.15459.break19@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: make installworld fails on releng9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2011 04:16:00 -0000 On Thu, 27 Oct 2011, Chuck Burns wrote: > I had some issues while running make installworld after I sync'd to the latest > releng9, on my RC1 install. > > Now, it appears to failed, while trying to create some links, > chfn > chsh > ypchpass > ypchfn > ypchsh. > > These are supposed to be hardlinked to /usr/bin/chpass, except that, since the > other files already exist, and are immutable, make installworld was unable to > do anything, so I wound up removing the immutable flag on these files and re- > running make installworld. > > I didn't see any mention of this little.. issue, in UPDATING, or in the - > current mailing list (yes, I know, 9.0 is no longer technically, current, but > since it isn't released yet, I figure it's close enough) I'm seeing this on head (226827, amd64), also. MfG CoCo From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 05:46:54 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0A67106564A; Fri, 28 Oct 2011 05:46:54 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 5A09C8FC0C; Fri, 28 Oct 2011 05:46:54 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 2CF22A39; Fri, 28 Oct 2011 07:46:52 +0200 (CEST) Date: Fri, 28 Oct 2011 07:46:07 +0200 From: Pawel Jakub Dawidek To: Lawrence Stewart Message-ID: <20111028054605.GF1667@garage.freebsd.pl> References: <20111022084931.GD1697@garage.freebsd.pl> <201110240814.22368.jhb@freebsd.org> <20111026075431.GB1672@garage.freebsd.pl> <201110260753.37264.jhb@freebsd.org> <4EA9F76E.9010008@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RE3pQJLXZi4fr8Xo" Content-Disposition: inline In-Reply-To: <4EA9F76E.9010008@freebsd.org> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Kostik Belousov , freebsd-net@freebsd.org, freebsd-current@freebsd.org, Andre Oppermann Subject: Re: 9.0-RC1 panic in tcp_input: negative winow. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2011 05:46:54 -0000 --RE3pQJLXZi4fr8Xo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 28, 2011 at 11:29:34AM +1100, Lawrence Stewart wrote: > On 10/26/11 22:53, John Baldwin wrote: > > The assertion would be triggered when the next packet arrives (as I said > > above). Try modifying your debugging output to also log if the ACK is > > delayed. I suspect it is not delayed until the last one. (Pushing out= an > > ACK will reset rcv_adv to be beyond rcv_nxt in tcp_output(), so in the = case > > of an immediate ACK, rcv_nxt> rcv_adv is only a transient condition all > > under a single lock invocation so never visible to other consumers of t= he > > protocol control block.) If that is what you see, then that confirms w= hat > > I guessed above and I will likely just remove the assertion in tcp_inpu= t() > > and patch the timewait code to handle this case. > > >=20 > Pawel, have you been able to confirm John's hypothesis? [...] Yeah, sorry. I moved the debug to the points where we drop the t_inpcb lock and I still see rcv_nxt being greater than rcv_adv: tcp_do_segment:2970 negative window: tp 0xfffffe00685ee3d0 rcv_nxt 1312878= 324 rcv_adv 1312878187 This is just before the INP_WUNLOCK(tp->t_inpcb) under 'check_delack' label. I see this a lot (it was logged 545 times for 11 different tp pointers during 24h period). tcp_do_segment:3009 negative window: tp 0xfffffe005cfc6000 rcv_nxt 1442546= 453 rcv_adv 1442545722 This is just before calling tcp_output(). This one was logged 65 times for 3 different tp pointers. I placed a debug also after tcp_output() call, but it is not logged, so once we return from tcp_output() everything is fine. The panic would be triggered 115 times for 5 different tp pointers during that time. I write 'tp pointers' as I'm not 100% sure if the same pointer always represents the same connection or if it is reused. > [...] What I don't=20 > quite get is why we haven't had a lot more reports of this issue... Maybe because my TCP/IP stack is heavly modified? ...not:) No idea to be honest. Ask Ken to turn on INVARIANTS in 9.0-RC2 and we will see:) --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --RE3pQJLXZi4fr8Xo Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk6qQZ0ACgkQForvXbEpPzTIcwCcC6C06i2hgJshb29NsE5iZ5NJ l/EAoO/qBU7/4+8tJOElQQUArjNWpq4t =CGv+ -----END PGP SIGNATURE----- --RE3pQJLXZi4fr8Xo-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 06:48:44 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A41C1065674; Fri, 28 Oct 2011 06:48:44 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: from worf.ds9.tecnik93.com (worf.ds9.tecnik93.com [81.196.207.130]) by mx1.freebsd.org (Postfix) with ESMTP id 42FB58FC18; Fri, 28 Oct 2011 06:48:44 +0000 (UTC) Received: from localhost (unknown [81.181.146.246]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by worf.ds9.tecnik93.com (Postfix) with ESMTPSA id 56DFC22C5490; Fri, 28 Oct 2011 09:48:42 +0300 (EEST) Date: Fri, 28 Oct 2011 09:48:41 +0300 From: Ion-Mihai Tetcu To: Ruslan Mahmatkhanov , current@FreeBSD.org Message-ID: <20111028094841.05cb82b5@FreeBSD.org> In-Reply-To: <4EA94388.1080906@yandex.ru> References: <20111011063602.GO68552@droso.net> <20111017153551.23281532@tetcu.info> <20111017135130.d9caa4f1.stas@FreeBSD.org> <20111018223146.GA93539@server.vk2pj.dyndns.org> <20111019105938.5aa842a4@FreeBSD.org> <20111019010420.646c0938.stas@FreeBSD.org> <20111019113136.316cb665@FreeBSD.org> <20111021124434.07c96389@FreeBSD.org> <20111027102104.GZ27932@droso.net> <4EA94388.1080906@yandex.ru> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Erwin Lansing , freebsd-ports@freebsd.org Subject: Re: [UPDATE] Re: Update on ports on 10.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: Fri, 28 Oct 2011 06:48:44 -0000 On Thu, 27 Oct 2011 15:42:00 +0400 Ruslan Mahmatkhanov wrote: > Erwin Lansing wrote on 27.10.2011 14:21: > > On Fri, Oct 21, 2011 at 12:44:34PM +0300, Ion-Mihai Tetcu wrote: > >>>>> What, on the other hand, makes sense is to have the fix that > >>>>> should include: > >>>>> a) a KNOB (WITH_FBSD10_FIX or similar), > >>>>> b) that only is run from bsd.port.mk when OSVERSION>1000000 > >>>>> c) runs the latest version of the above patch. > >>>>> The KNOB's existence allow us to turn on the fix only for broken > >>>>> ports, and easily know what these broken ports are -- so we can > >>>>> poke maintainers from time to time about upstream fixes, ... > >>>> > >> > >> Erwin is currently running a build on i386-10 with this and the > >> following patches: > >> - bsd.port.mk patch from beat (based on ed@, jilles@ and stas@ > >> patches) > >> - python patch from beat > >> - python patch from linimon > >> - WITH_FBSD10_FIX in: > >> - textproc/expat2 > >> - devel/pcre > >> - devel/libtool > >> - audio/libogg > >> Results by Monday. > >> > > > > These patches have now been committed to the tree, notably with > > lang/python27 missing in the above list but was included as well. > > There have been some proposals already and we can now incrementally > > improve the workaround and, more importantly, start fixing > > individual ports. Please note that the patch tries to balance > > between being a general enough fix to make it easy to get a working > > system running while not just swiping the whole issue under the rug > > and forget about it until the next release cycle. Make sure to > > send any fixes upstream to the hack can be removed from the ports > > again. > > > > Thanks for all your patience and thanks for all those involved, > > especially beat who sent many patches and improvements. > > > > Erwin > > About devel/libtool fix. Why to not update it to 2.4.2 where this was > fixed upstream? I mean http://bugs.freebsd.org/162012 We probably need an other set of -exps for that, given how many ports depends on it, and I don't think we have the time for that before the release. -- IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> itetcu@FreeBSD.org, PGP Key ID 057E9F8B493A297B From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 07:03:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18B021065672; Fri, 28 Oct 2011 07:03:52 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 9FC7C8FC15; Fri, 28 Oct 2011 07:03:51 +0000 (UTC) Received: from outgoing.leidinger.net (p5796CC28.dip.t-dialin.net [87.150.204.40]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 15567844016; Fri, 28 Oct 2011 09:03:35 +0200 (CEST) Received: from localhost (unknown [85.94.224.19]) by outgoing.leidinger.net (Postfix) with ESMTPSA id 9FC2119DF; Fri, 28 Oct 2011 09:03:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1319785412; bh=RmxU81G+jqoFvdM6N497P5bNVDRe6hlRZvEy5gQAOAo=; h=Date:Subject:Message-ID:From:To:MIME-Version:Content-Type; b=n8j0tf7zwupLvok30LUpRXQ2PrAYupxzW+3zL3VBDXeRDYzqDyPaFRAU1J8VkJmyi eZ3C52fEeIpqPo1aWoqS0SJ3TIJlevkNWKnUIgHFmqdcgAF+NhQPuX+DqIYf+lyL8I wQb9YBuiTyAZq6N7W1SHd4dOYvJB3nrDKv6tqhipOWnPJJdlocGecHz40sxQN943U2 nqhGWCXmv7n1Vm7jYjVE8vtlcbY6ORNN4DkM2NqgZc5LIL9Dz4KzowSSjgHUjyT1U1 9U8XyQb6whJL1kvnFQbjvWgMI0TFoMzVJQMqyDq3vKiFuDjfcXRgxz6DKJpHC9n5iw Umlxn68ZFUgoQ== Date: Fri, 28 Oct 2011 09:03:11 +0200 Message-ID: Importance: normal From: Alexander Leidinger To: d@delphij.net, freebsd-current@freebsd.org, netchild@freebsd.org MIME-Version: 1.0 X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 15567844016.A2608 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.099, required 6, autolearn=disabled, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, HTML_MESSAGE 0.00) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1320390217.0666@30CzrWIdNKiF4f64Ay7aaw X-EBL-Spam-Status: No Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: AW:[PATCH] Default scrub interval to whole weeks X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2011 07:03:52 -0000 CkhpLMKgCgp3aHkgNSB3ZWVrcyBhbmQgbm90IDQ/IFNob3VsZG4ndCB3ZSBhZGQgYSB2YXJpYWJs ZSBmb3IgdGhlIHdlZWtkYXkgdG8gbWFrZSBpdCBtb3JlIHByZWRpY3RhYmxlP8KgCgpCeWUswqAK QWxleGFuZGVyLsKgCgoKCi0tIApTZW5kIHZpYSBhbiBBbmRyb2lkIGRldmljZSwgcGxlYXNlIGZv cmdpdmUgYnJldml0eSBhbmQgdHlwb2dyYXBoaWMgYW5kIHNwZWxsaW5nIGVycm9ycy7CoFhpbiBM SSA8ZGVscGhpakBkZWxwaGlqLm5ldD4gaGF0IGdlc2NocmllYmVuOi0tLS0tQkVHSU4gUEdQIFNJ R05FRCBNRVNTQUdFLS0tLS0KSGFzaDogU0hBMjU2CgpIaSwKCkkgdGhpbmsgaXQgbWlnaHQgYmUg YmV0dGVyIGlmIHdlIHNldCBzY3J1YiBpbnRlcnZhbCB0byB3aG9sZSB3ZWVrcwoocHJvcG9zZWQg Y2hhbmdlc2V0IGNoYW5nZXMgaXQgdG8gNSB3ZWVrcykuCgpUaGUgcmVhc29uIGZvciB0aGlzIGlz IHRvIG1ha2UgaXQgZWFzaWVyIGZvciBzeXN0ZW0gYWRtaW5pc3RyYXRvcnMgdG8KZXN0aW1hdGUg d2hlbiB0aGUgc2NydWIgaGFwcGVucywgZm9yIGluc3RhbmNlLCBpZiBhIHNjcnViIHdhcyBkb25l IG9uClNhdHVyZGF5LCBpdCBhbHdheXMgaGFwcGVuIG9uIFNhdHVyZGF5cy7CoCBPbiBsYXJnZSB6 cG9vbHMsIHNjcnViIGNhbgpjb25zdW1lIGEgbG90IG9mIHRpbWUgYW5kIEkvTyBiYW5kd2lkdGgs IGFuZCBoYXZpbmcgaXQgaGFwcGVuIG9uCnJhbmRvbSB3ZWVrZGF5IGlzIG5vdCBhIGdvb2QgaWRl YS4KCkNoZWVycywKLSAtLSAKWGluIExJIDxkZWxwaGlqQGRlbHBoaWoubmV0PglodHRwczovL3d3 dy5kZWxwaGlqLm5ldC8KRnJlZUJTRCAtIFRoZSBQb3dlciB0byBTZXJ2ZSEJIExpdmUgZnJlZSBv ciBkaWUKLS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjIuMC4x OCAoRnJlZUJTRCkKCmlRRWNCQUVCQ0FBR0JRSk9xYXErQUFvSkVBVE8rQkkveWpmQk5xOElBTHht NnZydElJYm5rbHYrV005aGMxZWsKT3MzRHBJZjEyVU5BNTJ2MDJHZ2xxejNmeXVmZjR3UTRpSFFC aTFndlpSekVrWTlwVlRRZ0luRmkyRjVNbEJ4RgpEQzQ3NFJMeU9TaFMyU01CbUhaUVB4bFJjR2hH NmU5T1k3NVhMdTBIemJQbDNBaDcrSGlQY2NrRWdFWjdOamhMCjNDS1lpa3ZhWGVyRStJZWUrZHpy aFA5d04rSmFHNC9Salc0ZnZIQ2tXQ3VJY0RlbUt5ZWJVeXFiMU8rQTM1UDAKbFhqQ29tRTFTbll0 SlNqVldvYmdHSm05dGdKOENWOGZQTWQ2S2NFb2h3T2REb3E2WVNhZXNBMS9DQVlpclpUNwppNjVG R3BUN0VlcDNLNnJWNlhKdlpVZzJiTVFjUkwvSG1xSmVrb3dIc01teERaOCtsTFEwMDF0NVFVMGpG WTQ9Cj05Y2FOCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 07:12:07 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F792106566B; Fri, 28 Oct 2011 07:12:07 +0000 (UTC) (envelope-from hosting@syscare.sk) Received: from services.syscare.sk (services.syscare.sk [188.40.39.36]) by mx1.freebsd.org (Postfix) with ESMTP id EA7728FC12; Fri, 28 Oct 2011 07:12:06 +0000 (UTC) Received: from services.syscare.sk (services [188.40.39.36]) by services.syscare.sk (Postfix) with ESMTP id 9475A73E19; Fri, 28 Oct 2011 08:54:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.syscare.sk ([188.40.39.36]) by services.syscare.sk (services.rulez.sk [188.40.39.36]) (amavisd-new, port 10024) with ESMTP id dkFoj2B2NBlV; Fri, 28 Oct 2011 08:54:54 +0200 (CEST) Received: from hosting.syscare.sk (hosting [188.40.39.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by services.syscare.sk (Postfix) with ESMTPS id C8FBA73E0E; Fri, 28 Oct 2011 08:54:54 +0200 (CEST) Received: (from www@localhost) by hosting.syscare.sk (8.14.4/8.14.4/Submit) id p9S6ssHs029110; Fri, 28 Oct 2011 08:54:54 +0200 (CEST) (envelope-from hosting@syscare.sk) X-Authentication-Warning: hosting.syscare.sk: www set sender to hosting@syscare.sk using -f To: , X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 28 Oct 2011 07:54:54 +0100 From: Daniel Gerzo Organization: The FreeBSD Project In-Reply-To: <4E99FF0B.6080101@FreeBSD.org> References: <4E99FF0B.6080101@FreeBSD.org> Message-ID: <49dbd71d83b7b63f57dfb10c690535dc@rulez.sk> X-Sender: danger@FreeBSD.org User-Agent: Roundcube Webmail/0.5.4 Cc: Subject: Re: HEADSUP: Call for FreeBSD Status Reports - 3Q/2011 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2011 07:12:07 -0000 On Sat, 15 Oct 2011 23:45:47 +0200, Daniel Gerzo wrote: > Dear all, > > I would like to remind you that the next round of status reports > covering the third quarter of 2011 were due on October 15th, 2011. As > this initiative is very popular among our users, I would like to > ask you to submit your status reports as soon as possible, so that we > can compile the report in a timely fashion. I had a few requests to extend the deadline. If you have anything to submit for the upcoming status report (which would be very welcome!), please do so until Oct. 30th. Thank you. -- Kind regards Daniel From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 07:14:51 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C69E106564A; Fri, 28 Oct 2011 07:14:51 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.c2i.net [212.247.154.162]) by mx1.freebsd.org (Postfix) with ESMTP id 94E528FC16; Fri, 28 Oct 2011 07:14:50 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 195961601; Fri, 28 Oct 2011 09:14:48 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 28 Oct 2011 09:11:42 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <20111027170738.GB1667@garage.freebsd.pl> <201110272042.09238.hselasky@c2i.net> <20111027185115.GD1667@garage.freebsd.pl> In-Reply-To: <20111027185115.GD1667@garage.freebsd.pl> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201110280911.43003.hselasky@c2i.net> Cc: Pawel Jakub Dawidek , freebsd-usb@freebsd.org Subject: Re: umass(4) regression in 9.0-RC1. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2011 07:14:51 -0000 On Thursday 27 October 2011 20:51:15 Pawel Jakub Dawidek wrote: > On Thu, Oct 27, 2011 at 08:42:09PM +0200, Hans Petter Selasky wrote: > > This is the root HUB. Can you also show the actual device? > > Sorry, it wasn't connected, here it goes: > > ugen0.2: at usbus0, cfg=255 md=HOST spd=HIGH (480Mbps) > pwr=ON > > bLength = 0x0012 > bDescriptorType = 0x0001 > bcdUSB = 0x0200 > bDeviceClass = 0x0000 > bDeviceSubClass = 0x0000 > bDeviceProtocol = 0x0000 > bMaxPacketSize0 = 0x0008 > idVendor = 0x0bda > idProduct = 0x0119 > bcdDevice = 0x1981 > iManufacturer = 0x0001 > iProduct = 0x0002 > iSerialNumber = 0x0003 > bNumConfigurations = 0x0001 Hi, The control request in question is mandatory according to the UMASS specification, and I wonder why it times out and all other control requests aswell. Could you try setting the no-synchronize cache quirk instead, and then plug your device. I'm sorry, but this problem needs further investigation before we can make a patch. --HPS From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 08:43:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 134A0106566C for ; Fri, 28 Oct 2011 08:43:29 +0000 (UTC) (envelope-from mueller6727@bellsouth.net) Received: from fmailhost03.isp.att.net (fmailhost03.isp.att.net [207.115.11.53]) by mx1.freebsd.org (Postfix) with ESMTP id 01B168FC14 for ; Fri, 28 Oct 2011 08:43:28 +0000 (UTC) Date: Fri, 28 Oct 2011 08:43:28 +0000 (GMT) X-Comment: Sending client does not conform to RFC822 minimum requirements X-Comment: Date has been added by Maillennium Received: from localhost (adsl-68-18-76-46.sdf.bellsouth.net[68.18.76.46]) by isp.att.net (frfwmhc03) with SMTP id <20111028084328H03002t7hle>; Fri, 28 Oct 2011 08:43:28 +0000 X-Originating-IP: [68.18.76.46] From: "Thomas Mueller" To: freebsd-current@freebsd.org References: <20111027102208.88BFB106564A@hub.freebsd.org> Message-Id: <20111028084329.134A0106566C@hub.freebsd.org> 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, 28 Oct 2011 08:43:29 -0000 from Tom Evans : I have had this happen before, the PEBKAC. When running mergemaster, > it will prompt you to install new passwd, master.passwd and group > files - if you have added local users you must not say yes to this, > you must either merge the changes in or keep your local one. > If you still have a backup, you are probably missing just master.passwd. > hald, dbus would fail to start since their users are no longer there. > Once you've done this to your system once, you never want to do it again! When I had this problem, I was itching to get to bed. But since then, I checked /etc and the backup, and found master.passwd, copied it back, still have to boot into RC1 to see if the fix works. How does one run mergemaster without running roughshod over existing configuration? I did hit d (delete) on some files I didn't want to trash, such as mail.rc and the ports directory configuration. I wish there were a way to do a practice run with mergemaster without destroying anything, just as a medical student may practice on human cadavers, or flying in a flight simulator, where the consequences of doing the wrong thing are not disastrous. That way, I'd know what to do for next time. I could make one backup at the beginning, before the first mergemaster -p, and then another after that, before the second mergemaster. I remember etcupdate from NetBSD, see it in FreeBSD ports/sysutils, but not in FreeBSD base system. Tom From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 08:55:28 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6ADA6106566B; Fri, 28 Oct 2011 08:55:28 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 8D4E18FC14; Fri, 28 Oct 2011 08:55:27 +0000 (UTC) Received: by wwi18 with SMTP id 18so5262470wwi.31 for ; Fri, 28 Oct 2011 01:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:from:organization:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=33+yopX0bNKlZiR2PXnXVCTlySN6PycAj2fy1CkO9qk=; b=SQOYQh2QzSg2jrifBGQBz4jjni60I0psV3Nm0F8VlpK+0Y31Ir0SuJmhNXD6lBSut0 HC/T8kdbtoOxSYDkxnSszjrbWwkRyh2dMjk4RcwizsYTdZuh6o9pFEx4mDAzlshuEO2F agymGZYWD7hWQdHde5G4UQFG2M4F5LhAOEEZk= Received: by 10.227.198.203 with SMTP id ep11mr2549645wbb.0.1319792125981; Fri, 28 Oct 2011 01:55:25 -0700 (PDT) Received: from woodstock.peanuts (wifinat-16.polito.it. [130.192.232.16]) by mx.google.com with ESMTPS id fr4sm14253852wbb.0.2011.10.28.01.55.24 (version=SSLv3 cipher=OTHER); Fri, 28 Oct 2011 01:55:25 -0700 (PDT) Sender: Alberto Villa From: Alberto Villa Organization: The FreeBSD Project To: Mehmet Erol Sanliturk Date: Fri, 28 Oct 2011 10:55:17 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.0-RC1; KDE/4.7.2; amd64; ; ) References: <201110270133.44259.avilla@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2248259.HxzgsayBmr"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201110281055.20822.avilla@freebsd.org> Cc: freebsd-current@freebsd.org, kde@freebsd.org Subject: Re: FreeBSD 9.0 amd64 RC1 and KDE4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2011 08:55:28 -0000 --nextPart2248259.HxzgsayBmr Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable On Thursday 27 October 2011 02:34:11 Mehmet Erol Sanliturk wrote: > In a message previously I mentioned the KDE4 problem for 8.2 amd64=20 Release > , but that message even did not receive a single reply . Things just may get lost, sorry. > Install X . > Install KDE4 . > Login to console . > Without an .xinitrc file , and unmodified /etc/ttys file , execute startx= . > ( Do not start KDE4 directly . ) > In right xterm window of X , execute /usr/local/kde4/bin/startkde > ( /usr/local/kde4/bin is not in path definition ) . Done. > Then , I do not know , but , even this will supply much information=20 about > what is going problematic . Correction of first displayed errors and > continuing in that way , will solve the problems one by one . I see several kinds of messages: =2D kcheckrunning not found in PATH... this can indeed be fixed, and I'll d= o=20 it, but it's harmless; =2D logs of activity... they're expected; =2D the KSharedDataCache one, "ensure this partition...", is harmless (I'll= =20 patch kdelibs to hide this as it's causing a lot of misunderstandings...=20 and maybe I'll just make it work on 9.x and 10.x); =2D messages about Soprano/Akonadi/Virtuoso not being started... I guess=20 it's because they still have to start, and sure enough they disappear=20 after a while, and Akonadi/Nepomuk seem to work; =2D X errors... well, they're due to my driver. Apart from this, Plasma Desktop starts successfully, Amarok can play=20 music... In short, my session is fully restored. Apart from KWin, but a kwi= n=20 =2D-replace would be needed for this. > If KDE4 is starting directly , during waiting after display of hard disk > symbol , discontinuation of X with Ctrl-Alt-F1 will reveal some=20 messages , > but last ones . Therefore , the above method is better than that=20 second > method . I don't understand what "starting directly" means. Anyway, if you see=20 the same messages, there's nothing wrong here as well. =2D-=20 Alberto Villa, FreeBSD committer http://people.FreeBSD.org/~avilla COLORADO: Where they don't buy M & M's, 'cause they're so hard to peel. --nextPart2248259.HxzgsayBmr Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iJwEAAECAAYFAk6qbfgACgkQ3xiC6kQ1CovSaQQAop9kErmUJy0JYxmRuFtJVcd8 h3ky+hxHDXEqTJVgzfL9S3Q/GUKoAZIXVm+WvBcw8hg8ZDNbz7jBrkIvJO391ox3 qTnDnh1Y37DtvLCXplUO/lvEeRPQCVAX1o3wmCAxB6pO70omlIlLIa2OCfL5Zx73 1L2942ey9XKtXd1/t84= =QOd+ -----END PGP SIGNATURE----- --nextPart2248259.HxzgsayBmr-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 09:17:00 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53F75106566C for ; Fri, 28 Oct 2011 09:17:00 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 18F148FC0A for ; Fri, 28 Oct 2011 09:16:59 +0000 (UTC) Received: by qadz32 with SMTP id z32so4748298qad.13 for ; Fri, 28 Oct 2011 02:16:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=FpAhNjZ2O/aUMVQulkCshLRPFd3OQjOwpgWOiGR0CzY=; b=cTnZhbZT7j69lBZGuhAvhjxB278+/cLU9MmkhH13bG79jXJAuvX9GZc+KqUAkzfEgO J38OpSQa4UIuirxEN6Jp/RYGRQIwt+mpOt5M3M+sSrVEdKonMv7yM/JCtJsdhCxB/cvc Be7Ns62E9X7tTcC6jVioQasRyaJb958rRRMLU= MIME-Version: 1.0 Received: by 10.229.191.2 with SMTP id dk2mr464025qcb.32.1319793419298; Fri, 28 Oct 2011 02:16:59 -0700 (PDT) Received: by 10.229.226.65 with HTTP; Fri, 28 Oct 2011 02:16:59 -0700 (PDT) Date: Fri, 28 Oct 2011 11:16:59 +0200 Message-ID: From: "deeptech71@gmail.com" To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: panic: ffs_blkfree_cg: freeing free block X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2011 09:17:00 -0000 A panic occured while I was ``rm -rf''ing a large file&directory tree (that I just created with untar) on an old drive that I have not used for a long time. Unfortunately I'm not 100% sure that the filesystem was clean when I mounted it today. Could that result in such a panic? I don't have the intermediate object files for the kernel; now I'm building the kernel again (from the appropriate, exact sources). That shouldn't harm debugging, should it? Meanwhile, I'll take any debug info requests, which I'll attempt to address shortly. From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 09:50:34 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB0BD106566C for ; Fri, 28 Oct 2011 09:50:34 +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 74D978FC1B for ; Fri, 28 Oct 2011 09:50:34 +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 1RJj4w-0005n0-Re; Fri, 28 Oct 2011 10:50:29 +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 1RJj4e-00054b-GN; Fri, 28 Oct 2011 10:50:04 +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 p9S9nu8M006760; Fri, 28 Oct 2011 10:49:56 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5/Submit) id p9S9nueD006759; Fri, 28 Oct 2011 10:49:56 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Fri, 28 Oct 2011 10:49:56 +0100 From: Anton Shterenlikht To: Marco Steinbach Message-ID: <20111028094955.GA6728@mech-cluster241.men.bris.ac.uk> Mail-Followup-To: Marco Steinbach , freebsd-current@freebsd.org References: <201110272148.15459.break19@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: make installworld fails on releng9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2011 09:50:34 -0000 On Fri, Oct 28, 2011 at 05:59:57AM +0200, Marco Steinbach wrote: > > > On Thu, 27 Oct 2011, Chuck Burns wrote: > > >I had some issues while running make installworld after I sync'd to the > >latest > >releng9, on my RC1 install. > > > >Now, it appears to failed, while trying to create some links, > >chfn > >chsh > >ypchpass > >ypchfn > >ypchsh. > > > >These are supposed to be hardlinked to /usr/bin/chpass, except that, since > >the > >other files already exist, and are immutable, make installworld was unable > >to > >do anything, so I wound up removing the immutable flag on these files and > >re- > >running make installworld. > > > >I didn't see any mention of this little.. issue, in UPDATING, or in the - > >current mailing list (yes, I know, 9.0 is no longer technically, current, > >but > >since it isn't released yet, I figure it's close enough) > > I'm seeing this on head (226827, amd64), also. Just updated to 9.0-RC1 #2 r226827 sparc64, didn't see any problems. -- 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 Fri Oct 28 10:05:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47C141065673 for ; Fri, 28 Oct 2011 10:05:08 +0000 (UTC) (envelope-from mueller6727@bellsouth.net) Received: from fmailhost04.isp.att.net (fmailhost04.isp.att.net [204.127.217.104]) by mx1.freebsd.org (Postfix) with ESMTP id 34ACE8FC08 for ; Fri, 28 Oct 2011 10:05:07 +0000 (UTC) Date: Fri, 28 Oct 2011 10:05:05 +0000 (GMT) X-Comment: Sending client does not conform to RFC822 minimum requirements X-Comment: Date has been added by Maillennium Received: from localhost (adsl-68-18-76-46.sdf.bellsouth.net[68.18.76.46]) by isp.att.net (frfwmhc04) with SMTP id <20111028100505H0400ir69he>; Fri, 28 Oct 2011 10:05:05 +0000 X-Originating-IP: [68.18.76.46] From: "Thomas Mueller" To: freebsd-current@freebsd.org References: <20111027102208.88BFB106564A@hub.freebsd.org> Message-Id: <20111028100508.47C141065673@hub.freebsd.org> 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, 28 Oct 2011 10:05:08 -0000 from Tom Evans : I have had this happen before, the PEBKAC. When running mergemaster, > it will prompt you to install new passwd, master.passwd and group > files - if you have added local users you must not say yes to this, > you must either merge the changes in or keep your local one. > If you still have a backup, you are probably missing just master.passwd. > hald, dbus would fail to start since their users are no longer there. > Once you've done this to your system once, you never want to do it again! When I had this problem, I was itching to get to bed. But since then, I checked /etc and the backup, and found master.passwd, copied it back, still have to boot into RC1 to see if the fix works. Update: the fix didn't work, even though I have the necessary things in master.passwd. >From the boot messages: Starting dbus. Unknown username "polkit" in message bus configuration file Unknown username "haldaemon" in message bus configuration file Unknown username "avahi" in message bus configuration file Unknown username "pulse" in message bus configuration file Failed to start message bus: Could not get UID and GID for username "messagebus" /etc/rc: WARNING: failed to start dbus Starting hald. Updating motd:. Starting ntpd. Configuring syscons: keymap blanktime. Starting sshd. Starting cron. Starting background file system checks in 60 seconds. Update: the fix didn't work, even though I have the necessary things in master.passwd and /etc/rc.conf . >From the boot messages: Starting dbus. Unknown username "polkit" in message bus configuration file Unknown username "haldaemon" in message bus configuration file Unknown username "avahi" in message bus configuration file Unknown username "pulse" in message bus configuration file Failed to start message bus: Could not get UID and GID for username "messagebus" /etc/rc: WARNING: failed to start dbus Starting hald. Updating motd:. Starting ntpd. Configuring syscons: keymap blanktime. Starting sshd. Starting cron. Starting background file system checks in 60 seconds. Update: the fix didn't work, even though I have the necessary things in master.passwd. >From the boot messages: Starting dbus. Unknown username "polkit" in message bus configuration file Unknown username "haldaemon" in message bus configuration file Unknown username "avahi" in message bus configuration file Unknown username "pulse" in message bus configuration file Failed to start message bus: Could not get UID and GID for username "messagebus" /etc/rc: WARNING: failed to start dbus Starting hald. Updating motd:. Starting ntpd. Configuring syscons: keymap blanktime. Starting sshd. Starting cron. Starting background file system checks in 60 seconds. ... I still can't login as any nonroot user, even though I see the lines in /etc/master.passwd, which I copied back from backup, and if I startx as root, there is no response to keyboard or mouse. How do I recover? Do I have to copy the whole BETA2 /etc and possibly run mergemaster -p again? How does one run mergemaster without running roughshod over existing configuration? I did hit d (delete) on some files I didn't want to trash, such as mail.rc and the ports directory configuration. I wish there were a way to do a practice run with mergemaster without destroying anything, just as a medical student may practice on human cadavers, or flying in a flight simulator, where the consequences of doing the wrong thing are not disastrous. That way, I'd know what to do for next time. I could make one backup at the beginning, before the first mergemaster -p, and then another after that, before the second mergemaster. I remember etcupdate from NetBSD, see it in FreeBSD ports/sysutils, but not in FreeBSD base system. Tom From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 10:38:03 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF5BA106568E for ; Fri, 28 Oct 2011 10:38:03 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3fd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id 3A7428FC18 for ; Fri, 28 Oct 2011 10:38:03 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.187.76.163]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.5/8.14.5) with ESMTP id p9SAbvxI020802 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 28 Oct 2011 11:37:57 +0100 (BST) (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: OpenDKIM Filter v2.4.1 smtp.infracaninophile.co.uk p9SAbvxI020802 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infracaninophile.co.uk; s=201001-infracaninophile; t=1319798277; bh=Hw1CZ+B6hVYVYcYfh4a/IJSaKFiQbq8/ZlBosFYQt/E=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=XTlIjegtVjGltf+VHT1Y2tiy0cEgaDIhn8v463/EU7qq5rv1m+iVg9qKtML8q0rme CeWpB11KlTUGwKgkLlYT44rzR1oONN9oWnRm3O1BhKac8DenXZGwR2FEYjG7XtFFRH YCpORmAvB3GbIsLoTK4JIqiZDCBybuFgnt0BEVJM= Message-ID: <4EAA85FD.1060805@infracaninophile.co.uk> Date: Fri, 28 Oct 2011 11:37:49 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Thomas Mueller References: <20111027102208.88BFB106564A@hub.freebsd.org> <20111028100508.47C141065673@hub.freebsd.org> In-Reply-To: <20111028100508.47C141065673@hub.freebsd.org> X-Enigmail-Version: 1.3.2 OpenPGP: id=60AE908C Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA182BCBCD14BE90E8F4081F4" X-Virus-Scanned: clamav-milter 0.97.3 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_20,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,SPF_FAIL autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Cc: freebsd-current@freebsd.org 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, 28 Oct 2011 10:38:03 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA182BCBCD14BE90E8F4081F4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 28/10/2011 11:05, Thomas Mueller wrote: > I still can't login as any nonroot user, even though I see the lines > in /etc/master.passwd, which I copied back from backup, and if I > startx as root, there is no response to keyboard or mouse. pwd_mkdb -p /etc/master.passwd Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matthew@infracaninophile.co.uk Kent, CT11 9PW --------------enigA182BCBCD14BE90E8F4081F4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6qhgQACgkQ8Mjk52CukIxUnQCfQpvveQjwRtZWIzlT6mu2wIdg u3oAoI24GMUOJj94owKCDATrWjLHaVn4 =VuIH -----END PGP SIGNATURE----- --------------enigA182BCBCD14BE90E8F4081F4-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 10:48:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C3F2106564A for ; Fri, 28 Oct 2011 10:48:08 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 022018FC0A for ; Fri, 28 Oct 2011 10:48:07 +0000 (UTC) Received: by vws11 with SMTP id 11so5057874vws.13 for ; Fri, 28 Oct 2011 03:48:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nxTX9FEtXZx2OWOZDYqB4hsb2WtpLYQpNiKXUNfYwKU=; b=ca8WI53crevQgRvnMTj1FOK4lFGo936JHT3NqhtV31yoein5tqsgRDulQJL3qAE5lR jKIjWf3EQxPg5A6KpIu3NgPIsggU4AvS83ejc0j3hBNJzW10LGZhmFt1ZusZWUQndWu/ RbVak10v7L1hdb2goQ+mdfC4yn2pnazzH8f48= MIME-Version: 1.0 Received: by 10.52.68.43 with SMTP id s11mr536694vdt.62.1319798887077; Fri, 28 Oct 2011 03:48:07 -0700 (PDT) Received: by 10.52.182.40 with HTTP; Fri, 28 Oct 2011 03:48:07 -0700 (PDT) In-Reply-To: <20111028100508.47C141065673@hub.freebsd.org> References: <20111027102208.88BFB106564A@hub.freebsd.org> <20111028100508.47C141065673@hub.freebsd.org> Date: Fri, 28 Oct 2011 11:48:07 +0100 Message-ID: From: Tom Evans To: Thomas Mueller Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org 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, 28 Oct 2011 10:48:08 -0000 On Fri, Oct 28, 2011 at 11:05 AM, Thomas Mueller wrote: > Update: the fix didn't work, even though I have the necessary things in master.passwd and /etc/rc.conf . Did you re-run pwd_mkdb? > How does one run mergemaster without running roughshod over existing configuration? > So when mergemaster runs, it will ask you if you want to (i)nstall (d)elete or (m)erge the changes. If there are no additions to the file - eg new users or groups from the source - then you can just delete the update. If there are new users/groups, you need to merge them in. If you choose merge for /etc/group and /etc/master.passwd, it will show you the differences, and ask you to choose from the option on the left (your original file) or the right (the updated file) to merge them in. Cheers Tom PS Here is a log of me updating my /etc/group, as a new group 'hast' has been added that is not in my /etc/group *** Displaying differences between ./etc/group and installed version: --- /etc/group 2011-05-05 10:54:43.000000000 +0100 +++ ./etc/group 2011-10-28 11:39:54.000000000 +0100 @@ -1,11 +1,11 @@ -# $FreeBSD: src/etc/group,v 1.35.10.1.6.1 2010/12/21 17:09:25 kensmith Exp $ +# $FreeBSD: stable/8/etc/group 220104 2011-03-28 17:41:10Z trociny $ # -wheel:*:0:root,tom +wheel:*:0:root daemon:*:1: kmem:*:2: sys:*:3: tty:*:4: -operator:*:5:root,tom +operator:*:5:root mail:*:6: bin:*:7: news:*:8: @@ -26,21 +26,7 @@ dialer:*:68: network:*:69: audit:*:77: -www:*:80:tom +www:*:80: +hast:*:845: nogroup:*:65533: nobody:*:65534: -tom:*:1001: -cyrus:*:60: -messagebus:*:556: -avahi:*:558: -polkit:*:562: -haldaemon:*:560: -pulse:*:563: -pulse-access:*:564: -pulse-rt:*:557: -gdm:*:92: -pgsql:*:70: -rabbitmq:*:135: -_sabnzbd:*:350: -squid:*:100: -webcamd:*:145:tom Use 'd' to delete the temporary ./etc/group Use 'i' to install the temporary ./etc/group Use 'm' to merge the temporary and installed versions Use 'v' to view the diff results again Default is to leave the temporary file to deal with by hand How should I deal with this? [Leave it for later] m # $FreeBSD: src/etc/group,v 1.35.10.1.6.1 2010/12/21 17:09:25 kensmith Exp $ | # $FreeBSD: stable/8/etc/group 220104 2011-03-28 17:41:10Z trociny $ %r wheel:*:0:root,tom | wheel:*:0:root %l operator:*:5:root,tom | operator:*:5:root %l www:*:80:tom | www:*:80: > hast:*:845: %r tom:*:1001: < cyrus:*:60: < messagebus:*:556: < avahi:*:558: < polkit:*:562: < haldaemon:*:560: < pulse:*:563: < pulse-access:*:564: < pulse-rt:*:557: < gdm:*:92: < pgsql:*:70: < rabbitmq:*:135: < _sabnzbd:*:350: < squid:*:100: < webcamd:*:145:tom < %l Use 'i' to install merged file Use 'r' to re-do the merge Use 'v' to view the merged file Default is to leave the temporary file to deal with by hand *** How should I deal with the merged file? [Leave it for later] v # $FreeBSD: stable/8/etc/group 220104 2011-03-28 17:41:10Z trociny $ # wheel:*:0:root,tom daemon:*:1: kmem:*:2: sys:*:3: tty:*:4: operator:*:5:root,tom mail:*:6: bin:*:7: news:*:8: man:*:9: games:*:13: ftp:*:14: staff:*:20: sshd:*:22: smmsp:*:25: mailnull:*:26: guest:*:31: bind:*:53: proxy:*:62: authpf:*:63: _pflogd:*:64: _dhcp:*:65: uucp:*:66: dialer:*:68: network:*:69: audit:*:77: www:*:80: hast:*:845: nogroup:*:65533: nobody:*:65534: tom:*:1001: cyrus:*:60: messagebus:*:556: avahi:*:558: polkit:*:562: haldaemon:*:560: pulse:*:563: pulse-access:*:564: pulse-rt:*:557: gdm:*:92: pgsql:*:70: rabbitmq:*:135: _sabnzbd:*:350: squid:*:100: webcamd:*:145:tom Use 'i' to install merged file Use 'r' to re-do the merge Use 'v' to view the merged file Default is to leave the temporary file to deal with by hand *** How should I deal with the merged file? [Leave it for later] As you can see, the new file contains the changes from the update (it has the 'hast' group) plus the changes that were in my local /etc/group, and now I can tell mergemaster to install it (although it has managed to drop me from the www group, hand modification required!) From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 10:28:27 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 028DF1065670; Fri, 28 Oct 2011 10:28:27 +0000 (UTC) (envelope-from sascha@trimind.de) Received: from mikako.shopkeeper.de (mikako.shopkeeper.de [82.119.175.20]) by mx1.freebsd.org (Postfix) with ESMTP id 64EFD8FC15; Fri, 28 Oct 2011 10:28:26 +0000 (UTC) Received: from avalon.dobu.local (p508D47DF.dip.t-dialin.net [80.141.71.223]) (authenticated bits=0) by mikako.shopkeeper.de (8.14.3/8.14.3) with ESMTP id p9S9mTkq037682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Oct 2011 11:48:31 +0200 (CEST) (envelope-from sascha@trimind.de) Received: from avalon.dobu.local (localhost [127.0.0.1]) by avalon.dobu.local (8.14.4/8.14.2) with ESMTP id p9S9mS6H001886; Fri, 28 Oct 2011 11:48:28 +0200 (CEST) (envelope-from sascha@avalon.dobu.local) Received: (from sascha@localhost) by avalon.dobu.local (8.14.4/8.14.4/Submit) id p9S9mSCm001885; Fri, 28 Oct 2011 11:48:28 +0200 (CEST) (envelope-from sascha) Date: Fri, 28 Oct 2011 11:48:28 +0200 From: Sascha Klauder To: Garrett Cooper Message-ID: <20111028094828.GA1781@trimind.de> References: <8453E2A2-3219-4FAA-98CE-2F9D66EA1C39@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.97.2 at mikako.shopkeeper.de X-Virus-Status: Clean X-Mailman-Approved-At: Fri, 28 Oct 2011 11:16:42 +0000 Cc: antik@bsd.ee, freebsd-geom@freebsd.org, current@freebsd.org, Martin Wilke Subject: Re: gmirror failed with error 19. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sascha@trimind.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 10:28:27 -0000 On Tue, 2011-10-25 12:27 -0700, Garrett Cooper wrote: > On Tue, Oct 25, 2011 at 11:15 AM, Martin Wilke wrote: > > I face the same error since upgrade from 8.2 to 9.0RC1, is there any way to fix that? > errno == 19 => ENODEV -- so the question is, what device is missing? I've got bitten by this as well when trying a source up- grade of a freshly installed 8.2-RELEASE system that had gmirror configured after installation according to the procedure in the Handbook. The 9.0-RC1 kernel drops to the mountroot prompt when booting with GEOM_MIRROR: Device mirror/gm0 launched (2/2). GEOM_PART: partition 1 has end offset beyond last LBA: 490350671 > 490350670 GEOM_PART: integrity check failed (mirror/gm0, MBR) ... Trying to mount root from ufs:/dev/mirror/gm0s1a [rw]... mountroot: waiting for device /dev/mirror/gm0s1a ... Mounting from ufs:/dev/mirror/gm0s1a failed with error 19. which can be circumvented by setting the loader tunable kern.geom.part.check_integrity=0. The only immediately obvious difference I could find is that "gpart list" reports the last sector of the mirror/gm0 device different from the 8.2 kernel (490350670 vs 490350608). "gpart list" output when running the 8.2-RELEASE kernel: http://arwen.shopkeeper.de/~sascha/gpart-82 vs 9.0-RC1: http://arwen.shopkeeper.de/~sascha/gpart-90 Image of the MBR: http://arwen.shopkeeper.de/~sascha/ada0-mbr.bin Cheers, -sascha From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 11:56:32 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1B651065675 for ; Fri, 28 Oct 2011 11:56:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A7CDC8FC14 for ; Fri, 28 Oct 2011 11:56:32 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 19E6446B1A; Fri, 28 Oct 2011 07:56:25 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AFF458A02F; Fri, 28 Oct 2011 07:56:24 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 28 Oct 2011 07:47:25 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <20111027102208.88BFB106564A@hub.freebsd.org> <20111028084329.134A0106566C@hub.freebsd.org> In-Reply-To: <20111028084329.134A0106566C@hub.freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201110280747.25746.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 28 Oct 2011 07:56:24 -0400 (EDT) Cc: Thomas Mueller 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, 28 Oct 2011 11:56:32 -0000 On Friday, October 28, 2011 4:43:28 am Thomas Mueller wrote: > from Tom Evans : > > I have had this happen before, the PEBKAC. When running mergemaster, > > it will prompt you to install new passwd, master.passwd and group > > files - if you have added local users you must not say yes to this, > > you must either merge the changes in or keep your local one. > > > If you still have a backup, you are probably missing just master.passwd. > > > hald, dbus would fail to start since their users are no longer there. > > > Once you've done this to your system once, you never want to do it again! > > When I had this problem, I was itching to get to bed. But since then, I checked /etc and the backup, and found master.passwd, copied it back, still have to boot into RC1 to see if the fix works. > > How does one run mergemaster without running roughshod over existing configuration? > > I did hit d (delete) on some files I didn't want to trash, such as mail.rc and the ports directory configuration. > > I wish there were a way to do a practice run with mergemaster without destroying anything, just as a medical student may practice on human cadavers, or flying in a flight simulator, where the consequences of doing the wrong thing are not disastrous. That way, I'd know what to do for next time. > > I could make one backup at the beginning, before the first mergemaster -p, and then another after that, before the second mergemaster. > > I remember etcupdate from NetBSD, see it in FreeBSD ports/sysutils, but not in FreeBSD base system. Hmm, I did not know NetBSD had a util called etcupdate. However, the etcupdate in ports will work fine for FreeBSD. You do need to bootstrap it (see the notes in the manpage) once before you do a cvsup or svn up, but after that it should do 3-way merges to files rather easily. You can also see your local customizations via 'etcupdate diff'. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 11:56:32 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F15C51065676 for ; Fri, 28 Oct 2011 11:56:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C73688FC19 for ; Fri, 28 Oct 2011 11:56:32 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 5096546B06; Fri, 28 Oct 2011 07:56:26 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D7D4E8A037; Fri, 28 Oct 2011 07:56:25 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 28 Oct 2011 07:49:58 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <20111027102208.88BFB106564A@hub.freebsd.org> <20111027111451.GO63910@hoeg.nl> In-Reply-To: <20111027111451.GO63910@hoeg.nl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201110280749.58837.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 28 Oct 2011 07:56:25 -0400 (EDT) Cc: Tom Evans , Ed Schouten , Thomas Mueller 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, 28 Oct 2011 11:56:33 -0000 On Thursday, October 27, 2011 7:14:51 am Ed Schouten wrote: > * Tom Evans , 20111027 13:06: > > I have had this happen before, the PEBKAC. When running mergemaster, > > it will prompt you to install new passwd, master.passwd and group > > files - if you have added local users you must not say yes to this, > > you must either merge the changes in or keep your local one. > > It would have been so awesome if our /etc/master.passwd and /etc/group > included an #include directive. I do agree with this. Or if you could have /etc/passwd.d and /etc/group.d directories that can contain files that are auto-included. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 11:56:33 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FBE4106564A; Fri, 28 Oct 2011 11:56:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 74C618FC1A; Fri, 28 Oct 2011 11:56:33 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 5BFAD46B09; Fri, 28 Oct 2011 07:56:27 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F011C8A02E; Fri, 28 Oct 2011 07:56:26 -0400 (EDT) From: John Baldwin To: Pawel Jakub Dawidek Date: Fri, 28 Oct 2011 07:56:23 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <20111022084931.GD1697@garage.freebsd.pl> <4EA9F76E.9010008@freebsd.org> <20111028054605.GF1667@garage.freebsd.pl> In-Reply-To: <20111028054605.GF1667@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201110280756.23317.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 28 Oct 2011 07:56:27 -0400 (EDT) Cc: Kostik Belousov , Lawrence Stewart , freebsd-current@freebsd.org, Andre Oppermann , freebsd-net@freebsd.org Subject: Re: 9.0-RC1 panic in tcp_input: negative winow. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2011 11:56:33 -0000 On Friday, October 28, 2011 1:46:07 am Pawel Jakub Dawidek wrote: > On Fri, Oct 28, 2011 at 11:29:34AM +1100, Lawrence Stewart wrote: > > On 10/26/11 22:53, John Baldwin wrote: > > > The assertion would be triggered when the next packet arrives (as I said > > > above). Try modifying your debugging output to also log if the ACK is > > > delayed. I suspect it is not delayed until the last one. (Pushing out an > > > ACK will reset rcv_adv to be beyond rcv_nxt in tcp_output(), so in the case > > > of an immediate ACK, rcv_nxt> rcv_adv is only a transient condition all > > > under a single lock invocation so never visible to other consumers of the > > > protocol control block.) If that is what you see, then that confirms what > > > I guessed above and I will likely just remove the assertion in tcp_input() > > > and patch the timewait code to handle this case. > > > > > > > Pawel, have you been able to confirm John's hypothesis? [...] > > Yeah, sorry. I moved the debug to the points where we drop the t_inpcb > lock and I still see rcv_nxt being greater than rcv_adv: > > tcp_do_segment:2970 negative window: tp 0xfffffe00685ee3d0 rcv_nxt 1312878324 rcv_adv 1312878187 Yes, I still expect this. What I want to see is if 'delack' is always true in this case. > This is just before the INP_WUNLOCK(tp->t_inpcb) under 'check_delack' > label. I see this a lot (it was logged 545 times for 11 different tp > pointers during 24h period). > > tcp_do_segment:3009 negative window: tp 0xfffffe005cfc6000 rcv_nxt 1442546453 rcv_adv 1442545722 > > This is just before calling tcp_output(). This one was logged 65 times > for 3 different tp pointers. > I placed a debug also after tcp_output() call, but it is not logged, so > once we return from tcp_output() everything is fine. That is consistent with what I expect then, since in the delack case, tcp_output() isn't called. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 13:40:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 278D81065672 for ; Fri, 28 Oct 2011 13:40:29 +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 ABC728FC16 for ; Fri, 28 Oct 2011 13:40:28 +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 B1D1125D3872; Fri, 28 Oct 2011 13:40:27 +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 E5A59BD3DBD; Fri, 28 Oct 2011 13:40:26 +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 USPknvGOTwtw; Fri, 28 Oct 2011 13:40:26 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id EB859BD3D2C; Fri, 28 Oct 2011 13:40:25 +0000 (UTC) Date: Fri, 28 Oct 2011 13:40:25 +0000 (UTC) From: "Bjoern A. Zeeb" To: "deeptech71@gmail.com" In-Reply-To: Message-ID: References: X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: panic: ffs_blkfree_cg: freeing free block X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2011 13:40:29 -0000 On Fri, 28 Oct 2011, deeptech71@gmail.com wrote: > A panic occured while I was ``rm -rf''ing a large file&directory tree > (that I just created with untar) on an old drive that I have not used > for a long time. Unfortunately I'm not 100% sure that the filesystem > was clean when I mounted it today. Could that result in such a panic? > > I don't have the intermediate object files for the kernel; now I'm > building the kernel again (from the appropriate, exact sources). That > shouldn't harm debugging, should it? Meanwhile, I'll take any debug > info requests, which I'll attempt to address shortly. Do you know at which revision the kernel was or about from when? Consult uname -a. -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 14:41:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 519051065674 for ; Fri, 28 Oct 2011 14:41:53 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.server1.bsdforen.de (bsdforen.de [82.193.243.81]) by mx1.freebsd.org (Postfix) with ESMTP id 121108FC22 for ; Fri, 28 Oct 2011 14:41:52 +0000 (UTC) Received: from mobileKamikaze.norad (HSI-KBW-091-089-161-008.hsi2.kabel-badenwuerttemberg.de [91.89.161.8]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.server1.bsdforen.de (Postfix) with ESMTPSA id D2D378600C; Fri, 28 Oct 2011 16:41:51 +0200 (CEST) Message-ID: <4EAABF2E.3030709@bsdforen.de> Date: Fri, 28 Oct 2011 16:41:50 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111006 Thunderbird/7.0.1 MIME-Version: 1.0 To: Dimitry Andric References: <4EA80BD3.7000202@bsdforen.de> <4EA81B90.60501@FreeBSD.org> In-Reply-To: <4EA81B90.60501@FreeBSD.org> X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: 9.0 RC1 linking problem with i386 libs on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 14:41:53 -0000 On 26/10/2011 16:39, Dimitry Andric wrote: > On 2011-10-26 15:32, Dominic Fandrey wrote: >> I haven't tried to dig into this. Only "unusual" properties of the system >> are my non-default MAKEOBJDIRPREFIX and the use of ccache. >> >> # uname -a >> FreeBSD AryaStark.norad 9.0-RC1 FreeBSD 9.0-RC1 #0: Wed Oct 26 13:46:13 CEST 2011 root@AryaStark.norad:/usr/obj/GENERIC/amd64/usr/src/sys/GENERIC amd64 >> >> # make -VCC -VCPUTYPE -VCFLAGS >> /usr/local/bin/ccache clang >> athlon64-sse3 >> -O2 -pipe -march=athlon64-sse3 > > How are you setting CC and/or CFLAGS, precisely? Depending on how you > do it, the settings might not be propagated correctly to the build32 > stage. Like that: .if ${.CURDIR:M/usr/src} || ${.CURDIR:M/usr/src/*} CC=clang CXX=clang++ CPP=clang-cpp NO_WERROR= WERROR= .endif I had hoped that the .ifdef construction from the wiki was dated. I suppose it's emulating setting CC in the environment instead of in the make/src.conf. > Also, if you force CFLAGS to have -march=athlon64-sse3, I'm not > sure if the build32 stage can even work correctly. Just specify > CPUTYPE, that should be enough. That's what I do. I don't touch CFLAGS. > In any case, you can try out the attached patch, which should take care > of passing CC to the build32 stage correctly. I tried CC?=, but that doesn't work, because apparently make always initializes CC before parsing makefiles. I figure that means the !defined(CC) clause in the .ifdef construction is never true and thus obsolete. I didn't try it, though. Your patch works for me. > I would really like to have this in head, and even stable/9. It makes > it possible to just set CC in make.conf, without .ifdef trickery. Works > nicely for clang, too. :) Seconded! -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 15:18:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AA6C106566B for ; Fri, 28 Oct 2011 15:18:41 +0000 (UTC) (envelope-from rdeiriar@spock.cl) Received: from mail.spock.cl (enteljoven2.enteljoven.cl [164.77.63.23]) by mx1.freebsd.org (Postfix) with ESMTP id 98BC48FC0C for ; Fri, 28 Oct 2011 15:18:40 +0000 (UTC) Received: from [10.0.0.139] (190-21-149-119.baf.movistar.cl [190.21.149.119]) (AUTH: PLAIN rdeiriar@spock.cl, TLS: TLSv1/SSLv3, 256bits, CAMELLIA256-SHA) by mail.spock.cl with ESMTPSA; Fri, 28 Oct 2011 12:18:53 -0300 id 00001616.000000004EAAC7DD.000129D0 Message-ID: <4EAAC7A0.10808@spock.cl> Date: Fri, 28 Oct 2011 12:17:52 -0300 From: Roberto de Iriarte User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0) Gecko/20110930 Thunderbird/7.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <201110271723.p9RHNqVX082784@ambrisko.com> In-Reply-To: <201110271723.p9RHNqVX082784@ambrisko.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: LSI 9240-8i (IBM M1015) MegaRaid support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2011 15:18:41 -0000 Thank you Doug. I have another machine on the way, that i can use for testing. In the meantime, i got it to work with a reflashed controller, using the mps driver. I posted a "howto" to the forums http://forums.freebsd.org/showthread.php?t=27268 Best regards, Roberto > Roberto de Iriarte writes: > | Hi, > | > | Is there any expectancy of getting this piece of hardware (or it's IBM > | silbing, the M1015) working in MegaRaid mode, without having to reflash > | the card to IT mode. > | > | The reason of this request is that the UEFI Bios on the IBM XSeries > | 3550M3 refuses to properly initialize the controller if reflashed with > | the IT mode firmware, thus making it unusable. > | > | A search on LSI's website for a driver that supports 8-Stable or 9 did > | not produce any results > > I have driver changes from LSI to support the 9240 and newer ThunderBolt > based cards. I have the cards working but need to do a bunch more work > to get this into shape to commit to FreeBSD. I also need to look at > how they are dealing with their JBOD configuration and attachment. > > I have cards to test this stuff out but my time is limited to work on it. > One thing I should start working on is merging in the LSI changes into > the FreeBSD version since the LSI code drop has removed a bunch of > features that the FreeBSD version has. Then I can have a smaller change. > There are some architectural changes that I need to figure out. They > started to use 64 bit addressing. Then there are style issues. > > Probably the best thing for me to do is add the new HW support to > FreeBSD as a small diff then work on improving that and maybe others > can also help with that. > > Doug A. > _______________________________________________ > 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 Oct 28 15:25:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C90781065674; Fri, 28 Oct 2011 15:25:53 +0000 (UTC) (envelope-from kama@pvp.se) Received: from ms1.as.pvp.se (mail.pvp.se [213.64.187.227]) by mx1.freebsd.org (Postfix) with ESMTP id 8A0868FC12; Fri, 28 Oct 2011 15:25:53 +0000 (UTC) Received: by ms1.as.pvp.se (Postfix, from userid 1001) id B5C3270; Fri, 28 Oct 2011 16:57:47 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by ms1.as.pvp.se (Postfix) with ESMTP id B12E46F; Fri, 28 Oct 2011 16:57:47 +0200 (CEST) Date: Fri, 28 Oct 2011 16:57:47 +0200 (CEST) From: kama X-X-Sender: kama@ns1.as.pvp.se To: John Baldwin In-Reply-To: <201110280749.58837.jhb@freebsd.org> Message-ID: <20111028165451.O37058@ns1.as.pvp.se> References: <20111027102208.88BFB106564A@hub.freebsd.org> <20111027111451.GO63910@hoeg.nl> <201110280749.58837.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Tom Evans , Ed Schouten , Thomas Mueller , freebsd-current@freebsd.org 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, 28 Oct 2011 15:25:53 -0000 On Fri, 28 Oct 2011, John Baldwin wrote: > On Thursday, October 27, 2011 7:14:51 am Ed Schouten wrote: > > * Tom Evans , 20111027 13:06: > > > I have had this happen before, the PEBKAC. When running mergemaster, > > > it will prompt you to install new passwd, master.passwd and group > > > files - if you have added local users you must not say yes to this, > > > you must either merge the changes in or keep your local one. > > > > It would have been so awesome if our /etc/master.passwd and /etc/group > > included an #include directive. > > I do agree with this. Or if you could have /etc/passwd.d and /etc/group.d > directories that can contain files that are auto-included. Another idea is to let mergemaster call pw(8) to add remove users and groups instead of merging the files. It does not cover /etc/aliases though... But that is minor to this. =) /Bjorn From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 15:37:15 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB84D106566B for ; Fri, 28 Oct 2011 15:37:15 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 836AB8FC15 for ; Fri, 28 Oct 2011 15:37:15 +0000 (UTC) Received: by wwi18 with SMTP id 18so5794338wwi.31 for ; Fri, 28 Oct 2011 08:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=+z9tw7KxVwjgA4/6Zt7yXN4m8L6jY7iIXx5kXiyCvS0=; b=FuJUch5FVExDEOGvLmM6v6s5mQe0Kpb735jw2z4BKUV8Qdkok/NmrLvfdOjMtxLuJK k9+MMUAcovPWNn6DQDSEyoKZjZaUgJy51AMLNnxOuhto2p78OHdUxRcTjtgraqI1kCvY XOduDRtNjU3QHXzPtk3dDaecx/EKWlUh+bRMc= MIME-Version: 1.0 Received: by 10.227.202.143 with SMTP id fe15mr4458107wbb.25.1319816234415; Fri, 28 Oct 2011 08:37:14 -0700 (PDT) Received: by 10.180.8.34 with HTTP; Fri, 28 Oct 2011 08:37:14 -0700 (PDT) Date: Fri, 28 Oct 2011 11:37:14 -0400 Message-ID: From: Ryan Stone To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Subject: smp_rendezvous runs with interrupts and preemption enabled on unicore systems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2011 15:37:16 -0000 I'm seeing issues on a unicore systems running a derivative of FreeBSD 8.2-RELEASE if something calls mem_range_attr_set. It turns out that the root cause is a bug in smp_rendezvous_cpus. The first part of smp_rendezvous_cpus attempts to short-circuit the non-SMP case(note that smp_started is never set to 1 on a unicore system): if (!smp_started) { if (setup_func != NULL) setup_func(arg); if (action_func != NULL) action_func(arg); if (teardown_func != NULL) teardown_func(arg); return; } The problem is that this runs with interrupts enabled, outside of a critical section. My system runs with device_polling enabled with hz set to 2500, so its quite easy to wedge the system by having a thread run mem_range_attr_set. That has to do a smp_rendezvous, and if a timer interrupt happens to go off half-way through the action_func and preempt this thread, the system ends up deadlocked(although once it's wedged, typing at the serial console stands a good chance of unwedging the system. Go figure). I know that smp_rendezvous was reworked substantially on HEAD, but by inspection it looks like the bug is still present, as the short-circuit behaviour is still there. I am not entirely sure of the best way to fix this. Is it as simple as doing a spinlock_enter before setup_func and a spinlock_exit after teardown_func? It seems to boot fine, but I'm not at all confident that I understand the nuances of smp_rendezvous to be sure that there aren't side effects that I don't know about. From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 15:52:35 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 561BA106564A for ; Fri, 28 Oct 2011 15:52:35 +0000 (UTC) (envelope-from quazi@bk.ru) Received: from fallback7.mail.ru (fallback7.mail.ru [94.100.176.135]) by mx1.freebsd.org (Postfix) with ESMTP id 3F6CB8FC0C for ; Fri, 28 Oct 2011 15:52:33 +0000 (UTC) Received: from smtp23.mail.ru (smtp23.mail.ru [94.100.176.176]) by fallback7.mail.ru (mPOP.Fallback_MX) with ESMTP id 5963466CF86C for ; Fri, 28 Oct 2011 19:37:11 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=MvFSmZCel37zMKNf5MKbADsCt4uAEOxc/WO+d7JkX8I=; b=RlGWzte+C7QY1I1KfJEtdykEB2AeXHdJc17KHi1KY84Ddb8yGC07uFcsTPy1ktDSLsbXtH9Qg7mOoIyYxpu23wxpwWjX58iTUvLjmKv+iXSZgil5DqXJH8SBcZ77psY/; Received: from [178.126.97.161] (port=43097 helo=QUAZIS.SNNLAN.local) by smtp23.mail.ru with asmtp id 1RJoUV-0006gQ-00 for freebsd-current@freebsd.org; Fri, 28 Oct 2011 19:37:07 +0400 Message-ID: <4EAACE0D.1040702@bk.ru> Date: Fri, 28 Oct 2011 18:45:17 +0300 From: Ruslan Yakovlev User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:6.0) Gecko/20110824 Thunderbird/6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Spam: Not detected X-Mras: Ok X-Mras: Ok X-Mailman-Approved-At: Fri, 28 Oct 2011 16:19:50 +0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: FreeBSD 9.0 BETA1 build kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2011 15:52:35 -0000 Can't make buildkernel MAKE=make sh /usr/src/sys/conf/newvers.sh tinderbox cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror vers.c linking kernel nvenetlib.o:(.bss+0x0): multiple definition of `array' tws_services.o:(.data+0x0): first defined here ld: Warning: size of symbol `array' changed from 3536 in tws_services.o to 400 in nvenetlib.o *** Error code 1 Stop in /usr/obj/usr/src/sys/tinderkernel. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. # diff GENERIC tinderkernel 19c19 < # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.553.2.6 2011/10/26 23:05:59 kensmith Exp $ --- > # $FreeBSD: stable/9/sys/i386/conf/GENERIC 226405 2011-10-15 21:23:04Z kensmith $ 21,22c21,22 < cpu I486_CPU < cpu I586_CPU --- > #cpu I486_CPU > #cpu I586_CPU 24c24 < ident GENERIC --- > ident tinderbox 26c26 < makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols --- > #makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols 67,68d66 < options KDB # Kernel debugger related code < options KDB_TRACE # Print a stack trace for a panic 222c220 < #device nve # nVidia nForce MCP on-board Ethernet Networking --- > device nve # nVidia nForce MCP on-board Ethernet Networking 296c294 < options USB_DEBUG # enable debug msgs --- > #options USB_DEBUG # enable debug msgs 305c303 < device ulpt # Printer --- > #device ulpt # Printer 308c306 < device urio # Diamond Rio 500 MP3 player --- > #device urio # Diamond Rio 500 MP3 player 314c312 < device uipaq # Some WinCE based devices --- > #device uipaq # Some WinCE based devices 317c315 < device uvisor # Visor and Palm devices --- > #device uvisor # Visor and Palm devices 338,343c336,340 < # sbp(4) works for some systems but causes boot failure on others < #device sbp # SCSI over FireWire (Requires scbus and da) < device fwe # Ethernet over FireWire (non-standard!) < device fwip # IP over FireWire (RFC 2734,3146) < device dcons # Dumb console driver < device dcons_crom # Configuration ROM for dcons --- > device sbp # SCSI over FireWire (Requires scbus and da) > #device fwe # Ethernet over FireWire (non-standard!) > #device fwip # IP over FireWire (RFC 2734,3146) > #device dcons # Dumb console driver > #device dcons_crom # Configuration ROM for dcons 346,351c343,348 < device sound # Generic sound driver (required) < device snd_es137x # Ensoniq AudioPCI ES137x < device snd_hda # Intel High Definition Audio < device snd_ich # Intel, NVidia and other ICH AC'97 Audio < device snd_uaudio # USB Audio < device snd_via8233 # VIA VT8233x Audio --- > #device sound # Generic sound driver (required) > #device snd_es137x # Ensoniq AudioPCI ES137x > #device snd_hda # Intel High Definition Audio > #device snd_ich # Intel, NVidia and other ICH AC'97 Audio > #device snd_uaudio # USB Audio > #device snd_via8233 # VIA VT8233x Audio From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 17:33:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC6A2106566B; Fri, 28 Oct 2011 17:33:28 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id BF0898FC14; Fri, 28 Oct 2011 17:33:28 +0000 (UTC) Received: by pzk4 with SMTP id 4so21743978pzk.3 for ; Fri, 28 Oct 2011 10:33:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=u8MjrBv1XounJcu57HY42CCdGyXVh12eu3KkcN4+pKI=; b=BRuqTcDnGpL+QmfWTFr6U2OnDmE2yuCgDL/jchWg6sBbe+LdRd+P3EOmafTVA49dJl 94Y1z1r/4nNRU2MPu6fl4e9qyD5dvq2e7TEtlOld3PvBppZv4L1vco43aNTj5otQsWEV iFVZ9Tu+FmU9UFofbHmiJfAzK7GPgbAggwjUg= MIME-Version: 1.0 Received: by 10.68.38.41 with SMTP id d9mr5068922pbk.103.1319821633394; Fri, 28 Oct 2011 10:07:13 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.68.57.40 with HTTP; Fri, 28 Oct 2011 10:07:13 -0700 (PDT) In-Reply-To: References: Date: Fri, 28 Oct 2011 10:07:13 -0700 X-Google-Sender-Auth: 3BnhH3vVtWvMmTqw3tU9PEYMNO8 Message-ID: From: mdf@FreeBSD.org To: Ryan Stone Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current , mlaier@freebsd.org Subject: Re: smp_rendezvous runs with interrupts and preemption enabled on unicore systems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2011 17:33:29 -0000 On Fri, Oct 28, 2011 at 8:37 AM, Ryan Stone wrote: > I'm seeing issues on a unicore systems running a derivative of FreeBSD > 8.2-RELEASE if something calls mem_range_attr_set. =A0It turns out that > the root cause is a bug in smp_rendezvous_cpus. =A0The first part of > smp_rendezvous_cpus attempts to short-circuit the non-SMP case(note > that smp_started is never set to 1 on a unicore system): > > =A0 =A0 =A0 =A0if (!smp_started) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (setup_func !=3D NULL) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0setup_func(arg); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (action_func !=3D NULL) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0action_func(arg); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (teardown_func !=3D NULL) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0teardown_func(arg); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return; > =A0 =A0 =A0 =A0} > > The problem is that this runs with interrupts enabled, outside of a > critical section. =A0My system runs with device_polling enabled with hz > set to 2500, so its quite easy to wedge the system by having a thread > run mem_range_attr_set. =A0That has to do a smp_rendezvous, and if a > timer interrupt happens to go off half-way through the action_func and > preempt this thread, the system ends up deadlocked(although once it's > wedged, typing at the serial console stands a good chance of unwedging > the system. =A0Go figure). > > I know that smp_rendezvous was reworked substantially on HEAD, but by > inspection it looks like the bug is still present, as the > short-circuit behaviour is still there. > > I am not entirely sure of the best way to fix this. =A0Is it as simple > as doing a spinlock_enter before setup_func and a spinlock_exit after > teardown_func? =A0It seems to boot fine, but I'm not at all confident > that I understand the nuances of smp_rendezvous to be sure that there > aren't side effects that I don't know about. Looks like Max didn't have time to upstream this fix: struct mtx smp_ipi_mtx; +MTX_SYSINIT(smp_ipi_mtx, &smp_ipi_mtx, "smp rendezvous", MTX_SPIN); ... static void mp_start(void *dummy) { - mtx_init(&smp_ipi_mtx, "smp rendezvous", NULL, MTX_SPIN); ... if (!smp_started) { + mtx_lock_spin(&smp_ipi_mtx); if (setup_func !=3D NULL) setup_func(arg); if (action_func !=3D NULL) action_func(arg); if (teardown_func !=3D NULL) teardown_func(arg); + mtx_unlock_spin(&smp_ipi_mtx); return; } Cheers, matthew From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 18:19:21 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60E02106564A for ; Fri, 28 Oct 2011 18:19:21 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 23F778FC12 for ; Fri, 28 Oct 2011 18:19:21 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:4c76:9767:f5a:f9ce] (unknown [IPv6:2001:7b8:3a7:0:4c76:9767:f5a:f9ce]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id E7D2A5C37; Fri, 28 Oct 2011 20:19:18 +0200 (CEST) Message-ID: <4EAAF228.1060000@FreeBSD.org> Date: Fri, 28 Oct 2011 20:19:20 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111019 Thunderbird/8.0 MIME-Version: 1.0 To: Dominic Fandrey References: <4EA80BD3.7000202@bsdforen.de> <4EA81B90.60501@FreeBSD.org> <4EAABF2E.3030709@bsdforen.de> In-Reply-To: <4EAABF2E.3030709@bsdforen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: 9.0 RC1 linking problem with i386 libs on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 18:19:21 -0000 On 2011-10-28 16:41, Dominic Fandrey wrote: ... > Like that: > .if ${.CURDIR:M/usr/src} || ${.CURDIR:M/usr/src/*} > CC=clang > CXX=clang++ > CPP=clang-cpp > NO_WERROR= > WERROR= > .endif > > I had hoped that the .ifdef construction from the wiki was dated. I > suppose it's emulating setting CC in the environment instead of in > the make/src.conf. There are two different problems here. One is that src.conf is read relatively late, and only when bsd.own.mk is included. Therefore, src.conf is not the right place to put CC, CXX and so on. The other problem is that the build32 stage uses environment variables to override CC, CXX, AS and LD for its sub-make (see LIB32WMAKEENV in Makefile.inc1), adding the necessary flags for 32-bit compilation. However, since environment variables are in turn overridden by direct assignments (like via reading make.conf), the 32-bit compilation flags get lost when you specify any of CC, CXX, AS or LD in make.conf. This latter problem is what my patch attempts to fix, while changing as little as possible. ... > I tried CC?=, but that doesn't work, because apparently make always > initializes CC before parsing makefiles. Yes, that is because make implicitly reads sys.mk, which either defines CC directly, or through reading make.conf. ... > I didn't try it, though. Your patch works for me. > >> I would really like to have this in head, and even stable/9. It makes >> it possible to just set CC in make.conf, without .ifdef trickery. Works >> nicely for clang, too. :) > > Seconded! If there aren't any objections, I will commit it this weekend. From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 19:10:35 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD0FE106566C; Fri, 28 Oct 2011 19:10:35 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 7CFDF8FC17; Fri, 28 Oct 2011 19:10:35 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id CA4DECAE; Fri, 28 Oct 2011 21:10:32 +0200 (CEST) Date: Fri, 28 Oct 2011 21:09:47 +0200 From: Pawel Jakub Dawidek To: Hans Petter Selasky Message-ID: <20111028190947.GA1713@garage.freebsd.pl> References: <20111027170738.GB1667@garage.freebsd.pl> <201110272042.09238.hselasky@c2i.net> <20111027185115.GD1667@garage.freebsd.pl> <201110280911.43003.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline In-Reply-To: <201110280911.43003.hselasky@c2i.net> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: umass(4) regression in 9.0-RC1. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2011 19:10:35 -0000 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 28, 2011 at 09:11:42AM +0200, Hans Petter Selasky wrote: > On Thursday 27 October 2011 20:51:15 Pawel Jakub Dawidek wrote: > > On Thu, Oct 27, 2011 at 08:42:09PM +0200, Hans Petter Selasky wrote: > > > This is the root HUB. Can you also show the actual device? > >=20 > > Sorry, it wasn't connected, here it goes: > >=20 > > ugen0.2: at usbus0, cfg=3D255 md=3DHOST spd=3DHIGH= (480Mbps) > > pwr=3DON > >=20 > > bLength =3D 0x0012 > > bDescriptorType =3D 0x0001 > > bcdUSB =3D 0x0200 > > bDeviceClass =3D 0x0000 > > bDeviceSubClass =3D 0x0000 > > bDeviceProtocol =3D 0x0000 > > bMaxPacketSize0 =3D 0x0008 > > idVendor =3D 0x0bda > > idProduct =3D 0x0119 > > bcdDevice =3D 0x1981 > > iManufacturer =3D 0x0001 > > iProduct =3D 0x0002 > > iSerialNumber =3D 0x0003 > > bNumConfigurations =3D 0x0001 >=20 > Hi, >=20 > The control request in question is mandatory according to the UMASS=20 > specification, and I wonder why it times out and all other control reques= ts=20 > aswell. >=20 > Could you try setting the no-synchronize cache quirk instead, and then pl= ug=20 > your device. >=20 > I'm sorry, but this problem needs further investigation before we can mak= e a=20 > patch. It wasn't immediately obvious for me how to set the no-synchronize cache quirk, but I think I found it: # usbconfig add_quirk UQ_MSC_NO_SYNC_CACHE And it seems to work: umass0: on usbus0 (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI status: Check Condition (probe0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:28,0 (Not ready t= o ready change, medium may have changed) da0 at umass-sim0 bus 0 scbus13 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 30799MB (63076352 512 byte sectors: 255H 63S/T 3926C) --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk6q/fsACgkQForvXbEpPzTlcQCfSjF9ybX8gZI7/YsVrBGVnY2r hDUAn2tf2+lzvlOI4Dh+gFk5h6rgNdP0 =xcWu -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 19:37:31 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7446B106566B for ; Fri, 28 Oct 2011 19:37:31 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 02E068FC0C for ; Fri, 28 Oct 2011 19:37:30 +0000 (UTC) Received: by faar19 with SMTP id r19so5619526faa.13 for ; Fri, 28 Oct 2011 12:37:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8WooQuGI7mlGs5vXbDWLNMjF3lEuzamQEGDqkJRDAb8=; b=XaNZzk+vanSA268LKl0RMK6iTqKrEFQD9MxlH65WPRTuWjZYMJZN+v7FuiNtdX5RhZ +TkSVfHv6BsRu3x9yjoV9M/3rHi6xWD3OwfbdrOOe2q72Wvomi8+dEqiaZo6tfKEd90y F7vy7mgdPOCXB7TePr4IcX26oqyHfwx0KFDIY= Received: by 10.223.5.201 with SMTP id 9mr8459700faw.5.1319830649886; Fri, 28 Oct 2011 12:37:29 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id y8sm19061608faj.10.2011.10.28.12.37.28 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 28 Oct 2011 12:37:28 -0700 (PDT) Sender: Alexander Motin Message-ID: <4EAB0477.8060401@FreeBSD.org> Date: Fri, 28 Oct 2011 22:37:27 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: Dennis Koegel References: <4EA83DB1.4070602@FreeBSD.org> In-Reply-To: <4EA83DB1.4070602@FreeBSD.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: current Subject: Re: gmultipath: act/act, path checking? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2011 19:37:31 -0000 On 26.10.2011 12:09, Dennis Koegel wrote: > are there any plans to have gmultipath support for active/active? Few days ago I've started from fixing some issues in gmultipath and already rewritten half of it while trying to make it usable. I expect to have something to present in a week or two. It will also include active/active mode support there, as at my present point required changes are minimal. -- Alexander Motin. From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 19:59:18 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C17FB106566B for ; Fri, 28 Oct 2011 19:59:18 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 5C8C78FC14 for ; Fri, 28 Oct 2011 19:59:18 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id BD9C42A28CC3; Fri, 28 Oct 2011 21:59:17 +0200 (CEST) Date: Fri, 28 Oct 2011 21:59:17 +0200 From: Ed Schouten To: Ruslan Yakovlev Message-ID: <20111028195917.GA63910@hoeg.nl> References: <4EAACE0D.1040702@bk.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Oh6wehMCKJhhoxlo" Content-Disposition: inline In-Reply-To: <4EAACE0D.1040702@bk.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 9.0 BETA1 build kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2011 19:59:18 -0000 --Oh6wehMCKJhhoxlo Content-Type: multipart/mixed; boundary="/w6WUUxYkubDgwa5" Content-Disposition: inline --/w6WUUxYkubDgwa5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Ruslan Yakovlev , 20111028 17:45: > nvenetlib.o:(.bss+0x0): multiple definition of `array' >=20 > tws_services.o:(.data+0x0): first defined here Grrrr! $#(*@!&(*!@&# I think you can work around this by removing either nve or tws. I guess problems like these are mainly caused by the fact that we often forget to mark global variables as static, even though they ought to be. If only GCC/Clang had a warning for that... --=20 Ed Schouten WWW: http://80386.nl/ --/w6WUUxYkubDgwa5 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="missing-variable-declaration.diff" Content-Transfer-Encoding: quoted-printable diff --git a/contrib/llvm/tools/clang/include/clang/Basic/DiagnosticSemaKin= ds.td b/contrib/llvm/tools/clang/include/clang/Basic/DiagnosticSemaKinds.td index 97414f2..1306846 100644 --- a/contrib/llvm/tools/clang/include/clang/Basic/DiagnosticSemaKinds.td +++ b/contrib/llvm/tools/clang/include/clang/Basic/DiagnosticSemaKinds.td @@ -2273,6 +2273,9 @@ def note_sentinel_here : Note< def warn_missing_prototype : Warning< "no previous prototype for function %0">, InGroup>, DefaultIgnore; +def warn_missing_variable_declaration : Warning< + "no previous extern declaration for non-static variable %0">, + InGroup>, DefaultIgnore; def err_redefinition : Error<"redefinition of %0">; def err_definition_of_implicitly_declared_member : Error< "definition of implicitly declared %select{default constructor|copy " diff --git a/contrib/llvm/tools/clang/lib/Sema/SemaDecl.cpp b/contrib/llvm/= tools/clang/lib/Sema/SemaDecl.cpp index 9d91a48..9a5fe21 100644 --- a/contrib/llvm/tools/clang/lib/Sema/SemaDecl.cpp +++ b/contrib/llvm/tools/clang/lib/Sema/SemaDecl.cpp @@ -4002,6 +4002,11 @@ void Sema::CheckVariableDeclaration(VarDecl *NewVD, Previous.addDecl(Pos->second); } =20 + if (Previous.empty() && NewVD->getStorageClass() =3D=3D SC_None && + NewVD->hasGlobalStorage()) + Diag(NewVD->getLocation(), + diag::warn_missing_variable_declaration) << NewVD; + if (T->isVoidType() && !NewVD->hasExternalStorage()) { Diag(NewVD->getLocation(), diag::err_typecheck_decl_incomplete_type) << T; --/w6WUUxYkubDgwa5-- --Oh6wehMCKJhhoxlo Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJOqwmVAAoJEG5e2P40kaK7aZwP/i7QAwz17bQQp8LSph8elX1D Ko7GjTt8mUi0qBKvKLRGblSGn5IWCJdbM6+++IjSPNtpxmp32nsb6sjM7I1tWoUC x/f6ThH+/hZcKDg3yUa6mrlGZTkBQGCnIcbmV1zsIRVSbqoAIgan7cuRBqIAezr2 PGpT4ASRWiCAjDF6/11GeaVed3QStNP1mtHya+UP7CUcAREUoQcXLDJm32xZNj7N 1vRvYbR2AxcdISnse89peJaAIr+8vx113AjzZQhj4BhmnkJGvuaDo4jeIVutedlk wCVcaLNh/XPcvXWRZJ4VLFpimUU3qen4m6VxoAGNi4plPi6sEtl1ab7JyyqT/41M ptwmr2z/BKpAAF9VZkLFNzQM7KNyKqi+Tk6rXruBnSie8Lir+qmEWK1shTo/cSTx RTXP7OuUXQritTD26TugrJyyvjVu7ISdaJMtenTC/pjNhCu648pIIYUcY94z31Rw 24ZZ1uc4Vd5Dm8FLUuScM9FdfjYjZNO36SzN989hPXVmZh2drvwG2VP4ShKVCrzL 7lMJf2bnAG2sRFjApSu63x6/tkSrv/0coCTfHNExQhyC/KPZPknhFFh8XFqyeH4T 6hgohx8sBCsidtnSMOADzutspU0rMMg/aSq4yhCpEmgWVTwc36/D05omJJIe4hnF WnGnj7Yk/3muvRDFKkrf =U5qU -----END PGP SIGNATURE----- --Oh6wehMCKJhhoxlo-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 20:15:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 858C2106564A; Fri, 28 Oct 2011 20:15:17 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.server1.bsdforen.de (bsdforen.de [82.193.243.81]) by mx1.freebsd.org (Postfix) with ESMTP id 472F78FC0A; Fri, 28 Oct 2011 20:15:16 +0000 (UTC) Received: from mobileKamikaze.norad (HSI-KBW-091-089-161-008.hsi2.kabel-badenwuerttemberg.de [91.89.161.8]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.server1.bsdforen.de (Postfix) with ESMTPSA id 1A331860DD; Fri, 28 Oct 2011 22:15:15 +0200 (CEST) Message-ID: <4EAB0D53.7090000@bsdforen.de> Date: Fri, 28 Oct 2011 22:15:15 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111006 Thunderbird/7.0.1 MIME-Version: 1.0 To: Dimitry Andric References: <4EA80BD3.7000202@bsdforen.de> <4EA81B90.60501@FreeBSD.org> <4EAABF2E.3030709@bsdforen.de> <4EAAF228.1060000@FreeBSD.org> In-Reply-To: <4EAAF228.1060000@FreeBSD.org> X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: 9.0 RC1 linking problem with i386 libs on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 20:15:17 -0000 On 28/10/2011 20:19, Dimitry Andric wrote: > On 2011-10-28 16:41, Dominic Fandrey wrote: > ... >> ... >> >> I had hoped that the .ifdef construction from the wiki was dated. I >> suppose it's emulating setting CC in the environment instead of in >> the make/src.conf. > > There are two different problems here. One is that src.conf is read > relatively late, and only when bsd.own.mk is included. Therefore, > src.conf is not the right place to put CC, CXX and so on. I use buildflags (sysutils/bsdadminscripts), hence all my build configuration is included from the make.conf. > The other problem is that the build32 stage uses environment variables > to override CC, CXX, AS and LD for its sub-make (see LIB32WMAKEENV in > Makefile.inc1), adding the necessary flags for 32-bit compilation. > > However, since environment variables are in turn overridden by direct > assignments (like via reading make.conf), the 32-bit compilation flags > get lost when you specify any of CC, CXX, AS or LD in make.conf. > > This latter problem is what my patch attempts to fix, while changing as > little as possible. An alternative is to pass __MAKE_CONF=/dev/null to the 32-bit stage. That should also work in the environment, see make.conf(5) DESCRIPTION§3. I'm testing it now, just out of curiosity. One would probably have to add a _WITHOUT_SRCCONF, to be src.conf compatible, too. --- Makefile.inc1.orig 2011-10-28 22:00:20.000000000 +0200 +++ Makefile.inc1 2011-10-28 22:00:37.000000000 +0200 @@ -282,7 +282,8 @@ LIB32WMAKEENV= MACHINE=i386 MACHINE_ARCH=i386 \ MACHINE_CPU="i686 mmx sse sse2" \ LD="${LD} -m elf_i386_fbsd -Y P,${LIB32TMP}/usr/lib32" \ - AS="${AS} --32" + AS="${AS} --32" \ + __MAKE_CONF=/dev/null .elif ${TARGET_ARCH} == "powerpc64" .if empty(TARGET_CPUTYPE) > If there aren't any objections, I will commit it this weekend. Thanks! -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 20:30:38 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CB151065674 for ; Fri, 28 Oct 2011 20:30:38 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1ED8B8FC29 for ; Fri, 28 Oct 2011 20:30:38 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:4c76:9767:f5a:f9ce] (unknown [IPv6:2001:7b8:3a7:0:4c76:9767:f5a:f9ce]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 5EA915C37; Fri, 28 Oct 2011 22:30:37 +0200 (CEST) Message-ID: <4EAB10F0.9010606@FreeBSD.org> Date: Fri, 28 Oct 2011 22:30:40 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111019 Thunderbird/8.0 MIME-Version: 1.0 To: Dominic Fandrey References: <4EA80BD3.7000202@bsdforen.de> <4EA81B90.60501@FreeBSD.org> <4EAABF2E.3030709@bsdforen.de> <4EAAF228.1060000@FreeBSD.org> <4EAB0D53.7090000@bsdforen.de> In-Reply-To: <4EAB0D53.7090000@bsdforen.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: 9.0 RC1 linking problem with i386 libs on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 20:30:38 -0000 On 2011-10-28 22:15, Dominic Fandrey wrote: ... >> This latter problem is what my patch attempts to fix, while changing as >> little as possible. > > An alternative is to pass __MAKE_CONF=/dev/null to the 32-bit stage. > That should also work in the environment, see make.conf(5) The problem with this, is that you then skip *all* settings and logic in make.conf, which might not be what you want... The only variables that are specifically overridden for the build32 stage are CC, CXX, AS and LD, so those are the only ones whose value from make.conf needs to be 'ignored' in that stage. From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 20:13:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5653D106566C for ; Fri, 28 Oct 2011 20:13:16 +0000 (UTC) (envelope-from nimamisa1@gmail.com) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id F116E8FC08 for ; Fri, 28 Oct 2011 20:13:15 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com (192.168.222.22) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server id 14.0.694.0; Fri, 28 Oct 2011 16:02:27 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id 78D5433C02; Fri, 28 Oct 2011 16:02:27 -0400 (EDT) Date: Fri, 28 Oct 2011 16:02:27 -0400 From: Nima Misaghian To: Message-ID: <20111028200227.GA50663@sandvine.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Fri, 28 Oct 2011 20:51:14 +0000 Cc: andre@albsmeier.net Subject: Adding disk firmware programming capability to camcontrol X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2011 20:13:16 -0000 --cWoXeonUoKmBZSoM Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Hi, I have got code developed by Andre Albsmeier that is capable of programming firmware of hard drives from several vendors and turned it into a camcontrol command. The posted patch (against RELENG_8_2) basically adds the following new command to camcontrol: camcontrol fwdownload [device id] [generic args] <-f fw_image> [-s] I would appreciate it if FreeBSD experts in this area of code would take the time to review this patch. Thanks. Nima Misaghian Sandvine Incorporated --cWoXeonUoKmBZSoM Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="fwdownload.diff" --- old/camcontrol.h 2011-10-28 14:25:56.000000000 -0400 +++ camcontrol.h 2011-10-28 14:26:02.000000000 -0400 @@ -40,6 +40,8 @@ int got; }; +int fwdownload(struct cam_device *device, int argc, char **argv, + char *combinedopt, int verbose, int retry_count, int timeout); void mode_sense(struct cam_device *device, int mode_page, int page_control, int dbd, int retry_count, int timeout, u_int8_t *data, int datalen); --- old/camcontrol.c 2011-10-28 14:25:56.000000000 -0400 +++ camcontrol.c 2011-10-28 14:26:02.000000000 -0400 @@ -77,7 +77,8 @@ CAM_CMD_IDENTIFY = 0x00000013, CAM_CMD_IDLE = 0x00000014, CAM_CMD_STANDBY = 0x00000015, - CAM_CMD_SLEEP = 0x00000016 + CAM_CMD_SLEEP = 0x00000016, + CAM_CMD_DOWNLOAD_FW = 0x00000017 } cam_cmdmask; typedef enum { @@ -160,6 +161,7 @@ {"idle", CAM_CMD_IDLE, CAM_ARG_NONE, "t:"}, {"standby", CAM_CMD_STANDBY, CAM_ARG_NONE, "t:"}, {"sleep", CAM_CMD_SLEEP, CAM_ARG_NONE, ""}, + {"fwdownload", CAM_CMD_DOWNLOAD_FW, CAM_ARG_NONE, "f:s"}, #endif /* MINIMALISTIC */ {"help", CAM_CMD_USAGE, CAM_ARG_NONE, NULL}, {"-?", CAM_CMD_USAGE, CAM_ARG_NONE, NULL}, @@ -4565,6 +4567,7 @@ " camcontrol idle [dev_id][generic args][-t time]\n" " camcontrol standby [dev_id][generic args][-t time]\n" " camcontrol sleep [dev_id][generic args]\n" +" camcontrol fwdownload [dev_id][generic args] <-f fw_image> [-s]\n" #endif /* MINIMALISTIC */ " camcontrol help\n"); if (!verbose) @@ -4595,6 +4598,7 @@ "idle send the ATA IDLE command to the named device\n" "standby send the ATA STANDBY command to the named device\n" "sleep send the ATA SLEEP command to the named device\n" +"fwdownload program firmware of the named device with the given image" "help this message\n" "Device Identifiers:\n" "bus:target specify the bus and target, lun defaults to 0\n" @@ -4664,7 +4668,10 @@ "-w don't send immediate format command\n" "-y don't ask any questions\n" "idle/standby arguments:\n" -"-t number of seconds before respective state.\n"); +"-t number of seconds before respective state.\n" +"fwdownload arguments:\n" +"-f fw_image path to firmware image file\n" +"-s run in simulation mode\n"); #endif /* MINIMALISTIC */ } @@ -4959,6 +4966,10 @@ combinedopt, retry_count, timeout); break; + case CAM_CMD_DOWNLOAD_FW: + error = fwdownload(cam_dev, argc, argv, combinedopt, + arglist & CAM_ARG_VERBOSE, retry_count, timeout); + break; #endif /* MINIMALISTIC */ case CAM_CMD_USAGE: usage(1); --- old/fwdownload.c 2011-10-28 15:00:37.000000000 -0400 +++ fwdownload.c 2011-10-28 14:26:02.000000000 -0400 @@ -0,0 +1,349 @@ +/*- + * Copyright (c) 2011 Sandvine Incorporated. All rights reserved. + * Copyright (c) 2002-2011 Andre Albsmeier + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer, + * without modification, immediately at the beginning of the file. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +/* + * BEWARE: + * + * The fact that you see your favorite vendor listed below does not + * imply that your equipment won't break when you use this software + * with it. It only means that the firmware of at least one device type + * of each vendor listed has been programmed successfully using this code. + * + * The -s option simulates a download but does nothing apart from that. + * It can be used to check what chunk sizes would have been used with the + * specified device. + */ + + +#include +#include + +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#include "camcontrol.h" + +#define CMD_TIMEOUT 50000 /* 50 seconds */ + +typedef enum { + VENDOR_HITACHI, + VENDOR_HP, + VENDOR_IBM, + VENDOR_PLEXTOR, + VENDOR_QUALSTAR, + VENDOR_QUANTUM, + VENDOR_SEAGATE, + VENDOR_UNKNOWN +} fw_vendor_t; + +struct fw_vendor { + fw_vendor_t type; + const char *pattern; + int max_pkt_size; + u_int8_t cdb_byte2; + u_int8_t cdb_byte2_last; + int inc_cdb_buffer_id; + int inc_cdb_offset; +}; + +struct fw_vendor vendors_list[] = { + {VENDOR_HITACHI, "HITACHI", 0x8000, 0x05, 0x05, 1, 0}, + {VENDOR_HP, "HP", 0x8000, 0x07, 0x07, 0, 1}, + {VENDOR_IBM, "IBM", 0x8000, 0x05, 0x05, 1, 0}, + {VENDOR_PLEXTOR, "PLEXTOR", 0x2000, 0x04, 0x05, 0, 1}, + {VENDOR_QUALSTAR, "QUALSTAR", 0x2030, 0x05, 0x05, 0, 0}, + {VENDOR_QUANTUM, "QUANTUM", 0x2000, 0x04, 0x05, 0, 1}, + {VENDOR_SEAGATE, "SEAGATE", 0x8000, 0x07, 0x07, 0, 1}, + {VENDOR_UNKNOWN, NULL, 0x0000, 0x00, 0x00, 0, 0} +}; + +static struct fw_vendor *fw_get_vendor(struct cam_device *cam_dev); +static char *fw_read_img(char *fw_img_path, struct fw_vendor *vp, + int *num_bytes); +static int fw_download_img(struct cam_device *cam_dev, + struct fw_vendor *vp, char *buf, int img_size, + int sim_mode, int verbose, int retry_count, int timeout); + +/* + * Find entry in vendors list that belongs to + * the vendor of given cam device. + */ +static struct fw_vendor * +fw_get_vendor(struct cam_device *cam_dev) +{ + char vendor[SID_VENDOR_SIZE + 1]; + struct fw_vendor *vp = NULL; + + if (cam_dev == NULL) + return (NULL); + cam_strvis((u_char *)vendor, (u_char *)cam_dev->inq_data.vendor, + sizeof(cam_dev->inq_data.vendor), sizeof(vendor)); + for (vp = vendors_list; vp->pattern != NULL; vp++) { + if (!cam_strmatch((const u_char *)vendor, + (const u_char *)vp->pattern, strlen(vendor))) + break; + } + return (vp); +} + +/* + * Allocate a buffer and read fw image file into it + * from given path. Number of bytes read is stored + * in num_bytes. + */ +static char * +fw_read_img(char *fw_img_path, struct fw_vendor *vp, int *num_bytes) +{ + int fd; + struct stat stbuf; + char *buf; + off_t img_size; + int skip_bytes = 0; + + if ((fd = open(fw_img_path, O_RDONLY)) < 0) { + warn("Could not open image file %s", fw_img_path); + return (NULL); + } + if (fstat(fd, &stbuf) < 0) { + warn("Could not stat image file %s", fw_img_path); + goto bailout1; + } + if ((img_size = stbuf.st_size) == 0) { + warnx("Zero length image file %s", fw_img_path); + goto bailout1; + } + if ((buf = malloc(img_size)) == NULL) { + warnx("Could not allocate buffer to read image file %s", + fw_img_path); + goto bailout1; + } + /* Skip headers if applicable. */ + switch (vp->type) { + case VENDOR_SEAGATE: + if (read(fd, buf, 16) != 16) { + warn("Could not read image file %s", fw_img_path); + goto bailout; + } + if (lseek(fd, 0, SEEK_SET) == -1) { + warn("Unable to lseek"); + goto bailout; + } + if ((strncmp(buf, "SEAGATE,SEAGATE ", 16) == 0) || + (img_size % 512 == 80)) + skip_bytes = 80; + break; + case VENDOR_QUALSTAR: + skip_bytes = img_size % 1030; + break; + default: + break; + } + if (skip_bytes != 0) { + fprintf(stdout, "Skipping %d byte header.\n", skip_bytes); + if (lseek(fd, skip_bytes, SEEK_SET) == -1) { + warn("Could not lseek"); + goto bailout; + } + img_size -= skip_bytes; + } + /* Read image into a buffer. */ + if (read(fd, buf, img_size) != img_size) { + warn("Could not read image file %s", fw_img_path); + goto bailout; + } + *num_bytes = img_size; + return (buf); +bailout: + free(buf); +bailout1: + close(fd); + *num_bytes = 0; + return (NULL); +} + +/* + * Download firmware stored in buf to cam_dev. If simulation mode + * is enabled, only show what packet sizes would be sent to the + * device but do not sent any actual packets + */ +static int +fw_download_img(struct cam_device *cam_dev, struct fw_vendor *vp, + char *buf, int img_size, int sim_mode, int verbose, int retry_count, + int timeout) +{ + struct scsi_write_buffer cdb; + union ccb *ccb; + int pkt_count = 0; + u_int32_t pkt_size = 0; + char *pkt_ptr = buf; + u_int32_t offset; + int last_pkt = 0; + + if ((ccb = cam_getccb(cam_dev)) == NULL) { + warnx("Could not allocate CCB"); + return (1); + } + scsi_test_unit_ready(&ccb->csio, 0, NULL, MSG_SIMPLE_Q_TAG, + SSD_FULL_SIZE, 5000); + /* Disable freezing the device queue. */ + ccb->ccb_h.flags |= CAM_DEV_QFRZDIS; + if (cam_send_ccb(cam_dev, ccb) < 0) { + warnx("Error sending test unit ready"); + if (verbose) + cam_error_print(cam_dev, ccb, CAM_ESF_ALL, + CAM_EPF_ALL, stderr); + cam_freeccb(ccb); + return(1); + } + if ((ccb->ccb_h.status & CAM_STATUS_MASK) != CAM_REQ_CMP) { + warnx("Device is not ready"); + if (verbose) + cam_error_print(cam_dev, ccb, CAM_ESF_ALL, + CAM_EPF_ALL, stderr); + cam_freeccb(ccb); + return (1); + } + pkt_size = vp->max_pkt_size; + fprintf(stdout, "-------------------------------------------------\n" ); + fprintf(stdout, "PktNo. PktSize BytesRemaining LastPkt\n" ); + fprintf(stdout, "-------------------------------------------------\n" ); + /* Download single fw packets. */ + do { + if (img_size <= vp->max_pkt_size) { + last_pkt = 1; + pkt_size = img_size; + } + fprintf(stdout, "%3u %5u (0x%05X) %7u (0x%06X) %d\n", + pkt_count, pkt_size, pkt_size, img_size - pkt_size, + img_size - pkt_size, last_pkt); + bzero(&cdb, sizeof(cdb)); + cdb.opcode = WRITE_BUFFER; + cdb.control = 0; + /* Parameter list length. */ + scsi_ulto3b(pkt_size, &cdb.length[0]); + offset = vp->inc_cdb_offset ? (pkt_ptr - buf) : 0; + scsi_ulto3b(offset, &cdb.offset[0]); + cdb.byte2 = last_pkt ? vp->cdb_byte2_last : vp->cdb_byte2; + cdb.buffer_id = vp->inc_cdb_buffer_id ? pkt_count : 0; + /* Zero out payload of ccb union after ccb header. */ + bzero((u_char *)ccb + sizeof(struct ccb_hdr), + sizeof(struct ccb_scsiio) - sizeof(struct ccb_hdr)); + /* Copy previously constructed cdb into ccb_scsiio struct. */ + bcopy(&cdb, &ccb->csio.cdb_io.cdb_bytes[0], + sizeof(struct scsi_write_buffer)); + /* Fill rest of ccb_scsiio struct. */ + if (!sim_mode) { + cam_fill_csio(&ccb->csio, /* ccb_scsiio */ + retry_count, /* retries */ + NULL, /* cbfcnp */ + CAM_DIR_OUT | CAM_DEV_QFRZDIS, /* flags */ + CAM_TAG_ACTION_NONE, /* tag_action */ + (u_char *)pkt_ptr, /* data_ptr */ + pkt_size, /* dxfer_len */ + SSD_FULL_SIZE, /* sense_len */ + sizeof(struct scsi_write_buffer), /* cdb_len */ + timeout ? timeout : CMD_TIMEOUT); /* timeout */ + /* Execute the command. */ + if (cam_send_ccb(cam_dev, ccb) < 0) { + warnx("Error writing image to device"); + if (verbose) + cam_error_print(cam_dev, ccb, CAM_ESF_ALL, + CAM_EPF_ALL, stderr); + goto bailout; + } + } + /* Prepare next round. */ + pkt_count++; + pkt_ptr += pkt_size; + img_size -= pkt_size; + } while(!last_pkt); + cam_freeccb(ccb); + return (0); +bailout: + cam_freeccb(ccb); + return (1); +} + +int +fwdownload(struct cam_device *device, int argc, char **argv, + char *combinedopt, int verbose, int retry_count, int timeout) +{ + struct fw_vendor *vp; + char *fw_img_path = NULL; + char *buf; + int img_size; + int c; + int sim_mode = 0; + + while ((c = getopt(argc, argv, combinedopt)) != -1) { + switch (c) { + case 's': + sim_mode = 1; + break; + case 'f': + fw_img_path = optarg; + break; + default: + break; + } + } + + if (fw_img_path == NULL) + errx(1, "you must specify a firmware image file using -f option"); + + vp = fw_get_vendor(device); + if (vp == NULL || vp->type == VENDOR_UNKNOWN) + errx(1, "Unsupported device"); + + buf = fw_read_img(fw_img_path, vp, &img_size); + if (buf == NULL) + goto fail; + + if (fw_download_img(device, vp, buf, img_size, sim_mode, verbose, + retry_count, timeout) != 0) { + fprintf(stderr, "Firmware download failed"); + goto fail; + } + else + fprintf(stdout, "Firmware download successful\n"); + + free(buf); + return (0); +fail: + if (buf != NULL) + free(buf); + return (1); +} + --- old/camcontrol.8 2011-10-28 14:25:56.000000000 -0400 +++ camcontrol.8 2011-10-28 14:26:02.000000000 -0400 @@ -183,6 +183,12 @@ .Op device id .Op generic args .Nm +.Ic fwdownload +.Op device id +.Op generic args +.Aq Fl f Ar fw_image +.Op Fl s +.Nm .Ic help .Sh DESCRIPTION The @@ -853,6 +859,42 @@ .It Ic sleep Put ATA device into SLEEP state. Note that the only way get device out of this state may be reset. +.It Ic fwdownload +Program firmware of the named device using the image file provided. +.Pp +Current list of supported vendors: +.Bl -bullet -offset indent -compact +.It +HITACHI +.It +HP +.It +IBM +.It +PLEXTOR +.It +QUALSTAR +.It +QUANTUM +.It +SEAGATE +.El +.Pp +.Em WARNING! +.Pp +Very little testing has been done to make sure that different device models +of each vendor work correctly with fwdownload command. Showing up a vendor +name in the supported list basically means firmware of at least one device +type from that vendor has successfully been programmed with fwdownload +command. Extra caution should be taken when using this command since there is +no guarantee it would not break a device from listed vendors. +.Bl -tag -width 11n +.It Fl f Ar fw_image +Path to the firmware image file to be downloaded to the specified device. +.It Fl s +Run in simulation mode where packet sizes that are going to be sent are shown, +but no actual packet is sent to the device. +.El .It Ic help Print out verbose usage information. .El --cWoXeonUoKmBZSoM-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 20:57:56 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EBC0106566B for ; Fri, 28 Oct 2011 20:57:56 +0000 (UTC) (envelope-from nmisaghian@sandvine.com) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id 2A3458FC13 for ; Fri, 28 Oct 2011 20:57:56 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com (192.168.222.22) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server id 14.0.694.0; Fri, 28 Oct 2011 16:47:06 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id B60E633C02; Fri, 28 Oct 2011 16:47:06 -0400 (EDT) Date: Fri, 28 Oct 2011 16:47:06 -0400 From: Nima Misaghian To: Message-ID: <20111028204706.GA57454@sandvine.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: Adding disk firmware programming capability to camcontrol X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2011 20:57:56 -0000 --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Hi, I have got code developed by Andre Albsmeier that is capable of programming firmware of hard drives from several vendors and turned it into a camcontrol command. The posted patch (against RELENG_8_2) basically adds the following new command to camcontrol: camcontrol fwdownload [device id] [generic args] <-f fw_image> [-s] I would appreciate it if FreeBSD experts in this area of code would take the time to review this patch. Thanks. Nima Misaghian Sandvine Incorporated --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="fwdownload.diff" --- old/camcontrol.h 2011-10-28 14:25:56.000000000 -0400 +++ camcontrol.h 2011-10-28 14:26:02.000000000 -0400 @@ -40,6 +40,8 @@ int got; }; +int fwdownload(struct cam_device *device, int argc, char **argv, + char *combinedopt, int verbose, int retry_count, int timeout); void mode_sense(struct cam_device *device, int mode_page, int page_control, int dbd, int retry_count, int timeout, u_int8_t *data, int datalen); --- old/camcontrol.c 2011-10-28 14:25:56.000000000 -0400 +++ camcontrol.c 2011-10-28 14:26:02.000000000 -0400 @@ -77,7 +77,8 @@ CAM_CMD_IDENTIFY = 0x00000013, CAM_CMD_IDLE = 0x00000014, CAM_CMD_STANDBY = 0x00000015, - CAM_CMD_SLEEP = 0x00000016 + CAM_CMD_SLEEP = 0x00000016, + CAM_CMD_DOWNLOAD_FW = 0x00000017 } cam_cmdmask; typedef enum { @@ -160,6 +161,7 @@ {"idle", CAM_CMD_IDLE, CAM_ARG_NONE, "t:"}, {"standby", CAM_CMD_STANDBY, CAM_ARG_NONE, "t:"}, {"sleep", CAM_CMD_SLEEP, CAM_ARG_NONE, ""}, + {"fwdownload", CAM_CMD_DOWNLOAD_FW, CAM_ARG_NONE, "f:s"}, #endif /* MINIMALISTIC */ {"help", CAM_CMD_USAGE, CAM_ARG_NONE, NULL}, {"-?", CAM_CMD_USAGE, CAM_ARG_NONE, NULL}, @@ -4565,6 +4567,7 @@ " camcontrol idle [dev_id][generic args][-t time]\n" " camcontrol standby [dev_id][generic args][-t time]\n" " camcontrol sleep [dev_id][generic args]\n" +" camcontrol fwdownload [dev_id][generic args] <-f fw_image> [-s]\n" #endif /* MINIMALISTIC */ " camcontrol help\n"); if (!verbose) @@ -4595,6 +4598,7 @@ "idle send the ATA IDLE command to the named device\n" "standby send the ATA STANDBY command to the named device\n" "sleep send the ATA SLEEP command to the named device\n" +"fwdownload program firmware of the named device with the given image" "help this message\n" "Device Identifiers:\n" "bus:target specify the bus and target, lun defaults to 0\n" @@ -4664,7 +4668,10 @@ "-w don't send immediate format command\n" "-y don't ask any questions\n" "idle/standby arguments:\n" -"-t number of seconds before respective state.\n"); +"-t number of seconds before respective state.\n" +"fwdownload arguments:\n" +"-f fw_image path to firmware image file\n" +"-s run in simulation mode\n"); #endif /* MINIMALISTIC */ } @@ -4959,6 +4966,10 @@ combinedopt, retry_count, timeout); break; + case CAM_CMD_DOWNLOAD_FW: + error = fwdownload(cam_dev, argc, argv, combinedopt, + arglist & CAM_ARG_VERBOSE, retry_count, timeout); + break; #endif /* MINIMALISTIC */ case CAM_CMD_USAGE: usage(1); --- old/fwdownload.c 2011-10-28 15:00:37.000000000 -0400 +++ fwdownload.c 2011-10-28 14:26:02.000000000 -0400 @@ -0,0 +1,349 @@ +/*- + * Copyright (c) 2011 Sandvine Incorporated. All rights reserved. + * Copyright (c) 2002-2011 Andre Albsmeier + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer, + * without modification, immediately at the beginning of the file. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +/* + * BEWARE: + * + * The fact that you see your favorite vendor listed below does not + * imply that your equipment won't break when you use this software + * with it. It only means that the firmware of at least one device type + * of each vendor listed has been programmed successfully using this code. + * + * The -s option simulates a download but does nothing apart from that. + * It can be used to check what chunk sizes would have been used with the + * specified device. + */ + + +#include +#include + +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#include "camcontrol.h" + +#define CMD_TIMEOUT 50000 /* 50 seconds */ + +typedef enum { + VENDOR_HITACHI, + VENDOR_HP, + VENDOR_IBM, + VENDOR_PLEXTOR, + VENDOR_QUALSTAR, + VENDOR_QUANTUM, + VENDOR_SEAGATE, + VENDOR_UNKNOWN +} fw_vendor_t; + +struct fw_vendor { + fw_vendor_t type; + const char *pattern; + int max_pkt_size; + u_int8_t cdb_byte2; + u_int8_t cdb_byte2_last; + int inc_cdb_buffer_id; + int inc_cdb_offset; +}; + +struct fw_vendor vendors_list[] = { + {VENDOR_HITACHI, "HITACHI", 0x8000, 0x05, 0x05, 1, 0}, + {VENDOR_HP, "HP", 0x8000, 0x07, 0x07, 0, 1}, + {VENDOR_IBM, "IBM", 0x8000, 0x05, 0x05, 1, 0}, + {VENDOR_PLEXTOR, "PLEXTOR", 0x2000, 0x04, 0x05, 0, 1}, + {VENDOR_QUALSTAR, "QUALSTAR", 0x2030, 0x05, 0x05, 0, 0}, + {VENDOR_QUANTUM, "QUANTUM", 0x2000, 0x04, 0x05, 0, 1}, + {VENDOR_SEAGATE, "SEAGATE", 0x8000, 0x07, 0x07, 0, 1}, + {VENDOR_UNKNOWN, NULL, 0x0000, 0x00, 0x00, 0, 0} +}; + +static struct fw_vendor *fw_get_vendor(struct cam_device *cam_dev); +static char *fw_read_img(char *fw_img_path, struct fw_vendor *vp, + int *num_bytes); +static int fw_download_img(struct cam_device *cam_dev, + struct fw_vendor *vp, char *buf, int img_size, + int sim_mode, int verbose, int retry_count, int timeout); + +/* + * Find entry in vendors list that belongs to + * the vendor of given cam device. + */ +static struct fw_vendor * +fw_get_vendor(struct cam_device *cam_dev) +{ + char vendor[SID_VENDOR_SIZE + 1]; + struct fw_vendor *vp = NULL; + + if (cam_dev == NULL) + return (NULL); + cam_strvis((u_char *)vendor, (u_char *)cam_dev->inq_data.vendor, + sizeof(cam_dev->inq_data.vendor), sizeof(vendor)); + for (vp = vendors_list; vp->pattern != NULL; vp++) { + if (!cam_strmatch((const u_char *)vendor, + (const u_char *)vp->pattern, strlen(vendor))) + break; + } + return (vp); +} + +/* + * Allocate a buffer and read fw image file into it + * from given path. Number of bytes read is stored + * in num_bytes. + */ +static char * +fw_read_img(char *fw_img_path, struct fw_vendor *vp, int *num_bytes) +{ + int fd; + struct stat stbuf; + char *buf; + off_t img_size; + int skip_bytes = 0; + + if ((fd = open(fw_img_path, O_RDONLY)) < 0) { + warn("Could not open image file %s", fw_img_path); + return (NULL); + } + if (fstat(fd, &stbuf) < 0) { + warn("Could not stat image file %s", fw_img_path); + goto bailout1; + } + if ((img_size = stbuf.st_size) == 0) { + warnx("Zero length image file %s", fw_img_path); + goto bailout1; + } + if ((buf = malloc(img_size)) == NULL) { + warnx("Could not allocate buffer to read image file %s", + fw_img_path); + goto bailout1; + } + /* Skip headers if applicable. */ + switch (vp->type) { + case VENDOR_SEAGATE: + if (read(fd, buf, 16) != 16) { + warn("Could not read image file %s", fw_img_path); + goto bailout; + } + if (lseek(fd, 0, SEEK_SET) == -1) { + warn("Unable to lseek"); + goto bailout; + } + if ((strncmp(buf, "SEAGATE,SEAGATE ", 16) == 0) || + (img_size % 512 == 80)) + skip_bytes = 80; + break; + case VENDOR_QUALSTAR: + skip_bytes = img_size % 1030; + break; + default: + break; + } + if (skip_bytes != 0) { + fprintf(stdout, "Skipping %d byte header.\n", skip_bytes); + if (lseek(fd, skip_bytes, SEEK_SET) == -1) { + warn("Could not lseek"); + goto bailout; + } + img_size -= skip_bytes; + } + /* Read image into a buffer. */ + if (read(fd, buf, img_size) != img_size) { + warn("Could not read image file %s", fw_img_path); + goto bailout; + } + *num_bytes = img_size; + return (buf); +bailout: + free(buf); +bailout1: + close(fd); + *num_bytes = 0; + return (NULL); +} + +/* + * Download firmware stored in buf to cam_dev. If simulation mode + * is enabled, only show what packet sizes would be sent to the + * device but do not sent any actual packets + */ +static int +fw_download_img(struct cam_device *cam_dev, struct fw_vendor *vp, + char *buf, int img_size, int sim_mode, int verbose, int retry_count, + int timeout) +{ + struct scsi_write_buffer cdb; + union ccb *ccb; + int pkt_count = 0; + u_int32_t pkt_size = 0; + char *pkt_ptr = buf; + u_int32_t offset; + int last_pkt = 0; + + if ((ccb = cam_getccb(cam_dev)) == NULL) { + warnx("Could not allocate CCB"); + return (1); + } + scsi_test_unit_ready(&ccb->csio, 0, NULL, MSG_SIMPLE_Q_TAG, + SSD_FULL_SIZE, 5000); + /* Disable freezing the device queue. */ + ccb->ccb_h.flags |= CAM_DEV_QFRZDIS; + if (cam_send_ccb(cam_dev, ccb) < 0) { + warnx("Error sending test unit ready"); + if (verbose) + cam_error_print(cam_dev, ccb, CAM_ESF_ALL, + CAM_EPF_ALL, stderr); + cam_freeccb(ccb); + return(1); + } + if ((ccb->ccb_h.status & CAM_STATUS_MASK) != CAM_REQ_CMP) { + warnx("Device is not ready"); + if (verbose) + cam_error_print(cam_dev, ccb, CAM_ESF_ALL, + CAM_EPF_ALL, stderr); + cam_freeccb(ccb); + return (1); + } + pkt_size = vp->max_pkt_size; + fprintf(stdout, "-------------------------------------------------\n" ); + fprintf(stdout, "PktNo. PktSize BytesRemaining LastPkt\n" ); + fprintf(stdout, "-------------------------------------------------\n" ); + /* Download single fw packets. */ + do { + if (img_size <= vp->max_pkt_size) { + last_pkt = 1; + pkt_size = img_size; + } + fprintf(stdout, "%3u %5u (0x%05X) %7u (0x%06X) %d\n", + pkt_count, pkt_size, pkt_size, img_size - pkt_size, + img_size - pkt_size, last_pkt); + bzero(&cdb, sizeof(cdb)); + cdb.opcode = WRITE_BUFFER; + cdb.control = 0; + /* Parameter list length. */ + scsi_ulto3b(pkt_size, &cdb.length[0]); + offset = vp->inc_cdb_offset ? (pkt_ptr - buf) : 0; + scsi_ulto3b(offset, &cdb.offset[0]); + cdb.byte2 = last_pkt ? vp->cdb_byte2_last : vp->cdb_byte2; + cdb.buffer_id = vp->inc_cdb_buffer_id ? pkt_count : 0; + /* Zero out payload of ccb union after ccb header. */ + bzero((u_char *)ccb + sizeof(struct ccb_hdr), + sizeof(struct ccb_scsiio) - sizeof(struct ccb_hdr)); + /* Copy previously constructed cdb into ccb_scsiio struct. */ + bcopy(&cdb, &ccb->csio.cdb_io.cdb_bytes[0], + sizeof(struct scsi_write_buffer)); + /* Fill rest of ccb_scsiio struct. */ + if (!sim_mode) { + cam_fill_csio(&ccb->csio, /* ccb_scsiio */ + retry_count, /* retries */ + NULL, /* cbfcnp */ + CAM_DIR_OUT | CAM_DEV_QFRZDIS, /* flags */ + CAM_TAG_ACTION_NONE, /* tag_action */ + (u_char *)pkt_ptr, /* data_ptr */ + pkt_size, /* dxfer_len */ + SSD_FULL_SIZE, /* sense_len */ + sizeof(struct scsi_write_buffer), /* cdb_len */ + timeout ? timeout : CMD_TIMEOUT); /* timeout */ + /* Execute the command. */ + if (cam_send_ccb(cam_dev, ccb) < 0) { + warnx("Error writing image to device"); + if (verbose) + cam_error_print(cam_dev, ccb, CAM_ESF_ALL, + CAM_EPF_ALL, stderr); + goto bailout; + } + } + /* Prepare next round. */ + pkt_count++; + pkt_ptr += pkt_size; + img_size -= pkt_size; + } while(!last_pkt); + cam_freeccb(ccb); + return (0); +bailout: + cam_freeccb(ccb); + return (1); +} + +int +fwdownload(struct cam_device *device, int argc, char **argv, + char *combinedopt, int verbose, int retry_count, int timeout) +{ + struct fw_vendor *vp; + char *fw_img_path = NULL; + char *buf; + int img_size; + int c; + int sim_mode = 0; + + while ((c = getopt(argc, argv, combinedopt)) != -1) { + switch (c) { + case 's': + sim_mode = 1; + break; + case 'f': + fw_img_path = optarg; + break; + default: + break; + } + } + + if (fw_img_path == NULL) + errx(1, "you must specify a firmware image file using -f option"); + + vp = fw_get_vendor(device); + if (vp == NULL || vp->type == VENDOR_UNKNOWN) + errx(1, "Unsupported device"); + + buf = fw_read_img(fw_img_path, vp, &img_size); + if (buf == NULL) + goto fail; + + if (fw_download_img(device, vp, buf, img_size, sim_mode, verbose, + retry_count, timeout) != 0) { + fprintf(stderr, "Firmware download failed"); + goto fail; + } + else + fprintf(stdout, "Firmware download successful\n"); + + free(buf); + return (0); +fail: + if (buf != NULL) + free(buf); + return (1); +} + --- old/camcontrol.8 2011-10-28 14:25:56.000000000 -0400 +++ camcontrol.8 2011-10-28 14:26:02.000000000 -0400 @@ -183,6 +183,12 @@ .Op device id .Op generic args .Nm +.Ic fwdownload +.Op device id +.Op generic args +.Aq Fl f Ar fw_image +.Op Fl s +.Nm .Ic help .Sh DESCRIPTION The @@ -853,6 +859,42 @@ .It Ic sleep Put ATA device into SLEEP state. Note that the only way get device out of this state may be reset. +.It Ic fwdownload +Program firmware of the named device using the image file provided. +.Pp +Current list of supported vendors: +.Bl -bullet -offset indent -compact +.It +HITACHI +.It +HP +.It +IBM +.It +PLEXTOR +.It +QUALSTAR +.It +QUANTUM +.It +SEAGATE +.El +.Pp +.Em WARNING! +.Pp +Very little testing has been done to make sure that different device models +of each vendor work correctly with fwdownload command. Showing up a vendor +name in the supported list basically means firmware of at least one device +type from that vendor has successfully been programmed with fwdownload +command. Extra caution should be taken when using this command since there is +no guarantee it would not break a device from listed vendors. +.Bl -tag -width 11n +.It Fl f Ar fw_image +Path to the firmware image file to be downloaded to the specified device. +.It Fl s +Run in simulation mode where packet sizes that are going to be sent are shown, +but no actual packet is sent to the device. +.El .It Ic help Print out verbose usage information. .El --Q68bSM7Ycu6FN28Q-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 21:03:21 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33D01106566B for ; Fri, 28 Oct 2011 21:03:21 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by mx1.freebsd.org (Postfix) with ESMTP id 1B8908FC17 for ; Fri, 28 Oct 2011 21:03:21 +0000 (UTC) Received: from [127.0.0.1] (proxy7.corp.yahoo.com [216.145.48.98]) by mrout1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p9SKr4Ak077040; Fri, 28 Oct 2011 13:53:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1319835184; bh=YLkN+F/N8fvKbmj1v0j02EaiVDgil7ncDk3O6zB9/oE=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=ZVyKGtOeBDJf72uZqTm/VHnHCsGOWEIbQjkzLxSWSuApBmYZVerbMwAnvdqaM9vaR TYM4mm7hhbveA2lWILCPqLDQG/H/sbAQZQzucI2VSbBzdDLRaimXBmSQ0QBFNRtJTf g+ZKw0ysAOUax285DD4lO8DzvP7Szc2McdBB5BZk= From: Sean Bruno To: Penta Upa In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Fri, 28 Oct 2011 13:53:03 -0700 Message-ID: <1319835183.2664.12.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org" Subject: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 21:03:21 -0000 On Fri, 2011-10-21 at 08:25 -0700, Penta Upa wrote: > Attached is a test module (vmtest) and the makefile used. Uname output from > the system is I only see a Makefile attached here. Can you attach the code you are using? Sean From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 21:38:33 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E434106566B for ; Fri, 28 Oct 2011 21:38:33 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0813C8FC14 for ; Fri, 28 Oct 2011 21:38:32 +0000 (UTC) Received: by qadz32 with SMTP id z32so5527340qad.13 for ; Fri, 28 Oct 2011 14:38:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=TflxDpw4FNp071xFNZMJC8lDFlFBIjMjYbTt6pgj2js=; b=iMBAZGi2wUSK0K3QH8jAWipr/nL3JfMB8DXx/+YizesnJH3029tM4VoGc29QH/Dc2n fD/zbicAHpDJ260lVCGYrsvb1t6BPxBTWKA7cZXscJt2VI9EK0EQYNICXiYAR1SonNR+ MTHfFL0sI0E+WuxRVsTPWx8/FjRwwQabjaPPc= MIME-Version: 1.0 Received: by 10.182.51.103 with SMTP id j7mr1011861obo.36.1319837912135; Fri, 28 Oct 2011 14:38:32 -0700 (PDT) Received: by 10.182.122.33 with HTTP; Fri, 28 Oct 2011 14:38:32 -0700 (PDT) In-Reply-To: <20111028204706.GA57454@sandvine.com> References: <20111028204706.GA57454@sandvine.com> Date: Fri, 28 Oct 2011 14:38:32 -0700 Message-ID: From: Garrett Cooper To: Nima Misaghian Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Adding disk firmware programming capability to camcontrol X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2011 21:38:34 -0000 On Fri, Oct 28, 2011 at 1:47 PM, Nima Misaghian w= rote: > Hi, > > I have got code developed by Andre Albsmeier that is capable of > programming firmware of hard drives from several vendors and =A0turned > it into a camcontrol command. > > The posted patch (against RELENG_8_2) basically adds the following new > command to camcontrol: > > camcontrol fwdownload [device id] [generic args] <-f fw_image> [-s] > > I would appreciate it if FreeBSD experts in this area of code would > take the time to review this patch. This is awesome! I'm not a CAM expert, but I'll definitely take a look it this weekend. -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 22:31:26 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99DD91065670 for ; Fri, 28 Oct 2011 22:31:26 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 662DF8FC14 for ; Fri, 28 Oct 2011 22:31:26 +0000 (UTC) Received: from [172.16.135.105] (lportal.in1.lcl [172.16.1.9]) (authenticated bits=0) by ns1.feral.com (8.14.4/8.14.4) with ESMTP id p9SMVPQO042440 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 28 Oct 2011 15:31:25 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4EAB2D38.4040200@feral.com> Date: Fri, 28 Oct 2011 15:31:20 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20111028204706.GA57454@sandvine.com> In-Reply-To: <20111028204706.GA57454@sandvine.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (ns1.feral.com [192.67.166.1]); Fri, 28 Oct 2011 15:31:25 -0700 (PDT) Subject: Re: Adding disk firmware programming capability to camcontrol X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mj@feral.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 22:31:26 -0000 This is a good idea, except that it makes me really really nervous. I do not believe that fw downloads are generic enough to encapsulate. I've used camcontrol recently to tunnel an ATA command through mpt2 that does an ATA DOWNLOAD FW (mode 7), but that is only because it is a specific drive that I've validated works correctly. The linux hdparm program is so paranoid about this that you have to use extra arguments like "--yes-really-destroy-my-disk-drive" to do this. I'm very very nervous about putting it into camcontrol. From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 22:34:22 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 118701065670 for ; Fri, 28 Oct 2011 22:34:22 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id D02178FC14 for ; Fri, 28 Oct 2011 22:34:21 +0000 (UTC) Received: from [172.16.135.105] (lportal.in1.lcl [172.16.1.9]) (authenticated bits=0) by ns1.feral.com (8.14.4/8.14.4) with ESMTP id p9SMYKl4045974 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 28 Oct 2011 15:34:21 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4EAB2DE7.8090306@feral.com> Date: Fri, 28 Oct 2011 15:34:15 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4EA83DB1.4070602@FreeBSD.org> <4EAB0477.8060401@FreeBSD.org> In-Reply-To: <4EAB0477.8060401@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (ns1.feral.com [192.67.166.1]); Fri, 28 Oct 2011 15:34:21 -0700 (PDT) Subject: Re: gmultipath: act/act, path checking? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mj@feral.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 22:34:22 -0000 On 10/28/2011 12:37 PM, Alexander Motin wrote: > On 26.10.2011 12:09, Dennis Koegel wrote: >> are there any plans to have gmultipath support for active/active? > Few days ago I've started from fixing some issues in gmultipath and > already rewritten half of it while trying to make it usable. I expect to > have something to present in a week or two. It will also include > active/active mode support there, as at my present point required > changes are minimal. > Free at last! Free at last! Free at last! From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 22:43:33 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACDF0106566C for ; Fri, 28 Oct 2011 22:43:33 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [IPv6:2607:fc50:1000:8200:216:3eff:fe2c:dc8f]) by mx1.freebsd.org (Postfix) with ESMTP id 828238FC0C for ; Fri, 28 Oct 2011 22:43:33 +0000 (UTC) Received: from orthanc.ca (localhost [127.0.0.1]) by orthanc.ca (8.14.4/8.14.4) with ESMTP id p9SMhTQf026918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Oct 2011 15:43:30 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Received: (from uucp@localhost) by orthanc.ca (8.14.4/8.14.4/Submit) with UUCP id p9SMhTvB026917; Fri, 28 Oct 2011 15:43:29 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Received: from gandalf.orthanc.ca ([172.16.0.3]) by legolas.orthanc.ca (8.14.5/8.14.5) with ESMTP id p9SMhRoF077089; Fri, 28 Oct 2011 15:43:27 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Message-ID: To: mj@feral.com, freebsd-current@freebsd.org From: "Lyndon Nerenberg (VE6BBM/VE7TFX)" Date: Fri, 28 Oct 2011 15:43:27 -0700 In-Reply-To: <4EAB2D38.4040200@feral.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: Subject: Re: Adding disk firmware programming capability to camcontrol X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2011 22:43:33 -0000 > The linux hdparm program is so paranoid about this that you have to use > extra arguments like "--yes-really-destroy-my-disk-drive" to do this. I concur. Loudly. The ability to brick your hardware is just too large to not make people go through the "I tell you three times" dance. It's not like people will do this often enough that the pain will be fatal. And if it is, they ought to be bright enough to know how to automate the process. --lyndon From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 23:33:31 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10D02106564A for ; Fri, 28 Oct 2011 23:33:30 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 916F88FC13 for ; Fri, 28 Oct 2011 23:33:30 +0000 (UTC) Received: by qadz32 with SMTP id z32so5607076qad.13 for ; Fri, 28 Oct 2011 16:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=8ivi+S47CVuCVdg9Q5wR9XJa/5b7BbT0Bqc/E3rCQ6k=; b=XdaA3+/DoNXrbUS4BWOyYUVkaBvIH6yPgfNY+zvBaY0IjIjAMZZKF8Ej5Bsq/ALw3B blggxtcLjtMDIFk7MN/W2zQhWwf8fH0HrUeehTZkL10peuhZalLeyX8Q1Xy3V1gapuji 0Fjd/udcAd278EIdP3Pi9ffCRy2ZsoEsVm814= MIME-Version: 1.0 Received: by 10.229.92.2 with SMTP id p2mr1223849qcm.222.1319844809789; Fri, 28 Oct 2011 16:33:29 -0700 (PDT) Received: by 10.229.226.65 with HTTP; Fri, 28 Oct 2011 16:33:29 -0700 (PDT) In-Reply-To: References: Date: Sat, 29 Oct 2011 01:33:29 +0200 Message-ID: From: "deeptech71@gmail.com" To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: panic: ffs_blkfree_cg: freeing free block X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2011 23:33:31 -0000 On Fri, Oct 28, 2011 at 3:40 PM, Bjoern A. Zeeb wrote: > On Fri, 28 Oct 2011, deeptech71@gmail.com wrote: >> I don't have the intermediate object files for the kernel; now I'm >> building the kernel again (from the appropriate, exact sources). That >> shouldn't harm debugging, should it? Meanwhile, I'll take any debug >> info requests, which I'll attempt to address shortly. > > Do you know at which revision the kernel was or about from when? Of course. r226289. From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 23:34:31 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F08D7106564A for ; Fri, 28 Oct 2011 23:34:31 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id B065C8FC1E for ; Fri, 28 Oct 2011 23:34:31 +0000 (UTC) Received: by qyk35 with SMTP id 35so3114241qyk.13 for ; Fri, 28 Oct 2011 16:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=eHVgtIb1DcpAmXnt/YfXcGoyxASZ5eIaa5XiEeo4p4Q=; b=fXHPmHNBcldiRUE2vUQUq930UubIFwgpUiCFJl6EIC7M1cvrM+QTrfYuN8TBQzKSd1 JMgU8cuI6fNTY6aWIBkpeW346TFhrLv606ZBfIwAvXDNZO7rtAfqSgsP00tjcE6HKMov g1PIPeC7SmRoLvivK7Ghls6kZn47ywKQ1xdr0= MIME-Version: 1.0 Received: by 10.229.235.2 with SMTP id ke2mr1219021qcb.298.1319844870620; Fri, 28 Oct 2011 16:34:30 -0700 (PDT) Received: by 10.229.226.65 with HTTP; Fri, 28 Oct 2011 16:34:30 -0700 (PDT) In-Reply-To: References: Date: Sat, 29 Oct 2011 01:34:30 +0200 Message-ID: From: "deeptech71@gmail.com" To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: panic: ffs_blkfree_cg: freeing free block X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2011 23:34:32 -0000 With object files which were built using the original kernel configuration file (no debugging symbols included): #kgdb kernel /var/crash/vmcore.4 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"...(no debugging symbols found)... Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. #0 0xc0687d88 in doadump () (kgdb) bt #0 0xc0687d88 in doadump () #1 0xc0688302 in kern_reboot () #2 0xc0688768 in panic () #3 0xc07f92bf in ffs_blkfree_cg () #4 0xc07f9417 in ffs_blkfree () #5 0xc0803259 in ffs_indirtrunc () #6 0xc08042e1 in ffs_truncate () #7 0xc083171c in ufs_inactive () #8 0xc0712718 in vinactive () #9 0xc0716e2a in vputx () #10 0xc071affb in kern_unlinkat () #11 0xc071b1a6 in kern_unlink () #12 0xc071b1ca in sys_unlink () #13 0xc089c954 in syscall () #14 0xc0887021 in Xint0x80_syscall () #15 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) wtf? With object files which were built using a kernel configuration file that had ``makeoptions DEBUG=-g'' inserted compared to the original configuration file: #kgdb kernel.debug /var/crash/vmcore.4 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) bt #0 0x00000000 in ?? () wtf? From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 23:37:35 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FA01106564A for ; Fri, 28 Oct 2011 23:37:35 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from hercules.mthelicon.com (unknown [IPv6:2001:49f0:2023::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0A3B88FC0A for ; Fri, 28 Oct 2011 23:37:34 +0000 (UTC) Received: from PortaPegIII (hydra.fletchermoorland.co.uk [78.33.209.59]) (authenticated bits=0) by hercules.mthelicon.com (8.14.5/8.14.3) with ESMTP id p9SNb3qQ017425; Fri, 28 Oct 2011 23:37:03 GMT (envelope-from ken@mthelicon.com) From: "Pegasus Mc Cleaft" To: "'Lyndon Nerenberg \(VE6BBM/VE7TFX\)'" , , References: <4EAB2D38.4040200@feral.com> In-Reply-To: Date: Sat, 29 Oct 2011 00:37:04 +0100 Message-ID: <003101cc95ca$80ec8b60$82c5a220$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcyVwzP4Ifu52GYTQ/ixpGafLGo9RQABRrEQ Content-Language: en-gb X-Spam-Status: No, score=0.9 required=15.0 tests=BAYES_00,DOS_OUTLOOK_TO_MX, FSL_HELO_NON_FQDN_1 autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on hercules.mthelicon.com Cc: Subject: RE: Adding disk firmware programming capability to camcontrol X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2011 23:37:35 -0000 >> The linux hdparm program is so paranoid about this that you have to = use=20 >> extra arguments like "--yes-really-destroy-my-disk-drive" to do this. > >I concur. Loudly. The ability to brick your hardware is just too >large to not make people go through the "I tell you three times" >dance. It's not like people will do this often enough that the >pain will be fatal. And if it is, they ought to be bright enough to >know how to automate the process. > >--lyndon Hi Lyndon and group,=20 I tend to disagree that there should be such argument antics employed to protect an operation such as this. Being root should be the = only protection needed (of course, that's only my opinion). I don=92t want to = have to look up in a man page what magic token I need to add to prove to the utility that I understand the consequences of what I am about to do. I personally wouldn't mind a simple "Are you sure?" if the magic token is = not added on the command line, however.=20 To me, the only difference between borking a drive because of bad firmware and typing "rm -rf *" from root is about =A340. You still lose = at least a day rebuilding/restoring everything. IMHO Peg From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 23:55:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62D9D106564A for ; Fri, 28 Oct 2011 23:55:44 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 371D78FC13 for ; Fri, 28 Oct 2011 23:55:44 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p9SNtUXq073309 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 28 Oct 2011 16:55:34 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4EAB40EE.1080309@freebsd.org> Date: Fri, 28 Oct 2011 16:55:26 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: "Lyndon Nerenberg (VE6BBM/VE7TFX)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, mj@feral.com Subject: Re: Adding disk firmware programming capability to camcontrol X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Oct 2011 23:55:44 -0000 On 10/28/11 3:43 PM, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote: >> The linux hdparm program is so paranoid about this that you have to use >> extra arguments like "--yes-really-destroy-my-disk-drive" to do this. > I concur. Loudly. The ability to brick your hardware is just too > large to not make people go through the "I tell you three times" > dance. It's not like people will do this often enough that the > pain will be fatal. And if it is, they ought to be bright enough to > know how to automate the process. Camcontrol is used pretty much exclusively by people who should understand the risks. and you have to be root. Unix's job is to reliably and efficiently deliver the bullet to your foot should you so desire. Put in some of these safety belts and add it I think.. > --lyndon > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 00:33:45 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7488B1065679 for ; Sat, 29 Oct 2011 00:33:45 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 39EBD8FC0A for ; Sat, 29 Oct 2011 00:33:44 +0000 (UTC) Received: by ywt32 with SMTP id 32so5478470ywt.13 for ; Fri, 28 Oct 2011 17:33:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uANye0MzbnhgD1zbV5yjoIFB/nuXR6aakliixRhr9SI=; b=nkR/raxB5i3Xn8ERcUlIZ93h8SnGVyqqud1vbcj+Nba7OHRyq1fbrS9Gc8pozBK3Mb PH2qu9vrn9KJRvTR2k+Xyh57sU3ZlSoRhJKJ3kMUW7kVGG9ZKbeV+Dwr2cF8pY0Erx6A Ywq8OfvqNzsA57b/mg5rV7eq43D13m47ilopA= MIME-Version: 1.0 Received: by 10.182.36.36 with SMTP id n4mr1118206obj.16.1319848424411; Fri, 28 Oct 2011 17:33:44 -0700 (PDT) Received: by 10.182.122.33 with HTTP; Fri, 28 Oct 2011 17:33:44 -0700 (PDT) In-Reply-To: References: Date: Fri, 28 Oct 2011 17:33:44 -0700 Message-ID: From: Garrett Cooper To: Dan Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: samba+zfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Oct 2011 00:33:45 -0000 On Thu, Oct 27, 2011 at 6:42 PM, Dan wrote: > > > Updated from 9.0 beta3 to RC1 and using mkvmerge over samba/zfs > its taking over an hour to just mux in things like DTS english, where it was > 15 minutes on beta3. Hi Dan, - Can you do more deterministic / scientific benchmarks? - Did you upgrade Samba? - What is your system's operating hardware profile? Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 00:35:31 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 780F01065673 for ; Sat, 29 Oct 2011 00:35:31 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 386BD8FC15 for ; Sat, 29 Oct 2011 00:35:31 +0000 (UTC) Received: by ywt32 with SMTP id 32so5479735ywt.13 for ; Fri, 28 Oct 2011 17:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=eb581Izj2p+AIChWCiYkFteLQYSY04TvDS7eI5Ez+Vk=; b=HPogn6g1Vsr61Dr/wP8jwX+vMh01WlUmd5PLh8Rvv5fPEa+QKwLqsHDoIQS5yX/T/u Ea5o7GDpda1VgockqBSpguI7Ve+vxZaByvUOpDd57KbW5MP7pJ4kKhkcQqSzcFgmT2nF Q+96Jfc/7CyvBp2d+Nznfv/gZXmTFe13V7nOU= MIME-Version: 1.0 Received: by 10.182.7.10 with SMTP id f10mr1100303oba.56.1319848530613; Fri, 28 Oct 2011 17:35:30 -0700 (PDT) Received: by 10.182.122.33 with HTTP; Fri, 28 Oct 2011 17:35:30 -0700 (PDT) In-Reply-To: References: Date: Fri, 28 Oct 2011 17:35:30 -0700 Message-ID: From: Garrett Cooper To: "deeptech71@gmail.com" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: panic: ffs_blkfree_cg: freeing free block X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Oct 2011 00:35:31 -0000 On Fri, Oct 28, 2011 at 4:34 PM, deeptech71@gmail.com wrote: > With object files which were built using the original kernel > configuration file (no debugging symbols included): > > #kgdb kernel /var/crash/vmcore.4 > 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 conditi= ons. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. =A0Type "show warranty" for deta= ils. > This GDB was configured as "i386-marcel-freebsd"...(no debugging > symbols found)... > Attempt to extract a component of a value that is not a structure pointer= . > Attempt to extract a component of a value that is not a structure pointer= . > #0 =A00xc0687d88 in doadump () > (kgdb) bt > #0 =A00xc0687d88 in doadump () > #1 =A00xc0688302 in kern_reboot () > #2 =A00xc0688768 in panic () > #3 =A00xc07f92bf in ffs_blkfree_cg () > #4 =A00xc07f9417 in ffs_blkfree () > #5 =A00xc0803259 in ffs_indirtrunc () > #6 =A00xc08042e1 in ffs_truncate () > #7 =A00xc083171c in ufs_inactive () > #8 =A00xc0712718 in vinactive () > #9 =A00xc0716e2a in vputx () > #10 0xc071affb in kern_unlinkat () > #11 0xc071b1a6 in kern_unlink () > #12 0xc071b1ca in sys_unlink () > #13 0xc089c954 in syscall () > #14 0xc0887021 in Xint0x80_syscall () > #15 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > > wtf? > > With object files which were built using a kernel configuration file > that had ``makeoptions DEBUG=3D-g'' inserted compared to the original > configuration file: > > #kgdb kernel.debug /var/crash/vmcore.4 > 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 conditi= ons. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. =A0Type "show warranty" for deta= ils. > This GDB was configured as "i386-marcel-freebsd"... > Cannot access memory at address 0x0 > (kgdb) bt > #0 =A00x00000000 in ?? () > > wtf? Something stomped on the stack. What was the previous version of FreeBSD (major.minor.subminor, svn revision) at worked? Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 00:39:13 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D9F91065672 for ; Sat, 29 Oct 2011 00:39:13 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id E36A68FC16 for ; Sat, 29 Oct 2011 00:39:12 +0000 (UTC) Received: by ggnq2 with SMTP id q2so5482689ggn.13 for ; Fri, 28 Oct 2011 17:39:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=cUYfdUpqHq03DD20sJkWyJ1JmTDcC/xgU6MVunMjQek=; b=L4BZztUS9DiSZ13F5vLVKSFsj3Qhf0eOja5wHL9FEWdmKemiUQ693MZRJ9eFFIf54/ NCjuLrSh4xLiHvoMqYlT38l6SCj+7XqlAqcI0lUZRsy1+lp3Yq6JSz6jqTMKcTrRKia8 SJmwrSD7zSnTjw0Zc18UgTXwon1hiH0D22M/Q= MIME-Version: 1.0 Received: by 10.182.7.10 with SMTP id f10mr1101942oba.56.1319848752108; Fri, 28 Oct 2011 17:39:12 -0700 (PDT) Received: by 10.182.122.33 with HTTP; Fri, 28 Oct 2011 17:39:12 -0700 (PDT) In-Reply-To: <003101cc95ca$80ec8b60$82c5a220$@com> References: <4EAB2D38.4040200@feral.com> <003101cc95ca$80ec8b60$82c5a220$@com> Date: Fri, 28 Oct 2011 17:39:12 -0700 Message-ID: From: Garrett Cooper To: Pegasus Mc Cleaft Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: mj@feral.com, freebsd-current@freebsd.org, "Lyndon Nerenberg \(VE6BBM/VE7TFX\)" Subject: Re: Adding disk firmware programming capability to camcontrol X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Oct 2011 00:39:13 -0000 On Fri, Oct 28, 2011 at 4:37 PM, Pegasus Mc Cleaft wrot= e: >>> The linux hdparm program is so paranoid about this that you have to use >>> extra arguments like "--yes-really-destroy-my-disk-drive" to do this. >> >>I concur. Loudly. =A0The ability to brick your hardware is just too >>large to not make people go through the "I tell you three times" >>dance. =A0It's not like people will do this often enough that the >>pain will be fatal. =A0And if it is, they ought to be bright enough to >>know how to automate the process. >> >>--lyndon > > Hi Lyndon and group, > > =A0 =A0 =A0 =A0I tend to disagree that there should be such argument anti= cs > employed to protect an operation such as this. Being root should be the o= nly > protection needed (of course, that's only my opinion). I don=92t want to = have > to look up in a man page what magic token I need to add to prove to the > utility that I understand the consequences of what I am about to do. I > personally wouldn't mind a simple "Are you sure?" if the magic token is n= ot > added on the command line, however. > > =A0 =A0 =A0 =A0To me, the only difference between borking a drive because= of bad > firmware and typing "rm -rf *" from root is about =A340. =A0You still los= e at > least a day rebuilding/restoring everything. Unfortunately not backs up their systems on a regular basis. Having an interactive prompt with a loud warning like many vendor tools provide today with a non-interactive override option is sufficient. That being said, camcontrol doesn't understand the concept of interactive vs non-interactive use, so it seems like its design would need to be redone if you go this route. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 01:34:40 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id BAA90106566C for ; Sat, 29 Oct 2011 01:34:40 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 9653A15120F; Sat, 29 Oct 2011 01:34:27 +0000 (UTC) Message-ID: <4EAB5823.5090804@FreeBSD.org> Date: Fri, 28 Oct 2011 18:34:27 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: Thomas Mueller References: <20111027102208.88BFB106564A@hub.freebsd.org> <20111028084329.134A0106566C@hub.freebsd.org> In-Reply-To: <20111028084329.134A0106566C@hub.freebsd.org> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org 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: Sat, 29 Oct 2011 01:34:40 -0000 On 10/28/2011 01:43, Thomas Mueller wrote: > How does one run mergemaster without running roughshod over existing configuration? 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 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 01:40:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 70EB3106564A; Sat, 29 Oct 2011 01:40:08 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id BCB111A756E; Sat, 29 Oct 2011 01:40:07 +0000 (UTC) Message-ID: <4EAB5977.8050700@FreeBSD.org> Date: Fri, 28 Oct 2011 18:40:07 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: kama References: <20111027102208.88BFB106564A@hub.freebsd.org> <20111027111451.GO63910@hoeg.nl> <201110280749.58837.jhb@freebsd.org> <20111028165451.O37058@ns1.as.pvp.se> In-Reply-To: <20111028165451.O37058@ns1.as.pvp.se> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Tom Evans , Ed Schouten , Thomas Mueller , freebsd-current@freebsd.org 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: Sat, 29 Oct 2011 01:40:08 -0000 On 10/28/2011 07:57, kama wrote: > > > On Fri, 28 Oct 2011, John Baldwin wrote: > >> On Thursday, October 27, 2011 7:14:51 am Ed Schouten wrote: >>> * Tom Evans , 20111027 13:06: >>>> I have had this happen before, the PEBKAC. When running mergemaster, >>>> it will prompt you to install new passwd, master.passwd and group >>>> files - if you have added local users you must not say yes to this, >>>> you must either merge the changes in or keep your local one. >>> >>> It would have been so awesome if our /etc/master.passwd and /etc/group >>> included an #include directive. >> >> I do agree with this. Or if you could have /etc/passwd.d and /etc/group.d >> directories that can contain files that are auto-included. Agreed. > Another idea is to let mergemaster call pw(8) to add remove users and > groups instead of merging the files. I definitely would not be inclined to do it this way. The manner in which mergemaster works now is fine, it just requires the sysadmin to pay attention when doing the merge. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 02:10:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0874F106566B for ; Sat, 29 Oct 2011 02:10:29 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id BDAC88FC08 for ; Sat, 29 Oct 2011 02:10:28 +0000 (UTC) Received: by qadz32 with SMTP id z32so5643130qad.13 for ; Fri, 28 Oct 2011 19:10:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=aKPMSIWrReIrdCkax8NjiKT8Su4YYFJtsMmvJxLKFLQ=; b=SPHyyImvDKgivvZbLThcLxP8BfWaiP85G1pBB9km+J7Z7j7a0b7xf3bZ6a/hhcx4nA b3bG2mw38RxZpFpmTxRsEtAwQ4wH+gSjWIeNxd47J6SKHWTDP0geF7GVo6kklT/GAqGT w4eYV3HBfcWuARYyUPvhwmjzul9YfDd3WhVMk= MIME-Version: 1.0 Received: by 10.229.191.2 with SMTP id dk2mr1339833qcb.32.1319854227815; Fri, 28 Oct 2011 19:10:27 -0700 (PDT) Received: by 10.229.226.65 with HTTP; Fri, 28 Oct 2011 19:10:27 -0700 (PDT) In-Reply-To: References: Date: Sat, 29 Oct 2011 04:10:27 +0200 Message-ID: From: "deeptech71@gmail.com" To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: panic: ffs_blkfree_cg: freeing free block X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Oct 2011 02:10:29 -0000 On Fri, Oct 28, 2011 at 11:16 AM, deeptech71@gmail.com wrote: > I don't have the intermediate object files for the kernel; now I'm > building the kernel again (from the appropriate, exact sources). That > shouldn't harm debugging, should it? On Sat, Oct 29, 2011 at 2:35 AM, Garrett Cooper wrote: > On Fri, Oct 28, 2011 at 4:34 PM, deeptech71@gmail.com > wrote: >> With object files which were built using the original kernel >> configuration file (no debugging symbols included): >> >> #kgdb kernel /var/crash/vmcore.4 >> 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 condit= ions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. =A0Type "show warranty" for det= ails. >> This GDB was configured as "i386-marcel-freebsd"...(no debugging >> symbols found)... >> Attempt to extract a component of a value that is not a structure pointe= r. >> Attempt to extract a component of a value that is not a structure pointe= r. >> #0 =A00xc0687d88 in doadump () >> (kgdb) bt >> #0 =A00xc0687d88 in doadump () >> #1 =A00xc0688302 in kern_reboot () >> #2 =A00xc0688768 in panic () >> #3 =A00xc07f92bf in ffs_blkfree_cg () >> #4 =A00xc07f9417 in ffs_blkfree () >> #5 =A00xc0803259 in ffs_indirtrunc () >> #6 =A00xc08042e1 in ffs_truncate () >> #7 =A00xc083171c in ufs_inactive () >> #8 =A00xc0712718 in vinactive () >> #9 =A00xc0716e2a in vputx () >> #10 0xc071affb in kern_unlinkat () >> #11 0xc071b1a6 in kern_unlink () >> #12 0xc071b1ca in sys_unlink () >> #13 0xc089c954 in syscall () >> #14 0xc0887021 in Xint0x80_syscall () >> #15 0x00000033 in ?? () >> Previous frame inner to this frame (corrupt stack?) >> >> wtf? >> >> With object files which were built using a kernel configuration file >> that had ``makeoptions DEBUG=3D-g'' inserted compared to the original >> configuration file: >> >> #kgdb kernel.debug /var/crash/vmcore.4 >> 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 condit= ions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. =A0Type "show warranty" for det= ails. >> This GDB was configured as "i386-marcel-freebsd"... >> Cannot access memory at address 0x0 >> (kgdb) bt >> #0 =A00x00000000 in ?? () >> >> wtf? > > Something stomped on the stack. More like: the release build doesn't have enough debug information in itself, and the release build is not debuggable at all using debug objects that have been built posteriorly. > What was the previous version of > FreeBSD (major.minor.subminor, svn revision) at worked? Not applicable. The panic occured, out of nowhere, on an r226289 kernel that has been working well and is still working well, with the exception of the panic. From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 02:22:19 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D1BD106564A for ; Sat, 29 Oct 2011 02:22:19 +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 155588FC08 for ; Sat, 29 Oct 2011 02:22:19 +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:To:From:Subject:Date:Message-ID; bh=zkJKGZqha0LtB3Tz/lsuyU9Wapi+Z0aToy/9HpSfTvg=; b=kuKQw1fvZJcYzEaQliViNoctnGbRFmP2FZkVFYNC/P1Jye1J6qB6v7rFlfBJJVKM0Y1RTQ88yYGKAsiK8vRCT6+7X7vJJgXY9S3xKAaAd0jGFL5AGCtJQpCCSySxg1H3lPq8rsoBHQ6B62bbltwIKNocvPTeT4BDswZ8gZxYizc=; Received: from localhost.lerctr.org ([127.0.0.1]:61727 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RJyYr-000MDy-GR for freebsd-current@freebsd.org; Fri, 28 Oct 2011 21:22:18 -0500 Received: from 72.182.3.73 (SquirrelMail authenticated user ler) by webmail.lerctr.org with HTTP; Fri, 28 Oct 2011 21:22:17 -0500 Message-ID: <0dcf638e123d2161d0e9d3c77386a8e7.squirrel@webmail.lerctr.org> Date: Fri, 28 Oct 2011 21:22:17 -0500 From: "Larry Rosenman" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.21 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: -3.4 (---) X-LERCTR-Spam-Score: -3.4 (---) X-Spam-Report: SpamScore (-3.4/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.504 X-LERCTR-Spam-Report: SpamScore (-3.4/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.504 Subject: syslogd: Remote Logging busted? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Oct 2011 02:22:19 -0000 I enabled remote logging for my home subnet, and syslogd doesn't seem(!) to be logging the messages. They ARE making it to the system. Can someone look at bin/162135 which has all the details, including tcpdump to show that the messages are making it to the system. Thanks! -- 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 Sat Oct 29 03:09:27 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3435106564A for ; Sat, 29 Oct 2011 03:09:27 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id A16198FC0A for ; Sat, 29 Oct 2011 03:09:27 +0000 (UTC) Received: by iaky10 with SMTP id y10so7322461iak.13 for ; Fri, 28 Oct 2011 20:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ZvfoFdakUO+SveCGblKQs42102jqGjC6ZPrpFuwosj4=; b=kR8DR+YCCvo0kOc+F0pgorK2V2FBysL7KJjQ0K7Kqy01N8fR9k1787ShxEPnsp8gYY PZFz6BjY9DTfmxXXNLXREaX7S0V6Dgy0RrC4kORLhPyDW/kKlNaeZugVcuO/2uDJQjvn 5DvZxJemTgXWVBm7MYEFY1genIMEb9jK4MMsA= MIME-Version: 1.0 Received: by 10.231.6.10 with SMTP id 10mr1733396ibx.76.1319857766869; Fri, 28 Oct 2011 20:09:26 -0700 (PDT) Received: by 10.231.46.198 with HTTP; Fri, 28 Oct 2011 20:09:26 -0700 (PDT) In-Reply-To: <4EAB5823.5090804@FreeBSD.org> References: <20111027102208.88BFB106564A@hub.freebsd.org> <20111028084329.134A0106566C@hub.freebsd.org> <4EAB5823.5090804@FreeBSD.org> Date: Fri, 28 Oct 2011 20:09:26 -0700 Message-ID: From: Kevin Oberman To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Thomas Mueller , freebsd-current@freebsd.org 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: Sat, 29 Oct 2011 03:09:28 -0000 On Fri, Oct 28, 2011 at 6:34 PM, Doug Barton wrote: > On 10/28/2011 01:43, Thomas Mueller wrote: >> How does one run mergemaster without running roughshod over existing con= figuration? > > Carefully? :) =A0Seriously ... 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. I agree that just running mergemaster CAREFULLY does the job. The only time I was ever burned was when I was in a BIG hurry and ended up wasting a LOT of time. (I think I also learned.) Of course, I also remember merging /etc before we had mergemaster. I am a bit curious why you recommend against -U, though. I've been using it since it was added and have never had a problems. It's saved me quite a bit of time. Is thee a corner case that I'm missing? --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 03:15:38 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6B2C106566C; Sat, 29 Oct 2011 03:15:38 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 503B18FC12; Sat, 29 Oct 2011 03:15:37 +0000 (UTC) Received: by ywt32 with SMTP id 32so5586125ywt.13 for ; Fri, 28 Oct 2011 20:15:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=nDUrGJjUdF+45sxlQc2nqP+Nd/BjRkYdvDuhurnpinM=; b=apxxhoS/ydbDZdMC/xsM+qlWNrafcwJDrNZZLdkTtPHAOECxIdaC7hydx+D08lDMgz AO6MN66SqhTpuFYS1t3/sFwNkoM0oz9DZgf/eA4PtCz5rLM4rmClys8Abq3/Hkkf00Od S/OVVEbLwzLVNibDd+OjkTCC3jGpeMf1v2UEA= MIME-Version: 1.0 Received: by 10.182.111.70 with SMTP id ig6mr1198127obb.6.1319858137342; Fri, 28 Oct 2011 20:15:37 -0700 (PDT) Received: by 10.182.122.33 with HTTP; Fri, 28 Oct 2011 20:15:37 -0700 (PDT) In-Reply-To: References: <20111027102208.88BFB106564A@hub.freebsd.org> <20111028084329.134A0106566C@hub.freebsd.org> <4EAB5823.5090804@FreeBSD.org> Date: Fri, 28 Oct 2011 20:15:37 -0700 Message-ID: From: Garrett Cooper To: Kevin Oberman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Thomas Mueller , Doug Barton , freebsd-current@freebsd.org 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: Sat, 29 Oct 2011 03:15:38 -0000 On Fri, Oct 28, 2011 at 8:09 PM, Kevin Oberman wrote: > On Fri, Oct 28, 2011 at 6:34 PM, Doug Barton wrote: >> On 10/28/2011 01:43, Thomas Mueller wrote: >>> How does one run mergemaster without running roughshod over existing co= nfiguration? >> >> Carefully? :) =A0Seriously ... 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. > > I agree that just running mergemaster CAREFULLY does the job. The only > time I was ever burned was when I was in a BIG hurry and ended up > wasting a LOT of time. (I think I also learned.) Of course, I also > remember merging /etc before we had mergemaster. > > I am a bit curious why you recommend against -U, though. I've been > using it since it was added and have never had a problems. It's saved > me quite a bit of time. Is thee a corner case that I'm missing? Here's a prime example (follow the white rabbit on this commit thread): http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026= 310.html . Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 03:24:42 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id BA37E106566B for ; Sat, 29 Oct 2011 03:24:42 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 6736814D89B; Sat, 29 Oct 2011 03:24:41 +0000 (UTC) Message-ID: <4EAB71F9.9090602@FreeBSD.org> Date: Fri, 28 Oct 2011 20:24:41 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: Kevin Oberman References: <20111027102208.88BFB106564A@hub.freebsd.org> <20111028084329.134A0106566C@hub.freebsd.org> <4EAB5823.5090804@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Thomas Mueller , freebsd-current@freebsd.org 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: Sat, 29 Oct 2011 03:24:42 -0000 On 10/28/2011 20:09, Kevin Oberman wrote: > On Fri, Oct 28, 2011 at 6:34 PM, Doug Barton wrote: >> On 10/28/2011 01:43, Thomas Mueller wrote: >>> How does one run mergemaster without running roughshod over existing configuration? >> >> 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. > > I agree that just running mergemaster CAREFULLY does the job. The only > time I was ever burned was when I was in a BIG hurry and ended up > wasting a LOT of time. (I think I also learned.) Of course, I also > remember merging /etc before we had mergemaster. Yeah, me too, that's why I wrote it. :) > I am a bit curious why you recommend against -U, though. I've been > using it since it was added and have never had a problems. It's saved > me quite a bit of time. Is thee a corner case that I'm missing? The case where there are relevant changes in configuration or other files that you miss because you install them without examination. That said, I realize that what people *want* is an upgrade process that they don't have to look at and/or think about. As soon as I figure out how to make mergemaster telepathic I'll be sure to add that patch. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 03:30:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7EEA106564A for ; Sat, 29 Oct 2011 03:30:29 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7702C8FC15 for ; Sat, 29 Oct 2011 03:30:29 +0000 (UTC) Received: by iaky10 with SMTP id y10so7344496iak.13 for ; Fri, 28 Oct 2011 20:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ekxt+kWCy/A2fqSLzykMO1a/QpkZmZMalqC+0QmOSFk=; b=dWOBRHFrQpLyXGoIWajt7ZTq0tzh1NsP84LlyHvdDMYuq/ysvX4XBOUxIHiKCk+E/1 0KfcD+OvNyP3zyBARsVXlmlmXQXdcvMzmiFfa0UUshxRmK5Ma9v+1EMlQda2ivhw77VV WWRteSiaaWfRUhRzVvyo4qrwitjhJZGmotgxY= MIME-Version: 1.0 Received: by 10.231.21.217 with SMTP id k25mr1780257ibb.63.1319859028792; Fri, 28 Oct 2011 20:30:28 -0700 (PDT) Received: by 10.231.46.198 with HTTP; Fri, 28 Oct 2011 20:30:28 -0700 (PDT) In-Reply-To: <0dcf638e123d2161d0e9d3c77386a8e7.squirrel@webmail.lerctr.org> References: <0dcf638e123d2161d0e9d3c77386a8e7.squirrel@webmail.lerctr.org> Date: Fri, 28 Oct 2011 20:30:28 -0700 Message-ID: From: Kevin Oberman To: Larry Rosenman Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: syslogd: Remote Logging busted? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Oct 2011 03:30:29 -0000 On Fri, Oct 28, 2011 at 7:22 PM, Larry Rosenman wrote: > > I enabled remote logging for my home subnet, and syslogd doesn't seem(!) to > be logging the messages. > > They ARE making it to the system. > > Can someone look at bin/162135 which has all the details, including > tcpdump to show that the messages are making it to the system. Just to be clear, you are running tcpdump on borg, right? The statement "This is from my Cable Modem:" confuses me a bit. Assuming tcpdump is on borg, it is making past any firewall (pf or ipfw, at least). What about /etc/hosts.allow? I don't recall if it filters before or after pcap see packets. I used to have a diagram showing the sequence of processing this, but I can't seem to find it now. What does "netstat -af inet | grep syslog" show? Is syslogd actually listening? -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 03:37:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BEE51065678 for ; Sat, 29 Oct 2011 03:37:53 +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 1C3AA8FC15 for ; Sat, 29 Oct 2011 03:37:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:References:Message-ID:In-Reply-To:Subject:cc:To:Sender:From:Date; bh=g4HakCYCr0pOQx9Vy6ViT64rzn0ODnmaAmG23QfTCjs=; b=Ikp+O8G4rhVHZhEH6Cs9GCXY7smGF/Xj/GvwxxPemYHfVF9RGupI5BWuycGR2pkWQ1zuZ332MI7MOQDd3L8l0szCj778k75sShbA6FuP/YwIhjdXYnmUJm4byNjyn6YCro7Oj1Gf28Lq75yjWyUkBS5EMGKerdxMyVBlJ+1r0nQ=; Received: from cpe-72-182-3-73.austin.res.rr.com ([72.182.3.73]:11315 helo=borg) by thebighonker.lerctr.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RJzjt-000Mv2-Nd; Fri, 28 Oct 2011 22:37:52 -0500 Date: Fri, 28 Oct 2011 22:37:41 -0500 (CDT) From: Larry Rosenman Sender: ler@borg To: Kevin Oberman In-Reply-To: Message-ID: References: <0dcf638e123d2161d0e9d3c77386a8e7.squirrel@webmail.lerctr.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 Cc: freebsd-current@freebsd.org Subject: Re: syslogd: Remote Logging busted? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Oct 2011 03:37:53 -0000 On Fri, 28 Oct 2011, Kevin Oberman wrote: > On Fri, Oct 28, 2011 at 7:22 PM, Larry Rosenman wrote: >> >> I enabled remote logging for my home subnet, and syslogd doesn't seem(!) to >> be logging the messages. >> >> They ARE making it to the system. >> >> Can someone look at bin/162135 which has all the details, including >> tcpdump to show that the messages are making it to the system. > > Just to be clear, you are running tcpdump on borg, right? The > statement "This is from my Cable Modem:" confuses me a bit. Yes, the tcpdump is running on borg, and the source of the syslog packets is from my Cable Modem at 192.168.200.10. /etc/hosts.allow: # # hosts.allow access control file for "tcp wrapped" applications. # $FreeBSD: src/etc/hosts.allow,v 1.23 2006/08/29 09:20:48 ru Exp $ # # NOTE: The hosts.deny file is deprecated. # Place both 'allow' and 'deny' rules in the hosts.allow file. # See hosts_options(5) for the format of this file. # hosts_access(5) no longer fully applies. # _____ _ _ # | ____| __ __ __ _ _ __ ___ _ __ | | ___ | | # | _| \ \/ / / _` | | '_ ` _ \ | '_ \ | | / _ \ | | # | |___ > < | (_| | | | | | | | | |_) | | | | __/ |_| # |_____| /_/\_\ \__,_| |_| |_| |_| | .__/ |_| \___| (_) # |_| # !!! This is an example! You will need to modify it for your specific # !!! requirements! # Start by allowing everything (this prevents the rest of the file # from working, so remove it when you need protection). # The rules here work on a "First match wins" basis. #ALL : ALL : allow # Wrapping sshd(8) is not normally a good idea, but if you # need to do it, here's how #sshd : .evil.cracker.example.com : deny # Protect against simple DNS spoofing attacks by checking that the # forward and reverse records for the remote host match. If a mismatch # occurs, access is denied, and any positive ident response within # 20 seconds is logged. No protection is afforded against DNS poisoning, # IP spoofing or more complicated attacks. Hosts with no reverse DNS # pass this rule. ALL : PARANOID : RFC931 20 : deny # Allow anything from localhost. Note that an IP address (not a host # name) *MUST* be specified for rpcbind(8). ALL : localhost 127.0.0.1 : allow # Comment out next line if you build libwrap without IPv6 support. ALL : [::1] : allow #ALL : my.machine.example.com 192.0.2.35 : allow # To use IPv6 addresses you must enclose them in []'s #ALL : [fe80::%fxp0]/10 : allow #ALL : [fe80::]/10 : deny #ALL : [2001:db8:2:1:2:3:4:3fe1] : deny #ALL : [2001:db8:2:1::]/64 : allow # Sendmail can help protect you against spammers and relay-rapers #sendmail : localhost : allow #sendmail : .nice.guy.example.com : allow #sendmail : .evil.cracker.example.com : deny #sendmail : ALL : allow # Exim is an alternative to sendmail, available in the ports tree exim : localhost : allow #exim : .nice.guy.example.com : allow #exim : .evil.cracker.example.com : deny exim : ALL : allow # Rpcbind is used for all RPC services; protect your NFS! # (IP addresses rather than hostnames *MUST* be used here) #rpcbind : 192.0.2.32/255.255.255.224 : allow #rpcbind : 192.0.2.96/255.255.255.224 : allow rpcbind : ALL : deny # NIS master server. Only local nets should have access # (Since this is an RPC service, rpcbind needs to be considered) ypserv : localhost : allow #ypserv : .unsafe.my.net.example.com : deny #ypserv : .my.net.example.com : allow ypserv : ALL : deny # Provide a small amount of protection for ftpd ftpd : localhost : allow #ftpd : .nice.guy.example.com : allow #ftpd : .evil.cracker.example.com : deny ftpd : ALL : allow # You need to be clever with finger; do _not_ backfinger!! You can easily # start a "finger war". fingerd : ALL \ : spawn (echo Finger. | \ /usr/bin/mail -s "tcpd\: %u@%h[%a] fingered me!" root) & \ : deny # The rest of the daemons are protected. #ALL : ALL \ # : severity auth.info \ # : twist /bin/echo "You are not welcome to use %d from %h." # Added by SSHBlock [Sat Oct 22 00:10:49 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:10:52 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:10:55 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:10:58 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:11:00 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:11:02 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:11:04 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:11:06 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:11:08 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:11:10 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:11:12 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:11:14 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:11:16 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:11:18 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:11:19 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:11:21 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:11:24 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:11:26 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:11:29 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:11:31 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:11:33 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:11:36 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:11:38 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:11:40 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:11:42 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:11:44 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:11:46 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:11:48 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:11:50 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:11:52 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:11:54 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:11:56 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:11:58 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:12:00 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:12:02 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:12:04 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:12:06 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:12:08 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:12:10 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:12:12 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:12:14 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:12:16 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:12:19 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:12:21 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:12:23 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:12:26 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:12:29 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:12:32 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:12:34 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:12:36 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:12:39 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:12:41 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:12:43 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:12:46 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:12:48 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:12:50 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:12:53 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:12:55 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:12:57 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:13:00 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:13:02 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:13:04 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:13:06 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:13:10 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:13:12 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:13:15 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:13:18 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:13:21 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:13:23 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:13:26 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:13:28 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:13:30 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:13:33 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:13:35 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:13:37 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:13:39 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:13:41 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:13:42 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:13:45 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:13:47 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:13:49 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:13:51 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:13:53 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:13:54 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:13:57 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:13:58 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:14:00 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:14:03 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:14:05 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:14:06 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:14:08 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:14:11 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:14:13 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:14:15 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:14:17 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:14:20 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:14:22 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:14:24 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:14:26 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:14:29 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:14:30 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:14:32 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:14:34 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:14:36 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:14:39 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:14:41 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:14:44 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:14:44 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:14:46 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:14:48 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:14:51 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:14:54 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:14:56 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:14:59 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:15:02 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:15:04 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:15:07 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:15:09 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:15:11 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:15:14 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:15:16 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:15:19 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:15:21 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:15:24 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:15:26 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:15:28 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:15:31 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:15:33 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:15:35 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:15:38 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:15:40 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:15:42 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:15:45 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:15:47 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:15:49 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:15:52 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:15:54 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:15:56 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:15:59 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:16:01 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:16:03 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:16:06 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:16:08 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:16:11 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:16:13 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:16:15 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:16:16 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:16:18 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:16:20 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:16:22 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:16:25 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:16:27 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:16:27 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:16:29 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:16:32 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:16:34 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:16:36 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:16:39 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:16:41 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:16:44 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:16:46 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:16:48 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:16:50 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:16:53 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:16:55 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:16:58 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:17:00 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:17:02 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:17:04 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:17:07 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:17:09 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:17:10 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:17:12 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:17:14 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:17:17 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:17:19 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:17:21 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:17:22 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:17:24 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:17:26 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:17:28 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:17:31 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:17:33 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:17:33 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:17:36 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:17:38 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:17:40 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:17:43 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:17:45 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:17:48 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:17:50 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:17:52 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:17:55 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:17:57 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:18:01 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:18:04 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:18:07 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:18:09 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:18:13 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:18:16 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:18:18 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 00:18:21 2011] # 5 break-in attempts in 15 seconds: sshd : 58.20.110.21 : deny # Added by SSHBlock [Sat Oct 22 14:48:29 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 14:48:45 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 14:49:03 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 14:51:01 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 14:52:01 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 14:52:16 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 14:52:43 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 14:53:21 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 14:54:15 2011] # 10 break-in attempts in 60 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 14:54:43 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 14:55:14 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 14:55:35 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 14:56:14 2011] # 10 break-in attempts in 60 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 14:56:40 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 14:56:58 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 14:57:16 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 14:57:33 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 14:57:51 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 14:58:16 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 14:58:44 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 14:59:01 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 14:59:23 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:00:05 2011] # 10 break-in attempts in 60 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:00:21 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:00:38 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:00:55 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:01:13 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:01:27 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:01:45 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:02:00 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:02:31 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:02:52 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:03:07 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:03:26 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:03:42 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:03:56 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:04:15 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:04:31 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:04:49 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:05:10 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:05:28 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:05:49 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:06:04 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:06:23 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:06:38 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:07:03 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:07:25 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:07:47 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:08:11 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:08:27 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:08:42 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:09:00 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:09:17 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:09:32 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:09:49 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:10:07 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:10:23 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:10:46 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:11:00 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:11:18 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:11:33 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:11:49 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:12:07 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:12:23 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:12:39 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:12:54 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:13:17 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:13:32 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:13:46 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:14:03 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:14:22 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:14:38 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:14:54 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:15:08 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:15:24 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:15:45 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:16:00 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:16:51 2011] # 10 break-in attempts in 60 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:17:06 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:17:20 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:17:57 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:18:38 2011] # 10 break-in attempts in 60 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:18:53 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:19:18 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:19:42 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:20:06 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:20:23 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:21:05 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:21:22 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:22:20 2011] # 10 break-in attempts in 60 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:22:54 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:23:09 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:23:30 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:23:45 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:24:02 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:24:18 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:25:12 2011] # 10 break-in attempts in 60 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:25:41 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:25:57 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:26:12 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:26:27 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:26:51 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:27:09 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:27:24 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:29:02 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:29:17 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:29:34 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:30:10 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:30:25 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:30:57 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:31:13 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:31:29 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:31:45 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:31:59 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:32:15 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:32:31 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:32:45 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:33:06 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:33:29 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:33:45 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sat Oct 22 15:34:01 2011] # 5 break-in attempts in 15 seconds: sshd : 220.227.158.106 : deny # Added by SSHBlock [Sun Oct 23 09:58:42 2011] # 5 break-in attempts in 15 seconds: sshd : 121.31.110.201 : deny # Added by SSHBlock [Sun Oct 23 09:59:07 2011] # 5 break-in attempts in 15 seconds: sshd : 121.31.110.201 : deny # Added by SSHBlock [Sun Oct 23 09:59:23 2011] # 5 break-in attempts in 15 seconds: sshd : 121.31.110.201 : deny # Added by SSHBlock [Sun Oct 23 09:59:41 2011] # 5 break-in attempts in 15 seconds: sshd : 121.31.110.201 : deny # Added by SSHBlock [Sun Oct 23 10:00:34 2011] # 10 break-in attempts in 60 seconds: sshd : 121.31.110.201 : deny # Added by SSHBlock [Sun Oct 23 10:00:49 2011] # 5 break-in attempts in 15 seconds: sshd : 121.31.110.201 : deny # Added by SSHBlock [Sun Oct 23 10:01:14 2011] # 5 break-in attempts in 15 seconds: sshd : 121.31.110.201 : deny # Added by SSHBlock [Sun Oct 23 10:01:28 2011] # 5 break-in attempts in 15 seconds: sshd : 121.31.110.201 : deny # Added by SSHBlock [Sun Oct 23 12:10:05 2011] # 5 break-in attempts in 15 seconds: sshd : 60.191.221.184 : deny # Added by SSHBlock [Sun Oct 23 12:10:15 2011] # 5 break-in attempts in 15 seconds: sshd : 60.191.221.184 : deny # Added by SSHBlock [Sun Oct 23 12:10:26 2011] # 5 break-in attempts in 15 seconds: sshd : 60.191.221.184 : deny # Added by SSHBlock [Sun Oct 23 12:10:37 2011] # 5 break-in attempts in 15 seconds: sshd : 60.191.221.184 : deny # Added by SSHBlock [Sun Oct 23 12:10:50 2011] # 5 break-in attempts in 15 seconds: sshd : 60.191.221.184 : deny # Added by SSHBlock [Sun Oct 23 12:11:03 2011] # 5 break-in attempts in 15 seconds: sshd : 60.191.221.184 : deny # Added by SSHBlock [Sun Oct 23 12:11:13 2011] # 5 break-in attempts in 15 seconds: sshd : 60.191.221.184 : deny # Added by SSHBlock [Sun Oct 23 12:11:28 2011] # 5 break-in attempts in 15 seconds: sshd : 60.191.221.184 : deny # Added by SSHBlock [Sun Oct 23 12:11:59 2011] # 5 break-in attempts in 15 seconds: sshd : 60.191.221.184 : deny # Added by SSHBlock [Sun Oct 23 12:12:12 2011] # 5 break-in attempts in 15 seconds: sshd : 60.191.221.184 : deny # Added by SSHBlock [Sun Oct 23 12:12:29 2011] # 5 break-in attempts in 15 seconds: sshd : 60.191.221.184 : deny # Added by SSHBlock [Sun Oct 23 12:12:40 2011] # 5 break-in attempts in 15 seconds: sshd : 60.191.221.184 : deny # Added by SSHBlock [Sun Oct 23 12:12:57 2011] # 5 break-in attempts in 15 seconds: sshd : 60.191.221.184 : deny # Added by SSHBlock [Sun Oct 23 12:13:09 2011] # 5 break-in attempts in 15 seconds: sshd : 60.191.221.184 : deny # Added by SSHBlock [Sun Oct 23 12:13:26 2011] # 5 break-in attempts in 15 seconds: sshd : 60.191.221.184 : deny # Added by SSHBlock [Sun Oct 23 12:13:37 2011] # 5 break-in attempts in 15 seconds: sshd : 60.191.221.184 : deny # Added by SSHBlock [Sun Oct 23 12:13:48 2011] # 5 break-in attempts in 15 seconds: sshd : 60.191.221.184 : deny # Added by SSHBlock [Sun Oct 23 12:14:03 2011] # 5 break-in attempts in 15 seconds: sshd : 60.191.221.184 : deny # Added by SSHBlock [Sun Oct 23 12:14:19 2011] # 5 break-in attempts in 15 seconds: sshd : 60.191.221.184 : deny # Added by SSHBlock [Sun Oct 23 12:14:33 2011] # 5 break-in attempts in 15 seconds: sshd : 60.191.221.184 : deny # Added by SSHBlock [Sun Oct 23 12:14:44 2011] # 5 break-in attempts in 15 seconds: sshd : 60.191.221.184 : deny # Added by SSHBlock [Sun Oct 23 12:14:55 2011] # 5 break-in attempts in 15 seconds: sshd : 60.191.221.184 : deny # Added by SSHBlock [Sun Oct 23 12:15:05 2011] # 5 break-in attempts in 15 seconds: sshd : 60.191.221.184 : deny # Added by SSHBlock [Sun Oct 23 12:15:18 2011] # 5 break-in attempts in 15 seconds: sshd : 60.191.221.184 : deny # Added by SSHBlock [Sun Oct 23 12:15:29 2011] # 5 break-in attempts in 15 seconds: sshd : 60.191.221.184 : deny # Added by SSHBlock [Sun Oct 23 12:15:39 2011] # 5 break-in attempts in 15 seconds: sshd : 60.191.221.184 : deny # Added by SSHBlock [Sun Oct 23 12:15:52 2011] # 5 break-in attempts in 15 seconds: sshd : 60.191.221.184 : deny # Added by SSHBlock [Sun Oct 23 14:15:50 2011] # 5 break-in attempts in 15 seconds: sshd : 85.214.156.73 : deny # Added by SSHBlock [Sun Oct 23 14:20:03 2011] # 5 break-in attempts in 15 seconds: sshd : 85.214.156.73 : deny # Added by SSHBlock [Sun Oct 23 14:20:10 2011] # 5 break-in attempts in 15 seconds: sshd : 85.214.156.73 : deny # Added by SSHBlock [Sun Oct 23 14:20:18 2011] # 5 break-in attempts in 15 seconds: sshd : 85.214.156.73 : deny # Added by SSHBlock [Sun Oct 23 14:20:26 2011] # 5 break-in attempts in 15 seconds: sshd : 85.214.156.73 : deny # Added by SSHBlock [Sun Oct 23 14:20:34 2011] # 5 break-in attempts in 15 seconds: sshd : 85.214.156.73 : deny # Added by SSHBlock [Tue Oct 25 19:43:23 2011] # 10 break-in attempts in 60 seconds: sshd : 58.56.147.146 : deny # Added by SSHBlock [Fri Oct 28 11:37:48 2011] # 5 break-in attempts in 15 seconds: sshd : 61.236.182.11 : deny # Added by SSHBlock [Fri Oct 28 18:46:53 2011] # 5 break-in attempts in 15 seconds: sshd : 121.207.230.69 : deny > > Assuming tcpdump is on borg, it is making past any firewall (pf or > ipfw, at least). What about /etc/hosts.allow? I don't recall if it > filters before or after pcap see packets. I used to have a diagram > showing the sequence of processing this, but I can't seem to find it > now. > > What does "netstat -af inet | grep syslog" show? Is syslogd actually listening? the netstat output: udp4 0 0 *.syslog *.* and sockstat | grep syslog: root syslogd 65128 4 dgram /var/run/log root syslogd 65128 5 dgram /var/run/logpriv root syslogd 65128 6 udp6 *:514 *:* root syslogd 65128 7 udp4 *:514 *:* > -- 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 Sat Oct 29 03:44:18 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77E49106566C; Sat, 29 Oct 2011 03:44:18 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 35C718FC08; Sat, 29 Oct 2011 03:44:17 +0000 (UTC) Received: by iaky10 with SMTP id y10so7360124iak.13 for ; Fri, 28 Oct 2011 20:44:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=G3boJSo/zyJBXRVnmb0W7wlUsgZNkXVtc7+MPQKQFA4=; b=CNk2pZrG+Ym+6mI2Peqqfq8YdmemHf2GfS83HPsozPyjkM4+dC34Elw2zhj095bb8z Zob6pDLqFhLMZL3eXa5Mwlrcsbsmp2s+OlVsYc4FznH/wElKfFzUWZ4MxKRWajN+yju+ uRNRJ8v11gB7aum53o4odvS4DfUNsKHFskAR0= MIME-Version: 1.0 Received: by 10.231.63.212 with SMTP id c20mr1757876ibi.52.1319859857560; Fri, 28 Oct 2011 20:44:17 -0700 (PDT) Received: by 10.231.46.198 with HTTP; Fri, 28 Oct 2011 20:44:17 -0700 (PDT) In-Reply-To: <4EAB71F9.9090602@FreeBSD.org> References: <20111027102208.88BFB106564A@hub.freebsd.org> <20111028084329.134A0106566C@hub.freebsd.org> <4EAB5823.5090804@FreeBSD.org> <4EAB71F9.9090602@FreeBSD.org> Date: Fri, 28 Oct 2011 20:44:17 -0700 Message-ID: From: Kevin Oberman To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Thomas Mueller , freebsd-current@freebsd.org 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: Sat, 29 Oct 2011 03:44:18 -0000 On Fri, Oct 28, 2011 at 8:24 PM, Doug Barton wrote: > On 10/28/2011 20:09, Kevin Oberman wrote: >> On Fri, Oct 28, 2011 at 6:34 PM, Doug Barton wrote: >>> On 10/28/2011 01:43, Thomas Mueller wrote: >>>> How does one run mergemaster without running roughshod over existing c= onfiguration? >>> >>> Carefully? :) =A0Seriously ... 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 optio= n >>> 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. >> >> I agree that just running mergemaster CAREFULLY does the job. The only >> time I was ever burned was when I was in a BIG hurry and ended up >> wasting a LOT of time. (I think I also learned.) Of course, I also >> remember merging /etc before we had mergemaster. > > Yeah, me too, that's why I wrote it. :) > >> I am a bit curious why you recommend against -U, though. I've been >> using it since it was added and have never had a problems. It's saved >> me quite a bit of time. Is thee a corner case that I'm missing? > > The case where there are relevant changes in configuration or other > files that you miss because you install them without examination. That > said, I realize that what people *want* is an upgrade process that they > don't have to look at and/or think about. As soon as I figure out how to > make mergemaster telepathic I'll be sure to add that patch. An obvious problem that I managed overlook all of this time. And thanks for all of your shell code. Between mergemaster and portmaster you have saved many, many man-years of painful and error-prone effort. Do you dream in sh? --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 04:08:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FD8B1065672; Sat, 29 Oct 2011 04:08:53 +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 64A778FC13; Sat, 29 Oct 2011 04:08:53 +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:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=4oVDbyCgxf5GvZ4Mh62rhFsRd5cu/wrPlcZkZYcLtNo=; b=Kewl+Ng4aD0rrEDeOvzAhpcDy/c06eMo+YEsknRELvL+Z7+yOv4Jq/Gg0hx/xx6PRC3J0hxAB2ci4lSnuZY8T7X8OWquwgENtenOrXxCb/9s22idP3AgXTpQn109Blf/y/VRZtkw1pnfs6SBuN5B+es9ewuXgRNiusGA9KjUhYY=; Received: from cpe-72-182-3-73.austin.res.rr.com ([72.182.3.73]:52241 helo=[192.168.200.103]) by thebighonker.lerctr.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RK0DD-000NA0-4Q; Fri, 28 Oct 2011 23:08:52 -0500 Message-ID: <4EAB7C25.3020309@lerctr.org> Date: Fri, 28 Oct 2011 23:08:05 -0500 From: Larry Rosenman User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Stanislav Sedov References: <20111028201614.5e340538.stas@FreeBSD.org> <93b1f542-2d5a-4295-8c64-32889ce1ae63@email.android.com> <20111028210110.3afca748.stas@FreeBSD.org> In-Reply-To: <20111028210110.3afca748.stas@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 Cc: freebsd-current@freebsd.org, FreeBSD PR followup Subject: Re: bin/162135: remote syslog not logging X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Oct 2011 04:08:53 -0000 On 10/28/2011 11:01 PM, Stanislav Sedov wrote: > On Fri, 28 Oct 2011 22:20:27 -0500 > Larry Rosenman mentioned: > >> See the options lines >> >> -a 192.168.200.0/24 >> >> And the Cable modem is sending to 514. >> > Please, read the manpage description for the '-a' switch. > The modem is sending to the port 514, it's true, but it's not > using port 514 as a source. And you didn't specify the source > service in the '-a' command line argument parameter. > AHA! That's the issue. I changed the -a to: syslogd_flags="-n -a 192.168.200.0/24:*" and we now get the messages logged. THANK YOU. From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 04:16:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34BB21065673 for ; Sat, 29 Oct 2011 04:16:29 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 01BFD8FC17 for ; Sat, 29 Oct 2011 04:16:28 +0000 (UTC) Received: by iaky10 with SMTP id y10so7393092iak.13 for ; Fri, 28 Oct 2011 21:16:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=z9BS7x/q9qZF8D0QW1fTPy9r/3A7Ek0eAxa6bBJU36k=; b=hD9zpURSCUJttNWIWAIwpSyfwubCU7E+mpTmaL4LLmLzHBke6H+WAfhuYKa0r4py94 3M5FmPwo5KKo/3+i2DnxWEw3Q5dBfeNXw4YRj/8zBFKUAetzyCFtZK6HuKeAg2q/4sXQ UdqsjGm1yQzvVB10oq4EVU6ypg4csQxNmZrPA= MIME-Version: 1.0 Received: by 10.231.6.10 with SMTP id 10mr1777949ibx.76.1319861788405; Fri, 28 Oct 2011 21:16:28 -0700 (PDT) Received: by 10.231.46.198 with HTTP; Fri, 28 Oct 2011 21:16:28 -0700 (PDT) In-Reply-To: References: <0dcf638e123d2161d0e9d3c77386a8e7.squirrel@webmail.lerctr.org> Date: Fri, 28 Oct 2011 21:16:28 -0700 Message-ID: From: Kevin Oberman To: Larry Rosenman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: syslogd: Remote Logging busted? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Oct 2011 04:16:29 -0000 On Fri, Oct 28, 2011 at 8:37 PM, Larry Rosenman wrote: > On Fri, 28 Oct 2011, Kevin Oberman wrote: > >> On Fri, Oct 28, 2011 at 7:22 PM, Larry Rosenman wrote: >>> >>> I enabled remote logging for my home subnet, and syslogd doesn't seem(!= ) >>> to >>> be logging the messages. >>> >>> They ARE making it to the system. >>> >>> Can someone look at bin/162135 which has all the details, including >>> tcpdump to show that the messages are making it to the system. >> >> Just to be clear, you are running tcpdump on borg, right? The >> statement "This is from my Cable Modem:" confuses me a bit. > > Yes, the tcpdump is running on borg, and the source of the syslog packets > is from my Cable Modem at 192.168.200.10. > > /etc/hosts.allow: [Comments elided] > ALL : PARANOID : RFC931 20 : deny > ALL : localhost 127.0.0.1 : allow > ALL : [::1] : allow > exim : localhost : allow > exim : ALL : allow > rpcbind : ALL : deny > ypserv : localhost : allow > ypserv : ALL : deny > ftpd : localhost : allow > ftpd : ALL : allow > fingerd : ALL \ > =A0 =A0 =A0 =A0: spawn (echo Finger. | \ > =A0 =A0 =A0 =A0 /usr/bin/mail -s "tcpd\: %u@%h[%a] fingered me!" root) & = \ > =A0 =A0 =A0 =A0: deny Several superfluous rules, but I can't see anything that would block 514. >> >> Assuming tcpdump is on borg, it is making past any firewall (pf or >> ipfw, at least). What about /etc/hosts.allow? I don't recall if it >> filters before or after pcap see packets. I used to have a diagram >> showing the sequence of processing this, but I can't seem to find it >> now. >> >> What does "netstat -af inet | grep syslog" show? Is syslogd actually >> listening? > > > the netstat output: udp4 =A0 =A0 =A0 0 =A0 =A0 =A00 *.syslog =A0 =A0 =A0 = =A0 =A0 =A0 =A0 *.* > > and sockstat | grep syslog: root =A0 =A0 syslogd =A0 =A065128 4 =A0dgram = =A0/var/run/log > root =A0 =A0 syslogd =A0 =A065128 5 =A0dgram =A0/var/run/logpriv > root =A0 =A0 syslogd =A0 =A065128 6 =A0udp6 =A0 *:514 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 *:* > root =A0 =A0 syslogd =A0 =A065128 7 =A0udp4 =A0 *:514 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 *:* OK. I'm baffled! I can't see anything that looks wrong, but I'll think about it a bit more. --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 04:21:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id F39F91065675 for ; Sat, 29 Oct 2011 04:21:40 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 5E7E1152E89; Sat, 29 Oct 2011 04:21:40 +0000 (UTC) Message-ID: <4EAB7F53.5050803@FreeBSD.org> Date: Fri, 28 Oct 2011 21:21:39 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: Kevin Oberman References: <20111027102208.88BFB106564A@hub.freebsd.org> <20111028084329.134A0106566C@hub.freebsd.org> <4EAB5823.5090804@FreeBSD.org> <4EAB71F9.9090602@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Thomas Mueller , freebsd-current@freebsd.org 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: Sat, 29 Oct 2011 04:21:41 -0000 On 10/28/2011 20:44, Kevin Oberman wrote: > On Fri, Oct 28, 2011 at 8:24 PM, Doug Barton wrote: >> On 10/28/2011 20:09, Kevin Oberman wrote: >>> On Fri, Oct 28, 2011 at 6:34 PM, Doug Barton wrote: >>>> On 10/28/2011 01:43, Thomas Mueller wrote: >>>>> How does one run mergemaster without running roughshod over existing configuration? >>>> >>>> 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. >>> >>> I agree that just running mergemaster CAREFULLY does the job. The only >>> time I was ever burned was when I was in a BIG hurry and ended up >>> wasting a LOT of time. (I think I also learned.) Of course, I also >>> remember merging /etc before we had mergemaster. >> >> Yeah, me too, that's why I wrote it. :) >> >>> I am a bit curious why you recommend against -U, though. I've been >>> using it since it was added and have never had a problems. It's saved >>> me quite a bit of time. Is thee a corner case that I'm missing? >> >> The case where there are relevant changes in configuration or other >> files that you miss because you install them without examination. That >> said, I realize that what people *want* is an upgrade process that they >> don't have to look at and/or think about. As soon as I figure out how to >> make mergemaster telepathic I'll be sure to add that patch. > > An obvious problem that I managed overlook all of this time. Well people try very hard not to introduce POLA'ish problems, but sometimes it's necessary, and sometimes it happens in spite of our best efforts (as Garrett pointed out). > And thanks for all of your shell code. Between mergemaster and > portmaster you have saved many, many man-years of painful and > error-prone effort. You're welcome. :) > Do you dream in sh? Well I probably will NOW, thanks a lot! Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 04:26:31 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7927C106566C for ; Sat, 29 Oct 2011 04:26:31 +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 3F7958FC12 for ; Sat, 29 Oct 2011 04:26:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:References:Message-ID:In-Reply-To:Subject:cc:To:Sender:From:Date; bh=OcIctSwwDes7ATuPEKDDlvymNLCtkljV/TCUwaZrcfY=; b=WFoSej9Z7usCHfa47So7Ioh4rubVILNB8g4rLc+YOs2RkN3VOz1jBTQfAYwI5MHg10qnZbDIz7bwM6+57slAIH2r5fZ83GABaJa8U9tk2fR/jhRDmii1JIk8GFagG1JOysxkf8EmfwmSSMwGQMuufcQWCzgFMn0UPVQ99qaIWXU=; Received: from cpe-72-182-3-73.austin.res.rr.com ([72.182.3.73]:39515 helo=borg) by thebighonker.lerctr.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RK0V3-000NI4-7q; Fri, 28 Oct 2011 23:26:30 -0500 Date: Fri, 28 Oct 2011 23:26:26 -0500 (CDT) From: Larry Rosenman Sender: ler@borg To: Kevin Oberman In-Reply-To: Message-ID: References: <0dcf638e123d2161d0e9d3c77386a8e7.squirrel@webmail.lerctr.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 Cc: freebsd-current@freebsd.org Subject: Re: syslogd: Remote Logging busted? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Oct 2011 04:26:31 -0000 On Fri, 28 Oct 2011, Kevin Oberman wrote: > > OK. I'm baffled! I can't see anything that looks wrong, but I'll think > about it a bit more. > See my reply to Stas (cc'd to you). The issue is the damn cable modem is sending the packets from random source PORTS, so the -a entry needed a :* after the /24 to allow that. Now we're getting the log entries. -- 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 Sat Oct 29 05:14:02 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EE0F1065670 for ; Sat, 29 Oct 2011 05:14:02 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by mx1.freebsd.org (Postfix) with ESMTP id 3FE2B8FC08 for ; Sat, 29 Oct 2011 05:14:01 +0000 (UTC) X-AuditID: 1209190d-b7f726d0000008d1-24-4eab8b98a8f5 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id D0.B6.02257.89B8BAE4; Sat, 29 Oct 2011 01:14:00 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id p9T5E0bH025180; Sat, 29 Oct 2011 01:14:00 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p9T5Dwo2026796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 29 Oct 2011 01:14:00 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id p9T5Dwhp015442; Sat, 29 Oct 2011 01:13:58 -0400 (EDT) Date: Sat, 29 Oct 2011 01:13:58 -0400 (EDT) From: Benjamin Kaduk To: Chuck Burns In-Reply-To: <201110272148.15459.break19@gmail.com> Message-ID: References: <201110272148.15459.break19@gmail.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrDuje7Wfwav9hhbL1t9msZjz5gOT A5PHjE/zWTx2zrrLHsAUxWWTkpqTWZZapG+XwJWx5cox9oKJrBUP9jezNDC2s3QxcnJICJhI nH47mxXCFpO4cG89WxcjF4eQwD5GiflNl1khnA2MEn9/PYXKHGCSOHv4HQuE08AoceZyDxNI P4uAtsT9T5vA5rIJqEjMfLORDcQWEVCWaP3VxQ5iMwvIS/y/chmsXlhAX2LHr3tgNqeAscTb zz1gNbwC9hK/1/0DsjmAFhhJPLkUABIWFdCRWL1/CgtEiaDEyZlPWCBGWkr8W/uLdQKj4Cwk qVlIUgsYmVYxyqbkVunmJmbmFKcm6xYnJ+blpRbpGunlZpbopaaUbmIEh6ok7w7GdweVDjEK cDAq8fC+e7jKT4g1say4MvcQoyQHk5Io75uu1X5CfEn5KZUZicUZ8UWlOanFhxglOJiVRHhf PAYq501JrKxKLcqHSUlzsCiJ8xbucPATEkhPLEnNTk0tSC2CycpwcChJ8H4BGSpYlJqeWpGW mVOCkGbi4AQZzgM0fANIDW9xQWJucWY6RP4Uo6KUOG8bSEIAJJFRmgfXC0slrxjFgV4R5n0N UsUDTENw3a+ABjMBDZb8vwJkcEkiQkqqgTHcaifbr7SOORXC8RZ3O+MqkpU6uSplzThmsnDx /DcL3zdLjcMr8v/n7AmLChT8bk/azs/bsTXjpGeZ5IEb+etLbHUeLT1h8qw5ubFbME3puW7A 5PR7X/TebRXv9Y+5OntBdX/EPM6c+dFPi6y+JO6ZJbBCsv6pnsDPRC0FX6a2FO+F/8UMlViK MxINtZiLihMBpC9/8gADAAA= Cc: freebsd-current@freebsd.org Subject: Re: make installworld fails on releng9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Oct 2011 05:14:02 -0000 On Thu, 27 Oct 2011, Chuck Burns wrote: > I had some issues while running make installworld after I sync'd to the latest > releng9, on my RC1 install. > > Now, it appears to failed, while trying to create some links, > chfn > chsh > ypchpass > ypchfn > ypchsh. > > These are supposed to be hardlinked to /usr/bin/chpass, except that, since the > other files already exist, and are immutable, make installworld was unable to > do anything, so I wound up removing the immutable flag on these files and re- > running make installworld. Are you running installworld in single-user mode? What is the value of kern.securelevel? -Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 05:34:28 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 755F6106566B; Sat, 29 Oct 2011 05:34:28 +0000 (UTC) (envelope-from mueller6727@bellsouth.net) Received: from fmailhost04.isp.att.net (fmailhost04.isp.att.net [207.115.11.54]) by mx1.freebsd.org (Postfix) with ESMTP id 601738FC0C; Sat, 29 Oct 2011 05:34:28 +0000 (UTC) Date: Sat, 29 Oct 2011 05:29:02 +0000 (GMT) X-Comment: Sending client does not conform to RFC822 minimum requirements X-Comment: Date has been added by Maillennium Received: from localhost (adsl-68-18-111-140.sdf.bellsouth.net[68.18.111.140]) by isp.att.net (frfwmhc04) with SMTP id <20111029052900H0400ir9roe>; Sat, 29 Oct 2011 05:29:01 +0000 X-Originating-IP: [68.18.111.140] From: "Thomas Mueller" To: freebsd-current@freebsd.org References: <20111027102208.88BFB106564A@hub.freebsd.org> <4EAA85FD.1060805@infracaninophile.co.uk> <4EAB5823.5090804@FreeBSD.org> Message-Id: <20111029053428.755F6106566B@hub.freebsd.org> 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: Sat, 29 Oct 2011 05:34:28 -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 Sat Oct 29 06:05:44 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08B62106566B; Sat, 29 Oct 2011 06:05: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 C85E18FC16; Sat, 29 Oct 2011 06:05:43 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9T65gFp019650; Sat, 29 Oct 2011 02:05:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9T65gxQ019633; Sat, 29 Oct 2011 06:05:42 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 29 Oct 2011 06:05:42 GMT Message-Id: <201110290605.p9T65gxQ019633@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 06:05:44 -0000 TB --- 2011-10-29 03:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-29 03:10:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-10-29 03:10:00 - cleaning the object tree TB --- 2011-10-29 03:10:55 - cvsupping the source tree TB --- 2011-10-29 03:10:55 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-10-29 03:11:08 - building world TB --- 2011-10-29 03:11:08 - CROSS_BUILD_TESTING=YES TB --- 2011-10-29 03:11:08 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-29 03:11:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-29 03:11:08 - SRCCONF=/dev/null TB --- 2011-10-29 03:11:08 - TARGET=amd64 TB --- 2011-10-29 03:11:08 - TARGET_ARCH=amd64 TB --- 2011-10-29 03:11:08 - TZ=UTC TB --- 2011-10-29 03:11:08 - __MAKE_CONF=/dev/null TB --- 2011-10-29 03:11:08 - cd /src TB --- 2011-10-29 03:11:08 - /usr/bin/make -B buildworld >>> World build started on Sat Oct 29 03:11:08 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Oct 29 05:49:36 UTC 2011 TB --- 2011-10-29 05:49:36 - generating LINT kernel config TB --- 2011-10-29 05:49:36 - cd /src/sys/amd64/conf TB --- 2011-10-29 05:49:36 - /usr/bin/make -B LINT TB --- 2011-10-29 05:49:36 - cd /src/sys/amd64/conf TB --- 2011-10-29 05:49:36 - /usr/sbin/config -m LINT-NOINET TB --- 2011-10-29 05:49:36 - building LINT-NOINET kernel TB --- 2011-10-29 05:49:36 - CROSS_BUILD_TESTING=YES TB --- 2011-10-29 05:49:36 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-29 05:49:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-29 05:49:36 - SRCCONF=/dev/null TB --- 2011-10-29 05:49:36 - TARGET=amd64 TB --- 2011-10-29 05:49:36 - TARGET_ARCH=amd64 TB --- 2011-10-29 05:49:36 - TZ=UTC TB --- 2011-10-29 05:49:36 - __MAKE_CONF=/dev/null TB --- 2011-10-29 05:49:36 - cd /src TB --- 2011-10-29 05:49:36 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Sat Oct 29 05:49:36 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT-NOINET /usr/local/bin/svnversion cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue vers.c linking kernel ia32_syscall.o:(.bss+0x0): multiple definition of `systrace_probe_func' trap.o:(.bss+0x0): first defined here *** Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT-NOINET. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-10-29 06:05:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-29 06:05:42 - ERROR: failed to build LINT-NOINET kernel TB --- 2011-10-29 06:05:42 - 8280.03 user 1574.38 system 10541.34 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 11:22:48 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEF1B1065672; Sat, 29 Oct 2011 11:22:47 +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 AA4028FC19; Sat, 29 Oct 2011 11:22:47 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9TBMklu070973; Sat, 29 Oct 2011 07:22:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9TBMkcW070968; Sat, 29 Oct 2011 11:22:46 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 29 Oct 2011 11:22:46 GMT Message-Id: <201110291122.p9TBMkcW070968@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 11:22:48 -0000 TB --- 2011-10-29 08:30:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-29 08:30:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-10-29 08:30:00 - cleaning the object tree TB --- 2011-10-29 08:30:30 - cvsupping the source tree TB --- 2011-10-29 08:30:30 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-10-29 08:31:16 - building world TB --- 2011-10-29 08:31:16 - CROSS_BUILD_TESTING=YES TB --- 2011-10-29 08:31:16 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-29 08:31:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-29 08:31:16 - SRCCONF=/dev/null TB --- 2011-10-29 08:31:16 - TARGET=amd64 TB --- 2011-10-29 08:31:16 - TARGET_ARCH=amd64 TB --- 2011-10-29 08:31:16 - TZ=UTC TB --- 2011-10-29 08:31:16 - __MAKE_CONF=/dev/null TB --- 2011-10-29 08:31:16 - cd /src TB --- 2011-10-29 08:31:16 - /usr/bin/make -B buildworld >>> World build started on Sat Oct 29 08:31:17 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Oct 29 11:06:59 UTC 2011 TB --- 2011-10-29 11:06:59 - generating LINT kernel config TB --- 2011-10-29 11:06:59 - cd /src/sys/amd64/conf TB --- 2011-10-29 11:06:59 - /usr/bin/make -B LINT TB --- 2011-10-29 11:06:59 - cd /src/sys/amd64/conf TB --- 2011-10-29 11:06:59 - /usr/sbin/config -m LINT-NOINET TB --- 2011-10-29 11:06:59 - building LINT-NOINET kernel TB --- 2011-10-29 11:06:59 - CROSS_BUILD_TESTING=YES TB --- 2011-10-29 11:06:59 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-29 11:06:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-29 11:06:59 - SRCCONF=/dev/null TB --- 2011-10-29 11:06:59 - TARGET=amd64 TB --- 2011-10-29 11:06:59 - TARGET_ARCH=amd64 TB --- 2011-10-29 11:06:59 - TZ=UTC TB --- 2011-10-29 11:06:59 - __MAKE_CONF=/dev/null TB --- 2011-10-29 11:06:59 - cd /src TB --- 2011-10-29 11:06:59 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Sat Oct 29 11:07:00 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT-NOINET /usr/local/bin/svnversion cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue vers.c linking kernel ia32_syscall.o:(.bss+0x0): multiple definition of `systrace_probe_func' trap.o:(.bss+0x0): first defined here *** Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT-NOINET. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-10-29 11:22:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-29 11:22:46 - ERROR: failed to build LINT-NOINET kernel TB --- 2011-10-29 11:22:46 - 8105.64 user 1544.57 system 10365.60 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 12:19:56 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E409D1065672 for ; Sat, 29 Oct 2011 12:19:56 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id A2DC28FC0C for ; Sat, 29 Oct 2011 12:19:56 +0000 (UTC) Received: by ggnq2 with SMTP id q2so5903162ggn.13 for ; Sat, 29 Oct 2011 05:19:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding:content-type; bh=OcSLGpNLeIw3bIC0Kk7By/Eqspif5pESUCs61CHbsAI=; b=tJ3rYC8cCgFc1y/598pMGQfO6xu03QwD50ib1tUX7jqfvjXt0Q+gIXnUacPFDX4QUe XMy8soRqrrf78O+iSB27Z5p4VK6ydl166BH8TsRGNVCIJaxK2y+9V5bbGK7WYfScdfy+ dmCiz4eakkgBg1FVq+bYQr1xn9PEKFC+2oQvs= Received: by 10.150.53.4 with SMTP id b4mr5809899yba.42.1319890795788; Sat, 29 Oct 2011 05:19:55 -0700 (PDT) Received: from beastiefree.localnet (c-98-230-65-110.hsd1.al.comcast.net. [98.230.65.110]) by mx.google.com with ESMTPS id b20sm33427719anb.11.2011.10.29.05.19.54 (version=SSLv3 cipher=OTHER); Sat, 29 Oct 2011 05:19:55 -0700 (PDT) From: Chuck Burns To: Benjamin Kaduk Date: Sat, 29 Oct 2011 07:19:41 -0500 Message-ID: <7778873.vO2TIhRvIe@beastiefree> User-Agent: KMail/4.7.2 (FreeBSD/9.0-RC1; KDE/4.7.2; amd64; ; ) In-Reply-To: References: <201110272148.15459.break19@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: freebsd-current@freebsd.org Subject: Re: make installworld fails on releng9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Oct 2011 12:19:57 -0000 On Saturday, October 29, 2011 1:13:58 AM Benjamin Kaduk wrote: > > Are you running installworld in single-user mode? > What is the value of kern.securelevel? > > -Ben Kaduk Yes, I was running in single-user mode, and kern.securelevel was never modified, and is currently showing as "-1" Also, I am running zfs root, if that makes a difference -- Chuck Burns ======== "We have the right as individuals to give away as much of our own money as we please in charity; but as members of Congress we have no right to appropriate a dollar of the public money." - Davy Crockett From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 14:00:01 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84488106564A for ; Sat, 29 Oct 2011 14:00:01 +0000 (UTC) (envelope-from david.marec@davenulle.org) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.118]) by mx1.freebsd.org (Postfix) with ESMTP id 3E0E98FC15 for ; Sat, 29 Oct 2011 14:00:00 +0000 (UTC) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2518.sfr.fr (SMTP Server) with ESMTP id 441E9700013B for ; Sat, 29 Oct 2011 15:44:30 +0200 (CEST) Received: from david.marec (209.103.28.93.rev.sfr.net [93.28.103.209]) by msfrf2518.sfr.fr (SMTP Server) with ESMTP id 20FE47000134 for ; Sat, 29 Oct 2011 15:44:30 +0200 (CEST) X-SFR-UUID: 20111029134430135.20FE47000134@msfrf2518.sfr.fr Message-ID: <4EAC033E.6010201@davenulle.org> Date: Sat, 29 Oct 2011 15:44:30 +0200 From: David Marec User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111002 Thunderbird/7.0.1 MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: [9.0-RC1 FreeBSD] [amd64] buildworld fails on building lib/libss with CLANG X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 14:00:01 -0000 hi list, Running FreebSD 9.0 RC-1, the "make buildworld" processing failed on the following error on its attempt to build 'lib/libssp': ===> gnu/lib/libssp/libssp_nonshared (obj,depend,all,install) rm -f .depend CC='clang' mkdep -f .depend -a -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libssp/libs sp_nonshared/.. -I/usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/g cclibs/libssp -I/usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcc libs/include -DPIC /usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/ gcclibs/libssp/ssp-local.c clang -O2 -pipe -march=native -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libssp/libssp_n onshared/.. -I/usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gccl ibs/libssp -I/usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gccli bs/include -fPIC -DPIC -fvisibility=hidden -std=gnu99 -fstack-protector -c /usr /src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp/ssp-loca l.c error: unknown target CPU 'amdfam10' *** Error code 1 Stop in /usr/src/gnu/lib/libssp/libssp_nonshared. *** Error code 1 The sources files were updated yesterday evening. I did not try to process this with gcc yet. -- David Marec, mailto:david.marec@davenulle.org http://user.lamaiziere.net/david/Site http://www.diablotins.org/ From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 14:10:48 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 430F3106567A for ; Sat, 29 Oct 2011 14:10:48 +0000 (UTC) (envelope-from david.marec@davenulle.org) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by mx1.freebsd.org (Postfix) with ESMTP id F33C48FC17 for ; Sat, 29 Oct 2011 14:10:47 +0000 (UTC) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2102.sfr.fr (SMTP Server) with ESMTP id 2A71D700005C; Sat, 29 Oct 2011 16:10:46 +0200 (CEST) Received: from david.marec (209.103.28.93.rev.sfr.net [93.28.103.209]) by msfrf2102.sfr.fr (SMTP Server) with ESMTP id F00A370000BE; Sat, 29 Oct 2011 16:10:45 +0200 (CEST) X-SFR-UUID: 20111029141045983.F00A370000BE@msfrf2102.sfr.fr Message-ID: <4EAC0966.2050607@davenulle.org> Date: Sat, 29 Oct 2011 16:10:46 +0200 From: David Marec User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111002 Thunderbird/7.0.1 MIME-Version: 1.0 To: current@freebsd.org, freebsd-usb@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: [Freebsd 9] [amd64] [USB] [HPLIP] what's the (new) right way to manage hplip usb-plugged printers, running Freebsd 9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-usb@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: Sat, 29 Oct 2011 14:10:48 -0000 Hi list, While I was running Freebsd 8, I used to set the suitable rights for my hplip printer, plugged via usb, in this way: * ulpt removed from the kernel. * scripting /etc/devd.conf, to catch usb printers events, as follows: attach 10 { # device-name "ugen[0-9]+"; match "vendor" "0x03f0"; match "product" "0x4712"; # action "logger Chalut la foule"; action "/root/sbin/ugen-hdle $device-name"; }; with david:~>less /root/sbin/ugen-hdle #!/bin/sh echo "Printer detected on " $1 dev=`echo $1 | /usr/bin/awk 'BEGIN { } { s = substr($0, 5, 99); } END { print s; }'` # echo "setting suitable rights for " $dev /usr/sbin/chown cups:hplip /dev/usb/$dev.[0-9] /bin/chmod g+rw /dev/usb/$dev.[0-9] But, now running FreeBSD 9, I get new usb/devd behavior issues. First, the ulpt module is always loaded. Is there any elegant way to get rid of this 'self loading' behavior, except to remove it from /boot/modules ? Anyway, it sounds like HPLIP is now working with the ulpt module loaded. But, devd never sets the suitable rights on ugen. Moreover, switching to the 'action' that only logs something, reveals that devd never executes this entry. So, what's should be the news group&user's rights required by HPLIP/cups on FreeBSD 9 ? And, how to handle them with devd ? However, there is a new "devd" directory inside of "/etc". Is there new usb&devd procedures for FreeBSD9 ? [fu2 freebsd-usb@freebsd.org] regards -- David Marec, mailto:david.marec@davenulle.org http://user.lamaiziere.net/david/Site http://www.diablotins.org/ From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 16:22:31 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 267AF1065672 for ; Sat, 29 Oct 2011 16:22:31 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id DE6DE8FC16 for ; Sat, 29 Oct 2011 16:22:30 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:89e1:b26d:b9ae:d0c1] (unknown [IPv6:2001:7b8:3a7:0:89e1:b26d:b9ae:d0c1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 1A18D5C37; Sat, 29 Oct 2011 18:22:30 +0200 (CEST) Message-ID: <4EAC284A.4000001@FreeBSD.org> Date: Sat, 29 Oct 2011 18:22:34 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111019 Thunderbird/8.0 MIME-Version: 1.0 To: David Marec References: <4EAC033E.6010201@davenulle.org> In-Reply-To: <4EAC033E.6010201@davenulle.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: [9.0-RC1 FreeBSD] [amd64] buildworld fails on building lib/libss with CLANG X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 16:22:31 -0000 On 2011-10-29 15:44, David Marec wrote: > Running FreebSD 9.0 RC-1, the "make buildworld" processing failed on the > following error on its attempt to build 'lib/libssp': > > ===> gnu/lib/libssp/libssp_nonshared (obj,depend,all,install) > rm -f .depend > CC='clang' mkdep -f .depend -a -DHAVE_CONFIG_H > -I/usr/src/gnu/lib/libssp/libs > sp_nonshared/.. > -I/usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/g > cclibs/libssp > -I/usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcc > libs/include -DPIC > /usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/ > gcclibs/libssp/ssp-local.c > clang -O2 -pipe -march=native -DHAVE_CONFIG_H > -I/usr/src/gnu/lib/libssp/libssp_n > onshared/.. > -I/usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gccl > ibs/libssp > -I/usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gccli > bs/include -fPIC -DPIC -fvisibility=hidden -std=gnu99 -fstack-protector > -c /usr > /src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp/ssp-loca > l.c > error: unknown target CPU 'amdfam10' > *** Error code 1 > > Stop in /usr/src/gnu/lib/libssp/libssp_nonshared. > *** Error code 1 I think the problem is caused by using CPUTYPE=native in make.conf. Is that what you are using? If so, please add DEBUG_FLAGS=-v to your make command line, log the whole thing, and upload the log somewhere. (Don't post it to the list, because it will probably be very large.) From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 16:43:46 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 616AF1065670; Sat, 29 Oct 2011 16:43:46 +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 34BB28FC19; Sat, 29 Oct 2011 16:43:45 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9TGhjo4032957; Sat, 29 Oct 2011 12:43:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9TGhjus032872; Sat, 29 Oct 2011 16:43:45 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 29 Oct 2011 16:43:45 GMT Message-Id: <201110291643.p9TGhjus032872@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 16:43:46 -0000 TB --- 2011-10-29 13:50:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-29 13:50:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-10-29 13:50:00 - cleaning the object tree TB --- 2011-10-29 13:50:34 - cvsupping the source tree TB --- 2011-10-29 13:50:34 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-10-29 13:50:46 - building world TB --- 2011-10-29 13:50:46 - CROSS_BUILD_TESTING=YES TB --- 2011-10-29 13:50:46 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-29 13:50:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-29 13:50:46 - SRCCONF=/dev/null TB --- 2011-10-29 13:50:46 - TARGET=amd64 TB --- 2011-10-29 13:50:46 - TARGET_ARCH=amd64 TB --- 2011-10-29 13:50:46 - TZ=UTC TB --- 2011-10-29 13:50:46 - __MAKE_CONF=/dev/null TB --- 2011-10-29 13:50:46 - cd /src TB --- 2011-10-29 13:50:46 - /usr/bin/make -B buildworld >>> World build started on Sat Oct 29 13:50:47 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Oct 29 16:27:37 UTC 2011 TB --- 2011-10-29 16:27:37 - generating LINT kernel config TB --- 2011-10-29 16:27:37 - cd /src/sys/amd64/conf TB --- 2011-10-29 16:27:37 - /usr/bin/make -B LINT TB --- 2011-10-29 16:27:37 - cd /src/sys/amd64/conf TB --- 2011-10-29 16:27:37 - /usr/sbin/config -m LINT-NOINET TB --- 2011-10-29 16:27:37 - building LINT-NOINET kernel TB --- 2011-10-29 16:27:37 - CROSS_BUILD_TESTING=YES TB --- 2011-10-29 16:27:37 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-29 16:27:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-29 16:27:37 - SRCCONF=/dev/null TB --- 2011-10-29 16:27:37 - TARGET=amd64 TB --- 2011-10-29 16:27:37 - TARGET_ARCH=amd64 TB --- 2011-10-29 16:27:37 - TZ=UTC TB --- 2011-10-29 16:27:37 - __MAKE_CONF=/dev/null TB --- 2011-10-29 16:27:37 - cd /src TB --- 2011-10-29 16:27:37 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Sat Oct 29 16:27:38 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT-NOINET /usr/local/bin/svnversion cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue vers.c linking kernel ia32_syscall.o:(.bss+0x0): multiple definition of `systrace_probe_func' trap.o:(.bss+0x0): first defined here *** Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT-NOINET. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-10-29 16:43:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-29 16:43:44 - ERROR: failed to build LINT-NOINET kernel TB --- 2011-10-29 16:43:44 - 8179.45 user 1565.64 system 10423.47 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 17:15:57 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A974106566C for ; Sat, 29 Oct 2011 17:15:57 +0000 (UTC) (envelope-from david.marec@davenulle.org) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.4]) by mx1.freebsd.org (Postfix) with ESMTP id 5A8678FC0C for ; Sat, 29 Oct 2011 17:15:56 +0000 (UTC) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2117.sfr.fr (SMTP Server) with ESMTP id A28687000110; Sat, 29 Oct 2011 19:15:55 +0200 (CEST) Received: from david.marec (209.103.28.93.rev.sfr.net [93.28.103.209]) by msfrf2117.sfr.fr (SMTP Server) with ESMTP id 7591D7000105; Sat, 29 Oct 2011 19:15:55 +0200 (CEST) X-SFR-UUID: 20111029171555481.7591D7000105@msfrf2117.sfr.fr Message-ID: <4EAC34CC.4050906@davenulle.org> Date: Sat, 29 Oct 2011 19:15:56 +0200 From: David Marec User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111002 Thunderbird/7.0.1 MIME-Version: 1.0 To: current@freebsd.org References: <4EAC033E.6010201@davenulle.org> <4EAC284A.4000001@FreeBSD.org> In-Reply-To: <4EAC284A.4000001@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Dimitry Andric Subject: Re: [9.0-RC1 FreeBSD] [amd64] buildworld fails on building lib/libss with CLANG X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 17:15:57 -0000 Le 29.10.2011 18:22, Dimitry Andric a écrit : > I think the problem is caused by using CPUTYPE=native in make.conf. Is > that what you are using? True. / Anyone, feel free to suggest a better configuration to build an `amd64`'s world && kernel with the help of CLANG? / > If so, please add DEBUG_FLAGS=-v to your make command line, log the > whole thing, It's done. > and upload the log somewhere. (Don't post it to the list, > because it will probably be very large.) The file is available under the following link: http://user.lamaiziere.net/david/bsd/typescript -- David Marec, mailto:david.marec@davenulle.org http://user.lamaiziere.net/david/Site http://www.diablotins.org/ From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 18:24:54 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9447F106567B for ; Sat, 29 Oct 2011 18:24:54 +0000 (UTC) (envelope-from bsdboot@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5F5428FC14 for ; Sat, 29 Oct 2011 18:24:54 +0000 (UTC) Received: by iaky10 with SMTP id y10so8229043iak.13 for ; Sat, 29 Oct 2011 11:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RbZxGr9ZNkxdo4q0CPUhFdcbDaK1dtyu0UKfTuBvluU=; b=D6v7JE3j5XSarOB7tJ0RPxdeiu9Zjc9MLugEFOKI1GdboReOZtw0k+E3CrRcClFtr7 6UIsaiAiNopB6CRDK5rX29jLQjd7Ahz47sDEobgGX9OuZyu2AQPbr/SsQjDxdq7fpZdh cboeF45hQ8I+jSToWdmDbwl5RjVijedTGeQig= MIME-Version: 1.0 Received: by 10.42.148.198 with SMTP id s6mr5330478icv.55.1319912693761; Sat, 29 Oct 2011 11:24:53 -0700 (PDT) Received: by 10.50.15.234 with HTTP; Sat, 29 Oct 2011 11:24:53 -0700 (PDT) In-Reply-To: <1319835183.2664.12.camel@hitfishpass-lx.corp.yahoo.com> References: <1319835183.2664.12.camel@hitfishpass-lx.corp.yahoo.com> Date: Sat, 29 Oct 2011 23:54:53 +0530 Message-ID: From: Penta Upa To: Sean Bruno Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-current@freebsd.org" Subject: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 18:24:54 -0000 I created a bug report since there wasn't a response to this email. http://www.freebsd.org/cgi/query-pr.cgi?pr=161887 The test code is attached to the bug report. Regards, Penta On Sat, Oct 29, 2011 at 2:23 AM, Sean Bruno wrote: > On Fri, 2011-10-21 at 08:25 -0700, Penta Upa wrote: > > > Attached is a test module (vmtest) and the makefile used. Uname output > from > > the system is > > I only see a Makefile attached here. Can you attach the code you are > using? > > Sean > > From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 19:58:55 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94CC61065673; Sat, 29 Oct 2011 19:58:55 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 34B978FC18; Sat, 29 Oct 2011 19:58:55 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 686A1358C5A; Sat, 29 Oct 2011 21:58:53 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 446A228468; Sat, 29 Oct 2011 21:58:53 +0200 (CEST) Date: Sat, 29 Oct 2011 21:58:53 +0200 From: Jilles Tjoelker To: freebsd-usb@freebsd.org Message-ID: <20111029195852.GA90408@stack.nl> References: <4EAC0966.2050607@davenulle.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EAC0966.2050607@davenulle.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org Subject: Re: [Freebsd 9] [amd64] [USB] [HPLIP] what's the (new) right way to manage hplip usb-plugged printers, running Freebsd 9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Oct 2011 19:58:55 -0000 On Sat, Oct 29, 2011 at 04:10:46PM +0200, David Marec wrote: > So, what's should be the news group&user's rights required by HPLIP/cups > on FreeBSD 9 ? > And, how to handle them with devd ? Use devfs rules. Pasting from http://www.stack.nl/~jilles/unix/freebsd-devfs.txt Create or edit /etc/devfs.rules and put something like this in it: [devfsrules_mybox=10] add path 'fd0*' mode 660 See man 8 devfs for more information. Then put in /etc/rc.conf devfs_system_ruleset="devfsrules_mybox" If you want to edit other /dev mountpoints (e.g. for jails) use something like devfs_set_rulesets="/usr/jails/jail1/dev=devfsrules_jail1 /usr/jails/jail2/dev=devfsrules_jail2" -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 21:26:30 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18D441065670 for ; Sat, 29 Oct 2011 21:26:30 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id D12AE8FC08 for ; Sat, 29 Oct 2011 21:26:29 +0000 (UTC) Received: by qyg14 with SMTP id 14so6382534qyg.13 for ; Sat, 29 Oct 2011 14:26:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=VkL2dfbPUZ2//qB4q2rJ++x8YAwXwO+FiggNv42v4JQ=; b=cJO3dycV4i+VaQkGaDPitQKm4xxxmSC+e96FzETkovyuY5CiW3eE9FnthyVWgWMdF6 FTOUIS3McJSCebN6zsLX2YPugHs209i5Gu7Hk3CumZTXVxs2ggGBCoX4+/Px4dyjOD2P m7w0ShlEPJOhIhRgPsy+bTyVRW8OaZZbXEijM= MIME-Version: 1.0 Received: by 10.229.92.2 with SMTP id p2mr1876496qcm.222.1319923589300; Sat, 29 Oct 2011 14:26:29 -0700 (PDT) Received: by 10.229.226.65 with HTTP; Sat, 29 Oct 2011 14:26:29 -0700 (PDT) Date: Sat, 29 Oct 2011 23:26:29 +0200 Message-ID: From: "deeptech71@gmail.com" To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: lockup during probing because of a memory stick X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Oct 2011 21:26:30 -0000 If a USB mass storage device was connected when the computer was turned on or reset and the device is left connected, then the system locks up somewhere around the ``acpi0: on motherboard'' line (not exactly deterministically at that line). Otherwise (if the device is connected or disconnected just before FreeBSD started booting, or if the device is nowhere near the computer for the whole booting process), the system boots fine. I'm using a -CURRENT kernel. I don't recall this case happening some time ago. But now, this happens with and without the NEW_PCIB option. I mention this because ``acpi0: on motherboard'' is shortly followed by ``acpi0: reservation of 0, a0000 (3) failed'', whatever that means. From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 21:31:18 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7734106564A for ; Sat, 29 Oct 2011 21:31:18 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 4D98B8FC0C for ; Sat, 29 Oct 2011 21:31:18 +0000 (UTC) Received: by qyk35 with SMTP id 35so3540122qyk.13 for ; Sat, 29 Oct 2011 14:31:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=gsgZj52QdOvLQSAFCqfqYLGTaQFOisiM0KadoCgtgp0=; b=nrLDru6G7MYYElu9D1kKApvs3f6P1XG26v7iZ/U8G5XREl2PW0BCLaRuf9GAZwC52E AbThyvgR3OW9uWoE0GlLjLqq8egfOjyQFbVeqaJ0JxEE7TRZIoOPbCPw4A/Di64qOI4b ZRSNIxl5GKnmSzkzwgJSfuKLgtihYY46T7kyk= MIME-Version: 1.0 Received: by 10.229.65.70 with SMTP id h6mr466733qci.146.1319923877399; Sat, 29 Oct 2011 14:31:17 -0700 (PDT) Received: by 10.229.226.65 with HTTP; Sat, 29 Oct 2011 14:31:17 -0700 (PDT) In-Reply-To: References: Date: Sat, 29 Oct 2011 23:31:17 +0200 Message-ID: From: "deeptech71@gmail.com" To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: lockup during probing because of a memory stick X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Oct 2011 21:31:18 -0000 Spam: ========== ``dmesg'' begins ========== Copyright (c) 1992-2011 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 #0 r226900M: Sat Oct 29 19:06:59 CEST 2011 devhc@:/usr/obj/usr/src/sys/HQ i386 CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2798.72-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Family = f Model = 2 Stepping = 9 Features=0xbfebfbff Features2=0x4400 real memory = 536870912 (512 MB) avail memory = 513859584 (490 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 HTT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 ioapic0 irqs 0-23 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 1fef0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xd000-0xd0ff mem 0xd0000000-0xdfffffff,0xf7ee0000-0xf7eeffff irq 16 at device 0.0 on pci1 drm0: on vgapci0 info: [drm] AGP at 0xf8000000 64MB info: [drm] Initialized radeon 1.31.0 20080613 vgapci1: mem 0xe0000000-0xefffffff,0xf7ef0000-0xf7efffff at device 0.1 on pci1 uhci0: port 0xc880-0xc89f irq 16 at device 29.0 on pci0 usbus0: on uhci0 uhci1: port 0xcc00-0xcc1f irq 19 at device 29.1 on pci0 usbus1: on uhci1 ehci0: mem 0xf7dffc00-0xf7dfffff irq 23 at device 29.7 on pci0 usbus2: EHCI version 1.0 usbus2: on ehci0 pcib2: at device 30.0 on pci0 pcib2: failed to allocate initial memory window: 0xf7f00000-0xfbffffff pci2: on pcib2 skc0: <3Com 3C940 Gigabit Ethernet> port 0xe800-0xe8ff mem 0xf7ffc000-0xf7ffffff irq 22 at device 5.0 on pci2 skc0: 3Com Gigabit LOM (3C940) rev. (0x1) sk0: on skc0 sk0: Ethernet address: 00:0e:a6:35:15:91 miibus0: on sk0 e1000phy0: PHY 0 on miibus0 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto pcm0: port 0xec00-0xec3f irq 20 at device 12.0 on pci2 pcm0: pcm0: isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] pmtimer0 on isa0 orm0: at iomem 0xc0000-0xccfff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 p4tcc0: on cpu0 p4tcc1: on cpu1 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ata1: DMA limited to UDMA33, controller found non-ATA66 cable ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: ATA-7 device ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) ada0: 78167MB (160086528 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 cd0 at ata1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present SMP: AP CPU #1 Launched! GEOM: ada0s1: geometry does not match label (255h,63s != 16h,63s). Root mount waiting for: usbus2 usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered Root mount waiting for: usbus2 uhub2: 4 ports with 4 removable, self powered Root mount waiting for: usbus2 ugen2.2: at usbus2 umass0: on usbus2 Trying to mount root from ufs:/dev/ada0s1a [rw,noatime]... da0 at umass-sim0 bus 0 scbus2 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 1955MB (4005886 512 byte sectors: 255H 63S/T 249C) ugen0.2: at usbus0 ums0: on usbus0 ums0: 5 buttons and [XYZT] coordinates ID=1 sk0: link state changed to UP ========== ``dmesg'' ends ========== ========== ``devinfo -u'' begins ========== Interrupt request lines: 0 (attimer0) 1 (atkbdc0) 3-7 (root0) 8 (atrtc0) 9 (acpi0) 10-13 (root0) 14 (ata0) 15 (ata1) 16 (uhci0) 16 (vgapci0) 17-18 (root0) 19 (uhci1) 20 (pcm0) 21 (root0) 22 (skc0) 23 (ehci0) DMA request lines: 0-3 (root0) 4 (atdma0) 5-7 (root0) I/O ports: 0x0-0xf (atdma0) 0x10-0x1f (acpi0) 0x20-0x21 (atpic0) 0x22-0x3f (acpi0) 0x40-0x43 (attimer0) 0x44-0x5f (acpi0) 0x60 (atkbdc0) 0x61 ---- 0x62-0x63 (acpi0) 0x64 (atkbdc0) 0x65-0x6f (acpi0) 0x70-0x71 (atrtc0) 0x72-0x7f (acpi0) 0x80 (acpi0) 0x81-0x83 (atdma0) 0x84-0x86 (acpi0) 0x87 (atdma0) 0x88 (acpi0) 0x89-0x8b (atdma0) 0x8c-0x8e (acpi0) 0x8f (atdma0) 0x90-0x9f (acpi0) 0xa0-0xa1 (atpic0) 0xa2-0xbf (acpi0) 0xc0-0xdf (atdma0) 0xe0-0xef (acpi0) 0xf0-0xff (npxisa0) 0x100-0x16f (root0) 0x170-0x177 (atapci0) 0x178-0x1ef (root0) 0x1f0-0x1f7 (atapci0) 0x1f8-0x28f (root0) 0x290-0x297 (acpi0) 0x298-0x375 (root0) 0x376 (atapci0) 0x377-0x3bf (root0) 0x3c0-0x3df (vga0) 0x3e0-0x3f5 (root0) 0x3f6 (atapci0) 0x3f7-0x3ff (root0) 0x400-0x41f ---- 0x420-0x47f (root0) 0x480-0x4bf (acpi0) 0x4c0-0x4cf (root0) 0x4d0-0x4d1 (acpi0) 0x4d2-0x67f (root0) 0x680-0x6ff (acpi0) 0x700-0x7ff (root0) 0x800-0x87f (acpi0) 0x880-0xcf7 (root0) 0xcf8-0xcff (pcib0) 0xd00-0xc87f (root0) 0xc880-0xc89f (uhci0) 0xc8a0-0xcbff (root0) 0xcc00-0xcc1f (uhci1) 0xcc20-0xcfff (root0) 0xd000-0xdfff (pcib1) 0xe000-0xefff (pcib2) 0xf000-0xfbff (root0) 0xfc00-0xfc0f (atapci0) 0xfc10-0xffff (root0) I/O memory addresses: 0x0-0x9fbff (ram0) 0x9fc00-0x9ffff (root0) 0xa0000-0xbffff (vga0) 0xc0000-0xdffff (acpi0) 0xe0000-0xfffff (acpi0) 0x100000-0x1ff2ffff (ram0) 0x1ff30000-0xcfffffff (root0) 0xd0000000-0xf6ffffff (pcib1) 0xf7000000-0xf7dffbff (root0) 0xf7dffc00-0xf7dfffff (ehci0) 0xf7e00000-0xf7efffff (pcib1) 0xf7f00000-0xf7ffffff (pcib2) 0xf8000000-0xfbffffff (hostb0) 0xfc000000-0xfebfffff (root0) 0xfec00000-0xfec00fff (acpi0) 0xfec01000-0xfed1ffff (root0) 0xfed20000-0xfed8ffff (acpi0) 0xfed90000-0xfedfffff (root0) 0xfee00000-0xfee00fff (acpi0) 0xfee01000-0xffafffff (root0) 0xffb00000-0xffbfffff (acpi0) 0xffc00000-0xffefffff (root0) 0xfff00000-0xffffffff (acpi0) ACPI I/O ports: 0x10-0x1f (root0) 0x22-0x3f (root0) 0x44-0x5f (root0) 0x62-0x63 (root0) 0x65-0x6f (root0) 0x72-0x80 (root0) 0x84-0x86 (root0) 0x88 (root0) 0x8c-0x8e (root0) 0x90-0x9f (root0) 0xa2-0xbf (root0) 0xe0-0xef (root0) 0x290-0x297 (root0) 0x480-0x4bf (root0) 0x4d0-0x4d1 (root0) 0x680-0x6ff (root0) 0x800-0x807 (root0) 0x808-0x80b (acpi_timer0) 0x80c-0x87f (root0) ACPI I/O memory addresses: 0xc0000-0xccfff (orm0) 0xcd000-0xfffff (root0) 0xfec00000-0xfec00fff (root0) 0xfed20000-0xfed8ffff (root0) 0xfee00000-0xfee00fff (root0) 0xffb00000-0xffbfffff (root0) 0xfff00000-0xffffffff (root0) pcib1 I/O port window: 0xd000-0xd0ff (vgapci0) 0xd100-0xdfff (root0) pcib1 memory window: 0xf7e00000-0xf7edffff (root0) 0xf7ee0000-0xf7eeffff (vgapci0) 0xf7ef0000-0xf7efffff (vgapci1) pcib1 prefetch window: 0xd0000000-0xdfffffff (vgapci0) 0xe0000000-0xefffffff (vgapci1) 0xf0000000-0xf6ffffff (root0) pcib2 I/O port window: 0xe000-0xe7ff (root0) 0xe800-0xe8ff (skc0) 0xe900-0xebff (root0) 0xec00-0xec3f (pcm0) 0xec40-0xefff (root0) pcib2 memory window: 0xf7f00000-0xf7ffbfff (root0) 0xf7ffc000-0xf7ffffff (skc0) pcib2 prefetch window: ========== ``devinfo -u'' ends ========== ========== ``devinfo -rv'' begins ========== nexus0 npx0 apic0 ram0 I/O memory addresses: 0x0-0x9fbff 0x100000-0x1ff2ffff acpi0 Interrupt request lines: 9 I/O ports: 0x10-0x1f 0x22-0x3f 0x44-0x5f 0x62-0x63 0x65-0x6f 0x72-0x7f 0x80 0x84-0x86 0x88 0x8c-0x8e 0x90-0x9f 0xa2-0xbf 0xe0-0xef 0x290-0x297 0x480-0x4bf 0x4d0-0x4d1 0x680-0x6ff 0x800-0x87f I/O memory addresses: 0xc0000-0xdffff 0xe0000-0xfffff 0xfec00000-0xfec00fff 0xfed20000-0xfed8ffff 0xfee00000-0xfee00fff 0xffb00000-0xffbfffff 0xfff00000-0xffffffff cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU1 p4tcc0 cpufreq0 cpu1 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU2 p4tcc1 cpufreq1 pcib0 pnpinfo _HID=PNP0A03 _UID=0 at handle=\_SB_.PCI0 I/O ports: 0xcf8-0xcff pci0 hostb0 pnpinfo vendor=0x8086 device=0x2570 subvendor=0x1043 subdevice=0x80f2 class=0x060000 at slot=0 function=0 I/O memory addresses: 0xf8000000-0xfbffffff agp0 pcib1 pnpinfo vendor=0x8086 device=0x2571 subvendor=0x0000 subdevice=0x0000 class=0x060400 at slot=1 function=0 handle=\_SB_.PCI0.P0P1 I/O ports: 0xd000-0xdfff I/O memory addresses: 0xd0000000-0xf6ffffff 0xf7e00000-0xf7efffff pci1 vgapci0 pnpinfo vendor=0x1002 device=0x4150 subvendor=0x17ee subdevice=0x2002 class=0x030000 at slot=0 function=0 Interrupt request lines: 16 pcib1 I/O port window: 0xd000-0xd0ff pcib1 memory window: 0xf7ee0000-0xf7eeffff pcib1 prefetch window: 0xd0000000-0xdfffffff vgapm0 drm0 vgapci1 pnpinfo vendor=0x1002 device=0x4170 subvendor=0x17ee subdevice=0x2003 class=0x038000 at slot=0 function=1 pcib1 memory window: 0xf7ef0000-0xf7efffff pcib1 prefetch window: 0xe0000000-0xefffffff drm1 uhci0 pnpinfo vendor=0x8086 device=0x24d2 subvendor=0x1043 subdevice=0x80a6 class=0x0c0300 at slot=29 function=0 handle=\_SB_.PCI0.USB1 Interrupt request lines: 16 I/O ports: 0xc880-0xc89f usbus0 uhub0 ums0 pnpinfo vendor=0x04fc product=0x0801 devclass=0x00 devsubclass=0x00 sernum="" release=0x1611 mode=host intclass=0x03 intsubclass=0x01 i at bus=1 hubaddr=2 port=0 devaddr=2 interface=0 uhci1 pnpinfo vendor=0x8086 device=0x24d4 subvendor=0x1043 subdevice=0x80a6 class=0x0c0300 at slot=29 function=1 handle=\_SB_.PCI0.USB2 Interrupt request lines: 19 I/O ports: 0xcc00-0xcc1f usbus1 uhub1 ehci0 pnpinfo vendor=0x8086 device=0x24dd subvendor=0x1043 subdevice=0x80a6 class=0x0c0320 at slot=29 function=7 handle=\_SB_.PCI0.EUSB Interrupt request lines: 23 I/O memory addresses: 0xf7dffc00-0xf7dfffff usbus2 uhub2 umass0 pnpinfo vendor=0x058f product=0x6387 devclass=0x00 devsubclass=0x00 sernum="8DA152V7" release=0x0141 mode=host intclass=0x08 intsubclas at bus=1 hubaddr=3 port=2 devaddr=2 interface=0 pcib2 pnpinfo vendor=0x8086 device=0x244e subvendor=0x0000 subdevice=0x0000 class=0x060400 at slot=30 function=0 handle=\_SB_.PCI0.P0P4 I/O ports: 0xe000-0xefff I/O memory addresses: 0xf7f00000-0xf7ffffff pci2 skc0 pnpinfo vendor=0x10b7 device=0x1700 subvendor=0x1043 subdevice=0x80eb class=0x020000 at slot=5 function=0 Interrupt request lines: 22 pcib2 I/O port window: 0xe800-0xe8ff pcib2 memory window: 0xf7ffc000-0xf7ffffff sk0 miibus0 e1000phy0 pnpinfo oui=0xac2 model=0x2 rev=0x3 at phyno=0 pcm0 pnpinfo vendor=0x1274 device=0x5880 subvendor=0x1274 subdevice=0x8001 class=0x040100 at slot=12 function=0 Interrupt request lines: 20 pcib2 I/O port window: 0xec00-0xec3f isab0 pnpinfo vendor=0x8086 device=0x24d0 subvendor=0x0000 subdevice=0x0000 class=0x060100 at slot=31 function=0 handle=\_SB_.PCI0.SBRG isa0 pmtimer0 sc0 vga0 I/O ports: 0x3c0-0x3df I/O memory addresses: 0xa0000-0xbffff orm0 pnpinfo pnpid=ORM0000 ACPI I/O memory addresses: 0xc0000-0xccfff fdc0 ppc0 uart0 uart1 atapci0 pnpinfo vendor=0x8086 device=0x24db subvendor=0x1043 subdevice=0x80a6 class=0x01018a at slot=31 function=1 handle=\_SB_.PCI0.IDE0 I/O ports: 0x170-0x177 0x1f0-0x1f7 0x376 0x3f6 0xfc00-0xfc0f ata0 at channel=0 Interrupt request lines: 14 ata1 at channel=1 Interrupt request lines: 15 unknown pnpinfo vendor=0x8086 device=0x24d3 subvendor=0x1043 subdevice=0x80a6 class=0x0c0500 at slot=31 function=3 I/O ports: 0x400-0x41f atpic0 pnpinfo _HID=PNP0000 _UID=0 at handle=\_SB_.PCI0.SBRG.PIC_ I/O ports: 0x20-0x21 0xa0-0xa1 atdma0 pnpinfo _HID=PNP0200 _UID=0 at handle=\_SB_.PCI0.SBRG.DMAD DMA request lines: 4 I/O ports: 0x0-0xf 0x81-0x83 0x87 0x89-0x8b 0x8f 0xc0-0xdf attimer0 pnpinfo _HID=PNP0100 _UID=0 at handle=\_SB_.PCI0.SBRG.TMR_ Interrupt request lines: 0 I/O ports: 0x40-0x43 atrtc0 pnpinfo _HID=PNP0B00 _UID=0 at handle=\_SB_.PCI0.SBRG.RTC0 Interrupt request lines: 8 I/O ports: 0x70-0x71 atkbdc0 pnpinfo _HID=PNP0303 _UID=0 at handle=\_SB_.PCI0.SBRG.PS2K Interrupt request lines: 1 I/O ports: 0x60 0x64 atkbd0 psm0 psmcpnp0 pnpinfo _HID=PNP0F03 _UID=0 at handle=\_SB_.PCI0.SBRG.PS2M unknown pnpinfo _HID=PNP0800 _UID=0 at handle=\_SB_.PCI0.SBRG.SPKR I/O ports: 0x61 npxisa0 pnpinfo _HID=PNP0C04 _UID=0 at handle=\_SB_.PCI0.SBRG.COPR I/O ports: 0xf0-0xff unknown pnpinfo _HID=PNP0501 _UID=1 at handle=\_SB_.PCI0.SBRG.UAR1 unknown pnpinfo _HID=PNP0501 _UID=2 at handle=\_SB_.PCI0.SBRG.UAR2 unknown pnpinfo _HID=PNP0700 _UID=0 at handle=\_SB_.PCI0.SBRG.FDC_ unknown pnpinfo _HID=PNP0400 _UID=1 at handle=\_SB_.PCI0.SBRG.LPTE unknown pnpinfo _HID=PNPB02F _UID=0 at handle=\_SB_.PCI0.SBRG.GAME unknown pnpinfo _HID=PNPB006 _UID=0 at handle=\_SB_.PCI0.SBRG.MIDI acpi_sysresource0 pnpinfo _HID=PNP0C02 _UID=46 at handle=\_SB_.PCI0.SBRG.SIOR acpi_sysresource1 pnpinfo _HID=PNP0C02 _UID=16 at handle=\_SB_.PCI0.SBRG.RMSC unknown pnpinfo _HID=PNP0C02 _UID=1014 at handle=\_SB_.PCI0.SBRG.P3F6 acpi_sysresource2 pnpinfo _HID=PNP0C02 _UID=0 at handle=\_SB_.PCI0.SBRG.OMSC acpi_sysresource3 pnpinfo _HID=PNP0C01 _UID=1 at handle=\_SB_.RMEM acpi_button0 pnpinfo _HID=PNP0C0C _UID=170 at handle=\_SB_.PWRB pci_link0 pnpinfo _HID=PNP0C0F _UID=1 at handle=\_SB_.LNKA pci_link1 pnpinfo _HID=PNP0C0F _UID=2 at handle=\_SB_.LNKB pci_link2 pnpinfo _HID=PNP0C0F _UID=3 at handle=\_SB_.LNKC pci_link3 pnpinfo _HID=PNP0C0F _UID=4 at handle=\_SB_.LNKD pci_link4 pnpinfo _HID=PNP0C0F _UID=5 at handle=\_SB_.LNKE pci_link5 pnpinfo _HID=PNP0C0F _UID=6 at handle=\_SB_.LNKF pci_link6 pnpinfo _HID=PNP0C0F _UID=7 at handle=\_SB_.LNKG pci_link7 pnpinfo _HID=PNP0C0F _UID=8 at handle=\_SB_.LNKH acpi_timer0 pnpinfo unknown at unknown ACPI I/O ports: 0x808-0x80b ========== ``devinfo -rv'' ends ========== From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 22:18:55 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62FCD106564A; Sat, 29 Oct 2011 22:18:55 +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 373B08FC0C; Sat, 29 Oct 2011 22:18:54 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id p9TMIspl082816; Sat, 29 Oct 2011 18:18:54 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id p9TMIsm1082781; Sat, 29 Oct 2011 22:18:54 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 29 Oct 2011 22:18:54 GMT Message-Id: <201110292218.p9TMIsm1082781@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 22:18:55 -0000 TB --- 2011-10-29 19:20:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-29 19:20:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-10-29 19:20:00 - cleaning the object tree TB --- 2011-10-29 19:20:35 - cvsupping the source tree TB --- 2011-10-29 19:20:35 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-10-29 19:21:04 - building world TB --- 2011-10-29 19:21:04 - CROSS_BUILD_TESTING=YES TB --- 2011-10-29 19:21:04 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-29 19:21:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-29 19:21:04 - SRCCONF=/dev/null TB --- 2011-10-29 19:21:04 - TARGET=amd64 TB --- 2011-10-29 19:21:04 - TARGET_ARCH=amd64 TB --- 2011-10-29 19:21:04 - TZ=UTC TB --- 2011-10-29 19:21:04 - __MAKE_CONF=/dev/null TB --- 2011-10-29 19:21:04 - cd /src TB --- 2011-10-29 19:21:04 - /usr/bin/make -B buildworld >>> World build started on Sat Oct 29 19:21:05 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Oct 29 22:02:52 UTC 2011 TB --- 2011-10-29 22:02:53 - generating LINT kernel config TB --- 2011-10-29 22:02:53 - cd /src/sys/amd64/conf TB --- 2011-10-29 22:02:53 - /usr/bin/make -B LINT TB --- 2011-10-29 22:02:53 - cd /src/sys/amd64/conf TB --- 2011-10-29 22:02:53 - /usr/sbin/config -m LINT-NOINET TB --- 2011-10-29 22:02:53 - building LINT-NOINET kernel TB --- 2011-10-29 22:02:53 - CROSS_BUILD_TESTING=YES TB --- 2011-10-29 22:02:53 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-29 22:02:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-29 22:02:53 - SRCCONF=/dev/null TB --- 2011-10-29 22:02:53 - TARGET=amd64 TB --- 2011-10-29 22:02:53 - TARGET_ARCH=amd64 TB --- 2011-10-29 22:02:53 - TZ=UTC TB --- 2011-10-29 22:02:53 - __MAKE_CONF=/dev/null TB --- 2011-10-29 22:02:53 - cd /src TB --- 2011-10-29 22:02:53 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Sat Oct 29 22:02:53 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT-NOINET /usr/local/bin/svnversion cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue vers.c linking kernel ia32_syscall.o:(.bss+0x0): multiple definition of `systrace_probe_func' trap.o:(.bss+0x0): first defined here *** Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT-NOINET. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-10-29 22:18:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-29 22:18:53 - ERROR: failed to build LINT-NOINET kernel TB --- 2011-10-29 22:18:53 - 8459.21 user 1591.54 system 10732.73 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 22:59:24 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84290106564A; Sat, 29 Oct 2011 22:59:24 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [94.23.254.147]) by mx1.freebsd.org (Postfix) with ESMTP id 462458FC12; Sat, 29 Oct 2011 22:59:24 +0000 (UTC) Received: from baby-jane.lamaiziere.net (63.9.74.86.rev.sfr.net [86.74.9.63]) by smtp.lamaiziere.net (Postfix) with ESMTPA id 35672FAA31A5; Sun, 30 Oct 2011 00:43:52 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id AA1087320C; Sun, 30 Oct 2011 00:43:51 +0200 (CEST) Date: Sun, 30 Oct 2011 00:43:50 +0200 From: Patrick Lamaiziere To: Jilles Tjoelker Message-ID: <20111030004350.5ffb0e00@davenulle.org> In-Reply-To: <20111029195852.GA90408@stack.nl> References: <4EAC0966.2050607@davenulle.org> <20111029195852.GA90408@stack.nl> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: David Marec , current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [Freebsd 9] [amd64] [USB] [HPLIP] what's the (new) right way to manage hplip usb-plugged printers, running Freebsd 9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Oct 2011 22:59:24 -0000 Le Sat, 29 Oct 2011 21:58:53 +0200, Jilles Tjoelker a écrit : > On Sat, Oct 29, 2011 at 04:10:46PM +0200, David Marec wrote: > > So, what's should be the news group&user's rights required by > > HPLIP/cups on FreeBSD 9 ? > > > And, how to handle them with devd ? > > Use devfs rules. > > Pasting from http://www.stack.nl/~jilles/unix/freebsd-devfs.txt > > Create or edit /etc/devfs.rules and put something like this in it: > > [devfsrules_mybox=10] > add path 'fd0*' mode 660 The problem is that the printer appears as ugenXXX.Y, but other usb devices (disk, usb-key, ...) also have an entry in /dev/ugen/ You really don't want to allow the users to access these devices, but *only* the printer. This is why we use a devd rule that test the type of the device. I don't think we can do this with devfs. And the ugen number differs if the usb port is not always the same. Regards. From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 23:31:49 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 669B91065670 for ; Sat, 29 Oct 2011 23:31:49 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id C47E28FC12 for ; Sat, 29 Oct 2011 23:31:48 +0000 (UTC) Received: from ur.dons.net.au (ppp118-210-211-94.lns20.adl6.internode.on.net [118.210.211.94]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id p9TNVLQx029145 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 30 Oct 2011 10:01:27 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: "Daniel O'Connor" In-Reply-To: <4EAC0966.2050607@davenulle.org> Date: Sun, 30 Oct 2011 10:01:21 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EAC0966.2050607@davenulle.org> To: David Marec X-Mailer: Apple Mail (2.1251.1) X-Spam-Score: 2.162 (**) BAYES_00,KHOP_DYNAMIC,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [Freebsd 9] [amd64] [USB] [HPLIP] what's the (new) right way to manage hplip usb-plugged printers, running Freebsd 9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Oct 2011 23:31:49 -0000 On 30/10/2011, at 24:40, David Marec wrote: > But, now running FreeBSD 9, I get new usb/devd behavior issues. >=20 > First, the ulpt module is always loaded. Is there any elegant way to = get rid of this 'self loading' behavior, except to remove it from = /boot/modules ? > Anyway, it sounds like HPLIP is now working with the ulpt module = loaded. I'm not sure what would load it automatically - it may be built into the = kernel though. Anyway, as you say it should work with ulpt loaded = anyway. > But, devd never sets the suitable rights on ugen. >=20 > Moreover, switching to the 'action' that only logs something, reveals = that devd never executes this entry. >=20 >=20 > So, what's should be the news group&user's rights required by = HPLIP/cups on FreeBSD 9 ? >=20 > And, how to handle them with devd ? I have a similar problem.. Looking at /etc/devd/uath.conf I see.. notify 100 { match "system" "USB"; match "subsystem" "DEVICE"; match "type" "ATTACH"; match "vendor" "0x168c"; match "product" "0x0002"; action "/usr/sbin/uathload -d /dev/$cdev"; }; Also, I have devd entries for NUT (UPS software) which look like so.. attach 100 { match "vendor" "0x0463"; match "product" "0xffff"; action "chown :uucp /dev/$device-name; chmod 660 = /dev/$device-name"; }; However this doesn't seem to work anymore, it certainly used to.. :( I tried adding the system, subsystem & type parts and changing = device-name to cdev but no luck.. I ran devd -Dd and checked the output but while it says it parses = nut.conf it doesn't seem to match the entries. devd output looks like so.. Processing event '!system=3DUSB subsystem=3DDEVICE type=3DATTACH = ugen=3Dugen1.3 cdev=3Dugen1.3 vendor=3D0x046 3 product=3D0xffff devclass=3D0x00 devsubclass=3D0x00 sernum=3D"000000000"= release=3D0x4241 mode=3Dhost port=3D 3 parent=3Dugen1.1' Pushing table setting system=3DUSB setting subsystem=3DDEVICE setting type=3DATTACH setting ugen=3Dugen1.3 setting cdev=3Dugen1.3 setting vendor=3D0x0463 setting product=3D0xffff setting devclass=3D0x00 setting devsubclass=3D0x00 setting sernum=3D000000000 setting release=3D0x4241 setting mode=3Dhost setting port=3D3 setting parent=3Dugen1.1 Processing notify event -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C