From owner-freebsd-current@FreeBSD.ORG Sun Mar 17 02:47:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 27A61C82 for ; Sun, 17 Mar 2013 02:47:56 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id E40C6D57 for ; Sun, 17 Mar 2013 02:47:55 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEAMQtRVGDaFvO/2dsb2JhbABDDogmvH2CA3SCKgEBAQQBAQEgKyALGxgCAg0ZAikBCSYGCAcEARwEh3MMsFaRX4EjjEJ8NAeCLYETA5Qggj6BH49jgktbIDKBBTU X-IronPort-AV: E=Sophos;i="4.84,858,1355115600"; d="scan'208";a="21565408" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 16 Mar 2013 22:47:49 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 177D3B3F41; Sat, 16 Mar 2013 22:47:49 -0400 (EDT) Date: Sat, 16 Mar 2013 22:47:49 -0400 (EDT) From: Rick Macklem To: Benjamin Kaduk Message-ID: <1638777446.3976688.1363488469024.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: Subject: Re: Strange error when compiling minimal GSSAPI application MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-current@freebsd.org, =?utf-8?Q?Elias_M=C3=A5rtenson?= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 02:47:56 -0000 Benjamin Kaduk wrote: > On Sat, 16 Mar 2013, Rick Macklem wrote: > > > Elias Martenson wrote: > > > >> Is there a problem with the GSSAPI implementation in FreeBSD? > >> > >> I'm trying to compile a minimal application that does nothing more > >> than > >> including the file gssapi/gssapi_krb5.h: > >> > > If you add: > > #include > > it compiles. in included by krb5.h, which I suspect most > > programs that use the gssapi_krb5.h stuff also uses. > > Which FreeBSD version are you on, Rick? > The userland on this laptop is about 9.0 with a few utilities updated and a pretty recent (Jan. 7, 2013) kernel from head. So, it is the older version of Heimdal for the above, rick > -Ben > _______________________________________________ > 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 Sun Mar 17 08:50:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DA48D316 for ; Sun, 17 Mar 2013 08:50:52 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (unknown [IPv6:2001:470:1f09:14c0::2]) by mx1.freebsd.org (Postfix) with ESMTP id EE76B81C for ; Sun, 17 Mar 2013 08:50:51 +0000 (UTC) Received: from [192.168.248.32] ([192.168.248.32]) by elf.hq.norma.perm.ru (8.14.5/8.14.5) with ESMTP id r2H8ojmN039929 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 17 Mar 2013 14:50:46 +0600 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <514583E4.80904@norma.perm.ru> Date: Sun, 17 Mar 2013 14:50:44 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: 10.x and mpd5 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [192.168.3.10]); Sun, 17 Mar 2013 14:50:48 +0600 (YEKT) X-Spam-Status: No hits=-101.0 bayes=0.5 testhits ALL_TRUSTED=-1, USER_IN_WHITELIST=-100 autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 08:50:52 -0000 Hi. After an upgrade from 9-STABLE I have a problem with mpd5. It can go to an endless loop while accepting a new pptp connection with a probability of like 50%. It looks in its log like I show below. The loop starts and ends with "LCP: LayerUp". This is really an endless loop, because neither mpd5 nor windows 7, which I use as a client cannot break it, it can last for minutes (the output below was interrupted when I pressed 'Cancel' button on the client). I don't see any packet drops or other network problems. Furthermore, this machine was running fine when on 9.x. problem appeared after 10.x upgrade. This has nothing to do with a pf, which I use to filter the traffic - the problem persists when I switch it off. I've also rebuilt the mpd on 10.x, and this didn't help. ===Cut=== Mar 17 14:44:22 taiga mpd: [L-2] Accepting PPTP connection Mar 17 14:44:22 taiga mpd: [L-2] Link: OPEN event Mar 17 14:44:22 taiga mpd: [L-2] LCP: Open event Mar 17 14:44:22 taiga mpd: [L-2] LCP: state change Initial --> Starting Mar 17 14:44:22 taiga mpd: [L-2] LCP: LayerStart Mar 17 14:44:22 taiga mpd: [L-2] PPTP: attaching to peer's outgoing call Mar 17 14:44:22 taiga mpd: [L-2] Link: UP event Mar 17 14:44:22 taiga mpd: [L-2] LCP: Up event Mar 17 14:44:22 taiga mpd: [L-2] LCP: state change Starting --> Req-Sent Mar 17 14:44:22 taiga mpd: [L-2] LCP: SendConfigReq #1 Mar 17 14:44:22 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:22 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:22 taiga mpd: [L-2] MRU 1500 Mar 17 14:44:22 taiga mpd: [L-2] MAGICNUM 9d62a962 Mar 17 14:44:22 taiga mpd: [L-2] AUTHPROTO CHAP MSOFTv2 Mar 17 14:44:22 taiga mpd: [L-2] MP MRRU 2048 Mar 17 14:44:22 taiga mpd: [L-2] MP SHORTSEQ Mar 17 14:44:22 taiga mpd: [L-2] ENDPOINTDISC [802.1] 00 1a 64 c6 a8 7c Mar 17 14:44:22 taiga mpd: [L-2] LCP: rec'd Configure Request #0 (Req-Sent) Mar 17 14:44:22 taiga mpd: [L-2] MRU 1400 Mar 17 14:44:22 taiga mpd: [L-2] MAGICNUM 6be166e5 Mar 17 14:44:22 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:22 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:22 taiga mpd: [L-2] CALLBACK 6 Mar 17 14:44:22 taiga mpd: [L-2] LCP: SendConfigRej #0 Mar 17 14:44:22 taiga mpd: [L-2] CALLBACK 6 Mar 17 14:44:22 taiga mpd: [L-2] LCP: rec'd Configure Request #1 (Req-Sent) Mar 17 14:44:22 taiga mpd: [L-2] MRU 1400 Mar 17 14:44:22 taiga mpd: [L-2] MAGICNUM 6be166e5 Mar 17 14:44:22 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:22 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:22 taiga mpd: [L-2] LCP: SendConfigAck #1 Mar 17 14:44:22 taiga mpd: [L-2] MRU 1400 Mar 17 14:44:22 taiga mpd: [L-2] MAGICNUM 6be166e5 Mar 17 14:44:22 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:22 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:22 taiga mpd: [L-2] LCP: state change Req-Sent --> Ack-Sent Mar 17 14:44:24 taiga mpd: [L-2] LCP: SendConfigReq #2 Mar 17 14:44:24 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:24 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:24 taiga mpd: [L-2] MRU 1500 Mar 17 14:44:24 taiga mpd: [L-2] MAGICNUM 9d62a962 Mar 17 14:44:24 taiga mpd: [L-2] AUTHPROTO CHAP MSOFTv2 Mar 17 14:44:24 taiga mpd: [L-2] MP MRRU 2048 Mar 17 14:44:24 taiga mpd: [L-2] MP SHORTSEQ Mar 17 14:44:24 taiga mpd: [L-2] ENDPOINTDISC [802.1] 00 1a 64 c6 a8 7c Mar 17 14:44:24 taiga mpd: [L-2] LCP: rec'd Configure Reject #2 (Ack-Sent) Mar 17 14:44:24 taiga mpd: [L-2] MP MRRU 2048 Mar 17 14:44:24 taiga mpd: [L-2] MP SHORTSEQ Mar 17 14:44:24 taiga mpd: [L-2] ENDPOINTDISC [802.1] 00 1a 64 c6 a8 7c Mar 17 14:44:24 taiga mpd: [L-2] LCP: SendConfigReq #3 Mar 17 14:44:24 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:24 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:24 taiga mpd: [L-2] MRU 1500 Mar 17 14:44:24 taiga mpd: [L-2] MAGICNUM 9d62a962 Mar 17 14:44:24 taiga mpd: [L-2] AUTHPROTO CHAP MSOFTv2 Mar 17 14:44:24 taiga mpd: [L-2] LCP: rec'd Ident #2 (Ack-Sent) Mar 17 14:44:24 taiga mpd: [L-2] MESG: MSRASV5.20 Mar 17 14:44:24 taiga mpd: [L-2] LCP: rec'd Ident #3 (Ack-Sent) Mar 17 14:44:24 taiga mpd: [L-2] MESG: MSRAS-0-DROOKIEWIN Mar 17 14:44:24 taiga mpd: [L-2] LCP: rec'd Ident #4 (Ack-Sent) Mar 17 14:44:24 taiga mpd: [L-2] MESG: ЧNVчpM-^VМKM-^FaM-^M╙еше^D Mar 17 14:44:26 taiga mpd: [L-2] LCP: SendConfigReq #4 Mar 17 14:44:26 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:26 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:26 taiga mpd: [L-2] MRU 1500 Mar 17 14:44:26 taiga mpd: [L-2] MAGICNUM 9d62a962 Mar 17 14:44:26 taiga mpd: [L-2] AUTHPROTO CHAP MSOFTv2 Mar 17 14:44:26 taiga mpd: [L-2] LCP: rec'd Configure Ack #4 (Ack-Sent) Mar 17 14:44:26 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:26 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:26 taiga mpd: [L-2] MRU 1500 Mar 17 14:44:26 taiga mpd: [L-2] MAGICNUM 9d62a962 Mar 17 14:44:26 taiga mpd: [L-2] AUTHPROTO CHAP MSOFTv2 Mar 17 14:44:26 taiga mpd: [L-2] LCP: state change Ack-Sent --> Opened Mar 17 14:44:26 taiga mpd: [L-2] LCP: auth: peer wants nothing, I want CHAP Mar 17 14:44:26 taiga mpd: [L-2] CHAP: sending CHALLENGE #1 len: 21 Mar 17 14:44:26 taiga mpd: [L-2] LCP: LayerUp Mar 17 14:44:28 taiga mpd: [L-2] LCP: rec'd Configure Request #6 (Opened) Mar 17 14:44:28 taiga mpd: [L-2] MRU 1400 Mar 17 14:44:28 taiga mpd: [L-2] MAGICNUM 6be166e5 Mar 17 14:44:28 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:28 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:28 taiga mpd: [L-2] LCP: LayerDown Mar 17 14:44:28 taiga mpd: [L-2] LCP: SendConfigReq #5 Mar 17 14:44:28 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:28 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:28 taiga mpd: [L-2] MRU 1500 Mar 17 14:44:28 taiga mpd: [L-2] MAGICNUM 9d62a962 Mar 17 14:44:28 taiga mpd: [L-2] AUTHPROTO CHAP MSOFTv2 Mar 17 14:44:28 taiga mpd: [L-2] LCP: SendConfigAck #6 Mar 17 14:44:28 taiga mpd: [L-2] MRU 1400 Mar 17 14:44:28 taiga mpd: [L-2] MAGICNUM 6be166e5 Mar 17 14:44:28 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:28 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:28 taiga mpd: [L-2] LCP: state change Opened --> Ack-Sent Mar 17 14:44:28 taiga mpd: [L-2] LCP: rec'd Ident #8 (Ack-Sent) Mar 17 14:44:28 taiga mpd: [L-2] MESG: MSRAS-0-DROOKIEWIN Mar 17 14:44:28 taiga mpd: [L-2] LCP: rec'd Ident #9 (Ack-Sent) Mar 17 14:44:28 taiga mpd: [L-2] MESG: ЧNVчpM-^VМKM-^FaM-^M╙еше^D Mar 17 14:44:28 taiga mpd: [L-2] LCP: rec'd Configure Ack #5 (Ack-Sent) Mar 17 14:44:28 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:28 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:28 taiga mpd: [L-2] MRU 1500 Mar 17 14:44:28 taiga mpd: [L-2] MAGICNUM 9d62a962 Mar 17 14:44:28 taiga mpd: [L-2] AUTHPROTO CHAP MSOFTv2 Mar 17 14:44:28 taiga mpd: [L-2] LCP: state change Ack-Sent --> Opened Mar 17 14:44:28 taiga mpd: [L-2] LCP: auth: peer wants nothing, I want CHAP Mar 17 14:44:28 taiga mpd: [L-2] CHAP: sending CHALLENGE #1 len: 21 Mar 17 14:44:28 taiga mpd: [L-2] LCP: LayerUp Mar 17 14:44:30 taiga mpd: [L-2] CHAP: sending CHALLENGE #2 len: 21 Mar 17 14:44:31 taiga mpd: [L-2] LCP: rec'd Configure Request #11 (Opened) Mar 17 14:44:31 taiga mpd: [L-2] MRU 1400 Mar 17 14:44:31 taiga mpd: [L-2] MAGICNUM 6be166e5 Mar 17 14:44:31 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:31 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:31 taiga mpd: [L-2] LCP: LayerDown Mar 17 14:44:31 taiga mpd: [L-2] LCP: SendConfigReq #6 Mar 17 14:44:31 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:31 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:31 taiga mpd: [L-2] MRU 1500 Mar 17 14:44:31 taiga mpd: [L-2] MAGICNUM 9d62a962 Mar 17 14:44:31 taiga mpd: [L-2] AUTHPROTO CHAP MSOFTv2 Mar 17 14:44:31 taiga mpd: [L-2] LCP: SendConfigAck #11 Mar 17 14:44:31 taiga mpd: [L-2] MRU 1400 Mar 17 14:44:31 taiga mpd: [L-2] MAGICNUM 6be166e5 Mar 17 14:44:31 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:31 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:31 taiga mpd: [L-2] LCP: state change Opened --> Ack-Sent Mar 17 14:44:31 taiga mpd: [L-2] LCP: rec'd Ident #13 (Ack-Sent) Mar 17 14:44:31 taiga mpd: [L-2] MESG: MSRAS-0-DROOKIEWIN Mar 17 14:44:31 taiga mpd: [L-2] LCP: rec'd Ident #14 (Ack-Sent) Mar 17 14:44:31 taiga mpd: [L-2] MESG: ЧNVчpM-^VМKM-^FaM-^M╙еше^D Mar 17 14:44:31 taiga mpd: [L-2] LCP: rec'd Configure Ack #6 (Ack-Sent) Mar 17 14:44:31 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:31 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:31 taiga mpd: [L-2] MRU 1500 Mar 17 14:44:31 taiga mpd: [L-2] MAGICNUM 9d62a962 Mar 17 14:44:31 taiga mpd: [L-2] AUTHPROTO CHAP MSOFTv2 Mar 17 14:44:31 taiga mpd: [L-2] LCP: state change Ack-Sent --> Opened Mar 17 14:44:31 taiga mpd: [L-2] LCP: auth: peer wants nothing, I want CHAP Mar 17 14:44:31 taiga mpd: [L-2] CHAP: sending CHALLENGE #1 len: 21 Mar 17 14:44:31 taiga mpd: [L-2] LCP: LayerUp Mar 17 14:44:33 taiga mpd: [L-2] CHAP: sending CHALLENGE #2 len: 21 Mar 17 14:44:35 taiga mpd: [L-2] LCP: rec'd Configure Request #16 (Opened) Mar 17 14:44:35 taiga mpd: [L-2] MRU 1400 Mar 17 14:44:35 taiga mpd: [L-2] MAGICNUM 6be166e5 Mar 17 14:44:35 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:35 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:35 taiga mpd: [L-2] LCP: LayerDown Mar 17 14:44:35 taiga mpd: [L-2] LCP: SendConfigReq #7 Mar 17 14:44:35 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:35 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:35 taiga mpd: [L-2] MRU 1500 Mar 17 14:44:35 taiga mpd: [L-2] MAGICNUM 9d62a962 Mar 17 14:44:35 taiga mpd: [L-2] AUTHPROTO CHAP MSOFTv2 Mar 17 14:44:35 taiga mpd: [L-2] LCP: SendConfigAck #16 Mar 17 14:44:35 taiga mpd: [L-2] MRU 1400 Mar 17 14:44:35 taiga mpd: [L-2] MAGICNUM 6be166e5 Mar 17 14:44:35 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:35 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:35 taiga mpd: [L-2] LCP: state change Opened --> Ack-Sent Mar 17 14:44:35 taiga mpd: [L-2] LCP: rec'd Ident #18 (Ack-Sent) Mar 17 14:44:35 taiga mpd: [L-2] MESG: MSRAS-0-DROOKIEWIN Mar 17 14:44:35 taiga mpd: [L-2] LCP: rec'd Ident #19 (Ack-Sent) Mar 17 14:44:35 taiga mpd: [L-2] MESG: ЧNVчpM-^VМKM-^FaM-^M╙еше^D Mar 17 14:44:35 taiga mpd: [L-2] LCP: rec'd Configure Ack #7 (Ack-Sent) Mar 17 14:44:35 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:35 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:35 taiga mpd: [L-2] MRU 1500 Mar 17 14:44:35 taiga mpd: [L-2] MAGICNUM 9d62a962 Mar 17 14:44:35 taiga mpd: [L-2] AUTHPROTO CHAP MSOFTv2 Mar 17 14:44:35 taiga mpd: [L-2] LCP: state change Ack-Sent --> Opened Mar 17 14:44:35 taiga mpd: [L-2] LCP: auth: peer wants nothing, I want CHAP Mar 17 14:44:35 taiga mpd: [L-2] CHAP: sending CHALLENGE #1 len: 21 Mar 17 14:44:35 taiga mpd: [L-2] LCP: LayerUp Mar 17 14:44:37 taiga mpd: [L-2] CHAP: sending CHALLENGE #2 len: 21 Mar 17 14:44:39 taiga mpd: [L-2] LCP: rec'd Configure Request #21 (Opened) Mar 17 14:44:39 taiga mpd: [L-2] MRU 1400 Mar 17 14:44:39 taiga mpd: [L-2] MAGICNUM 6be166e5 Mar 17 14:44:39 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:39 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:39 taiga mpd: [L-2] LCP: LayerDown Mar 17 14:44:39 taiga mpd: [L-2] LCP: SendConfigReq #8 Mar 17 14:44:39 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:39 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:39 taiga mpd: [L-2] MRU 1500 Mar 17 14:44:39 taiga mpd: [L-2] MAGICNUM 9d62a962 Mar 17 14:44:39 taiga mpd: [L-2] AUTHPROTO CHAP MSOFTv2 Mar 17 14:44:39 taiga mpd: [L-2] LCP: SendConfigAck #21 Mar 17 14:44:39 taiga mpd: [L-2] MRU 1400 Mar 17 14:44:39 taiga mpd: [L-2] MAGICNUM 6be166e5 Mar 17 14:44:39 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:39 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:39 taiga mpd: [L-2] LCP: state change Opened --> Ack-Sent Mar 17 14:44:39 taiga mpd: [L-2] LCP: rec'd Ident #23 (Ack-Sent) Mar 17 14:44:39 taiga mpd: [L-2] MESG: MSRAS-0-DROOKIEWIN Mar 17 14:44:39 taiga mpd: [L-2] LCP: rec'd Ident #24 (Ack-Sent) Mar 17 14:44:39 taiga mpd: [L-2] MESG: ЧNVчpM-^VМKM-^FaM-^M╙еше^D Mar 17 14:44:39 taiga mpd: [L-2] LCP: rec'd Configure Ack #8 (Ack-Sent) Mar 17 14:44:39 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:39 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:39 taiga mpd: [L-2] MRU 1500 Mar 17 14:44:39 taiga mpd: [L-2] MAGICNUM 9d62a962 Mar 17 14:44:39 taiga mpd: [L-2] AUTHPROTO CHAP MSOFTv2 Mar 17 14:44:39 taiga mpd: [L-2] LCP: state change Ack-Sent --> Opened Mar 17 14:44:39 taiga mpd: [L-2] LCP: auth: peer wants nothing, I want CHAP Mar 17 14:44:39 taiga mpd: [L-2] CHAP: sending CHALLENGE #1 len: 21 Mar 17 14:44:39 taiga mpd: [L-2] LCP: LayerUp Mar 17 14:44:41 taiga mpd: [L-2] CHAP: sending CHALLENGE #2 len: 21 Mar 17 14:44:43 taiga mpd: [L-2] LCP: rec'd Configure Request #26 (Opened) Mar 17 14:44:43 taiga mpd: [L-2] MRU 1400 Mar 17 14:44:43 taiga mpd: [L-2] MAGICNUM 6be166e5 Mar 17 14:44:43 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:43 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:43 taiga mpd: [L-2] LCP: LayerDown Mar 17 14:44:43 taiga mpd: [L-2] LCP: SendConfigReq #9 Mar 17 14:44:43 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:43 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:43 taiga mpd: [L-2] MRU 1500 Mar 17 14:44:43 taiga mpd: [L-2] MAGICNUM 9d62a962 Mar 17 14:44:43 taiga mpd: [L-2] AUTHPROTO CHAP MSOFTv2 Mar 17 14:44:43 taiga mpd: [L-2] LCP: SendConfigAck #26 Mar 17 14:44:43 taiga mpd: [L-2] MRU 1400 Mar 17 14:44:43 taiga mpd: [L-2] MAGICNUM 6be166e5 Mar 17 14:44:43 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:43 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:43 taiga mpd: [L-2] LCP: state change Opened --> Ack-Sent Mar 17 14:44:43 taiga mpd: [L-2] LCP: rec'd Ident #28 (Ack-Sent) Mar 17 14:44:43 taiga mpd: [L-2] MESG: MSRAS-0-DROOKIEWIN Mar 17 14:44:43 taiga mpd: [L-2] LCP: rec'd Ident #29 (Ack-Sent) Mar 17 14:44:43 taiga mpd: [L-2] MESG: ЧNVчpM-^VМKM-^FaM-^M╙еше^D Mar 17 14:44:43 taiga mpd: [L-2] LCP: rec'd Configure Ack #9 (Ack-Sent) Mar 17 14:44:43 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:43 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:43 taiga mpd: [L-2] MRU 1500 Mar 17 14:44:43 taiga mpd: [L-2] MAGICNUM 9d62a962 Mar 17 14:44:43 taiga mpd: [L-2] AUTHPROTO CHAP MSOFTv2 Mar 17 14:44:43 taiga mpd: [L-2] LCP: state change Ack-Sent --> Opened Mar 17 14:44:43 taiga mpd: [L-2] LCP: auth: peer wants nothing, I want CHAP Mar 17 14:44:43 taiga mpd: [L-2] CHAP: sending CHALLENGE #1 len: 21 Mar 17 14:44:43 taiga mpd: [L-2] LCP: LayerUp Mar 17 14:44:44 taiga mpd: [L-2] LCP: rec'd Terminate Request #31 (Opened) Mar 17 14:44:44 taiga mpd: [L-2] LCP: state change Opened --> Stopping Mar 17 14:44:44 taiga mpd: [L-2] LCP: SendTerminateAck #10 Mar 17 14:44:44 taiga mpd: [L-2] LCP: LayerDown Mar 17 14:44:46 taiga mpd: [L-2] LCP: state change Stopping --> Stopped Mar 17 14:44:46 taiga mpd: [L-2] LCP: LayerFinish Mar 17 14:44:46 taiga mpd: [L-2] PPTP call terminated Mar 17 14:44:46 taiga mpd: [L-2] Link: DOWN event Mar 17 14:44:46 taiga mpd: [L-2] LCP: Close event Mar 17 14:44:46 taiga mpd: [L-2] LCP: state change Stopped --> Closed Mar 17 14:44:46 taiga mpd: [L-2] LCP: Down event Mar 17 14:44:46 taiga mpd: [L-2] LCP: state change Closed --> Initial Mar 17 14:44:46 taiga mpd: [L-2] Link: SHUTDOWN event Mar 17 14:44:46 taiga mpd: [L-2] Link: Shutdown ===Cut=== From owner-freebsd-current@FreeBSD.ORG Sun Mar 17 20:26:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ACB922EE for ; Sun, 17 Mar 2013 20:26:32 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ve0-f178.google.com (mail-ve0-f178.google.com [209.85.128.178]) by mx1.freebsd.org (Postfix) with ESMTP id 6C5A211E for ; Sun, 17 Mar 2013 20:26:32 +0000 (UTC) Received: by mail-ve0-f178.google.com with SMTP id db10so3875271veb.37 for ; Sun, 17 Mar 2013 13:26:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=D8h7ZkB/QbYr+GB2xJtaHX/RGj+ccogzpZ0zVZDk+H8=; b=dMVRXr9cQt6Dnn3vk98CMnaNxOCOiw+xChZB+Jjrw1x2QL7ad6C9eMwkFKfqfzI25Z eDfco9KJhv/3OAnopNZghzTA1Zk94WYHvPiYQPSP7H5FPgbifMbrw1M0tqAL+Bgcub2H 0tJ0njmmgQTEfCL8G57UawDeMiAP4HhkpA2LwuKhRSOeymqUYSAva7OwWOjbjUM6MSxM Bp4g7+n8j2D5ZFo8pVlbJZAYcW9I07HLbfSlWQ3UmPkFFt9WFWPkdApGbmtAepxhM48l U/nmUwUB8kJYFwjFOF+kRM6GHczm0EwACG8tUe/a1NxmgMCqyubYo2WDpawiL+IHCc2C iemw== MIME-Version: 1.0 X-Received: by 10.58.154.229 with SMTP id vr5mr17189161veb.11.1363551991212; Sun, 17 Mar 2013 13:26:31 -0700 (PDT) Received: by 10.58.132.203 with HTTP; Sun, 17 Mar 2013 13:26:31 -0700 (PDT) Date: Sun, 17 Mar 2013 13:26:31 -0700 Message-ID: Subject: FreeBSD is very slow when Memory chip sizes are imbalanced in slots From: Mehmet Erol Sanliturk To: freebsd-current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 20:26:32 -0000 Dear All , Previously , in the following message , I have mentioned effect of memory chip placement on execution speed : http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031836.html Effect of Processor and Memory on KDE4 execution speed The above thread did not produce any usable result . The problem is persisting over 9.1 and 10.0 current . My opinion is that , it is NOT related to KDE only . After X is started , any desktop is behaving very slowly . This is also visible in PC-BSD and GhostBSD . I am reading about very much slowness in some messages , which I suspect that , their problem may also be caused such an imbalanced memory chip placement . This problem is making FreeBSD unusable in such computers . The Linux distributions are NOT exhibiting such a slow behavior , and also Windows 7 is NOT affected . It seems that , in some memory management part of FreeBSD is badly affected such an imbalanced memory chip size placement . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Mon Mar 18 10:57:31 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C54FD1EA2 for ; Mon, 18 Mar 2013 10:57:31 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by mx1.freebsd.org (Postfix) with ESMTP id 9ADF5884 for ; Mon, 18 Mar 2013 10:57:31 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id k11so6689852iea.38 for ; Mon, 18 Mar 2013 03:57:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=fAVBUY/Mrnj7hWje2080jmvxAgdXDl0liwaXhoSd10I=; b=xksiPouP68X1XJDqO5M2MLRaxIm4v6nqbAeEq7+rk8Cx+9zBEhyYBNrLZMdbxCcD/W mZjUOAeyTBMmTt1Jg2vZJnsjwjtBRTKXvnrIpjLe4W2Xc8TlOPJ6U4p3UIRT5039UC3I JC080M2e3LjdVZRKe0J0ksUU3uAIpD/WGSAAJjF3+Nd06fuiWOzegcO6EwqX3UUQn8TJ 2foTD+lD+mzDAA26OF8f9RN6H0LH4Bz+FGmpwg+jDDS+r61peadKlfqTBNNRtZlovjDo mkPVi+yKcDWYswhJSOQtYnbaGyvR8+raXDkFmLi4OS1NGrvRKMJARIi+unfx/6avzgXY FvzQ== MIME-Version: 1.0 X-Received: by 10.50.6.3 with SMTP id w3mr5839899igw.76.1363602640165; Mon, 18 Mar 2013 03:30:40 -0700 (PDT) Received: by 10.64.107.162 with HTTP; Mon, 18 Mar 2013 03:30:40 -0700 (PDT) In-Reply-To: References: Date: Mon, 18 Mar 2013 03:30:40 -0700 Message-ID: Subject: Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots From: Mehmet Erol Sanliturk To: Tom Evans Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 10:57:31 -0000 On Mon, Mar 18, 2013 at 3:01 AM, Tom Evans wrote: > On Sun, Mar 17, 2013 at 8:26 PM, Mehmet Erol Sanliturk > wrote: > > Dear All , > > > > Previously , in the following message , I have mentioned effect of memory > > chip placement on execution speed : > > > > > http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031836.html > > Effect of Processor and Memory on KDE4 execution > > speed< > http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031836.html > > > > These seems to be more than different memory slot allocation between > those two boxes. > > Can you reproduce this on the one labelled 'FAST' by assigning memory > in the same manner as it is assigned in the one labelled 'SLOW'? > > > > > > > The above thread did not produce any usable result . > > > > The problem is persisting over 9.1 and 10.0 current . > > > > My opinion is that , it is NOT related to KDE only . > > > > After X is started , any desktop is behaving very slowly . > > This is also visible in PC-BSD and GhostBSD . > > This is very nebulous. What is 'very slowly'? Is there a test you can > run that is independent of X, KDE, etc that demonstrates this? > > One thing that KDE does require (iirc - from about 5 years ago, > probably wrong now) is that since KDE is C++, it spends a lot of time > loading executables/libraries into memory and prelinking them. If you > have dramatically lowered your RAM bandwidth, then this stage could > take a lot longer. > > One thing that could cause memory bandwidth to lower is by installing > mismatched modules. The BIOS will set all RAM up at the same speed, > the lowest that all of the installed RAM supports. If you fill the RAM > slots with mismatched modules of different sizes, it may also not > enable dual channel memory, further reducing the RAM bandwidth. > > Because of this, I think it is a jump to go from "My computer runs > slow when I put these bits of RAM in" to "FreeBSD always runs slow > when there is mismatched RAM". > > If you find out what is slow on FreeBSD - eg RAM bandwidth - you can > then test the same thing in Linux. If Linux shows the same slowdown > from fast to slow, then I'm sorry, that's a hardware defect. If, on > the other hand, Linux is just as fast in both configurations, then I'm > sure a lot of people would be interested as to why. > > Cheers > > Tom > I think , all of the answers to your questions may be found in the above referenced thread messages : Every possible combination has been tried , and identified that the problem is different memory chip sizes for FreeBSD ( v9.0 , v9.1 , v10.0 ) ( GhostBSD , PC-BSD , v9.0 , v9.1 ) : Channel A : Slot 1 : 2 GB Slot 2 : 1 GB Channel B : Slot 1 : 2 GB Slot 2 : 1 GB All of the memory chips : Kingston HyperX , same clock frequency . Memory placement kind is correct . There is NO any hardware defect . Linux is insensitive to such different memory chip sizes ( I am using Fedora , CentOS , Mandriva , Mageia , OpenSUSE , Arch Linux , Puppy Linux , and some others ... ) Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Mon Mar 18 10:59:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 97261255 for ; Mon, 18 Mar 2013 10:59:56 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 6ED188F8 for ; Mon, 18 Mar 2013 10:59:56 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id c12so6655706ieb.20 for ; Mon, 18 Mar 2013 03:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lWteIHcbZbLM/5Lhn2TVqMgWPxnjZ288oAJ/BEa61vs=; b=d4OCArSCHwctb3HErH6qo18cIUU7ZlntAt99qdAxQyaXyZZq+ijtfbrK+sNLn5neg8 8PYWSddI1RUimqukGohA0P7WQl5dEmB61YFM7xBGsyJYLO/qaJ9oBP0QxetzIMMKrPH1 EHtJlf/W0jbKgYUO/N8LMJODHSSM38hA/zzBnwqpzJu0Ogn9899TpVOZOUmFWQpjEM3A 0t7I3KMm0s+POAUm+8XAqc51guF2xQ3rRJPKqwi1L9Gn/dvPp/xPxQSi/CQrhyyMQCLD yg58GTHefZ/Wkg7vGXuwTS4gdoJ8xLSmTjT1FkS8yXFArPGczF9+4In78omPzYVlvu1R QrhQ== MIME-Version: 1.0 X-Received: by 10.50.135.105 with SMTP id pr9mr5766658igb.6.1363600903766; Mon, 18 Mar 2013 03:01:43 -0700 (PDT) Received: by 10.64.6.234 with HTTP; Mon, 18 Mar 2013 03:01:43 -0700 (PDT) In-Reply-To: References: Date: Mon, 18 Mar 2013 10:01:43 +0000 Message-ID: Subject: Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots From: Tom Evans To: Mehmet Erol Sanliturk Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 10:59:56 -0000 On Sun, Mar 17, 2013 at 8:26 PM, Mehmet Erol Sanliturk wrote: > Dear All , > > Previously , in the following message , I have mentioned effect of memory > chip placement on execution speed : > > http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031836.html > Effect of Processor and Memory on KDE4 execution > speed These seems to be more than different memory slot allocation between those two boxes. Can you reproduce this on the one labelled 'FAST' by assigning memory in the same manner as it is assigned in the one labelled 'SLOW'? > > > The above thread did not produce any usable result . > > The problem is persisting over 9.1 and 10.0 current . > > My opinion is that , it is NOT related to KDE only . > > After X is started , any desktop is behaving very slowly . > This is also visible in PC-BSD and GhostBSD . This is very nebulous. What is 'very slowly'? Is there a test you can run that is independent of X, KDE, etc that demonstrates this? One thing that KDE does require (iirc - from about 5 years ago, probably wrong now) is that since KDE is C++, it spends a lot of time loading executables/libraries into memory and prelinking them. If you have dramatically lowered your RAM bandwidth, then this stage could take a lot longer. One thing that could cause memory bandwidth to lower is by installing mismatched modules. The BIOS will set all RAM up at the same speed, the lowest that all of the installed RAM supports. If you fill the RAM slots with mismatched modules of different sizes, it may also not enable dual channel memory, further reducing the RAM bandwidth. Because of this, I think it is a jump to go from "My computer runs slow when I put these bits of RAM in" to "FreeBSD always runs slow when there is mismatched RAM". If you find out what is slow on FreeBSD - eg RAM bandwidth - you can then test the same thing in Linux. If Linux shows the same slowdown from fast to slow, then I'm sorry, that's a hardware defect. If, on the other hand, Linux is just as fast in both configurations, then I'm sure a lot of people would be interested as to why. Cheers Tom From owner-freebsd-current@FreeBSD.ORG Mon Mar 18 11:19:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7D23B648 for ; Mon, 18 Mar 2013 11:19:14 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by mx1.freebsd.org (Postfix) with ESMTP id 541C5F24 for ; Mon, 18 Mar 2013 11:19:14 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id c13so6666481ieb.23 for ; Mon, 18 Mar 2013 04:19:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ph7ob87KcBU8IbU5TeP3Kje01lPxJXPQccDroqEkjuY=; b=z9/JbkMDcv/Njt5HzgroLOPMS6G5UFmxItALK/bzAq8yPk6DlJfbNKSqpwLSGtzWHA BQXattuzd4P43uKhiLA3XmUaZ/SF1l7DQIgjzaZQ7Z7CrH/YhIk6oTEApD4DN25Rv/mD 48VljsMczBj22zgPotboez5mfvecnIryzjVkyrsUFTkqO8nz9VQ6YnIGd4ASTooYrS42 hwHESXckUb1ss39GGJX5Nrzyu0pzKep0peoa346W8I1QeCzGwkTKz91B7ap5SP6IVciY axzXEQDXA6uJxWus/sPprAIbNjTt+GWozvbtcUR00Fo5MSc5mdHa+vYEkHhaa2g0Sr/A znug== MIME-Version: 1.0 X-Received: by 10.50.135.100 with SMTP id pr4mr5624364igb.37.1363605554025; Mon, 18 Mar 2013 04:19:14 -0700 (PDT) Received: by 10.64.6.234 with HTTP; Mon, 18 Mar 2013 04:19:13 -0700 (PDT) In-Reply-To: References: Date: Mon, 18 Mar 2013 11:19:13 +0000 Message-ID: Subject: Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots From: Tom Evans To: Mehmet Erol Sanliturk Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 11:19:14 -0000 On Mon, Mar 18, 2013 at 10:30 AM, Mehmet Erol Sanliturk wrote: > > > On Mon, Mar 18, 2013 at 3:01 AM, Tom Evans wrote: >> >> On Sun, Mar 17, 2013 at 8:26 PM, Mehmet Erol Sanliturk >> wrote: >> > Dear All , >> > >> > Previously , in the following message , I have mentioned effect of >> > memory >> > chip placement on execution speed : >> > >> > >> > http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031836.html >> > Effect of Processor and Memory on KDE4 execution >> > >> > speed >> >> These seems to be more than different memory slot allocation between >> those two boxes. >> >> Can you reproduce this on the one labelled 'FAST' by assigning memory >> in the same manner as it is assigned in the one labelled 'SLOW'? >> >> > >> > >> > The above thread did not produce any usable result . >> > >> > The problem is persisting over 9.1 and 10.0 current . >> > >> > My opinion is that , it is NOT related to KDE only . >> > >> > After X is started , any desktop is behaving very slowly . >> > This is also visible in PC-BSD and GhostBSD . >> >> This is very nebulous. What is 'very slowly'? Is there a test you can >> run that is independent of X, KDE, etc that demonstrates this? >> >> One thing that KDE does require (iirc - from about 5 years ago, >> probably wrong now) is that since KDE is C++, it spends a lot of time >> loading executables/libraries into memory and prelinking them. If you >> have dramatically lowered your RAM bandwidth, then this stage could >> take a lot longer. >> >> One thing that could cause memory bandwidth to lower is by installing >> mismatched modules. The BIOS will set all RAM up at the same speed, >> the lowest that all of the installed RAM supports. If you fill the RAM >> slots with mismatched modules of different sizes, it may also not >> enable dual channel memory, further reducing the RAM bandwidth. >> >> Because of this, I think it is a jump to go from "My computer runs >> slow when I put these bits of RAM in" to "FreeBSD always runs slow >> when there is mismatched RAM". >> >> If you find out what is slow on FreeBSD - eg RAM bandwidth - you can >> then test the same thing in Linux. If Linux shows the same slowdown >> from fast to slow, then I'm sorry, that's a hardware defect. If, on >> the other hand, Linux is just as fast in both configurations, then I'm >> sure a lot of people would be interested as to why. >> >> Cheers >> >> Tom > > > I think , all of the answers to your questions may be found in the above > referenced thread messages : Nope, you tested 'running KDE' and on different computers found out that one runs at a different speed than another. You've not done anything else to determine why or because of what. You're the one seeing this problem. If you want it fixed, you will need to do some work to determine what is causing it. All you are saying now is "When I build this complex combination of hardware and software, it's slow. Fix my special case". > > Every possible combination has been tried , and identified that the problem > is different memory chip sizes for FreeBSD ( v9.0 , v9.1 , v10.0 ) ( > GhostBSD , PC-BSD , v9.0 , v9.1 ) : > > Channel A : Slot 1 : 2 GB > Slot 2 : 1 GB > > > Channel B : Slot 1 : 2 GB > Slot 2 : 1 GB > > > All of the memory chips : Kingston HyperX , same clock frequency . > Memory placement kind is correct . You say this, have you actually measured/checked. sysutils/dmidecode will interrogate your BIOS and tell us what it thinks is installed in each RAM socket. It is not uncommon for RAM to say one thing on the outside, and report something completely different to the BIOS. > > There is NO any hardware defect . > > Linux is insensitive to such different memory chip sizes ( I am using Fedora > , CentOS , Mandriva , Mageia , OpenSUSE , Arch Linux , Puppy Linux , and > some others ... ) And you've run the tests which clearly demonstrate this? Or you've installed KDE, and it's not been 'too slow'? I'm trying to get you to approach a more scientific approach to this. Hopefully, this would lead to some actual conclusions and things that can be improved, rather than "FreeBSD is slow". You've got a problem when you have mismatched memory, your computer runs slower. Is the memory running slower? Test memory bandwidth in both 'fast' and 'slow' configurations. Is there a difference? Apparently linux is unaffected. Test memory bandwidth in both fast and slow configurations on linux. Is there a difference? Doing those 4 steps should tell us more about your actual problem, and might spur an idea in someone. You can use ramspeed to test ram speed in both linux and freebsd: http://alasir.com/software/ramspeed/ Problems with your memory modules should produce testable scenarios that don't involve X and KDE. Cheers Tom From owner-freebsd-current@FreeBSD.ORG Mon Mar 18 11:54:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1EBD9D2 for ; Mon, 18 Mar 2013 11:54:59 +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 C06893DE for ; Mon, 18 Mar 2013 11:54:58 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 05EDA8A521; Mon, 18 Mar 2013 11:54:51 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.6/8.14.6) with ESMTP id r2IBsp6t035879; Mon, 18 Mar 2013 11:54:51 GMT (envelope-from phk@phk.freebsd.dk) To: Tom Evans Subject: Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots In-reply-to: From: "Poul-Henning Kamp" References: Content-Type: text/plain; charset=ISO-8859-1> Date: Mon, 18 Mar 2013 11:54:51 +0000 Message-ID: <35878.1363607691@critter.freebsd.dk> Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 11:54:59 -0000 In message , Tom Evans writes: >You say this, have you actually measured/checked. sysutils/dmidecode >will interrogate your BIOS and tell us what it thinks is installed in >each RAM socket. It is not uncommon for RAM to say one thing on the >outside, and report something completely different to the BIOS. I can only second Tom's call for a proper scientific approach to debugging this issue, rather than just assume that it is the operating systems fault. -- 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 Mon Mar 18 12:18:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 92B598C0 for ; Mon, 18 Mar 2013 12:18:26 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ia0-x229.google.com (mail-ia0-x229.google.com [IPv6:2607:f8b0:4001:c02::229]) by mx1.freebsd.org (Postfix) with ESMTP id 502E7762 for ; Mon, 18 Mar 2013 12:18:26 +0000 (UTC) Received: by mail-ia0-f169.google.com with SMTP id j5so5271771iaf.0 for ; Mon, 18 Mar 2013 05:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ayVvSHiw88inmOjx2wzH0Cr3Zd1+QXklt+4gGk5HSLY=; b=rxq+o7hxZ204eJLb6IPLjjBMaoMHzRqzg7p1IP7tiU+f7rdli3B3CCHM7GNpDpIqdE AdwvUy46LH12ledXlE1Xs5Fna75FyaOZG/jvTc8SEnwNgWImPmUHPL32tVERT5AYIBEV GUBy7WtkhE9h0Mc9X3T9bYp3Ad79udxztYF3L6nMxU/YuS63uoQ4ChWs0yfSLZLKeR1/ V5/x6O3knMlSE3u2BTFtor2JQE9GvY4ugWINHaiDeCD3AQnQPq1fFxpYRUgyqplMcEZ5 Qw+CcSyjVSihd1YxTH6F3OlT7gmRiG7UNLgeCVaMxs2N+QI6eBz88hNeQ3AYSNQwPpeo KVqA== MIME-Version: 1.0 X-Received: by 10.50.46.197 with SMTP id x5mr5830290igm.7.1363609105998; Mon, 18 Mar 2013 05:18:25 -0700 (PDT) Received: by 10.64.107.162 with HTTP; Mon, 18 Mar 2013 05:18:25 -0700 (PDT) In-Reply-To: <35878.1363607691@critter.freebsd.dk> References: <35878.1363607691@critter.freebsd.dk> Date: Mon, 18 Mar 2013 05:18:25 -0700 Message-ID: Subject: Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots From: Mehmet Erol Sanliturk To: Poul-Henning Kamp Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Tom Evans , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 12:18:26 -0000 On Mon, Mar 18, 2013 at 4:54 AM, Poul-Henning Kamp wrote: > In message DjjMoe5ttGA@mail.gmail.com>, Tom Evans writes: > > >You say this, have you actually measured/checked. sysutils/dmidecode > >will interrogate your BIOS and tell us what it thinks is installed in > >each RAM socket. It is not uncommon for RAM to say one thing on the > >outside, and report something completely different to the BIOS. > > I can only second Tom's call for a proper scientific approach to > debugging this issue, rather than just assume that it is the > operating systems fault. > > -- > 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. > I am a graduate of Operations Research and Statistics option of a Mathematics department . All of your considerations are considered . It is so much apparent that , the cause is FreeBSD . In my previous year message and in its subsequent messages , there are sufficiently detailed information . This message is caused from the following fact : In previous year case , KDE used was a cause , but FluxBox was working fast . Now , I have installed 10.0 current . It does not have KDE in packages . I have installed FluxBox . It is not a few second slow : Many minutes to start Firefox , and activate a menu of it ! What is the point of measuring milliseconds when the difference is around many minutes ? PC-BSD installation ( it is a graphical installation after starting X ) is taking many hours to reach 20 percent completion . The same is for GhostBSD : Start it at night , at the next morning , it is likely that it is not finished yet . Then : WQhat will be measured ? Linux installations are around 30 minutes . Starting/Opening menus are instantenous : I do no have chronometer , but everything is within a second . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Mon Mar 18 12:40:46 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 033ABDCB for ; Mon, 18 Mar 2013 12:40:46 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 3DA0085B for ; Mon, 18 Mar 2013 12:40:44 +0000 (UTC) Received: (qmail 99893 invoked from network); 18 Mar 2013 13:52:13 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 18 Mar 2013 13:52:13 -0000 Message-ID: <51470B47.7040108@freebsd.org> Date: Mon, 18 Mar 2013 13:40:39 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Peter Wemm Subject: Re: NewNFS vs. oldNFS for 10.0? References: <514324E8.30209@freebsd.org> <201303150946.29100.jhb@freebsd.org> <51433D30.30405@freebsd.org> <201303151703.09688.jhb@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rmacklem@uoguelph.ca, freebsd-current@freebsd.org, bright@mu.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 12:40:46 -0000 On 16.03.2013 01:44, Peter Wemm wrote: > On Fri, Mar 15, 2013 at 2:03 PM, John Baldwin wrote: >> On Friday, March 15, 2013 11:24:32 am Andre Oppermann wrote: >>> On 15.03.2013 14:46, John Baldwin wrote: >>>> On Friday, March 15, 2013 9:40:56 am Andre Oppermann wrote: >>>>> Hi Rick, all, >>>>> >>>>> is there a plan to decide for one NFS implementation for FreeBSD 10.0, >>>>> or to keep both around indefinately? >>>>> >>>>> I'm talking about: >>>>> oldNFS in sys/{nfs, nfsclient, nfsserver} NFSv2+NFSv3 >>>>> newNFS in sys/fs/{nfs, nfsclient, nfsserver} NFSv2+NFSv3+NFSv4 >>>>> >>>>> NewNFS supports newer NFS standards and seems to have proven itself in >>>>> some quite heavy traffic environments. >>>>> >>>>> Is there any reason to keep oldNFS around other than nostalgic? >>>> >>>> It can probably be removed. It's kind of handy to keep around as long as 8.x >>>> is around since it uses oldNFS by default as it makes merging bugfixes to the >>>> NFS client a bit easier (you fix both clients in HEAD and can then just svn >>>> merge both of those to 8 and 9). Having several fixes to the NFS client >>>> recently and being in a position of still using 8.x with oldNFS in production, >>>> I would prefer to not remove it quite yet. >>> >>> Do you have a timeframe on the sunset of oldNFS in HEAD so we can communicate >>> a) that oldNFS won't be in 10.0; and b) it will go on date X? >> >> I thought I implied one above: when 8.x is EOL'd. However, that has more to do >> with developer convience. It's actually a PITA to use the old NFS client even >> on 9.0. > > Yes to both. As somebody who uses oldNFS in production in 9.x, I can > vouch for that. Sounds like we have a plan. > Personally I'd like to see oldnfs go away from head after a > comfortable dust-settling period 8.4-R and then call it a day. Since 8.4-R is scheduled for this year(-ish), actually for mid-April, that would put OldNFS going away around mid to later summer 2013. Current users of OldNFS on 10-CURRENT should start to test NewNFS and report any issues they find. The maintainer of NewNFS is very responsive and tries hard to fix problems given a sufficient precise problem report. Users of OldNFS on 9-STABLE should also start to test NewNFS and report any issues, especially divergent behavior to OldNFS. > Although, please, as part of this please hunt down and s/newnfs/nfs/g > in the process. This should be done well before 10.x so loose ends > can be tracked down and fixed. Later summer 2013 fits very well with this and gives about 4 month's of leading time for a theoretical start of the 10.0 release process. This seems to be the majority consensus unless someone forcefully objects on technical grounds and is willing to provide quality input to help fixing NewNFS regressions. -- Andre From owner-freebsd-current@FreeBSD.ORG Mon Mar 18 12:43:31 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1FB35F99 for ; Mon, 18 Mar 2013 12:43:31 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 86F9B892 for ; Mon, 18 Mar 2013 12:43:30 +0000 (UTC) Received: (qmail 113 invoked from network); 18 Mar 2013 13:54:58 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 18 Mar 2013 13:54:58 -0000 Message-ID: <51470BEC.5090304@freebsd.org> Date: Mon, 18 Mar 2013 13:43:24 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: peter@holm.cc Subject: Re: NewNFS vs. oldNFS for 10.0? References: <1547734002.3937074.1363356520474.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1547734002.3937074.1363356520474.JavaMail.root@erie.cs.uoguelph.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Rick Macklem , Lars Eggert , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 12:43:31 -0000 On 15.03.2013 15:08, Rick Macklem wrote: > Lars Eggert wrote: >> Hi, >> >> this reminds me that I ran into an issue lately with the new NFS and >> locking for NFSv3 mounts on a client that ran -CURRENT and a server >> that ran -STABLE. >> >> When I ran "portmaster -a" on the client, which mounted /usr/ports and >> /usr/local, as well as the location of the respective sqlite databases >> over NFSv3, the client network stack became unresponsive on all >> interfaces for 30 or so seconds and e.g. SSH connections broke. The >> serial console remained active throughout, and the system didn't >> crash. About a minute after the wedgie I could SSH into the box again, >> too. >> >> The issue went away when I killed lockd on the client, but that caused >> the sqlite database to become corrupted over time. The workaround for >> me was to move to NFSv4, which has been working fine. (One more reason >> to make it the default...) >> > I've mentioned limitations w.r.t. the design of the NLM protocol (rpc.lockd) > before. Any time there is any kind of network topology issue, it will run > into difficulties. There may also be other issues. > > However, since both the old and new client use the same rpc.lockd in the > same way (the new one just cribbed the code from the old one), I think > the same problem would exist for the old one. As such, I don't believe > this is a regression. Maybe we can talk Peter Holm into periodically running his file system stress test suite against NFS too? :-) Peter? -- Andre From owner-freebsd-current@FreeBSD.ORG Mon Mar 18 13:26:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C6DC0BBD for ; Mon, 18 Mar 2013 13:26:26 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id 9AFBDA64 for ; Mon, 18 Mar 2013 13:26:26 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0MJU00B00Y4PXI00@smtpauth1.wiscmail.wisc.edu> for freebsd-current@freebsd.org; Mon, 18 Mar 2013 08:26:19 -0500 (CDT) X-Spam-PmxInfo: Server=avs-1, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.18.131815, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from wanderer.tachypleus.net (adsl-76-208-67-228.dsl.mdsnwi.sbcglobal.net [76.208.67.228]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0MJU00071YNTBO40@smtpauth1.wiscmail.wisc.edu> for freebsd-current@freebsd.org; Mon, 18 Mar 2013 08:26:18 -0500 (CDT) X-Wisc-Sender: whitehorn@wisc.edu Message-id: <514715F9.2080506@freebsd.org> Date: Mon, 18 Mar 2013 08:26:17 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130223 Thunderbird/17.0.3 To: freebsd-current@freebsd.org Subject: Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots References: <35878.1363607691@critter.freebsd.dk> In-reply-to: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 13:26:26 -0000 On 03/18/13 07:18, Mehmet Erol Sanliturk wrote: > On Mon, Mar 18, 2013 at 4:54 AM, Poul-Henning Kamp wrote: > >> In message > DjjMoe5ttGA@mail.gmail.com>, Tom Evans writes: >> >>> You say this, have you actually measured/checked. sysutils/dmidecode >>> will interrogate your BIOS and tell us what it thinks is installed in >>> each RAM socket. It is not uncommon for RAM to say one thing on the >>> outside, and report something completely different to the BIOS. >> >> I can only second Tom's call for a proper scientific approach to >> debugging this issue, rather than just assume that it is the >> operating systems fault. >> >> -- >> 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. >> > > > I am a graduate of Operations Research and Statistics option of a > Mathematics department . > All of your considerations are considered . It is so much apparent that , > the cause is FreeBSD . > > In my previous year message and in its subsequent messages , there are > sufficiently detailed information . > > > This message is caused from the following fact : > > In previous year case , KDE used was a cause , but FluxBox was working fast > . > Now , I have installed 10.0 current . It does not have KDE in packages . I > have installed FluxBox . > It is not a few second slow : Many minutes to start Firefox , and activate > a menu of it ! > > What is the point of measuring milliseconds when the difference is around > many minutes ? > > PC-BSD installation ( it is a graphical installation after starting X ) is > taking many hours to reach 20 percent completion . > The same is for GhostBSD : Start it at night , at the next morning , it is > likely that it is not finished yet . > > > Then : WQhat will be measured ? > > Linux installations are around 30 minutes . > Starting/Opening menus are instantenous : I do no have chronometer , but > everything is within a second . > > > Thank you very much . The problem is that "slow" doesn't mean anything. An incomplete list of things it might be related to: 1. Something to do with the way KDE is built (options, system compiler) 2. A disk I/O issue 3. A memory speed issue 4. Some other process using CPU that isn't running on Linux 5. A scheduler issue triggered by some property of the machine Doing some of these smaller tests will help pin down which of these are causing the problem. Without that, there's no possibility to even start debugging. Even just running top and seeing whether you are spinning in a user thread, in the kernel, or waiting while the slow things are happening would be extremely helpful. -Nathan From owner-freebsd-current@FreeBSD.ORG Mon Mar 18 14:27:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7F50DD3C; Mon, 18 Mar 2013 14:27:40 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by mx1.freebsd.org (Postfix) with ESMTP id 03763DFB; Mon, 18 Mar 2013 14:27:39 +0000 (UTC) Received: by mail-vc0-f172.google.com with SMTP id hr11so2963131vcb.17 for ; Mon, 18 Mar 2013 07:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=38I3sVwA8+zcG7YuUOppaWqjzz2bvtq54L958yBo5tM=; b=p3aDn4G7DT0RWViLuiZEYm9nn+wSqH4sP8zRkaKJAhTr3lNwzN1CWTWLPiGshq9DT2 RciMNTx8qjOSPyLinA+eWLTP5aUiqm+JizZQUolA/9gvhxXNmP1W/TIdcjboOglnbptA 60xPxwAy9ducQDDwy3nijgQKmdLUPREr3min4ag9MPdDG7Nypz12A3REcge99bn1SnUr zAgxB+ojWWwncRl7NxqP+nRnRAQo1hVU4sZ9Ly/VjoZ1LRaibYXNr0pBaSLxAUGwWMWj zFk+d92sjsQq6Os18wsQA3YfpF5SGhCRHHAtCGT+3knFjFdFTCbyClhrp6MKirYrjAAT CAMw== MIME-Version: 1.0 X-Received: by 10.52.68.116 with SMTP id v20mr17027453vdt.126.1363616858871; Mon, 18 Mar 2013 07:27:38 -0700 (PDT) Received: by 10.58.132.203 with HTTP; Mon, 18 Mar 2013 07:27:38 -0700 (PDT) In-Reply-To: <514715F9.2080506@freebsd.org> References: <35878.1363607691@critter.freebsd.dk> <514715F9.2080506@freebsd.org> Date: Mon, 18 Mar 2013 07:27:38 -0700 Message-ID: Subject: Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots From: Mehmet Erol Sanliturk To: Nathan Whitehorn Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 14:27:40 -0000 On Mon, Mar 18, 2013 at 6:26 AM, Nathan Whitehorn wrote: > On 03/18/13 07:18, Mehmet Erol Sanliturk wrote: > > On Mon, Mar 18, 2013 at 4:54 AM, Poul-Henning Kamp >wrote: > > > >> In message >> DjjMoe5ttGA@mail.gmail.com>, Tom Evans writes: > >> > >>> You say this, have you actually measured/checked. sysutils/dmidecode > >>> will interrogate your BIOS and tell us what it thinks is installed in > >>> each RAM socket. It is not uncommon for RAM to say one thing on the > >>> outside, and report something completely different to the BIOS. > >> > >> I can only second Tom's call for a proper scientific approach to > >> debugging this issue, rather than just assume that it is the > >> operating systems fault. > >> > >> -- > >> 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. > >> > > > > > > I am a graduate of Operations Research and Statistics option of a > > Mathematics department . > > All of your considerations are considered . It is so much apparent that , > > the cause is FreeBSD . > > > > In my previous year message and in its subsequent messages , there are > > sufficiently detailed information . > > > > > > This message is caused from the following fact : > > > > In previous year case , KDE used was a cause , but FluxBox was working > fast > > . > > Now , I have installed 10.0 current . It does not have KDE in packages . > I > > have installed FluxBox . > > It is not a few second slow : Many minutes to start Firefox , and > activate > > a menu of it ! > > > > What is the point of measuring milliseconds when the difference is around > > many minutes ? > > > > PC-BSD installation ( it is a graphical installation after starting X ) > is > > taking many hours to reach 20 percent completion . > > The same is for GhostBSD : Start it at night , at the next morning , it > is > > likely that it is not finished yet . > > > > > > Then : WQhat will be measured ? > > > > Linux installations are around 30 minutes . > > Starting/Opening menus are instantenous : I do no have chronometer , but > > everything is within a second . > > > > > > Thank you very much . > > The problem is that "slow" doesn't mean anything. An incomplete list of > things it might be related to: > 1. Something to do with the way KDE is built (options, system compiler) > 2. A disk I/O issue > 3. A memory speed issue > 4. Some other process using CPU that isn't running on Linux > 5. A scheduler issue triggered by some property of the machine > > Doing some of these smaller tests will help pin down which of these are > causing the problem. Without that, there's no possibility to even start > debugging. Even just running top and seeing whether you are spinning in > a user thread, in the kernel, or waiting while the slow things are > happening would be extremely helpful. > -Nathan > _______________________________________________ > > In the following messages , there are some values for possible combinations on two identical main boards with 2 and 4 core processors : http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031836.html http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031912.html http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031928.html http://lists.freebsd.org/pipermail/freebsd-current/2012-February/032012.html FreeBSD 9.1 Stable ( 2013-03-09 ) top in console mode : Load averages : 0.22 0.53 0.28 33 processes , 1 running , 32 sleeping CPU : 1.5 ... 3.5 % user 0.0 % nice 0.6 .. 1.5 % system 0.0 ... 0.4 interrupt ~ 0.95 % idle top in X + FluxBox : Load averages : 0.22 0.53 0.28 xterm ( top ) xterm ( Firefox ) 44 processes , 1 running , 43 sleeping CPU : 1.5 ... 3.5 % user 0.0 % nice 0.0 .. 1.5 % system 0.0 ... 0.4 interrupt ~ 0.96 % idle When there is no user activity : Sometimes % user is increasing , % idle decreasing . When anything clicked in Firefox % user increasing , % idle decreasing . Response is slow ( to open a menu sometimes reaching to minute ) . Closing a menu is taking many seconds . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Mon Mar 18 14:45:46 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 106FA90E; Mon, 18 Mar 2013 14:45:46 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) by mx1.freebsd.org (Postfix) with ESMTP id B1A2AEF5; Mon, 18 Mar 2013 14:45:45 +0000 (UTC) Received: by mail-vc0-f181.google.com with SMTP id hv10so3017752vcb.12 for ; Mon, 18 Mar 2013 07:45:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Bp87gWuMewmrpit9AKqe+N6lrEwc/Jh3Bz1ClmdrWVw=; b=YrG4BwEhV/5MrmAkN5z8BwYzRJS8cDphkkExNxeNgICmsblfZYAu4J7ikF1VLqXPcb AD/rN4PWnpg4hk6vTgoDu4hKZ3toVbHLnlpknECNCVAltg4GMGeTUegInY8zhEGEcdHZ HPw1g7zc9lgFqRBbqtYW5vBv+sYmOrD4VmluTJ7LyLQxvPACCeBYN8hds74naFVetmAC rfNVHXSbMO/Rhqmt4GMBLyJ0cHSRbtLrihVmw+vt64jhgaJ5CYDRuibWmbQIGkDBdMDH yALTgK60UlX/cC/oBbyT4WDgFzprNUYgO2FKFqxQB7tbwZkgawam2UQQUyXtSLSp9wPc mx6w== MIME-Version: 1.0 X-Received: by 10.220.242.73 with SMTP id lh9mr19445063vcb.49.1363617944978; Mon, 18 Mar 2013 07:45:44 -0700 (PDT) Received: by 10.58.132.203 with HTTP; Mon, 18 Mar 2013 07:45:44 -0700 (PDT) In-Reply-To: <514715F9.2080506@freebsd.org> References: <35878.1363607691@critter.freebsd.dk> <514715F9.2080506@freebsd.org> Date: Mon, 18 Mar 2013 07:45:44 -0700 Message-ID: Subject: Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots From: Mehmet Erol Sanliturk To: Nathan Whitehorn Content-Type: multipart/mixed; boundary=14dae9cdcaad384cae04d8340bf5 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 14:45:46 -0000 --14dae9cdcaad384cae04d8340bf5 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 18, 2013 at 6:26 AM, Nathan Whitehorn wrote: > On 03/18/13 07:18, Mehmet Erol Sanliturk wrote: > > On Mon, Mar 18, 2013 at 4:54 AM, Poul-Henning Kamp >wrote: > > > >> In message >> DjjMoe5ttGA@mail.gmail.com>, Tom Evans writes: > >> > >>> You say this, have you actually measured/checked. sysutils/dmidecode > >>> will interrogate your BIOS and tell us what it thinks is installed in > >>> each RAM socket. It is not uncommon for RAM to say one thing on the > >>> outside, and report something completely different to the BIOS. > >> > >> I can only second Tom's call for a proper scientific approach to > >> debugging this issue, rather than just assume that it is the > >> operating systems fault. > >> > >> -- > >> 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. > >> > > > > > > I am a graduate of Operations Research and Statistics option of a > > Mathematics department . > > All of your considerations are considered . It is so much apparent that , > > the cause is FreeBSD . > > > > In my previous year message and in its subsequent messages , there are > > sufficiently detailed information . > > > > > > This message is caused from the following fact : > > > > In previous year case , KDE used was a cause , but FluxBox was working > fast > > . > > Now , I have installed 10.0 current . It does not have KDE in packages . > I > > have installed FluxBox . > > It is not a few second slow : Many minutes to start Firefox , and > activate > > a menu of it ! > > > > What is the point of measuring milliseconds when the difference is around > > many minutes ? > > > > PC-BSD installation ( it is a graphical installation after starting X ) > is > > taking many hours to reach 20 percent completion . > > The same is for GhostBSD : Start it at night , at the next morning , it > is > > likely that it is not finished yet . > > > > > > Then : WQhat will be measured ? > > > > Linux installations are around 30 minutes . > > Starting/Opening menus are instantenous : I do no have chronometer , but > > everything is within a second . > > > > > > Thank you very much . > > The problem is that "slow" doesn't mean anything. An incomplete list of > things it might be related to: > 1. Something to do with the way KDE is built (options, system compiler) > 2. A disk I/O issue > 3. A memory speed issue > 4. Some other process using CPU that isn't running on Linux > 5. A scheduler issue triggered by some property of the machine > > Doing some of these smaller tests will help pin down which of these are > causing the problem. Without that, there's no possibility to even start > debugging. Even just running top and seeing whether you are spinning in > a user thread, in the kernel, or waiting while the slow things are > happening would be extremely helpful. > -Nathan > _______________________________________________ > > The dmidecode output is attached . Thank you very much . Mehmet Erol Sanliturk --14dae9cdcaad384cae04d8340bf5 Content-Type: text/plain; charset=US-ASCII; name="dmidecode_output.txt" Content-Disposition: attachment; filename="dmidecode_output.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_heg5swk30 IyBkbWlkZWNvZGUgMi4xMQpTTUJJT1MgMi40IHByZXNlbnQuCjM5IHN0cnVjdHVyZXMgb2NjdXB5 aW5nIDE3OTQgYnl0ZXMuClRhYmxlIGF0IDB4MDAwRTMyRjAuCgpIYW5kbGUgMHgwMDAwLCBETUkg dHlwZSA0LCAzNSBieXRlcwpQcm9jZXNzb3IgSW5mb3JtYXRpb24KCVNvY2tldCBEZXNpZ25hdGlv bjogTEdBIDc3NQoJVHlwZTogQ2VudHJhbCBQcm9jZXNzb3IKCUZhbWlseTogUGVudGl1bSBECglN YW51ZmFjdHVyZXI6IEludGVsKFIpIENvcnBvcmF0aW9uCglJRDogRkQgMDYgMDAgMDAgRkYgRkIg RUIgQkYKCVNpZ25hdHVyZTogVHlwZSAwLCBGYW1pbHkgNiwgTW9kZWwgMTUsIFN0ZXBwaW5nIDEz CglGbGFnczoKCQlGUFUgKEZsb2F0aW5nLXBvaW50IHVuaXQgb24tY2hpcCkKCQlWTUUgKFZpcnR1 YWwgbW9kZSBleHRlbnNpb24pCgkJREUgKERlYnVnZ2luZyBleHRlbnNpb24pCgkJUFNFIChQYWdl IHNpemUgZXh0ZW5zaW9uKQoJCVRTQyAoVGltZSBzdGFtcCBjb3VudGVyKQoJCU1TUiAoTW9kZWwg c3BlY2lmaWMgcmVnaXN0ZXJzKQoJCVBBRSAoUGh5c2ljYWwgYWRkcmVzcyBleHRlbnNpb24pCgkJ TUNFIChNYWNoaW5lIGNoZWNrIGV4Y2VwdGlvbikKCQlDWDggKENNUFhDSEc4IGluc3RydWN0aW9u IHN1cHBvcnRlZCkKCQlBUElDIChPbi1jaGlwIEFQSUMgaGFyZHdhcmUgc3VwcG9ydGVkKQoJCVNF UCAoRmFzdCBzeXN0ZW0gY2FsbCkKCQlNVFJSIChNZW1vcnkgdHlwZSByYW5nZSByZWdpc3RlcnMp CgkJUEdFIChQYWdlIGdsb2JhbCBlbmFibGUpCgkJTUNBIChNYWNoaW5lIGNoZWNrIGFyY2hpdGVj dHVyZSkKCQlDTU9WIChDb25kaXRpb25hbCBtb3ZlIGluc3RydWN0aW9uIHN1cHBvcnRlZCkKCQlQ QVQgKFBhZ2UgYXR0cmlidXRlIHRhYmxlKQoJCVBTRS0zNiAoMzYtYml0IHBhZ2Ugc2l6ZSBleHRl bnNpb24pCgkJQ0xGU0ggKENMRkxVU0ggaW5zdHJ1Y3Rpb24gc3VwcG9ydGVkKQoJCURTIChEZWJ1 ZyBzdG9yZSkKCQlBQ1BJIChBQ1BJIHN1cHBvcnRlZCkKCQlNTVggKE1NWCB0ZWNobm9sb2d5IHN1 cHBvcnRlZCkKCQlGWFNSIChGWFNBVkUgYW5kIEZYU1RPUiBpbnN0cnVjdGlvbnMgc3VwcG9ydGVk KQoJCVNTRSAoU3RyZWFtaW5nIFNJTUQgZXh0ZW5zaW9ucykKCQlTU0UyIChTdHJlYW1pbmcgU0lN RCBleHRlbnNpb25zIDIpCgkJU1MgKFNlbGYtc25vb3ApCgkJSFRUIChNdWx0aS10aHJlYWRpbmcp CgkJVE0gKFRoZXJtYWwgbW9uaXRvciBzdXBwb3J0ZWQpCgkJUEJFIChQZW5kaW5nIGJyZWFrIGVu YWJsZWQpCglWZXJzaW9uOiBJbnRlbChSKSBQZW50aXVtKFIpIER1YWwgIENQVSAgRTIyMjAgIEAg Mi40MEdIegoJVm9sdGFnZTogMS42IFYKCUV4dGVybmFsIENsb2NrOiAyMDAgTUh6CglNYXggU3Bl ZWQ6IDQwMDAgTUh6CglDdXJyZW50IFNwZWVkOiAyNDAwIE1IegoJU3RhdHVzOiBQb3B1bGF0ZWQs IEVuYWJsZWQKCVVwZ3JhZGU6IFNvY2tldCBMR0E3NzUKCUwxIENhY2hlIEhhbmRsZTogMHgwMDAz CglMMiBDYWNoZSBIYW5kbGU6IDB4MDAwMQoJTDMgQ2FjaGUgSGFuZGxlOiBOb3QgUHJvdmlkZWQK CVNlcmlhbCBOdW1iZXI6IE5vdCBTcGVjaWZpZWQKCUFzc2V0IFRhZzogTm90IFNwZWNpZmllZAoJ UGFydCBOdW1iZXI6IE5vdCBTcGVjaWZpZWQKCkhhbmRsZSAweDAwMDEsIERNSSB0eXBlIDcsIDE5 IGJ5dGVzCkNhY2hlIEluZm9ybWF0aW9uCglTb2NrZXQgRGVzaWduYXRpb246IFVua25vd24KCUNv bmZpZ3VyYXRpb246IEVuYWJsZWQsIE5vdCBTb2NrZXRlZCwgTGV2ZWwgMgoJT3BlcmF0aW9uYWwg TW9kZTogV3JpdGUgQmFjawoJTG9jYXRpb246IEludGVybmFsCglJbnN0YWxsZWQgU2l6ZTogMTAy NCBrQgoJTWF4aW11bSBTaXplOiAxMDI0IGtCCglTdXBwb3J0ZWQgU1JBTSBUeXBlczoKCQlBc3lu Y2hyb25vdXMKCUluc3RhbGxlZCBTUkFNIFR5cGU6IEFzeW5jaHJvbm91cwoJU3BlZWQ6IFVua25v d24KCUVycm9yIENvcnJlY3Rpb24gVHlwZTogU2luZ2xlLWJpdCBFQ0MKCVN5c3RlbSBUeXBlOiBV bmlmaWVkCglBc3NvY2lhdGl2aXR5OiA0LXdheSBTZXQtYXNzb2NpYXRpdmUKCkhhbmRsZSAweDAw MDIsIERNSSB0eXBlIDcsIDE5IGJ5dGVzCkNhY2hlIEluZm9ybWF0aW9uCglTb2NrZXQgRGVzaWdu YXRpb246IFVua25vd24KCUNvbmZpZ3VyYXRpb246IEVuYWJsZWQsIE5vdCBTb2NrZXRlZCwgTGV2 ZWwgMQoJT3BlcmF0aW9uYWwgTW9kZTogV3JpdGUgQmFjawoJTG9jYXRpb246IEludGVybmFsCglJ bnN0YWxsZWQgU2l6ZTogMzIga0IKCU1heGltdW0gU2l6ZTogMzIga0IKCVN1cHBvcnRlZCBTUkFN IFR5cGVzOgoJCUFzeW5jaHJvbm91cwoJSW5zdGFsbGVkIFNSQU0gVHlwZTogQXN5bmNocm9ub3Vz CglTcGVlZDogVW5rbm93bgoJRXJyb3IgQ29ycmVjdGlvbiBUeXBlOiBTaW5nbGUtYml0IEVDQwoJ U3lzdGVtIFR5cGU6IEluc3RydWN0aW9uCglBc3NvY2lhdGl2aXR5OiA4LXdheSBTZXQtYXNzb2Np YXRpdmUKCkhhbmRsZSAweDAwMDMsIERNSSB0eXBlIDcsIDE5IGJ5dGVzCkNhY2hlIEluZm9ybWF0 aW9uCglTb2NrZXQgRGVzaWduYXRpb246IFVua25vd24KCUNvbmZpZ3VyYXRpb246IEVuYWJsZWQs IE5vdCBTb2NrZXRlZCwgTGV2ZWwgMQoJT3BlcmF0aW9uYWwgTW9kZTogV3JpdGUgQmFjawoJTG9j YXRpb246IEludGVybmFsCglJbnN0YWxsZWQgU2l6ZTogMzIga0IKCU1heGltdW0gU2l6ZTogMzIg a0IKCVN1cHBvcnRlZCBTUkFNIFR5cGVzOgoJCUFzeW5jaHJvbm91cwoJSW5zdGFsbGVkIFNSQU0g VHlwZTogQXN5bmNocm9ub3VzCglTcGVlZDogVW5rbm93bgoJRXJyb3IgQ29ycmVjdGlvbiBUeXBl OiBTaW5nbGUtYml0IEVDQwoJU3lzdGVtIFR5cGU6IERhdGEKCUFzc29jaWF0aXZpdHk6IDgtd2F5 IFNldC1hc3NvY2lhdGl2ZQoKSGFuZGxlIDB4MDAwNCwgRE1JIHR5cGUgMCwgMjQgYnl0ZXMKQklP UyBJbmZvcm1hdGlvbgoJVmVuZG9yOiBJbnRlbCBDb3JwLgoJVmVyc2lvbjogTVE5NjUxMEouODZB LjE3MDUuMjAwNy4wOTAyLjE4NTAKCVJlbGVhc2UgRGF0ZTogMDkvMDIvMjAwNwoJQWRkcmVzczog MHhGMDAwMAoJUnVudGltZSBTaXplOiA2NCBrQgoJUk9NIFNpemU6IDEwMjQga0IKCUNoYXJhY3Rl cmlzdGljczoKCQlQQ0kgaXMgc3VwcG9ydGVkCgkJQklPUyBpcyB1cGdyYWRlYWJsZQoJCUJJT1Mg c2hhZG93aW5nIGlzIGFsbG93ZWQKCQlCb290IGZyb20gQ0QgaXMgc3VwcG9ydGVkCgkJU2VsZWN0 YWJsZSBib290IGlzIHN1cHBvcnRlZAoJCUVERCBpcyBzdXBwb3J0ZWQKCQk4MDQyIGtleWJvYXJk IHNlcnZpY2VzIGFyZSBzdXBwb3J0ZWQgKGludCA5aCkKCQlTZXJpYWwgc2VydmljZXMgYXJlIHN1 cHBvcnRlZCAoaW50IDE0aCkKCQlQcmludGVyIHNlcnZpY2VzIGFyZSBzdXBwb3J0ZWQgKGludCAx N2gpCgkJQ0dBL21vbm8gdmlkZW8gc2VydmljZXMgYXJlIHN1cHBvcnRlZCAoaW50IDEwaCkKCQlB Q1BJIGlzIHN1cHBvcnRlZAoJCVVTQiBsZWdhY3kgaXMgc3VwcG9ydGVkCgkJQVRBUEkgWmlwIGRy aXZlIGJvb3QgaXMgc3VwcG9ydGVkCgkJQklPUyBib290IHNwZWNpZmljYXRpb24gaXMgc3VwcG9y dGVkCgkJRnVuY3Rpb24ga2V5LWluaXRpYXRlZCBuZXR3b3JrIGJvb3QgaXMgc3VwcG9ydGVkCgkJ VGFyZ2V0ZWQgY29udGVudCBkaXN0cmlidXRpb24gaXMgc3VwcG9ydGVkCglCSU9TIFJldmlzaW9u OiAwLjAKCUZpcm13YXJlIFJldmlzaW9uOiAwLjAKCkhhbmRsZSAweDAwMDUsIERNSSB0eXBlIDEs IDI3IGJ5dGVzClN5c3RlbSBJbmZvcm1hdGlvbgoJTWFudWZhY3R1cmVyOiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAoJUHJvZHVjdCBOYW1lOiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAoJVmVyc2lvbjogICAgICAgICAgICAgICAgICAgICAgICAgCglTZXJpYWwgTnVt YmVyOiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAoJVVVJRDogNTNCMzZCQkEtOEUz RS0xMURDLTkxMUUtMDAwRUE2OEY3MjUyCglXYWtlLXVwIFR5cGU6IFBvd2VyIFN3aXRjaAoJU0tV IE51bWJlcjogTm90IFNwZWNpZmllZAoJRmFtaWx5OiBOb3QgU3BlY2lmaWVkCgpIYW5kbGUgMHgw MDA2LCBETUkgdHlwZSAyLCAyMCBieXRlcwpCYXNlIEJvYXJkIEluZm9ybWF0aW9uCglNYW51ZmFj dHVyZXI6IEludGVsIENvcnBvcmF0aW9uCglQcm9kdWN0IE5hbWU6IERHOTY1V0gKCVZlcnNpb246 IEFBRDQxNjkyLTMxMAoJU2VyaWFsIE51bWJlcjogQlFXSDc0NTAwMFZHCglBc3NldCBUYWc6IEJh c2UgQm9hcmQgQXNzZXQgVGFnCglGZWF0dXJlczoKCQlCb2FyZCBpcyBhIGhvc3RpbmcgYm9hcmQK CQlCb2FyZCBpcyByZXBsYWNlYWJsZQoJTG9jYXRpb24gSW4gQ2hhc3NpczogQmFzZSBCb2FyZCBD aGFzc2lzIExvY2F0aW9uCglDaGFzc2lzIEhhbmRsZTogMHgwMDA3CglUeXBlOiBVbmtub3duCglD b250YWluZWQgT2JqZWN0IEhhbmRsZXM6IDAKCkhhbmRsZSAweDAwMDcsIERNSSB0eXBlIDMsIDE3 IGJ5dGVzCkNoYXNzaXMgSW5mb3JtYXRpb24KCU1hbnVmYWN0dXJlcjogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAKCVR5cGU6IERlc2t0b3AKCUxvY2s6IE5vdCBQcmVzZW50CglWZXJz aW9uOiAgICAgICAgICAgICAgICAgICAgICAgICAKCVNlcmlhbCBOdW1iZXI6ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCglBc3NldCBUYWc6ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgCglCb290LXVwIFN0YXRlOiBTYWZlCglQb3dlciBTdXBwbHkgU3RhdGU6IFNhZmUK CVRoZXJtYWwgU3RhdGU6IE90aGVyCglTZWN1cml0eSBTdGF0dXM6IE90aGVyCglPRU0gSW5mb3Jt YXRpb246IDB4MDAwMDAwMDAKCkhhbmRsZSAweDAwMDgsIERNSSB0eXBlIDgsIDkgYnl0ZXMKUG9y dCBDb25uZWN0b3IgSW5mb3JtYXRpb24KCUludGVybmFsIFJlZmVyZW5jZSBEZXNpZ25hdG9yOiBQ UklNQVJZCglJbnRlcm5hbCBDb25uZWN0b3IgVHlwZTogT24gQm9hcmQgSURFCglFeHRlcm5hbCBS ZWZlcmVuY2UgRGVzaWduYXRvcjogTm90IFNwZWNpZmllZAoJRXh0ZXJuYWwgQ29ubmVjdG9yIFR5 cGU6IE5vbmUKCVBvcnQgVHlwZTogT3RoZXIKCkhhbmRsZSAweDAwMDksIERNSSB0eXBlIDgsIDkg Ynl0ZXMKUG9ydCBDb25uZWN0b3IgSW5mb3JtYXRpb24KCUludGVybmFsIFJlZmVyZW5jZSBEZXNp Z25hdG9yOiBTRUNPTkRBUlkKCUludGVybmFsIENvbm5lY3RvciBUeXBlOiBPbiBCb2FyZCBJREUK CUV4dGVybmFsIFJlZmVyZW5jZSBEZXNpZ25hdG9yOiBOb3QgU3BlY2lmaWVkCglFeHRlcm5hbCBD b25uZWN0b3IgVHlwZTogTm9uZQoJUG9ydCBUeXBlOiBPdGhlcgoKSGFuZGxlIDB4MDAwQSwgRE1J IHR5cGUgOCwgOSBieXRlcwpQb3J0IENvbm5lY3RvciBJbmZvcm1hdGlvbgoJSW50ZXJuYWwgUmVm ZXJlbmNlIERlc2lnbmF0b3I6IEFUWF9QV1IKCUludGVybmFsIENvbm5lY3RvciBUeXBlOiBPdGhl cgoJRXh0ZXJuYWwgUmVmZXJlbmNlIERlc2lnbmF0b3I6IE5vdCBTcGVjaWZpZWQKCUV4dGVybmFs IENvbm5lY3RvciBUeXBlOiBOb25lCglQb3J0IFR5cGU6IE90aGVyCgpIYW5kbGUgMHgwMDBCLCBE TUkgdHlwZSA5LCAxMyBieXRlcwpTeXN0ZW0gU2xvdCBJbmZvcm1hdGlvbgoJRGVzaWduYXRpb246 IFBDSUUgWDE2IFNMT1QKCVR5cGU6IHgxNiBQQ0kgRXhwcmVzcwoJQ3VycmVudCBVc2FnZTogQXZh aWxhYmxlCglMZW5ndGg6IFNob3J0CglJRDogMTEKCUNoYXJhY3RlcmlzdGljczoKCQkzLjMgViBp cyBwcm92aWRlZAoKSGFuZGxlIDB4MDAwQywgRE1JIHR5cGUgOSwgMTMgYnl0ZXMKU3lzdGVtIFNs b3QgSW5mb3JtYXRpb24KCURlc2lnbmF0aW9uOiBQQ0lFIFgxIFNMT1QgMQoJVHlwZTogeDEgUENJ IEV4cHJlc3MKCUN1cnJlbnQgVXNhZ2U6IEF2YWlsYWJsZQoJTGVuZ3RoOiBTaG9ydAoJSUQ6IDEy CglDaGFyYWN0ZXJpc3RpY3M6CgkJMy4zIFYgaXMgcHJvdmlkZWQKCQlQTUUgc2lnbmFsIGlzIHN1 cHBvcnRlZAoJCVNNQnVzIHNpZ25hbCBpcyBzdXBwb3J0ZWQKCkhhbmRsZSAweDAwMEQsIERNSSB0 eXBlIDksIDEzIGJ5dGVzClN5c3RlbSBTbG90IEluZm9ybWF0aW9uCglEZXNpZ25hdGlvbjogUENJ RSBYMSBTTE9UIDIKCVR5cGU6IHgxIFBDSSBFeHByZXNzCglDdXJyZW50IFVzYWdlOiBBdmFpbGFi bGUKCUxlbmd0aDogU2hvcnQKCUlEOiAxMwoJQ2hhcmFjdGVyaXN0aWNzOgoJCTMuMyBWIGlzIHBy b3ZpZGVkCgkJUE1FIHNpZ25hbCBpcyBzdXBwb3J0ZWQKCQlTTUJ1cyBzaWduYWwgaXMgc3VwcG9y dGVkCgpIYW5kbGUgMHgwMDBFLCBETUkgdHlwZSA5LCAxMyBieXRlcwpTeXN0ZW0gU2xvdCBJbmZv cm1hdGlvbgoJRGVzaWduYXRpb246IFBDSUUgWDEgU0xPVCAzCglUeXBlOiB4MSBQQ0kgRXhwcmVz cwoJQ3VycmVudCBVc2FnZTogQXZhaWxhYmxlCglMZW5ndGg6IFNob3J0CglJRDogMTQKCUNoYXJh Y3RlcmlzdGljczoKCQkzLjMgViBpcyBwcm92aWRlZAoJCVBNRSBzaWduYWwgaXMgc3VwcG9ydGVk CgkJU01CdXMgc2lnbmFsIGlzIHN1cHBvcnRlZAoKSGFuZGxlIDB4MDAwRiwgRE1JIHR5cGUgOSwg MTMgYnl0ZXMKU3lzdGVtIFNsb3QgSW5mb3JtYXRpb24KCURlc2lnbmF0aW9uOiBQQ0kgU0xPVCAx CglUeXBlOiAzMi1iaXQgUENJCglDdXJyZW50IFVzYWdlOiBBdmFpbGFibGUKCUxlbmd0aDogTG9u ZwoJSUQ6IDEKCUNoYXJhY3RlcmlzdGljczoKCQkzLjMgViBpcyBwcm92aWRlZAoJCVBNRSBzaWdu YWwgaXMgc3VwcG9ydGVkCgkJU01CdXMgc2lnbmFsIGlzIHN1cHBvcnRlZAoKSGFuZGxlIDB4MDAx MCwgRE1JIHR5cGUgOSwgMTMgYnl0ZXMKU3lzdGVtIFNsb3QgSW5mb3JtYXRpb24KCURlc2lnbmF0 aW9uOiBQQ0kgU0xPVCAyCglUeXBlOiAzMi1iaXQgUENJCglDdXJyZW50IFVzYWdlOiBJbiBVc2UK CUxlbmd0aDogTG9uZwoJSUQ6IDIKCUNoYXJhY3RlcmlzdGljczoKCQkzLjMgViBpcyBwcm92aWRl ZAoJCVBNRSBzaWduYWwgaXMgc3VwcG9ydGVkCgkJU01CdXMgc2lnbmFsIGlzIHN1cHBvcnRlZAoK SGFuZGxlIDB4MDAxMSwgRE1JIHR5cGUgOSwgMTMgYnl0ZXMKU3lzdGVtIFNsb3QgSW5mb3JtYXRp b24KCURlc2lnbmF0aW9uOiBQQ0kgU0xPVCAzCglUeXBlOiAzMi1iaXQgUENJCglDdXJyZW50IFVz YWdlOiBBdmFpbGFibGUKCUxlbmd0aDogTG9uZwoJSUQ6IDMKCUNoYXJhY3RlcmlzdGljczoKCQkz LjMgViBpcyBwcm92aWRlZAoJCVBNRSBzaWduYWwgaXMgc3VwcG9ydGVkCgkJU01CdXMgc2lnbmFs IGlzIHN1cHBvcnRlZAoKSGFuZGxlIDB4MDAxMiwgRE1JIHR5cGUgMTAsIDYgYnl0ZXMKT24gQm9h cmQgRGV2aWNlIEluZm9ybWF0aW9uCglUeXBlOiBWaWRlbwoJU3RhdHVzOiBFbmFibGVkCglEZXNj cmlwdGlvbjogSW50ZWwoUikgR01BIFgzMDAwIFZpZGVvIERldmljZQoKSGFuZGxlIDB4MDAxMywg RE1JIHR5cGUgMTAsIDYgYnl0ZXMKT24gQm9hcmQgRGV2aWNlIEluZm9ybWF0aW9uCglUeXBlOiBF dGhlcm5ldAoJU3RhdHVzOiBFbmFibGVkCglEZXNjcmlwdGlvbjogSW50ZWwoUikgODI1NjZEQyBH aWdhYml0IEV0aGVybmV0IERldmljZQoKSGFuZGxlIDB4MDAxNCwgRE1JIHR5cGUgMTAsIDYgYnl0 ZXMKT24gQm9hcmQgRGV2aWNlIEluZm9ybWF0aW9uCglUeXBlOiBTb3VuZAoJU3RhdHVzOiBFbmFi bGVkCglEZXNjcmlwdGlvbjogSW50ZWwoUikgSGlnaCBEZWZpbml0aW9uIEF1ZGlvIERldmljZQoK SGFuZGxlIDB4MDAxNSwgRE1JIHR5cGUgMTMsIDIyIGJ5dGVzCkJJT1MgTGFuZ3VhZ2UgSW5mb3Jt YXRpb24KCUxhbmd1YWdlIERlc2NyaXB0aW9uIEZvcm1hdDogQWJicmV2aWF0ZWQKCUluc3RhbGxh YmxlIExhbmd1YWdlczogMQoJCWVuVVMKCUN1cnJlbnRseSBJbnN0YWxsZWQgTGFuZ3VhZ2U6IGVu VVMKCkhhbmRsZSAweDAwMTYsIERNSSB0eXBlIDMyLCAyMCBieXRlcwpTeXN0ZW0gQm9vdCBJbmZv cm1hdGlvbgoJU3RhdHVzOiBObyBlcnJvcnMgZGV0ZWN0ZWQKCkhhbmRsZSAweDAwMTcsIERNSSB0 eXBlIDE2LCAxNSBieXRlcwpQaHlzaWNhbCBNZW1vcnkgQXJyYXkKCUxvY2F0aW9uOiBTeXN0ZW0g Qm9hcmQgT3IgTW90aGVyYm9hcmQKCVVzZTogU3lzdGVtIE1lbW9yeQoJRXJyb3IgQ29ycmVjdGlv biBUeXBlOiBOb25lCglNYXhpbXVtIENhcGFjaXR5OiA4IEdCCglFcnJvciBJbmZvcm1hdGlvbiBI YW5kbGU6IE5vdCBQcm92aWRlZAoJTnVtYmVyIE9mIERldmljZXM6IDQKCkhhbmRsZSAweDAwMTgs IERNSSB0eXBlIDE3LCAyNyBieXRlcwpNZW1vcnkgRGV2aWNlCglBcnJheSBIYW5kbGU6IDB4MDAx NwoJRXJyb3IgSW5mb3JtYXRpb24gSGFuZGxlOiBOb3QgUHJvdmlkZWQKCVRvdGFsIFdpZHRoOiA2 NCBiaXRzCglEYXRhIFdpZHRoOiA2NCBiaXRzCglTaXplOiAxMDI0IE1CCglGb3JtIEZhY3Rvcjog RElNTQoJU2V0OiBOb25lCglMb2NhdG9yOiBKMU1ZCglCYW5rIExvY2F0b3I6IENIQU4gQSBESU1N IDAKCVR5cGU6IEREUjIKCVR5cGUgRGV0YWlsOiBTeW5jaHJvbm91cwoJU3BlZWQ6IDY2NyBNSHoK CU1hbnVmYWN0dXJlcjogMHg3Rjk4MDAwMDAwMDAwMDAwCglTZXJpYWwgTnVtYmVyOiAweDk2MzlB NTc5CglBc3NldCBUYWc6IFVua25vd24KCVBhcnQgTnVtYmVyOiAweDM5Mzk0MzM1MzMzMTM2MkQz MDMyMzYyRTQxMzAzMDRDNDYwMAoKSGFuZGxlIDB4MDAxOSwgRE1JIHR5cGUgMjAsIDE5IGJ5dGVz Ck1lbW9yeSBEZXZpY2UgTWFwcGVkIEFkZHJlc3MKCVN0YXJ0aW5nIEFkZHJlc3M6IDB4MDAwMDAw MDAwMDAKCUVuZGluZyBBZGRyZXNzOiAweDAwMDNGRkZGRkZGCglSYW5nZSBTaXplOiAxIEdCCglQ aHlzaWNhbCBEZXZpY2UgSGFuZGxlOiAweDAwMTgKCU1lbW9yeSBBcnJheSBNYXBwZWQgQWRkcmVz cyBIYW5kbGU6IDB4MDAyMAoJUGFydGl0aW9uIFJvdyBQb3NpdGlvbjogMQoJSW50ZXJsZWF2ZSBQ b3NpdGlvbjogMQoJSW50ZXJsZWF2ZWQgRGF0YSBEZXB0aDogMQoKSGFuZGxlIDB4MDAxQSwgRE1J IHR5cGUgMTcsIDI3IGJ5dGVzCk1lbW9yeSBEZXZpY2UKCUFycmF5IEhhbmRsZTogMHgwMDE3CglF cnJvciBJbmZvcm1hdGlvbiBIYW5kbGU6IE5vdCBQcm92aWRlZAoJVG90YWwgV2lkdGg6IDY0IGJp dHMKCURhdGEgV2lkdGg6IDY0IGJpdHMKCVNpemU6IDIwNDggTUIKCUZvcm0gRmFjdG9yOiBESU1N CglTZXQ6IE5vbmUKCUxvY2F0b3I6IEoyTVkKCUJhbmsgTG9jYXRvcjogQ0hBTiBBIERJTU0gMQoJ VHlwZTogRERSMgoJVHlwZSBEZXRhaWw6IFN5bmNocm9ub3VzCglTcGVlZDogNjY3IE1IegoJTWFu dWZhY3R1cmVyOiAweDdGOTgwMDAwMDAwMDAwMDAKCVNlcmlhbCBOdW1iZXI6IDB4NTcxNTg0NEIK CUFzc2V0IFRhZzogVW5rbm93bgoJUGFydCBOdW1iZXI6IDB4MzI0NzJENTU0NDQ5NEQ0RDAwMDAw MDAwMDAwMDAwMDAwMDAwCgpIYW5kbGUgMHgwMDFCLCBETUkgdHlwZSAyMCwgMTkgYnl0ZXMKTWVt b3J5IERldmljZSBNYXBwZWQgQWRkcmVzcwoJU3RhcnRpbmcgQWRkcmVzczogMHgwMDA0MDAwMDAw MAoJRW5kaW5nIEFkZHJlc3M6IDB4MDAwQkZGRkZGRkYKCVJhbmdlIFNpemU6IDIgR0IKCVBoeXNp Y2FsIERldmljZSBIYW5kbGU6IDB4MDAxQQoJTWVtb3J5IEFycmF5IE1hcHBlZCBBZGRyZXNzIEhh bmRsZTogMHgwMDIwCglQYXJ0aXRpb24gUm93IFBvc2l0aW9uOiAxCglJbnRlcmxlYXZlIFBvc2l0 aW9uOiAxCglJbnRlcmxlYXZlZCBEYXRhIERlcHRoOiAxCgpIYW5kbGUgMHgwMDFDLCBETUkgdHlw ZSAxNywgMjcgYnl0ZXMKTWVtb3J5IERldmljZQoJQXJyYXkgSGFuZGxlOiAweDAwMTcKCUVycm9y IEluZm9ybWF0aW9uIEhhbmRsZTogTm90IFByb3ZpZGVkCglUb3RhbCBXaWR0aDogNjQgYml0cwoJ RGF0YSBXaWR0aDogNjQgYml0cwoJU2l6ZTogMTAyNCBNQgoJRm9ybSBGYWN0b3I6IERJTU0KCVNl dDogTm9uZQoJTG9jYXRvcjogSjNNWQoJQmFuayBMb2NhdG9yOiBDSEFOIEIgRElNTSAwCglUeXBl OiBERFIyCglUeXBlIERldGFpbDogU3luY2hyb25vdXMKCVNwZWVkOiA2NjcgTUh6CglNYW51ZmFj dHVyZXI6IDB4N0Y5ODAwMDAwMDAwMDAwMAoJU2VyaWFsIE51bWJlcjogMHg3RDNBNTFBOAoJQXNz ZXQgVGFnOiBVbmtub3duCglQYXJ0IE51bWJlcjogMHgzOTM5NDMzNTMzMzEzNjJEMzAzMjM2MkU0 MTMwMzA0QzQ2MDAKCkhhbmRsZSAweDAwMUQsIERNSSB0eXBlIDIwLCAxOSBieXRlcwpNZW1vcnkg RGV2aWNlIE1hcHBlZCBBZGRyZXNzCglTdGFydGluZyBBZGRyZXNzOiAweDAwMEMwMDAwMDAwCglF bmRpbmcgQWRkcmVzczogMHgwMDBGRkZGRkZGRgoJUmFuZ2UgU2l6ZTogMSBHQgoJUGh5c2ljYWwg RGV2aWNlIEhhbmRsZTogMHgwMDFDCglNZW1vcnkgQXJyYXkgTWFwcGVkIEFkZHJlc3MgSGFuZGxl OiAweDAwMjAKCVBhcnRpdGlvbiBSb3cgUG9zaXRpb246IDIKCUludGVybGVhdmUgUG9zaXRpb246 IDIKCUludGVybGVhdmVkIERhdGEgRGVwdGg6IDEKCkhhbmRsZSAweDAwMUUsIERNSSB0eXBlIDE3 LCAyNyBieXRlcwpNZW1vcnkgRGV2aWNlCglBcnJheSBIYW5kbGU6IDB4MDAxNwoJRXJyb3IgSW5m b3JtYXRpb24gSGFuZGxlOiBOb3QgUHJvdmlkZWQKCVRvdGFsIFdpZHRoOiA2NCBiaXRzCglEYXRh IFdpZHRoOiA2NCBiaXRzCglTaXplOiAyMDQ4IE1CCglGb3JtIEZhY3RvcjogRElNTQoJU2V0OiBO b25lCglMb2NhdG9yOiBKNE1ZCglCYW5rIExvY2F0b3I6IENIQU4gQiBESU1NIDEKCVR5cGU6IERE UjIKCVR5cGUgRGV0YWlsOiBTeW5jaHJvbm91cwoJU3BlZWQ6IDY2NyBNSHoKCU1hbnVmYWN0dXJl cjogMHg3Rjk4MDAwMDAwMDAwMDAwCglTZXJpYWwgTnVtYmVyOiAweEQyMTZCMjk2CglBc3NldCBU YWc6IFVua25vd24KCVBhcnQgTnVtYmVyOiAweDMyNDcyRDU1NDQ0OTRENEQwMDAwMDAwMDAwMDAw MDAwMDAwMAoKSGFuZGxlIDB4MDAxRiwgRE1JIHR5cGUgMjAsIDE5IGJ5dGVzCk1lbW9yeSBEZXZp Y2UgTWFwcGVkIEFkZHJlc3MKCVN0YXJ0aW5nIEFkZHJlc3M6IDB4MDAxMDAwMDAwMDAKCUVuZGlu ZyBBZGRyZXNzOiAweDAwMTdGRkZGRkZGCglSYW5nZSBTaXplOiAyIEdCCglQaHlzaWNhbCBEZXZp Y2UgSGFuZGxlOiAweDAwMUUKCU1lbW9yeSBBcnJheSBNYXBwZWQgQWRkcmVzcyBIYW5kbGU6IDB4 MDAyMAoJUGFydGl0aW9uIFJvdyBQb3NpdGlvbjogMgoJSW50ZXJsZWF2ZSBQb3NpdGlvbjogMgoJ SW50ZXJsZWF2ZWQgRGF0YSBEZXB0aDogMQoKSGFuZGxlIDB4MDAyMCwgRE1JIHR5cGUgMTksIDE1 IGJ5dGVzCk1lbW9yeSBBcnJheSBNYXBwZWQgQWRkcmVzcwoJU3RhcnRpbmcgQWRkcmVzczogMHgw MDAwMDAwMDAwMAoJRW5kaW5nIEFkZHJlc3M6IDB4MDAxN0ZGRkZGRkYKCVJhbmdlIFNpemU6IDYg R0IKCVBoeXNpY2FsIEFycmF5IEhhbmRsZTogMHgwMDE3CglQYXJ0aXRpb24gV2lkdGg6IDQKCkhh bmRsZSAweDAwMjEsIERNSSB0eXBlIDE4NywgOSBieXRlcwpPRU0tc3BlY2lmaWMgVHlwZQoJSGVh ZGVyIGFuZCBEYXRhOgoJCUJCIDA5IDIxIDAwIDE4IDAwIDAzIDlCIDAyCgpIYW5kbGUgMHgwMDIy LCBETUkgdHlwZSAxODcsIDkgYnl0ZXMKT0VNLXNwZWNpZmljIFR5cGUKCUhlYWRlciBhbmQgRGF0 YToKCQlCQiAwOSAyMiAwMCAxQSAwMCAwMyAyMCAwMwoKSGFuZGxlIDB4MDAyMywgRE1JIHR5cGUg MTg3LCA5IGJ5dGVzCk9FTS1zcGVjaWZpYyBUeXBlCglIZWFkZXIgYW5kIERhdGE6CgkJQkIgMDkg MjMgMDAgMUMgMDAgMDMgOUIgMDIKCkhhbmRsZSAweDAwMjQsIERNSSB0eXBlIDE4NywgOSBieXRl cwpPRU0tc3BlY2lmaWMgVHlwZQoJSGVhZGVyIGFuZCBEYXRhOgoJCUJCIDA5IDI0IDAwIDFFIDAw IDAzIDIwIDAzCgpIYW5kbGUgMHgwMDI1LCBETUkgdHlwZSAxMzYsIDYgYnl0ZXMKT0VNLXNwZWNp ZmljIFR5cGUKCUhlYWRlciBhbmQgRGF0YToKCQk4OCAwNiAyNSAwMCA1QSA1QQoKSGFuZGxlIDB4 RkVGRiwgRE1JIHR5cGUgMTI3LCA0IGJ5dGVzCkVuZCBPZiBUYWJsZQoK --14dae9cdcaad384cae04d8340bf5-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 18 14:47:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9F77ADB1; Mon, 18 Mar 2013 14:47:32 +0000 (UTC) (envelope-from prvs=17892983bb=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 09B3CF4C; Mon, 18 Mar 2013 14:47:31 +0000 (UTC) Received: from r2d2 ([46.65.172.4]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50002792453.msg; Mon, 18 Mar 2013 14:47:20 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Mon, 18 Mar 2013 14:47:20 +0000 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 46.65.172.4 X-Return-Path: prvs=17892983bb=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: "Nathan Whitehorn" , References: <35878.1363607691@critter.freebsd.dk> <514715F9.2080506@freebsd.org> Subject: Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots Date: Mon, 18 Mar 2013 14:47:35 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 14:47:32 -0000 ----- Original Message ----- From: "Nathan Whitehorn" To: Sent: Monday, March 18, 2013 1:26 PM Subject: Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots > On 03/18/13 07:18, Mehmet Erol Sanliturk wrote: >> On Mon, Mar 18, 2013 at 4:54 AM, Poul-Henning Kamp wrote: >> >>> In message >> DjjMoe5ttGA@mail.gmail.com>, Tom Evans writes: >>> >>>> You say this, have you actually measured/checked. sysutils/dmidecode >>>> will interrogate your BIOS and tell us what it thinks is installed in >>>> each RAM socket. It is not uncommon for RAM to say one thing on the >>>> outside, and report something completely different to the BIOS. >>> >>> I can only second Tom's call for a proper scientific approach to >>> debugging this issue, rather than just assume that it is the >>> operating systems fault. >>> >>> -- >>> 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. >>> >> >> >> I am a graduate of Operations Research and Statistics option of a >> Mathematics department . >> All of your considerations are considered . It is so much apparent that , >> the cause is FreeBSD . >> >> In my previous year message and in its subsequent messages , there are >> sufficiently detailed information . >> >> >> This message is caused from the following fact : >> >> In previous year case , KDE used was a cause , but FluxBox was working fast >> . >> Now , I have installed 10.0 current . It does not have KDE in packages . I >> have installed FluxBox . >> It is not a few second slow : Many minutes to start Firefox , and activate >> a menu of it ! >> >> What is the point of measuring milliseconds when the difference is around >> many minutes ? >> >> PC-BSD installation ( it is a graphical installation after starting X ) is >> taking many hours to reach 20 percent completion . >> The same is for GhostBSD : Start it at night , at the next morning , it is >> likely that it is not finished yet . >> >> >> Then : WQhat will be measured ? >> >> Linux installations are around 30 minutes . >> Starting/Opening menus are instantenous : I do no have chronometer , but >> everything is within a second . >> >> >> Thank you very much . > > The problem is that "slow" doesn't mean anything. An incomplete list of > things it might be related to: > 1. Something to do with the way KDE is built (options, system compiler) > 2. A disk I/O issue > 3. A memory speed issue > 4. Some other process using CPU that isn't running on Linux > 5. A scheduler issue triggered by some property of the machine > > Doing some of these smaller tests will help pin down which of these are > causing the problem. Without that, there's no possibility to even start > debugging. Even just running top and seeing whether you are spinning in > a user thread, in the kernel, or waiting while the slow things are > happening would be extremely helpful. Surely you can eliminate all of those and confirm / deny the original diagnosis by simply installing balanced memory in the machine and checking to see if the problem goes away? Could this be an NUMA related issue? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Mon Mar 18 14:49:04 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D06C4FBF; Mon, 18 Mar 2013 14:49:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A4CE6F85; Mon, 18 Mar 2013 14:49:04 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2IEmvLT050977; Mon, 18 Mar 2013 10:48:57 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2IEmvvS050976; Mon, 18 Mar 2013 14:48:57 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 18 Mar 2013 14:48:57 GMT Message-Id: <201303181448.r2IEmvvS050976@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 14:49:04 -0000 TB --- 2013-03-18 13:20:17 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-18 13:20:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-18 13:20:17 - starting HEAD tinderbox run for arm/arm TB --- 2013-03-18 13:20:17 - cleaning the object tree TB --- 2013-03-18 13:20:17 - /usr/local/bin/svn stat /src TB --- 2013-03-18 13:20:21 - At svn revision 248465 TB --- 2013-03-18 13:20:22 - building world TB --- 2013-03-18 13:20:22 - CROSS_BUILD_TESTING=YES TB --- 2013-03-18 13:20:22 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-18 13:20:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-18 13:20:22 - SRCCONF=/dev/null TB --- 2013-03-18 13:20:22 - TARGET=arm TB --- 2013-03-18 13:20:22 - TARGET_ARCH=arm TB --- 2013-03-18 13:20:22 - TZ=UTC TB --- 2013-03-18 13:20:22 - __MAKE_CONF=/dev/null TB --- 2013-03-18 13:20:22 - cd /src TB --- 2013-03-18 13:20:22 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Mar 18 13:20:27 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -DBFD_DEFAULT_TARGET_SIZE=32 -I. -I/src/gnu/usr.bin/binutils/as -I/src/gnu/usr.bin/binutils/as/../libbfd -I/obj/arm.arm/src/gnu/usr.bin/binutils/as/../libbfd -I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/include -DDEFAULT_ARCH=\"arm\" -DTARGET_CPU=\"arm\" -DTARGET_OS=\"freebsd\" -DTARGET_CANONICAL=\"arm-unknown-freebsd\" -DTARGET_ALIAS=\"arm-unknown-freebsd\" -DVERSION=\""2.17.50 [FreeBSD] 2007-07-03"\" -D_GNU_SOURCE -I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas -I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/bfd -I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config -I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils -I/src/gnu/usr.bin/binutils/as -I/src/gnu/usr.bin/binutils/as/arm-freebsd -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/gnu/usr.bin/binutils/as! /../../../../contrib/binutils/gas/symbols.c cc -O -pipe -DBFD_DEFAULT_TARGET_SIZE=32 -I. -I/src/gnu/usr.bin/binutils/as -I/src/gnu/usr.bin/binutils/as/../libbfd -I/obj/arm.arm/src/gnu/usr.bin/binutils/as/../libbfd -I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/include -DDEFAULT_ARCH=\"arm\" -DTARGET_CPU=\"arm\" -DTARGET_OS=\"freebsd\" -DTARGET_CANONICAL=\"arm-unknown-freebsd\" -DTARGET_ALIAS=\"arm-unknown-freebsd\" -DVERSION=\""2.17.50 [FreeBSD] 2007-07-03"\" -D_GNU_SOURCE -I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas -I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/bfd -I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config -I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils -I/src/gnu/usr.bin/binutils/as -I/src/gnu/usr.bin/binutils/as/arm-freebsd -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/gnu/usr.bin/binutils/as! /../../../../contrib/binutils/gas/write.c cc -O -pipe -DBFD_DEFAULT_TARGET_SIZE=32 -I. -I/src/gnu/usr.bin/binutils/as -I/src/gnu/usr.bin/binutils/as/../libbfd -I/obj/arm.arm/src/gnu/usr.bin/binutils/as/../libbfd -I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/include -DDEFAULT_ARCH=\"arm\" -DTARGET_CPU=\"arm\" -DTARGET_OS=\"freebsd\" -DTARGET_CANONICAL=\"arm-unknown-freebsd\" -DTARGET_ALIAS=\"arm-unknown-freebsd\" -DVERSION=\""2.17.50 [FreeBSD] 2007-07-03"\" -D_GNU_SOURCE -I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas -I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/bfd -I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config -I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils -I/src/gnu/usr.bin/binutils/as -I/src/gnu/usr.bin/binutils/as/arm-freebsd -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/gnu/usr.bin/binutils/as! /../../../../contrib/binutils/gas/config/tc-arm.c cc1: warnings being treated as errors /src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config/tc-arm.c:15793: warning: initialization from incompatible pointer type /src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config/tc-arm.c:15793: warning: initialization from incompatible pointer type /src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config/tc-arm.c:15794: warning: initialization from incompatible pointer type /src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config/tc-arm.c:15794: warning: initialization from incompatible pointer type *** [tc-arm.o] Error code 1 Stop in /src/gnu/usr.bin/binutils/as. *** [all] Error code 1 Stop in /src/gnu/usr.bin/binutils. *** [all] Error code 1 Stop in /src/gnu/usr.bin. *** [all] Error code 1 Stop in /src/gnu. *** [gnu.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-18 14:48:57 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-18 14:48:57 - ERROR: failed to build world TB --- 2013-03-18 14:48:57 - 4340.85 user 773.02 system 5320.04 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Mon Mar 18 14:49:07 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9E5F5FC4; Mon, 18 Mar 2013 14:49:07 +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 75E74F87; Mon, 18 Mar 2013 14:49:04 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2IEmw7K050989; Mon, 18 Mar 2013 10:48:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2IEmwFG050988; Mon, 18 Mar 2013 14:48:58 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 18 Mar 2013 14:48:58 GMT Message-Id: <201303181448.r2IEmwFG050988@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on armv6/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 14:49:07 -0000 TB --- 2013-03-18 13:20:17 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-18 13:20:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-18 13:20:17 - starting HEAD tinderbox run for armv6/arm TB --- 2013-03-18 13:20:17 - cleaning the object tree TB --- 2013-03-18 13:20:17 - /usr/local/bin/svn stat /src TB --- 2013-03-18 13:20:21 - At svn revision 248465 TB --- 2013-03-18 13:20:22 - building world TB --- 2013-03-18 13:20:22 - CROSS_BUILD_TESTING=YES TB --- 2013-03-18 13:20:22 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-18 13:20:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-18 13:20:22 - SRCCONF=/dev/null TB --- 2013-03-18 13:20:22 - TARGET=arm TB --- 2013-03-18 13:20:22 - TARGET_ARCH=armv6 TB --- 2013-03-18 13:20:22 - TZ=UTC TB --- 2013-03-18 13:20:22 - __MAKE_CONF=/dev/null TB --- 2013-03-18 13:20:22 - cd /src TB --- 2013-03-18 13:20:22 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Mar 18 13:20:27 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -DBFD_DEFAULT_TARGET_SIZE=32 -I. -I/src/gnu/usr.bin/binutils/as -I/src/gnu/usr.bin/binutils/as/../libbfd -I/obj/arm.armv6/src/gnu/usr.bin/binutils/as/../libbfd -I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/include -DCPU_DEFAULT=ARM_ARCH_V6K -DDEFAULT_ARCH=\"armv6\" -DTARGET_CPU=\"armv6\" -DTARGET_OS=\"freebsd\" -DTARGET_CANONICAL=\"armv6-unknown-freebsd\" -DTARGET_ALIAS=\"armv6-unknown-freebsd\" -DVERSION=\""2.17.50 [FreeBSD] 2007-07-03"\" -D_GNU_SOURCE -I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas -I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/bfd -I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config -I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils -I/src/gnu/usr.bin/binutils/as -I/src/gnu/usr.bin/binutils/as/arm-freebsd -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer! -sign -c /src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/symbols.c cc -O -pipe -DBFD_DEFAULT_TARGET_SIZE=32 -I. -I/src/gnu/usr.bin/binutils/as -I/src/gnu/usr.bin/binutils/as/../libbfd -I/obj/arm.armv6/src/gnu/usr.bin/binutils/as/../libbfd -I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/include -DCPU_DEFAULT=ARM_ARCH_V6K -DDEFAULT_ARCH=\"armv6\" -DTARGET_CPU=\"armv6\" -DTARGET_OS=\"freebsd\" -DTARGET_CANONICAL=\"armv6-unknown-freebsd\" -DTARGET_ALIAS=\"armv6-unknown-freebsd\" -DVERSION=\""2.17.50 [FreeBSD] 2007-07-03"\" -D_GNU_SOURCE -I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas -I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/bfd -I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config -I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils -I/src/gnu/usr.bin/binutils/as -I/src/gnu/usr.bin/binutils/as/arm-freebsd -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer! -sign -c /src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/write.c cc -O -pipe -DBFD_DEFAULT_TARGET_SIZE=32 -I. -I/src/gnu/usr.bin/binutils/as -I/src/gnu/usr.bin/binutils/as/../libbfd -I/obj/arm.armv6/src/gnu/usr.bin/binutils/as/../libbfd -I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/include -DCPU_DEFAULT=ARM_ARCH_V6K -DDEFAULT_ARCH=\"armv6\" -DTARGET_CPU=\"armv6\" -DTARGET_OS=\"freebsd\" -DTARGET_CANONICAL=\"armv6-unknown-freebsd\" -DTARGET_ALIAS=\"armv6-unknown-freebsd\" -DVERSION=\""2.17.50 [FreeBSD] 2007-07-03"\" -D_GNU_SOURCE -I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas -I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/bfd -I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config -I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils -I/src/gnu/usr.bin/binutils/as -I/src/gnu/usr.bin/binutils/as/arm-freebsd -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer! -sign -c /src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config/tc-arm.c cc1: warnings being treated as errors /src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config/tc-arm.c:15793: warning: initialization from incompatible pointer type /src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config/tc-arm.c:15793: warning: initialization from incompatible pointer type /src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config/tc-arm.c:15794: warning: initialization from incompatible pointer type /src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config/tc-arm.c:15794: warning: initialization from incompatible pointer type *** [tc-arm.o] Error code 1 Stop in /src/gnu/usr.bin/binutils/as. *** [all] Error code 1 Stop in /src/gnu/usr.bin/binutils. *** [all] Error code 1 Stop in /src/gnu/usr.bin. *** [all] Error code 1 Stop in /src/gnu. *** [gnu.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-18 14:48:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-18 14:48:58 - ERROR: failed to build world TB --- 2013-03-18 14:48:58 - 4335.85 user 773.81 system 5320.52 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-armv6-arm.full From owner-freebsd-current@FreeBSD.ORG Mon Mar 18 15:04:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C4644595; Mon, 18 Mar 2013 15:04:22 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ve0-f178.google.com (mail-ve0-f178.google.com [209.85.128.178]) by mx1.freebsd.org (Postfix) with ESMTP id 67618F3; Mon, 18 Mar 2013 15:04:22 +0000 (UTC) Received: by mail-ve0-f178.google.com with SMTP id db10so4387204veb.23 for ; Mon, 18 Mar 2013 08:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Ipnxwa4DLLgUKEtTh0YRPNjKx5fodZEIGXgMtlKlBxk=; b=sQn432V0wwJAPhBahKo3v0S6/Jj6pPV8h4ov0MATY6MUi+Mzrwst8Yhmwa06+i+3fo M2Mp+dCFqjcIUWbOn2bJ3RVT2CXs2QO8QvysL7BuBh5Kr+QrgZ6LcAYI8IiBd39SbkJk eLCZdzyZiduDgKCTVHr6lgFRkAh8s4HBmY7gqACId8BCdrUcKS0HXmkcXKs8RrzxHOc3 UacPKKHWLEackxmUs6OIOOgcnB7QYddUYD+iLvw4dPdEXT2qS1ipGHSIDee0RHNvOFiv 8JnfNIrU/KOHG++EpDmstWoqyrpZwsiRK032XYtXN5yzGy2jrOdth2dr/hwlNdbaZRky poWA== MIME-Version: 1.0 X-Received: by 10.58.23.169 with SMTP id n9mr20218319vef.58.1363618605686; Mon, 18 Mar 2013 07:56:45 -0700 (PDT) Received: by 10.58.132.203 with HTTP; Mon, 18 Mar 2013 07:56:45 -0700 (PDT) In-Reply-To: References: <35878.1363607691@critter.freebsd.dk> <514715F9.2080506@freebsd.org> Date: Mon, 18 Mar 2013 07:56:45 -0700 Message-ID: Subject: Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots From: Mehmet Erol Sanliturk To: Steven Hartland Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org, Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 15:04:22 -0000 On Mon, Mar 18, 2013 at 7:47 AM, Steven Hartland wrote: > > ----- Original Message ----- From: "Nathan Whitehorn" < > nwhitehorn@freebsd.org> > To: > Sent: Monday, March 18, 2013 1:26 PM > Subject: Re: FreeBSD is very slow when Memory chip sizes are imbalanced in > slots > > > On 03/18/13 07:18, Mehmet Erol Sanliturk wrote: >> >>> On Mon, Mar 18, 2013 at 4:54 AM, Poul-Henning Kamp >> >wrote: >>> >>> In message >>> DjjMoe5ttGA@mail.gmail.com>, Tom Evans writes: >>>> >>>> You say this, have you actually measured/checked. sysutils/dmidecode >>>>> will interrogate your BIOS and tell us what it thinks is installed in >>>>> each RAM socket. It is not uncommon for RAM to say one thing on the >>>>> outside, and report something completely different to the BIOS. >>>>> >>>> >>>> I can only second Tom's call for a proper scientific approach to >>>> debugging this issue, rather than just assume that it is the >>>> operating systems fault. >>>> >>>> -- >>>> 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. >>>> >>>> >>> >>> I am a graduate of Operations Research and Statistics option of a >>> Mathematics department . >>> All of your considerations are considered . It is so much apparent that , >>> the cause is FreeBSD . >>> >>> In my previous year message and in its subsequent messages , there are >>> sufficiently detailed information . >>> >>> >>> This message is caused from the following fact : >>> >>> In previous year case , KDE used was a cause , but FluxBox was working >>> fast >>> . >>> Now , I have installed 10.0 current . It does not have KDE in packages . >>> I >>> have installed FluxBox . >>> It is not a few second slow : Many minutes to start Firefox , and >>> activate >>> a menu of it ! >>> >>> What is the point of measuring milliseconds when the difference is around >>> many minutes ? >>> >>> PC-BSD installation ( it is a graphical installation after starting X ) >>> is >>> taking many hours to reach 20 percent completion . >>> The same is for GhostBSD : Start it at night , at the next morning , it >>> is >>> likely that it is not finished yet . >>> >>> >>> Then : WQhat will be measured ? >>> >>> Linux installations are around 30 minutes . >>> Starting/Opening menus are instantenous : I do no have chronometer , but >>> everything is within a second . >>> >>> >>> Thank you very much . >>> >> >> The problem is that "slow" doesn't mean anything. An incomplete list of >> things it might be related to: >> 1. Something to do with the way KDE is built (options, system compiler) >> 2. A disk I/O issue >> 3. A memory speed issue >> 4. Some other process using CPU that isn't running on Linux >> 5. A scheduler issue triggered by some property of the machine >> >> Doing some of these smaller tests will help pin down which of these are >> causing the problem. Without that, there's no possibility to even start >> debugging. Even just running top and seeing whether you are spinning in >> a user thread, in the kernel, or waiting while the slow things are >> happening would be extremely helpful. >> > > Surely you can eliminate all of those and confirm / deny the original > diagnosis by simply installing balanced memory in the machine and checking > to see if the problem goes away? > > Could this be an NUMA related issue? > > Regards > Steve > > Please see links in my previous mails . All of these are worked in detail . This is Intel DG965WH main board and I do not know much about NUMA , but with respect to Wikipedia Non-Uniform_Memory_Access page , it seems that there is no NUMA structure in this main board . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Mon Mar 18 15:09:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F0539851; Mon, 18 Mar 2013 15:09:35 +0000 (UTC) (envelope-from prvs=17892983bb=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 6D29B140; Mon, 18 Mar 2013 15:09:34 +0000 (UTC) Received: from r2d2 ([46.65.172.4]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50002792688.msg; Mon, 18 Mar 2013 15:09:33 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Mon, 18 Mar 2013 15:09:33 +0000 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 46.65.172.4 X-Return-Path: prvs=17892983bb=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: "Mehmet Erol Sanliturk" References: <35878.1363607691@critter.freebsd.dk><514715F9.2080506@freebsd.org> Subject: Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots Date: Mon, 18 Mar 2013 15:09:53 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-current@freebsd.org, Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 15:09:36 -0000 ----- Original Message ----- From: Mehmet Erol Sanliturk >> Surely you can eliminate all of those and confirm / deny the original >> diagnosis by simply installing balanced memory in the machine and checking >> to see if the problem goes away? > > Please see links in my previous mails . > All of these are worked in detail . > > This is Intel DG965WH main board and I do not know much about NUMA , but > with respect to Wikipedia Non-Uniform_Memory_Access page , it seems that > there is no NUMA structure in this main board . But have you installed balanced memory and confirmed the problem goes away? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Mon Mar 18 15:11:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6C9C4A3F; Mon, 18 Mar 2013 15:11:03 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by mx1.freebsd.org (Postfix) with ESMTP id 1A33915C; Mon, 18 Mar 2013 15:11:02 +0000 (UTC) Received: by mail-vc0-f180.google.com with SMTP id m17so2965245vca.25 for ; Mon, 18 Mar 2013 08:11:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=F9wHHCaoIqDZXPZSlTVQeXTvHScfN2fCPCsuepehTOc=; b=zbsVJ7snGbtdadRufL+JG5o60fPoJ9k7oTGwEVlQD65NVw3Ydu+eDJ8EfWEcRWXme+ ci1g2FuxA2sVQS40LwhUpBg+fPE3rVXEmhzv1x5WvgJZ8ateCAT70z/f84w9AoiXXXPB aacEw7x5Zu4WnF0nuOxVs//5BfvSbuPZvb7oaMQN4lE/9J0PX+VdwwDFO4VuAAcV6YLO htwya19/KP89tY7xtcf+o5wuZfvFCiyFPtD4TR5mZPMhYBouH5a337yMWUIibs9e2/LU TMPwNoP6qKECvx3siAIgzkNx+UBI6+rKp3+32lwVL34EnoThcHRPq015JFoHE7furfds wvsg== MIME-Version: 1.0 X-Received: by 10.220.242.73 with SMTP id lh9mr19583222vcb.49.1363619461520; Mon, 18 Mar 2013 08:11:01 -0700 (PDT) Received: by 10.58.132.203 with HTTP; Mon, 18 Mar 2013 08:11:01 -0700 (PDT) In-Reply-To: References: <35878.1363607691@critter.freebsd.dk> <514715F9.2080506@freebsd.org> Date: Mon, 18 Mar 2013 08:11:01 -0700 Message-ID: Subject: Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots From: Mehmet Erol Sanliturk To: Steven Hartland Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org, Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 15:11:03 -0000 On Mon, Mar 18, 2013 at 8:09 AM, Steven Hartland wrote: > > ----- Original Message ----- From: Mehmet Erol Sanliturk > >> Surely you can eliminate all of those and confirm / deny the original >>> diagnosis by simply installing balanced memory in the machine and >>> checking >>> to see if the problem goes away? >>> >> >> Please see links in my previous mails . >> All of these are worked in detail . >> >> This is Intel DG965WH main board and I do not know much about NUMA , but >> with respect to Wikipedia Non-Uniform_Memory_Access page , it seems that >> there is no NUMA structure in this main board . >> > > But have you installed balanced memory and confirmed the problem goes away? > > Regards > Steve > Yes . http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031836.html http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031912.html http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031928.html http://lists.freebsd.org/pipermail/freebsd-current/2012-February/032012.html Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Mon Mar 18 15:21:39 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D3520142; Mon, 18 Mar 2013 15:21:39 +0000 (UTC) (envelope-from prvs=17892983bb=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 4B33A1F0; Mon, 18 Mar 2013 15:21:39 +0000 (UTC) Received: from r2d2 ([46.65.172.4]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50002792839.msg; Mon, 18 Mar 2013 15:21:38 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Mon, 18 Mar 2013 15:21:38 +0000 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 46.65.172.4 X-Return-Path: prvs=17892983bb=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: "Mehmet Erol Sanliturk" References: <35878.1363607691@critter.freebsd.dk><514715F9.2080506@freebsd.org> Subject: Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots Date: Mon, 18 Mar 2013 15:21:43 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org, Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 15:21:39 -0000 >> ----- Original Message ----- From: Mehmet Erol Sanliturk >>> >>> Surely you can eliminate all of those and confirm / deny the original >>>> diagnosis by simply installing balanced memory in the machine and >>>> checking >>>> to see if the problem goes away? >>>> >>> >>> Please see links in my previous mails . >>> All of these are worked in detail . >>> >>> This is Intel DG965WH main board and I do not know much about NUMA , but >>> with respect to Wikipedia Non-Uniform_Memory_Access page , it seems that >>> there is no NUMA structure in this main board . >>> >> >> But have you installed balanced memory and confirmed the problem goes away? > > Yes . > > > http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031836.html > http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031912.html > http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031928.html > http://lists.freebsd.org/pipermail/freebsd-current/2012-February/032012.html > You state there that "The main boards are the same" which indicates to me the machines aren't the same machine which could result in some other subtle difference causing the problem. To confirm you'll need to use the "exact same machine" for tests with the only difference being the ram modules installed. Regards Steve =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.=20 In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Mon Mar 18 15:26:17 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 55495374; Mon, 18 Mar 2013 15:26:17 +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 169B6254; Mon, 18 Mar 2013 15:26:16 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id C9BAB8A525; Mon, 18 Mar 2013 15:26:15 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.6/8.14.6) with ESMTP id r2IFQFoE036507; Mon, 18 Mar 2013 15:26:15 GMT (envelope-from phk@phk.freebsd.dk) To: "Steven Hartland" Subject: Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots In-reply-to: From: "Poul-Henning Kamp" References: <35878.1363607691@critter.freebsd.dk><514715F9.2080506@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1> Date: Mon, 18 Mar 2013 15:26:15 +0000 Message-ID: <36506.1363620375@critter.freebsd.dk> Cc: Nathan Whitehorn , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 15:26:17 -0000 In message , "Steven Hartland" writes: >You state there that "The main boards are the same" which indicates to me >the machines aren't the same machine which could result in some other subtle >difference causing the problem. > >To confirm you'll need to use the "exact same machine" for tests with the only >difference being the ram modules installed. Or, at the very least, switch _all_ the RAM between the two machines, and confirm that the problem follows the RAM. -- 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 Mon Mar 18 15:29:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E618561B; Mon, 18 Mar 2013 15:29:14 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-vb0-x231.google.com (mail-vb0-x231.google.com [IPv6:2607:f8b0:400c:c02::231]) by mx1.freebsd.org (Postfix) with ESMTP id 911D6281; Mon, 18 Mar 2013 15:29:14 +0000 (UTC) Received: by mail-vb0-f49.google.com with SMTP id s24so3464459vbi.36 for ; Mon, 18 Mar 2013 08:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=VWBCDD2GmBH77Q0PmtMxwc+L1cJwvFokjZD7qNVLMV0=; b=J/MtOVqcY5kY7gJjBmWU3y8a8tk6mGnhxLoahV5V3tSnA2rInzZaYF63yDkAn273nT M5ff8qdZsI8vtpop4/4IV1n7zHpSzwdIRqmhM72ehbOgYn+euo72+YZTecRNJQ11QDCn Xb3CaEpc39l8ZzfxCDmT4nDrnd4ta8HcjuLBpIrPYRm2Ofgh15kHIkDPXlpqWL3rwmkj cHiPu8yvO2Zjmhrr2oKEFvUGDnXUhZSJzzI5eI5M/lyuMF/2IZvOzpBeOnryMdY6l3bD wi6V+8zRG8WqeqFxujDC4uHcMVriP3tfTI4RmtneKXF9PGu890pN+rRKxa/pgdLXFikt 0i5w== MIME-Version: 1.0 X-Received: by 10.58.23.169 with SMTP id n9mr20400147vef.58.1363620554030; Mon, 18 Mar 2013 08:29:14 -0700 (PDT) Received: by 10.58.132.203 with HTTP; Mon, 18 Mar 2013 08:29:13 -0700 (PDT) In-Reply-To: References: <35878.1363607691@critter.freebsd.dk> <514715F9.2080506@freebsd.org> Date: Mon, 18 Mar 2013 08:29:13 -0700 Message-ID: Subject: Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots From: Mehmet Erol Sanliturk To: Steven Hartland Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org, Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 15:29:15 -0000 On Mon, Mar 18, 2013 at 8:21 AM, Steven Hartland wrote: > ** > >> ----- Original Message ----- From: Mehmet Erol Sanliturk > >>> > >>> Surely you can eliminate all of those and confirm / deny the original > >>>> diagnosis by simply installing balanced memory in the machine and > >>>> checking > >>>> to see if the problem goes away? > >>>> > >>> > >>> Please see links in my previous mails . > >>> All of these are worked in detail . > >>> > >>> This is Intel DG965WH main board and I do not know much about NUMA , > but > >>> with respect to Wikipedia Non-Uniform_Memory_Access page , it seems > that > >>> there is no NUMA structure in this main board . > >>> > >> > >> But have you installed balanced memory and confirmed the problem goes > away? > > > > Yes . > > > > > > > http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031836.html > > > http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031912.html > > > http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031928.html > > > http://lists.freebsd.org/pipermail/freebsd-current/2012-February/032012.html > > > > You state there that "The main boards are the same" which indicates to me > the machines aren't the same machine which could result in some other > subtle > difference causing the problem. > > To confirm you'll need to use the "exact same machine" for tests with the > only > difference being the ram modules installed. > Regards > Steve > > The main boards are the same model , two of them in two different cases , not one main board . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Mon Mar 18 15:31:04 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E37927D2; Mon, 18 Mar 2013 15:31:04 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ve0-f174.google.com (mail-ve0-f174.google.com [209.85.128.174]) by mx1.freebsd.org (Postfix) with ESMTP id 749122AD; Mon, 18 Mar 2013 15:31:04 +0000 (UTC) Received: by mail-ve0-f174.google.com with SMTP id pb11so4421169veb.5 for ; Mon, 18 Mar 2013 08:30:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=MXKJ7du/iTT48BBzaBdAcVp/0fwZNRHAXclG4LhEXj8=; b=dVT6WgxK/MRsO0FA5B8Da8nHH41cbugSbJNW4zz628X7ohZN3Wl9k8gmiezF/jyL0H G2oL14jdjL3QswVrowMSUxG+Hqa8EeJTBY4ot584qy4LfzCMlETj160LfzYtkp8EKzUg IhIGWGaKhFYZFZDlwA2hYIs1WeqrB93UyCwwYcD3NY8NDpO6fW80lTtfx3kMviQgWq2c zbs/oGJCeTh0ZpZ2Ag7cjKt5tbCg27Xg4raZuYPmNXdgBULwafGct/Iv1Uhsf7G1psf6 oolG/wMwqQo7SGcqqz/HzzWiAGvLPpzbjL2rjamUq1Cw4QVp+WYLq+nmpKYw6ok+LNRG hqNQ== MIME-Version: 1.0 X-Received: by 10.58.23.169 with SMTP id n9mr20409385vef.58.1363620657784; Mon, 18 Mar 2013 08:30:57 -0700 (PDT) Received: by 10.58.132.203 with HTTP; Mon, 18 Mar 2013 08:30:57 -0700 (PDT) In-Reply-To: <36506.1363620375@critter.freebsd.dk> References: <35878.1363607691@critter.freebsd.dk> <514715F9.2080506@freebsd.org> <36506.1363620375@critter.freebsd.dk> Date: Mon, 18 Mar 2013 08:30:57 -0700 Message-ID: Subject: Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots From: Mehmet Erol Sanliturk To: Poul-Henning Kamp Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org, Steven Hartland , Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 15:31:05 -0000 On Mon, Mar 18, 2013 at 8:26 AM, Poul-Henning Kamp wrote: > In message , "Steven > Hartland" writes: > > >You state there that "The main boards are the same" which indicates to me > >the machines aren't the same machine which could result in some other > subtle > >difference causing the problem. > > > >To confirm you'll need to use the "exact same machine" for tests with the > only > >difference being the ram modules installed. > > Or, at the very least, switch _all_ the RAM between the two machines, and > confirm > that the problem follows the RAM. > > > -- > 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. > Yes . http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031836.html http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031912.html http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031928.html http://lists.freebsd.org/pipermail/freebsd-current/2012-February/032012.html Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Mon Mar 18 15:41:31 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7744FC5E; Mon, 18 Mar 2013 15:41:31 +0000 (UTC) (envelope-from prvs=17892983bb=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id D098434D; Mon, 18 Mar 2013 15:41:30 +0000 (UTC) Received: from r2d2 ([46.65.172.4]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50002793014.msg; Mon, 18 Mar 2013 15:41:29 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Mon, 18 Mar 2013 15:41:29 +0000 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 46.65.172.4 X-Return-Path: prvs=17892983bb=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <43BD412145BF4C7A9E2EFF91CF2ED379@multiplay.co.uk> From: "Steven Hartland" To: "Mehmet Erol Sanliturk" References: <35878.1363607691@critter.freebsd.dk> <514715F9.2080506@freebsd.org> Subject: Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots Date: Mon, 18 Mar 2013 15:41:49 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-current@freebsd.org, Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 15:41:31 -0000 ----- Original Message ----- From: "Mehmet Erol Sanliturk" >> You state there that "The main boards are the same" which indicates to me >> the machines aren't the same machine which could result in some other >> subtle >> difference causing the problem. >> >> To confirm you'll need to use the "exact same machine" for tests with the >> only difference being the ram modules installed. > > The main boards are the same model , two of them in two different cases , > not one main board . That doesn't mean that both machines are configured / installed identically you need to rule out other differences before continuing. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Mon Mar 18 16:06:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C6E51470; Mon, 18 Mar 2013 16:06:12 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by mx1.freebsd.org (Postfix) with ESMTP id 720AF6D9; Mon, 18 Mar 2013 16:06:12 +0000 (UTC) Received: by mail-vc0-f178.google.com with SMTP id hz11so3094971vcb.9 for ; Mon, 18 Mar 2013 09:06:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=oSa7SO1DzbWnR1W/Bi/m1tBjKNyrIS16Ww5FSRx+IQE=; b=eo/DwUzGzKSaJ9pUQSSbdllLMXo8wkMlyAeE1LBeQre0Jvp+D/5lolbn0AwUJyRETj YZKDM/KG5XTrubPnoVVQIIw5cx6POMZFjCh6WxW9r5WxwS07BZ9CN8r9CkwimwfOig9x wtt1319lYTKSAYzhUmvoCCVyRuxuf2Z5fsrdL/ENaE6BZeMwqCUQ9IpkG1Ud6i0vYurz hPET8lyFyox8p2VAL1BMRSwaC5LBhKvLYS6xqoUVK39UcYj72a3VqccYRhzoGpOegp5c 0xWo4oTRRKipbhipgoOn/lVy3hrn32zFSDcdIEuOhSfWrbmftxerwHPD+ow0phZBghlJ gyvQ== MIME-Version: 1.0 X-Received: by 10.220.222.8 with SMTP id ie8mr20171965vcb.27.1363622771711; Mon, 18 Mar 2013 09:06:11 -0700 (PDT) Received: by 10.58.132.203 with HTTP; Mon, 18 Mar 2013 09:06:11 -0700 (PDT) In-Reply-To: <43BD412145BF4C7A9E2EFF91CF2ED379@multiplay.co.uk> References: <35878.1363607691@critter.freebsd.dk> <514715F9.2080506@freebsd.org> <43BD412145BF4C7A9E2EFF91CF2ED379@multiplay.co.uk> Date: Mon, 18 Mar 2013 09:06:11 -0700 Message-ID: Subject: Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots From: Mehmet Erol Sanliturk To: Steven Hartland Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org, Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 16:06:12 -0000 On Mon, Mar 18, 2013 at 8:41 AM, Steven Hartland wrote: > > ----- Original Message ----- From: "Mehmet Erol Sanliturk" < > m.e.sanliturk@gmail.com> > > You state there that "The main boards are the same" which indicates to me >>> the machines aren't the same machine which could result in some other >>> subtle >>> difference causing the problem. >>> >>> To confirm you'll need to use the "exact same machine" for tests with the >>> only difference being the ram modules installed. >>> >> >> The main boards are the same model , two of them in two different cases , >> not one main board . >> > > That doesn't mean that both machines are configured / installed identically > you need to rule out other differences before continuing. > > Regards > Steve > > Important ( determiner ) parameters are ( FreeBSD ( 9.0 , 9.1 , 10.0 : any of them with X + Desktop ( FluxBox , KDE , Gnome , I never used any other one , except one time I have tried Enlightenment , but not for this case ) , Memory Chip Sizes ) . Assume : Computer A : Memory Chip Sizes : ( 2 GB , 1 GB , 2 GB , 1 GB ) : Working SLOW . FreeBSD A Computer B : Memory Chip Sizes : ( 2 GB , 2 GB , 2 GB , 2 GB ) : Working FAST . FreeBSD B Interchange memory chips : Computer A : Memory Chip Sizes : ( 2 GB , 2 GB , 2 GB , 2 GB ) : Working FAST . FreeBSD A Computer B : Memory Chip Sizes : ( 2 GB , 1 GB , 2 GB , 1 GB ) : Working SLOW . FreeBSD B Then : Interchanging only memory chips is interchanging also the SPEED . Means : FreeBSD installation is NOT important ( or effective ) . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Mon Mar 18 16:20:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 388367E0; Mon, 18 Mar 2013 16:20:20 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 7AD2F78C; Mon, 18 Mar 2013 16:20:19 +0000 (UTC) Received: by mail-we0-f175.google.com with SMTP id x8so5058567wey.20 for ; Mon, 18 Mar 2013 09:20:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=hEl4yd27G6vIt8eviNUy4k0FUq9IvoQM7JaJToCkGGU=; b=nFSx+nTcA++8N6xrckd3WGdCwNtrO1mkTYZwYwMVPPyX/N/reNWbQZBA7liL5KfToc yGJG2auOUqTcNhzYSnrUkHBW8+lXRDvrDmNRuyJ2XJP9/sqEsM/DUJ4pxzO+MwaXeSwY TRReL5lgBjDIMIqVnatiy3OWBKGqpNVnEhf3BTlWBBpL/y/cevuT3wTpwN25fB32MXRs qZ8NEx/+O5kRmt4wRNxui2WWBpApT3tkKZBFb9GBma3tTiHazH/l7qe+R2rqKiqefOpn 27iOcT8GBlb6vLpHF2i5X83VKH6y8fVxf1mxh13YtLNyhLWUknXB/u/iJdI6fW9wdRDg n23Q== MIME-Version: 1.0 X-Received: by 10.180.104.225 with SMTP id gh1mr6074290wib.27.1363623618703; Mon, 18 Mar 2013 09:20:18 -0700 (PDT) Received: by 10.216.9.68 with HTTP; Mon, 18 Mar 2013 09:20:18 -0700 (PDT) In-Reply-To: <5146F49B.5080609@beatsnet.com> References: <5146F49B.5080609@beatsnet.com> Date: Mon, 18 Mar 2013 18:20:18 +0200 Message-ID: Subject: Re: troubles with buildworld/sendmail/sasl/clang From: Kimmo Paasiala To: Beat Siegenthaler Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD current , FreeBSD-STABLE Mailing List X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 16:20:20 -0000 On Mon, Mar 18, 2013 at 1:03 PM, Beat Siegenthaler wrote: > Hi all, > > since some days i try to "make buildworld", but have some errors in > sendmail. > The make conf is not changed since years (in this case) . Adding > NO_WERROR= in src.conf helps, but i think it is not the optimal solution? > > # SASL (cyrus-sasl v2) sendmail build flags... > SENDMAIL_CFLAGS+=-I/usr/local/include -DSASL=2 > SENDMAIL_LDFLAGS+=-L/usr/local/lib > SENDMAIL_LDADD+=-lsasl2 > SENDMAIL_CFLAGS+= -D_FFR_SMTP_SSL > > SENDMAIL_MC = /etc/mail/xyz.mc > WITH_SSL_AND_PLAINTEXT=yes # for imaps and cclient > > ==============src.conf=================== > > CC=clang > CXX=clang++ > CPP=clang-cpp > # This setting to build world without -Werror: > # NO_WERROR= > # This setting to build kernel without -Werror: > # WERROR= > > =================buildworld=============== > > /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/usersmtp.c:1864:8: > error: incompatible pointer types passing 'void ()' to parameter of type > 'void (*)(char *, bool, MAILER *, struct mailer_con_info *, ENVELOPE *)' > [-Werror,-Wincompatible-pointer-types] > getsasldata, NULL, XS_AUTH); > ^~~~~~~~~~~ > /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/sendmail.h:2519:67: note: > passing argument to parameter here > extern int reply __P((MAILER *, MCI *, ENVELOPE *, time_t, void > (*)__P((char *, bool, MAILER *, MCI *, ENVELOPE *)), char **, int)); > ^ > /usr/obj/usr/src/tmp/usr/include/sys/cdefs.h:129:21: note: expanded from > macro '__P' > #define __P(protos) protos /* full-blown ANSI C */ > ^ > 3 errors generated. > *** [usersmtp.o] Error code 1 > 1 error > *** [all] Error code 2 > 1 error > *** [usr.sbin.all__D] Error code 2 > 1 error > *** [everything] Error code 2 > 1 error > *** [buildworld] Error code 2 > 1 error > > regards > beat I can not help with the error but I really have to make this question: Does FreeBSD really have to support pre-ANSI C compilers in 2013? -Kimmo From owner-freebsd-current@FreeBSD.ORG Mon Mar 18 16:48:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 421B6119 for ; Mon, 18 Mar 2013 16:48:53 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by mx1.freebsd.org (Postfix) with ESMTP id EDBA68F9 for ; Mon, 18 Mar 2013 16:48:52 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id 10so7267719ied.2 for ; Mon, 18 Mar 2013 09:48:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=kd09HQKlPCWSRs4edd8DxMzg6hT/IR+xoOCOuHbTDvQ=; b=p7VRgLl+CoQtiC9MUjoJF3Zb5JgpAxaRNp4MF5zt8NSmSk5+cGx9seEwL1rjAlsgJ2 eY2q7EJJ8EfRyGHLtu8EOwpJDeDXW5StFeHWwIenfCC4eC9juom8Yx4hHbs4bH6IWJJ7 d9o7hDREf3BXkZComdHLY4FsYpPFPGvljX9Yr1LTkRyMvsttv99FuEHx332ttGkWfT7g EodcmOYkfV/XZPYsQSweVCVJkUut8Uhq6ciTGT1UQ+euM6WxqLgTfoTV+WiMAEsy4hOv uzihuxFkG2Dwz6skDUTbg+g82SZdGOGdQHyKl+3e80kZv9NvynjH8M5h1T/Q9IN82ns7 qvFQ== MIME-Version: 1.0 X-Received: by 10.50.135.8 with SMTP id po8mr6449369igb.41.1363625332746; Mon, 18 Mar 2013 09:48:52 -0700 (PDT) Received: by 10.50.6.82 with HTTP; Mon, 18 Mar 2013 09:48:52 -0700 (PDT) In-Reply-To: References: <35878.1363607691@critter.freebsd.dk> <514715F9.2080506@freebsd.org> <43BD412145BF4C7A9E2EFF91CF2ED379@multiplay.co.uk> Date: Mon, 18 Mar 2013 11:48:52 -0500 Message-ID: Subject: Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots From: Scot Hetzel To: Mehmet Erol Sanliturk Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 16:48:53 -0000 On Mon, Mar 18, 2013 at 11:06 AM, Mehmet Erol Sanliturk wrote: > Computer A : Memory Chip Sizes : ( 2 GB , 1 GB , 2 GB , 1 GB ) : Working > SLOW . FreeBSD A > Computer B : Memory Chip Sizes : ( 2 GB , 2 GB , 2 GB , 2 GB ) : Working > FAST . FreeBSD B > > Interchange memory chips : > > Computer A : Memory Chip Sizes : ( 2 GB , 2 GB , 2 GB , 2 GB ) : Working > FAST . FreeBSD A > Computer B : Memory Chip Sizes : ( 2 GB , 1 GB , 2 GB , 1 GB ) : Working > SLOW . FreeBSD B > > What happens if you configure the memory as ( 2 GB , 2 GB , 1 GB , 1 GB )? -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. From owner-freebsd-current@FreeBSD.ORG Mon Mar 18 16:57:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DFF27500; Mon, 18 Mar 2013 16:57:59 +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 A2093985; Mon, 18 Mar 2013 16:57:59 +0000 (UTC) Received: from [10.0.10.1] ([173.88.202.176]) by mail-03.name-services.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Mar 2013 09:58:00 -0700 Message-ID: <51474796.1030808@a1poweruser.com> Date: Mon, 18 Mar 2013 12:57:58 -0400 From: Fbsd8 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: FreeBSD questions , freebsd-current , freebsd-doc@freebsd.org Subject: Handbook Jail Chapter rewrite available for critique Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Mar 2013 16:58:00.0570 (UTC) FILETIME=[BF6C55A0:01CE23F9] X-Sender: fbsd8@a1poweruser.com X-Authenticated-Sender: fbsd8@a1poweruser.com X-EchoSenderHash: [fbsd8]-[a1poweruser*com] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 16:58:00 -0000 To all interested parties; I have completed the final draft of the total rewrite of FreeBSD's handbook Chapter 16 on Jails. Before submitting my work for submission to the documentation group for insertion in the handbook I am looking for critique of the work to find errors in concept, wrong use of words, or anything to make it better. All feedback welcomed. Use this URL to access it http://www.jails.a1poweruser.com/ Thank You. From owner-freebsd-current@FreeBSD.ORG Mon Mar 18 17:30:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D617F1A3; Mon, 18 Mar 2013 17:30:52 +0000 (UTC) (envelope-from ike@blackskyresearch.net) Received: from rs149.luxsci.com (rs149.luxsci.com [64.49.224.181]) by mx1.freebsd.org (Postfix) with ESMTP id 9486EB6C; Mon, 18 Mar 2013 17:30:52 +0000 (UTC) Received: from rs149.luxsci.com (localhost.localdomain [127.0.0.1]) by rs149.luxsci.com (8.14.4/8.13.8) with ESMTP id r2IHUioG000619; Mon, 18 Mar 2013 13:30:45 -0400 Received: (from root@localhost) by rs149.luxsci.com (8.14.4/8.13.8/Submit) id r2IHU2IW031608; Mon, 18 Mar 2013 17:30:02 GMT Received: (from sender 74627) (rs149.luxsci.com [127.0.0.1]) by LuxSci SP; Mon, 18 Mar 2013 17:30:02 +0000 Subject: Re: Handbook Jail Chapter rewrite available for critique Content-Type: text/plain; charset=windows-1252 From: "Isaac (.ike) Levy" In-Reply-To: <51474796.1030808@a1poweruser.com> Date: Mon, 18 Mar 2013 13:29:18 -0400 Content-Transfer-Encoding: quoted-printable References: <51474796.1030808@a1poweruser.com> To: Fbsd8 X-Lux-Comment: Message r2IHTIkR030230 sent by user #74627 Message-Id: <1363627802-7836632.18463322.fr2IHTIkR030230@rs149.luxsci.com> X-Comment: LuxSci SP Message ID - 1363627802-7836632.18463322 Cc: freebsd-doc@freebsd.org, FreeBSD questions , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 17:30:52 -0000 Pretty heavy cross-posting here, could you perhaps reign this in to the = freebsd-jail@ list, where it can be discussed in-context? This will = help keep the noise down. On Mar 18, 2013, at 12:57 PM, Fbsd8 wrote: > To all interested parties; >=20 > I have completed the final draft of the total rewrite of FreeBSD's = handbook Chapter 16 on Jails. >=20 > Before submitting my work for submission to the documentation group = for insertion in the handbook I am looking for critique of the work to = find errors in concept, wrong use of words, or anything to make it = better. >=20 > All feedback welcomed. >=20 > Use this URL to access it http://www.jails.a1poweruser.com/ >=20 >=20 > Thank You. Wow, overall that's really quite cool. - Do you have a rough timeframe for when you want feedback? (I would = like to give this the time it deserves). -- Feedback right off the bat, (please tell me if I'm off track here): - After a short skim- I do not believe the qjail utilities referenced = are appropriate for the FreeBSD handbook. There are many 3rd party = approaches to handling/managing jails, some of them with quite long = histories and loyal user bases- it is impractical and not appropriate to = try to cover any/all of them here. - The "Jail Cell" vocabulary is a serious departure- and may create some = confusion- I'll read thoroughly to get your context right. In what I = understand to be the majority of uses, it's confusing to think of the = hardware host as the 'jail' and the jailed instance as the 'cell'. - The references and history cite some works, but do not cite the = original (and possibly most important) document on jailing, = http://docs.freebsd.org/44doc/papers/jail/jail.ps.gz - There are a number of common lexical errors right off the bat, (There = instead of Their), etc=85 -- I look foreword to reading this on my subway commute this week- Best, .ike From owner-freebsd-current@FreeBSD.ORG Mon Mar 18 17:45:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A6B748D4 for ; Mon, 18 Mar 2013 17:45:52 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) by mx1.freebsd.org (Postfix) with ESMTP id 700C5D29 for ; Mon, 18 Mar 2013 17:45:52 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.0 cv=EehKsYaC c=1 sm=0 a=0NJkuBbZY5VCdgJ+v5fl0w==:17 a=zlqUEQRlq4EA:10 a=AaUjGI9IrlcA:10 a=kj9zAlcOel0A:10 a=OA2lqS22AAAA:8 a=sIt-5M63AAAA:8 a=z7-fl8PHoGEA:10 a=nHIcmVGWnHiVvRmFFYUA:9 a=CjuIK1q_8ugA:10 a=0NJkuBbZY5VCdgJ+v5fl0w==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=roberthuff@rcn.com; spf=neutral; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=roberthuff@rcn.com; sender-id=neutral Received-SPF: neutral (smtp02.rcn.cmh.synacor.com: 209.6.84.183 is neither permitted nor denied by domain of rcn.com) Received: from [209.6.84.183] ([209.6.84.183:32488] helo=jerusalem.litteratus.org.litteratus.org) by smtp.rcn.com (envelope-from ) (ecelerity 2.2.3.49 r(42060/42061)) with ESMTP id E0/C2-28841-9C257415; Mon, 18 Mar 2013 13:45:46 -0400 From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20807.21192.655076.142290@jerusalem.litteratus.org> Date: Mon, 18 Mar 2013 13:45:44 -0400 To: "Isaac (.ike) Levy" Subject: Re: Handbook Jail Chapter rewrite available for critique In-Reply-To: <1363627802-7836632.18463322.fr2IHTIkR030230@rs149.luxsci.com> References: <51474796.1030808@a1poweruser.com> <1363627802-7836632.18463322.fr2IHTIkR030230@rs149.luxsci.com> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid Cc: freebsd-doc@freebsd.org, Fbsd8 , FreeBSD questions , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 17:45:52 -0000 Isaac (.ike) Levy writes: > Pretty heavy cross-posting here, could you perhaps reign this in > to the freebsd-jail@ list, where it can be discussed in-context? > This will help keep the noise down. It will also keep down the signal from people who use or are interested in jails, but do not (and do not plan to) subscribe to that list. Respectfully, Robert Huff From owner-freebsd-current@FreeBSD.ORG Mon Mar 18 18:42:39 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8322AADB for ; Mon, 18 Mar 2013 18:42:39 +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 6ABA5F6 for ; Mon, 18 Mar 2013 18:42:39 +0000 (UTC) Received: from [10.0.10.1] ([173.88.202.176]) by mail-03.name-services.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Mar 2013 11:42:37 -0700 Message-ID: <5147601B.3030900@a1poweruser.com> Date: Mon, 18 Mar 2013 14:42:35 -0400 From: Fbsd8 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: freebsd-current Subject: Handbook Jail Chapter rewrite available for critique Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Mar 2013 18:42:37.0949 (UTC) FILETIME=[5D085AD0:01CE2408] X-Sender: fbsd8@a1poweruser.com X-Authenticated-Sender: fbsd8@a1poweruser.com X-EchoSenderHash: [fbsd8]-[a1poweruser*com] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 18:42:39 -0000 To all interested parties; I have completed the final draft of the total rewrite of FreeBSD's handbook Chapter 16 on Jails. Before submitting my work for submission to the documentation group for insertion in the handbook I am looking for critique of the work to find errors in concept, wrong use of words, or anything to make it better. All feedback welcomed. Please email me directly so we keep the noise down on the mailing list. Use this URL to access it http://www.jails.a1poweruser.com/ Thank You. _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Mar 18 19:10:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4559F379 for ; Mon, 18 Mar 2013 19:10:56 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.freebsd.org (Postfix) with SMTP id 00BF229B for ; Mon, 18 Mar 2013 19:10:54 +0000 (UTC) Received: (qmail 70669 invoked from network); 18 Mar 2013 19:10:48 -0000 Received: from 87.58.146.155 (HELO x2.osted.lan) (87.58.146.155) by relay02.pair.com with SMTP; 18 Mar 2013 19:10:48 -0000 X-pair-Authenticated: 87.58.146.155 Received: from x2.osted.lan (localhost [127.0.0.1]) by x2.osted.lan (8.14.5/8.14.5) with ESMTP id r2IJAkUQ041505; Mon, 18 Mar 2013 20:10:46 +0100 (CET) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.5/8.14.5/Submit) id r2IJAkwT041504; Mon, 18 Mar 2013 20:10:46 +0100 (CET) (envelope-from pho) Date: Mon, 18 Mar 2013 20:10:45 +0100 From: Peter Holm To: Andre Oppermann Subject: Re: NewNFS vs. oldNFS for 10.0? Message-ID: <20130318191045.GA41473@x2.osted.lan> References: <1547734002.3937074.1363356520474.JavaMail.root@erie.cs.uoguelph.ca> <51470BEC.5090304@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51470BEC.5090304@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Rick Macklem , Lars Eggert , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 19:10:56 -0000 On Mon, Mar 18, 2013 at 01:43:24PM +0100, Andre Oppermann wrote: > On 15.03.2013 15:08, Rick Macklem wrote: > > Lars Eggert wrote: > >> Hi, > >> > >> this reminds me that I ran into an issue lately with the new NFS and > >> locking for NFSv3 mounts on a client that ran -CURRENT and a server > >> that ran -STABLE. > >> > >> When I ran "portmaster -a" on the client, which mounted /usr/ports and > >> /usr/local, as well as the location of the respective sqlite databases > >> over NFSv3, the client network stack became unresponsive on all > >> interfaces for 30 or so seconds and e.g. SSH connections broke. The > >> serial console remained active throughout, and the system didn't > >> crash. About a minute after the wedgie I could SSH into the box again, > >> too. > >> > >> The issue went away when I killed lockd on the client, but that caused > >> the sqlite database to become corrupted over time. The workaround for > >> me was to move to NFSv4, which has been working fine. (One more reason > >> to make it the default...) > >> > > I've mentioned limitations w.r.t. the design of the NLM protocol (rpc.lockd) > > before. Any time there is any kind of network topology issue, it will run > > into difficulties. There may also be other issues. > > > > However, since both the old and new client use the same rpc.lockd in the > > same way (the new one just cribbed the code from the old one), I think > > the same problem would exist for the old one. As such, I don't believe > > this is a regression. > > Maybe we can talk Peter Holm into periodically running his file system > stress test suite against NFS too? :-) Peter? > I'll add this to my work queue :) - Peter From owner-freebsd-current@FreeBSD.ORG Mon Mar 18 20:43:02 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 28C33DF3 for ; Mon, 18 Mar 2013 20:43:02 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-vb0-x235.google.com (mail-vb0-x235.google.com [IPv6:2607:f8b0:400c:c02::235]) by mx1.freebsd.org (Postfix) with ESMTP id BA23C96C for ; Mon, 18 Mar 2013 20:43:01 +0000 (UTC) Received: by mail-vb0-f53.google.com with SMTP id fj18so3736182vbb.12 for ; Mon, 18 Mar 2013 13:43:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=24OGNYqAG9L7LEFqnS9oig5ZQBHt921uhTjJYbFqwuI=; b=CWoXd9AR4eV4YrZZTNyindrLocJbxdqd8T7NmkuM97p2PFL+HRzjp9f2lS8hv+wuCC BmZpLEEqfK5wUHxqwbTJ9wMXWrIy1jpDb4F1TwRH+LrnYTDeSKkboi0SGelkMXijpHCc FENaVKlMWs5oaTeXmoi0NIH0wr1c+R7/BWBuzBTyA4JPVRz4pxI/IhkUjpXDYyhVev4a LkA7fv1F1kZsuJaLpuWMAzxDSwfM9hrdQylakonL315SuCIGSLLWTRaF5juWIN+QWJaD rK/tMnCh9/03xQssYCOZbbl3tSVfhRbeIA5B2njirmhaDxFoRANgJhoBl2tmXUoxqowO RRcg== MIME-Version: 1.0 X-Received: by 10.52.27.17 with SMTP id p17mr19319091vdg.0.1363639381182; Mon, 18 Mar 2013 13:43:01 -0700 (PDT) Received: by 10.58.132.203 with HTTP; Mon, 18 Mar 2013 13:43:01 -0700 (PDT) In-Reply-To: References: <35878.1363607691@critter.freebsd.dk> <514715F9.2080506@freebsd.org> <43BD412145BF4C7A9E2EFF91CF2ED379@multiplay.co.uk> Date: Mon, 18 Mar 2013 13:43:01 -0700 Message-ID: Subject: Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots From: Mehmet Erol Sanliturk To: Scot Hetzel Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 20:43:02 -0000 On Mon, Mar 18, 2013 at 9:48 AM, Scot Hetzel wrote: > On Mon, Mar 18, 2013 at 11:06 AM, Mehmet Erol Sanliturk > wrote: > > Computer A : Memory Chip Sizes : ( 2 GB , 1 GB , 2 GB , 1 GB ) : Working > > SLOW . FreeBSD A > > Computer B : Memory Chip Sizes : ( 2 GB , 2 GB , 2 GB , 2 GB ) : Working > > FAST . FreeBSD B > > > > Interchange memory chips : > > > > Computer A : Memory Chip Sizes : ( 2 GB , 2 GB , 2 GB , 2 GB ) : Working > > FAST . FreeBSD A > > Computer B : Memory Chip Sizes : ( 2 GB , 1 GB , 2 GB , 1 GB ) : Working > > SLOW . FreeBSD B > > > > > > What happens if you configure the memory as ( 2 GB , 2 GB , 1 GB , 1 GB )? > > -- > DISCLAIMER: > > No electrons were maimed while sending this message. Only slightly bruised. > This can NOT be done , because Channel A : Slot 1 : Slot 2 : Channel B : Slot 1 : Slot 2 : ( Slot 1 , Slot 1 ) should be equivalent when chips inserted to both . ( Slot 2 , Slot 2 ) should be equivalent when chips inserted to both . Thank you ver much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Mon Mar 18 20:49:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 38D7A269 for ; Mon, 18 Mar 2013 20:49:19 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.180]) by mx1.freebsd.org (Postfix) with ESMTP id 0083F9D6 for ; Mon, 18 Mar 2013 20:49:18 +0000 (UTC) Received: by mail-ve0-f180.google.com with SMTP id jx10so4811106veb.11 for ; Mon, 18 Mar 2013 13:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=k1c57geKpj21I2BH5qqhSOsbsOxOdk8Adxwig1SnR9Q=; b=lC54EEOTegjsfBnOj3Fqz2f13Hr+metIEfS1+JviClEPsXTl3I7YZXMfbgvMaQ37JJ /wTUHcgQM2MPB6jU+yXr1k1RHog9m+hsDmxVZ1mrbij2X1LAokSVevUuM/t1Ct39dZRN JgLhf0/2QVW7xE7hCXn6Y/lBuFREEgk9fvvZ63eKKnpdyHIRDzYhP7FYiPs9f5M7Zk1l PRcO6ClPNgvHo1s6UcYparnF6uG1+gqNxkcnybmxNDXEluI29sNAq70lsm5yealG42Mu 2OqI8xByyFEsFdBQ1SUaMnQKm3EetH3YybgO5t3taiDou9IUOXZGZvOWiUPEQ2xpyair wdlQ== MIME-Version: 1.0 X-Received: by 10.52.24.114 with SMTP id t18mr18557363vdf.62.1363639758294; Mon, 18 Mar 2013 13:49:18 -0700 (PDT) Received: by 10.58.132.203 with HTTP; Mon, 18 Mar 2013 13:49:18 -0700 (PDT) Date: Mon, 18 Mar 2013 13:49:18 -0700 Message-ID: Subject: Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots From: Mehmet Erol Sanliturk To: freebsd-current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 20:49:19 -0000 Dear All , I tried the following on Nathan Whitehorn's suggestions : I have disabled ~/.xinitrc , leaving X with its default window manager . I have started Firefox . The same slow behavior ! The problem starts after STARTING X . The rest ( FluxBox , KDE , Gnome ) seems to be innocent . If I can apply other tests , please tell me . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Mon Mar 18 21:27:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 57C90389 for ; Mon, 18 Mar 2013 21:27:55 +0000 (UTC) (envelope-from ohauer@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by mx1.freebsd.org (Postfix) with ESMTP id C4ABBC36 for ; Mon, 18 Mar 2013 21:27:54 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.10]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Lewz3-1V4I5x22ql-00qmfY for ; Mon, 18 Mar 2013 22:27:50 +0100 Received: (qmail invoked by alias); 18 Mar 2013 21:27:50 -0000 Received: from p578be941.dip0.t-ipconnect.de (EHLO [192.168.0.100]) [87.139.233.65] by mail.gmx.net (mp010) with SMTP; 18 Mar 2013 22:27:50 +0100 X-Authenticated: #1956535 X-Provags-ID: V01U2FsdGVkX18Z7NJgLaUZfIA3MhqDfphftCueNz8eU/P6bAj8ic nZX3Y+dLIHJGMj Message-ID: <51478703.7030907@gmx.de> Date: Mon, 18 Mar 2013 22:28:35 +0100 From: olli hauer User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots References: <35878.1363607691@critter.freebsd.dk> <514715F9.2080506@freebsd.org> <43BD412145BF4C7A9E2EFF91CF2ED379@multiplay.co.uk> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 21:27:55 -0000 On 2013-03-18 21:43, Mehmet Erol Sanliturk wrote: > On Mon, Mar 18, 2013 at 9:48 AM, Scot Hetzel wrote: > >> On Mon, Mar 18, 2013 at 11:06 AM, Mehmet Erol Sanliturk >> wrote: >>> Computer A : Memory Chip Sizes : ( 2 GB , 1 GB , 2 GB , 1 GB ) : Working >>> SLOW . FreeBSD A >>> Computer B : Memory Chip Sizes : ( 2 GB , 2 GB , 2 GB , 2 GB ) : Working >>> FAST . FreeBSD B >>> >>> Interchange memory chips : >>> >>> Computer A : Memory Chip Sizes : ( 2 GB , 2 GB , 2 GB , 2 GB ) : Working >>> FAST . FreeBSD A >>> Computer B : Memory Chip Sizes : ( 2 GB , 1 GB , 2 GB , 1 GB ) : Working >>> SLOW . FreeBSD B >>> >>> >> >> What happens if you configure the memory as ( 2 GB , 2 GB , 1 GB , 1 GB )? >> >> -- >> DISCLAIMER: >> >> No electrons were maimed while sending this message. Only slightly bruised. >> > > > This can NOT be done , because > > Channel A : Slot 1 : > Slot 2 : > > Channel B : Slot 1 : > Slot 2 : > > ( Slot 1 , Slot 1 ) should be equivalent when chips inserted to both . > ( Slot 2 , Slot 2 ) should be equivalent when chips inserted to both . > > Thank you ver much . > I suspect the BIOS does not detect the optimal timing for the "SLOW" RAM or a RAM Module is running on a slower timing. What happen if you test with only the 2GB or the 1GB modules (to identify possible CHIP issues). How is the memory detected in the BIOS (timings ...) some newer BIOS can run manual tests to detect timing issues. From owner-freebsd-current@FreeBSD.ORG Mon Mar 18 21:41:57 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 76EB3B02; Mon, 18 Mar 2013 21:41:57 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by mx1.freebsd.org (Postfix) with ESMTP id EB2A4DA7; Mon, 18 Mar 2013 21:41:56 +0000 (UTC) Received: by mail-ob0-f178.google.com with SMTP id wd20so5921155obb.9 for ; Mon, 18 Mar 2013 14:41:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=W3Dsy9YSVX70y5vYtHEN3rpPjACWZ5c+BI644aJcotY=; b=FjcrWGne37y9NyRCRsPYkAxHJPt/z0+nsGUkjvSUq2BORTA5G/lbuOwksmqP+hOWbE ajnawByYuntCkvg0Ev0++ou35oY0vi3CD9D2Us0yd4HivmrLvgZy5JZVwJifj8k5lpBn 1RoTI/D04Y2G8s3q9H+pLPmHI2Y7VN9r6aSJdPJNMKfU4/kWkCMD1Qbp3IoCtZgPtAfo E/iBnXiQn/6Ay2hmtR0NwZlm0RiFMNUBiCLpg4MbsDR4BkOHf0m6r2uu9jXJpooPQ07K w7XzhBBS0WblV2KGgxncf7hb0PR3Xncg0mOALZ/AQDMLVVWXqFp+jXz4fW1xwDtSdhD5 bXaA== MIME-Version: 1.0 X-Received: by 10.182.98.109 with SMTP id eh13mr7703972obb.50.1363642916590; Mon, 18 Mar 2013 14:41:56 -0700 (PDT) Received: by 10.76.94.12 with HTTP; Mon, 18 Mar 2013 14:41:56 -0700 (PDT) In-Reply-To: <20807.21192.655076.142290@jerusalem.litteratus.org> References: <51474796.1030808@a1poweruser.com> <1363627802-7836632.18463322.fr2IHTIkR030230@rs149.luxsci.com> <20807.21192.655076.142290@jerusalem.litteratus.org> Date: Mon, 18 Mar 2013 22:41:56 +0100 Message-ID: Subject: Re: Handbook Jail Chapter rewrite available for critique From: Andreas Nilsson To: Robert Huff Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-doc@freebsd.org, Fbsd8 , FreeBSD questions , freebsd-current , "Isaac \(.ike\) Levy" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 21:41:57 -0000 On Mon, Mar 18, 2013 at 6:45 PM, Robert Huff wrote: > > Isaac (.ike) Levy writes: > > > Pretty heavy cross-posting here, could you perhaps reign this in > > to the freebsd-jail@ list, where it can be discussed in-context? > > This will help keep the noise down. > > It will also keep down the signal from people who use or are > interested in jails, but do not (and do not plan to) subscribe to > that list. > Respectfully, > > > Robert Huff > > Great! There really was a need to modernize the handbook with regards to jails. Since I'm not a native English speaker I'll leave grammar and spelling for those who are ;) My first impressions are along the lines: To much scripts, to few examples/scenarios. Our users are smart, show them what can be accomplished with "high-level" config, leave minutiae to some part of the appendix. Also the exclusion of zfs and vnet is surprising, as those really make jails shine, imo ( although jails really need to be thought about the "gray" area visa-vi networking in rc-scripts that vnet provides ). How about the resource control, which further makes jails really spiffy. I would have preferred top-level separation of the different methods, ie after the introduction there was one "track" manual, one for old-school rc-, one for new-school rc- and one for jail.conf-style jails. More specifically I agree with Isaac Levy's, especially in regards to the "jail cell" terminology: "16.1 Synopsis": the term jail cell is used, long before being defined. "16.2 Introduction": Mentioning jail cells in a historic contest is imho a "blatant" lie ( they were never known as such ). As far as I know, no official documentation has called them cells, either. That does not mean that it's not an appropriate term, though. As a contrast there is Solaris vocabulary of zones ( "cells" ) and global zone ( "jail system" ). In this regard I prefer the solaris one. Most importantly, a large chunk of 16.2 would imo fit much better as a "history"-appendix. Current and new users don't need to know and consider the limitations of earlier implementations. The "generations" talked about could perhaps be quantified with a release version :) There are, as stated by Isaac Levy, many (good) utils for managing jails. Why the focus on qjail? I also think that most of the strong points of jails are rendered moot without, in order, zfs and vimage. Linux jails might also interest quite a few people. Best regards Andreas From owner-freebsd-current@FreeBSD.ORG Mon Mar 18 21:48:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AFCF971 for ; Mon, 18 Mar 2013 21:48:40 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-vb0-x235.google.com (mail-vb0-x235.google.com [IPv6:2607:f8b0:400c:c02::235]) by mx1.freebsd.org (Postfix) with ESMTP id 6C7C1E48 for ; Mon, 18 Mar 2013 21:48:40 +0000 (UTC) Received: by mail-vb0-f53.google.com with SMTP id fj18so3677075vbb.40 for ; Mon, 18 Mar 2013 14:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Y286Acf8rMUJ2wnnVIPHio16Fh7Ul5wyhlXLD3Fsulo=; b=HcD8RB0E0n+mK9sykte8Ln/xTwC9XgBNyIb/xwLZ46KjUv9nYDKKFSKIA0phi0csoo 5yKw3xINmxJd7uGeF5WeLngYPa4mI4Rfl7BNZjqm+6xmk1YDl58WACzwoVIqNVPf/oBt vp3ehN2efHSPzWR2qVdJTrzy0yDa5JRb+xloVWx2qM61/eln5ItzPzYvuJHE3iTmB/pZ hH7CDC/OKnnnjaorKmoiMEMaTSfd/Fr182ZlNCv9q7SbhWfsTam0jpysim+kl6wsA7Mn EDyzFXRdog4S4F4jGQjzUWKTxLeGc6TWUeupzkRzlLAiYmtKdWMpfNR/Ata5AMfOmHAa c4VA== MIME-Version: 1.0 X-Received: by 10.58.252.72 with SMTP id zq8mr22634744vec.20.1363643319973; Mon, 18 Mar 2013 14:48:39 -0700 (PDT) Received: by 10.58.132.203 with HTTP; Mon, 18 Mar 2013 14:48:39 -0700 (PDT) In-Reply-To: <51478703.7030907@gmx.de> References: <35878.1363607691@critter.freebsd.dk> <514715F9.2080506@freebsd.org> <43BD412145BF4C7A9E2EFF91CF2ED379@multiplay.co.uk> <51478703.7030907@gmx.de> Date: Mon, 18 Mar 2013 14:48:39 -0700 Message-ID: Subject: Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots From: Mehmet Erol Sanliturk To: olli hauer Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 21:48:40 -0000 On Mon, Mar 18, 2013 at 2:28 PM, olli hauer wrote: > On 2013-03-18 21:43, Mehmet Erol Sanliturk wrote: > > On Mon, Mar 18, 2013 at 9:48 AM, Scot Hetzel wrote: > > > >> On Mon, Mar 18, 2013 at 11:06 AM, Mehmet Erol Sanliturk > >> wrote: > >>> Computer A : Memory Chip Sizes : ( 2 GB , 1 GB , 2 GB , 1 GB ) : > Working > >>> SLOW . FreeBSD A > >>> Computer B : Memory Chip Sizes : ( 2 GB , 2 GB , 2 GB , 2 GB ) : > Working > >>> FAST . FreeBSD B > >>> > >>> Interchange memory chips : > >>> > >>> Computer A : Memory Chip Sizes : ( 2 GB , 2 GB , 2 GB , 2 GB ) : > Working > >>> FAST . FreeBSD A > >>> Computer B : Memory Chip Sizes : ( 2 GB , 1 GB , 2 GB , 1 GB ) : > Working > >>> SLOW . FreeBSD B > >>> > >>> > >> > >> What happens if you configure the memory as ( 2 GB , 2 GB , 1 GB , 1 GB > )? > >> > >> -- > >> DISCLAIMER: > >> > >> No electrons were maimed while sending this message. Only slightly > bruised. > >> > > > > > > This can NOT be done , because > > > > Channel A : Slot 1 : > > Slot 2 : > > > > Channel B : Slot 1 : > > Slot 2 : > > > > ( Slot 1 , Slot 1 ) should be equivalent when chips inserted to both . > > ( Slot 2 , Slot 2 ) should be equivalent when chips inserted to both . > > > > Thank you ver much . > > > > I suspect the BIOS does not detect the optimal timing for the "SLOW" RAM or > a RAM Module is running on a slower timing. > > What happen if you test with only the 2GB or the 1GB modules (to identify > possible CHIP issues). > How is the memory detected in the BIOS (timings ...) some newer BIOS can > run manual tests to detect timing issues. > > > > These are worked : http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031836.html http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031912.html http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031928.html http://lists.freebsd.org/pipermail/freebsd-current/2012-February/032012.html It seems that memory chip sizes are not checked one by one or used per chip in slots , but a COMMON value is used : Size of chip in first slot . When size of chip in second slot is smaller than size of chip in first slot , problem appears . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Mon Mar 18 22:46:58 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5659D891; Mon, 18 Mar 2013 22:46:58 +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 27EF9201; Mon, 18 Mar 2013 22:46:57 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2IMkung009745; Mon, 18 Mar 2013 18:46:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2IMkuS1009741; Mon, 18 Mar 2013 22:46:56 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 18 Mar 2013 22:46:56 GMT Message-Id: <201303182246.r2IMkuS1009741@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 22:46:58 -0000 TB --- 2013-03-18 19:54:43 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-18 19:54:43 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-18 19:54:43 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-03-18 19:54:43 - cleaning the object tree TB --- 2013-03-18 19:54:43 - /usr/local/bin/svn stat /src TB --- 2013-03-18 19:54:46 - At svn revision 248465 TB --- 2013-03-18 19:54:47 - building world TB --- 2013-03-18 19:54:47 - CROSS_BUILD_TESTING=YES TB --- 2013-03-18 19:54:47 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-18 19:54:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-18 19:54:47 - SRCCONF=/dev/null TB --- 2013-03-18 19:54:47 - TARGET=powerpc TB --- 2013-03-18 19:54:47 - TARGET_ARCH=powerpc64 TB --- 2013-03-18 19:54:47 - TZ=UTC TB --- 2013-03-18 19:54:47 - __MAKE_CONF=/dev/null TB --- 2013-03-18 19:54:47 - cd /src TB --- 2013-03-18 19:54:47 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Mar 18 19:54:52 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Mon Mar 18 22:38:03 UTC 2013 TB --- 2013-03-18 22:38:03 - generating LINT kernel config TB --- 2013-03-18 22:38:03 - cd /src/sys/powerpc/conf TB --- 2013-03-18 22:38:03 - /usr/bin/make -B LINT TB --- 2013-03-18 22:38:03 - cd /src/sys/powerpc/conf TB --- 2013-03-18 22:38:03 - /usr/sbin/config -m LINT TB --- 2013-03-18 22:38:03 - skipping LINT kernel TB --- 2013-03-18 22:38:03 - cd /src/sys/powerpc/conf TB --- 2013-03-18 22:38:03 - /usr/sbin/config -m GENERIC TB --- 2013-03-18 22:38:03 - skipping GENERIC kernel TB --- 2013-03-18 22:38:03 - cd /src/sys/powerpc/conf TB --- 2013-03-18 22:38:03 - /usr/sbin/config -m GENERIC64 TB --- 2013-03-18 22:38:03 - building GENERIC64 kernel TB --- 2013-03-18 22:38:03 - CROSS_BUILD_TESTING=YES TB --- 2013-03-18 22:38:03 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-18 22:38:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-18 22:38:03 - SRCCONF=/dev/null TB --- 2013-03-18 22:38:03 - TARGET=powerpc TB --- 2013-03-18 22:38:03 - TARGET_ARCH=powerpc64 TB --- 2013-03-18 22:38:03 - TZ=UTC TB --- 2013-03-18 22:38:03 - __MAKE_CONF=/dev/null TB --- 2013-03-18 22:38:03 - cd /src TB --- 2013-03-18 22:38:03 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64 >>> Kernel build for GENERIC64 started on Mon Mar 18 22:38:03 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/modules/dtrace/fbt/../../../cddl/dev/fbt/fbt.c:291: error: 'DTRACE_INVOP_PUSHL_EBP' undeclared (first use in this function) /src/sys/modules/dtrace/fbt/../../../cddl/dev/fbt/fbt.c:291: error: (Each undeclared identifier is reported only once /src/sys/modules/dtrace/fbt/../../../cddl/dev/fbt/fbt.c:291: error: for each function it appears in.) cc1: warnings being treated as errors /src/sys/modules/dtrace/fbt/../../../cddl/dev/fbt/fbt.c:311: warning: implicit declaration of function 'dtrace_instr_size' /src/sys/modules/dtrace/fbt/../../../cddl/dev/fbt/fbt.c:311: warning: nested extern declaration of 'dtrace_instr_size' [-Wnested-externs] /src/sys/modules/dtrace/fbt/../../../cddl/dev/fbt/fbt.c:385: error: 'DTRACE_INVOP_POPL_EBP' undeclared (first use in this function) /src/sys/modules/dtrace/fbt/../../../cddl/dev/fbt/fbt.c:388: error: 'DTRACE_INVOP_LEAVE' undeclared (first use in this function) *** [fbt.o] Error code 1 Stop in /src/sys/modules/dtrace/fbt. *** [all] Error code 1 Stop in /src/sys/modules/dtrace. *** [all] Error code 1 Stop in /src/sys/modules. *** [modules-all] Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/GENERIC64. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-18 22:46:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-18 22:46:56 - ERROR: failed to build GENERIC64 kernel TB --- 2013-03-18 22:46:56 - 9218.26 user 1190.64 system 10333.29 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Mar 19 05:41:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C5515F42 for ; Tue, 19 Mar 2013 05:41:52 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-bk0-x230.google.com (mail-bk0-x230.google.com [IPv6:2a00:1450:4008:c01::230]) by mx1.freebsd.org (Postfix) with ESMTP id 58F2E2EF for ; Tue, 19 Mar 2013 05:41:52 +0000 (UTC) Received: by mail-bk0-f48.google.com with SMTP id jf20so43789bkc.7 for ; Mon, 18 Mar 2013 22:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=yrx9dmpZ4YKwTPmYltMna5mW0KVxKRzuCV7JV6sa+3U=; b=fTKAxhYFHbwAo1e3D1Y3D07gxH2HpNut9DMpmq6fFi+YmNJPPdi8HZof5CA+NDG087 mJQLXiKP71pLn0sRP5MY3FM84ZrLJmHauuDnM8XLzjHbgcNhUHyvpoMYtyI8DUjsjTmm G5FIdDPnEZu71A4Cb+o+pSV6GAaARi2uIWga+Ei1tqucQplN6UKNilZohr8R4cI1rTsC DB5KxTfQkXR3Wn681lmm0OCBSoESGaJsODRuVWtK0LQYaUtnRL39SRqyM8m+R37WvLAV /WrE9JcLLvwYeLDVNNo4lQw/Bsr48l8tDxUSfENJDsPC39RVkpMF7hdABoDWPlYDSdPf WDKA== MIME-Version: 1.0 X-Received: by 10.205.39.3 with SMTP id tk3mr8097647bkb.113.1363671711336; Mon, 18 Mar 2013 22:41:51 -0700 (PDT) Received: by 10.204.16.144 with HTTP; Mon, 18 Mar 2013 22:41:51 -0700 (PDT) In-Reply-To: References: <50311741.3000204@yandex.ru> Date: Tue, 19 Mar 2013 08:41:51 +0300 Message-ID: Subject: Re: gptzfsboot problem on HP P410i Smart Array From: Sergey Dyatko To: Bjorn Larsson Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 05:41:52 -0000 2012/8/20 Bjorn Larsson > Hi Andrey, > > We are installing freeBSD using ZFS as root filesystem using the GPT > method as described on the freeBSD ZFS wiki. We are creating a GPT > boot partition with the gptzfsboot program embedded and then a zroot > partition with the freeBSD binaries. This works well and boots on > every system we tested except HP P410i smart array systems. The > problem is that no disks are identified in gptzfsboot and the > following error code is displayed: > > gptzfsboot: error 1 lba 32 > gptzfsboot: error 1 lba 1 > > It appears that gptzfsboot is not identifying the drives properly. > However, when we insert a printf() command in main() in zfsboot.c to > troubleshoot the identification problem, the system boots perfectly > fine. > > This is a problem that I believe was fixed last year in 9-CURRENT by > implementing a proper struct for edd rather than using a char array > for BIOS communication. However, it doesn't seems to have fixed the on > the p410i smart arrays. > > I was faced with same problem on my laptop. Adding printf() into main() before dsk =3D malloc(sizeof(struct dsk)); fix boot. Yesterday, avg@ propos= ed patch: Index: /usr/src/sys/boot/i386/zfsboot/zfsboot.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/boot/i386/zfsboot/zfsboot.c (revision 248421) +++ /usr/src/sys/boot/i386/zfsboot/zfsboot.c (working copy) @@ -302,6 +302,7 @@ * region in the SMAP, use the last 3MB of 'extended' memory as a * high heap candidate. */ + high_heap_size =3D 0; if (bios_extmem >=3D HEAP_MIN && high_heap_size < HEAP_MIN) { high_heap_size =3D HEAP_MIN; high_heap_base =3D bios_extmem + 0x100000 - HEAP_MIN; it works for me, without printf() :) Can you test it ? > Best regards, > > Bj=F6rn Larsson > > > On Sun, Aug 19, 2012 at 6:41 PM, Andrey V. Elsukov > wrote: > > > > On 19.08.2012 11:22, Bjorn Larsson wrote: > > > We are having problems with gptzfsboot on a HP DL360 G7 using the P41= 0i > > > Smart Array Controller. > > > I=92ve some information on this in the archive on this mailing list t= hat > this > > > has supposedly been fixed with revision 227400, by implementing the e= dd > > > data structure. > > > However we still see the same problem and by adding a printf() in > zfsboot.c > > > fixes the problem. > > > Please, let me know if anyone have seen this problem and if there is = a > fix > > > for it? > > > > Hi, > > > > what exactly do you have? > > > > -- > > WBR, Andrey V. Elsukov > > > _______________________________________________ > 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 Tue Mar 19 07:11:17 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7088C1ED; Tue, 19 Mar 2013 07:11:17 +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 33954838; Tue, 19 Mar 2013 07:11:16 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2J7BG3R011246; Tue, 19 Mar 2013 03:11:16 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2J7BGw3011245; Tue, 19 Mar 2013 07:11:16 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 19 Mar 2013 07:11:16 GMT Message-Id: <201303190711.r2J7BGw3011245@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 07:11:17 -0000 TB --- 2013-03-19 04:49:40 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-19 04:49:40 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-19 04:49:40 - starting HEAD tinderbox run for mips/mips TB --- 2013-03-19 04:49:40 - cleaning the object tree TB --- 2013-03-19 04:49:40 - /usr/local/bin/svn stat /src TB --- 2013-03-19 04:49:59 - At svn revision 248477 TB --- 2013-03-19 04:50:00 - building world TB --- 2013-03-19 04:50:00 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 04:50:00 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 04:50:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 04:50:00 - SRCCONF=/dev/null TB --- 2013-03-19 04:50:00 - TARGET=mips TB --- 2013-03-19 04:50:00 - TARGET_ARCH=mips TB --- 2013-03-19 04:50:00 - TZ=UTC TB --- 2013-03-19 04:50:00 - __MAKE_CONF=/dev/null TB --- 2013-03-19 04:50:00 - cd /src TB --- 2013-03-19 04:50:00 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Mar 19 04:50:05 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Mar 19 05:53:22 UTC 2013 TB --- 2013-03-19 05:53:22 - cd /src/sys/mips/conf TB --- 2013-03-19 05:53:22 - /usr/sbin/config -m ADM5120 TB --- 2013-03-19 05:53:22 - skipping ADM5120 kernel TB --- 2013-03-19 05:53:22 - cd /src/sys/mips/conf TB --- 2013-03-19 05:53:22 - /usr/sbin/config -m ALCHEMY TB --- 2013-03-19 05:53:22 - skipping ALCHEMY kernel TB --- 2013-03-19 05:53:22 - cd /src/sys/mips/conf TB --- 2013-03-19 05:53:22 - /usr/sbin/config -m AP91 TB --- 2013-03-19 05:53:22 - building AP91 kernel TB --- 2013-03-19 05:53:22 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 05:53:22 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 05:53:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 05:53:22 - SRCCONF=/dev/null TB --- 2013-03-19 05:53:22 - TARGET=mips TB --- 2013-03-19 05:53:22 - TARGET_ARCH=mips TB --- 2013-03-19 05:53:22 - TZ=UTC TB --- 2013-03-19 05:53:22 - __MAKE_CONF=/dev/null TB --- 2013-03-19 05:53:22 - cd /src TB --- 2013-03-19 05:53:22 - /usr/bin/make -B buildkernel KERNCONF=AP91 >>> Kernel build for AP91 started on Tue Mar 19 05:53:22 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for AP91 completed on Tue Mar 19 05:57:31 UTC 2013 TB --- 2013-03-19 05:57:31 - cd /src/sys/mips/conf TB --- 2013-03-19 05:57:31 - /usr/sbin/config -m AP93 TB --- 2013-03-19 05:57:31 - building AP93 kernel TB --- 2013-03-19 05:57:31 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 05:57:31 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 05:57:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 05:57:31 - SRCCONF=/dev/null TB --- 2013-03-19 05:57:31 - TARGET=mips TB --- 2013-03-19 05:57:31 - TARGET_ARCH=mips TB --- 2013-03-19 05:57:31 - TZ=UTC TB --- 2013-03-19 05:57:31 - __MAKE_CONF=/dev/null TB --- 2013-03-19 05:57:31 - cd /src TB --- 2013-03-19 05:57:31 - /usr/bin/make -B buildkernel KERNCONF=AP93 >>> Kernel build for AP93 started on Tue Mar 19 05:57:31 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for AP93 completed on Tue Mar 19 06:01:20 UTC 2013 TB --- 2013-03-19 06:01:20 - cd /src/sys/mips/conf TB --- 2013-03-19 06:01:20 - /usr/sbin/config -m AP94 TB --- 2013-03-19 06:01:20 - building AP94 kernel TB --- 2013-03-19 06:01:20 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 06:01:20 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 06:01:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 06:01:20 - SRCCONF=/dev/null TB --- 2013-03-19 06:01:20 - TARGET=mips TB --- 2013-03-19 06:01:20 - TARGET_ARCH=mips TB --- 2013-03-19 06:01:20 - TZ=UTC TB --- 2013-03-19 06:01:20 - __MAKE_CONF=/dev/null TB --- 2013-03-19 06:01:20 - cd /src TB --- 2013-03-19 06:01:20 - /usr/bin/make -B buildkernel KERNCONF=AP94 >>> Kernel build for AP94 started on Tue Mar 19 06:01:20 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for AP94 completed on Tue Mar 19 06:06:20 UTC 2013 TB --- 2013-03-19 06:06:20 - cd /src/sys/mips/conf TB --- 2013-03-19 06:06:20 - /usr/sbin/config -m AP96 TB --- 2013-03-19 06:06:20 - building AP96 kernel TB --- 2013-03-19 06:06:20 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 06:06:20 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 06:06:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 06:06:20 - SRCCONF=/dev/null TB --- 2013-03-19 06:06:20 - TARGET=mips TB --- 2013-03-19 06:06:20 - TARGET_ARCH=mips TB --- 2013-03-19 06:06:20 - TZ=UTC TB --- 2013-03-19 06:06:20 - __MAKE_CONF=/dev/null TB --- 2013-03-19 06:06:20 - cd /src TB --- 2013-03-19 06:06:20 - /usr/bin/make -B buildkernel KERNCONF=AP96 >>> Kernel build for AP96 started on Tue Mar 19 06:06:20 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for AP96 completed on Tue Mar 19 06:11:01 UTC 2013 TB --- 2013-03-19 06:11:01 - cd /src/sys/mips/conf TB --- 2013-03-19 06:11:01 - /usr/sbin/config -m AR71XX_BASE TB --- 2013-03-19 06:11:01 - building AR71XX_BASE kernel TB --- 2013-03-19 06:11:01 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 06:11:01 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 06:11:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 06:11:01 - SRCCONF=/dev/null TB --- 2013-03-19 06:11:01 - TARGET=mips TB --- 2013-03-19 06:11:01 - TARGET_ARCH=mips TB --- 2013-03-19 06:11:01 - TZ=UTC TB --- 2013-03-19 06:11:01 - __MAKE_CONF=/dev/null TB --- 2013-03-19 06:11:01 - cd /src TB --- 2013-03-19 06:11:01 - /usr/bin/make -B buildkernel KERNCONF=AR71XX_BASE >>> Kernel build for AR71XX_BASE started on Tue Mar 19 06:11:01 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for AR71XX_BASE completed on Tue Mar 19 06:15:59 UTC 2013 TB --- 2013-03-19 06:15:59 - cd /src/sys/mips/conf TB --- 2013-03-19 06:15:59 - /usr/sbin/config -m AR724X_BASE TB --- 2013-03-19 06:15:59 - building AR724X_BASE kernel TB --- 2013-03-19 06:15:59 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 06:15:59 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 06:15:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 06:15:59 - SRCCONF=/dev/null TB --- 2013-03-19 06:15:59 - TARGET=mips TB --- 2013-03-19 06:15:59 - TARGET_ARCH=mips TB --- 2013-03-19 06:15:59 - TZ=UTC TB --- 2013-03-19 06:15:59 - __MAKE_CONF=/dev/null TB --- 2013-03-19 06:15:59 - cd /src TB --- 2013-03-19 06:15:59 - /usr/bin/make -B buildkernel KERNCONF=AR724X_BASE >>> Kernel build for AR724X_BASE started on Tue Mar 19 06:15:59 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for AR724X_BASE completed on Tue Mar 19 06:19:44 UTC 2013 TB --- 2013-03-19 06:19:44 - cd /src/sys/mips/conf TB --- 2013-03-19 06:19:44 - /usr/sbin/config -m AR91XX_BASE TB --- 2013-03-19 06:19:44 - building AR91XX_BASE kernel TB --- 2013-03-19 06:19:44 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 06:19:44 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 06:19:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 06:19:44 - SRCCONF=/dev/null TB --- 2013-03-19 06:19:44 - TARGET=mips TB --- 2013-03-19 06:19:44 - TARGET_ARCH=mips TB --- 2013-03-19 06:19:44 - TZ=UTC TB --- 2013-03-19 06:19:44 - __MAKE_CONF=/dev/null TB --- 2013-03-19 06:19:44 - cd /src TB --- 2013-03-19 06:19:44 - /usr/bin/make -B buildkernel KERNCONF=AR91XX_BASE >>> Kernel build for AR91XX_BASE started on Tue Mar 19 06:19:44 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for AR91XX_BASE completed on Tue Mar 19 06:24:33 UTC 2013 TB --- 2013-03-19 06:24:33 - cd /src/sys/mips/conf TB --- 2013-03-19 06:24:33 - /usr/sbin/config -m BERI_DE4_MDROOT TB --- 2013-03-19 06:24:33 - skipping BERI_DE4_MDROOT kernel TB --- 2013-03-19 06:24:33 - cd /src/sys/mips/conf TB --- 2013-03-19 06:24:33 - /usr/sbin/config -m BERI_DE4_SDROOT TB --- 2013-03-19 06:24:33 - skipping BERI_DE4_SDROOT kernel TB --- 2013-03-19 06:24:33 - cd /src/sys/mips/conf TB --- 2013-03-19 06:24:33 - /usr/sbin/config -m BERI_SIM_MDROOT TB --- 2013-03-19 06:24:33 - skipping BERI_SIM_MDROOT kernel TB --- 2013-03-19 06:24:33 - cd /src/sys/mips/conf TB --- 2013-03-19 06:24:33 - /usr/sbin/config -m BERI_TEMPLATE TB --- 2013-03-19 06:24:33 - skipping BERI_TEMPLATE kernel TB --- 2013-03-19 06:24:33 - cd /src/sys/mips/conf TB --- 2013-03-19 06:24:33 - /usr/sbin/config -m DIR-825 TB --- 2013-03-19 06:24:33 - building DIR-825 kernel TB --- 2013-03-19 06:24:33 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 06:24:33 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 06:24:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 06:24:33 - SRCCONF=/dev/null TB --- 2013-03-19 06:24:33 - TARGET=mips TB --- 2013-03-19 06:24:33 - TARGET_ARCH=mips TB --- 2013-03-19 06:24:33 - TZ=UTC TB --- 2013-03-19 06:24:33 - __MAKE_CONF=/dev/null TB --- 2013-03-19 06:24:33 - cd /src TB --- 2013-03-19 06:24:33 - /usr/bin/make -B buildkernel KERNCONF=DIR-825 >>> Kernel build for DIR-825 started on Tue Mar 19 06:24:34 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DIR-825 completed on Tue Mar 19 06:28:09 UTC 2013 TB --- 2013-03-19 06:28:09 - cd /src/sys/mips/conf TB --- 2013-03-19 06:28:09 - /usr/sbin/config -m GXEMUL TB --- 2013-03-19 06:28:09 - skipping GXEMUL kernel TB --- 2013-03-19 06:28:09 - cd /src/sys/mips/conf TB --- 2013-03-19 06:28:09 - /usr/sbin/config -m IDT TB --- 2013-03-19 06:28:09 - skipping IDT kernel TB --- 2013-03-19 06:28:09 - cd /src/sys/mips/conf TB --- 2013-03-19 06:28:09 - /usr/sbin/config -m MALTA TB --- 2013-03-19 06:28:09 - skipping MALTA kernel TB --- 2013-03-19 06:28:09 - cd /src/sys/mips/conf TB --- 2013-03-19 06:28:09 - /usr/sbin/config -m MALTA64 TB --- 2013-03-19 06:28:09 - skipping MALTA64 kernel TB --- 2013-03-19 06:28:09 - cd /src/sys/mips/conf TB --- 2013-03-19 06:28:09 - /usr/sbin/config -m OCTEON1 TB --- 2013-03-19 06:28:09 - skipping OCTEON1 kernel TB --- 2013-03-19 06:28:09 - cd /src/sys/mips/conf TB --- 2013-03-19 06:28:09 - /usr/sbin/config -m PB47 TB --- 2013-03-19 06:28:09 - building PB47 kernel TB --- 2013-03-19 06:28:09 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 06:28:09 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 06:28:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 06:28:09 - SRCCONF=/dev/null TB --- 2013-03-19 06:28:09 - TARGET=mips TB --- 2013-03-19 06:28:09 - TARGET_ARCH=mips TB --- 2013-03-19 06:28:09 - TZ=UTC TB --- 2013-03-19 06:28:09 - __MAKE_CONF=/dev/null TB --- 2013-03-19 06:28:09 - cd /src TB --- 2013-03-19 06:28:09 - /usr/bin/make -B buildkernel KERNCONF=PB47 >>> Kernel build for PB47 started on Tue Mar 19 06:28:09 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PB47 completed on Tue Mar 19 06:32:43 UTC 2013 TB --- 2013-03-19 06:32:43 - cd /src/sys/mips/conf TB --- 2013-03-19 06:32:43 - /usr/sbin/config -m PB92 TB --- 2013-03-19 06:32:43 - building PB92 kernel TB --- 2013-03-19 06:32:43 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 06:32:43 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 06:32:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 06:32:43 - SRCCONF=/dev/null TB --- 2013-03-19 06:32:43 - TARGET=mips TB --- 2013-03-19 06:32:43 - TARGET_ARCH=mips TB --- 2013-03-19 06:32:43 - TZ=UTC TB --- 2013-03-19 06:32:43 - __MAKE_CONF=/dev/null TB --- 2013-03-19 06:32:43 - cd /src TB --- 2013-03-19 06:32:43 - /usr/bin/make -B buildkernel KERNCONF=PB92 >>> Kernel build for PB92 started on Tue Mar 19 06:32:43 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PB92 completed on Tue Mar 19 06:36:45 UTC 2013 TB --- 2013-03-19 06:36:45 - cd /src/sys/mips/conf TB --- 2013-03-19 06:36:45 - /usr/sbin/config -m QEMU TB --- 2013-03-19 06:36:45 - skipping QEMU kernel TB --- 2013-03-19 06:36:45 - cd /src/sys/mips/conf TB --- 2013-03-19 06:36:45 - /usr/sbin/config -m ROUTERSTATION TB --- 2013-03-19 06:36:45 - building ROUTERSTATION kernel TB --- 2013-03-19 06:36:45 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 06:36:45 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 06:36:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 06:36:45 - SRCCONF=/dev/null TB --- 2013-03-19 06:36:45 - TARGET=mips TB --- 2013-03-19 06:36:45 - TARGET_ARCH=mips TB --- 2013-03-19 06:36:45 - TZ=UTC TB --- 2013-03-19 06:36:45 - __MAKE_CONF=/dev/null TB --- 2013-03-19 06:36:45 - cd /src TB --- 2013-03-19 06:36:45 - /usr/bin/make -B buildkernel KERNCONF=ROUTERSTATION >>> Kernel build for ROUTERSTATION started on Tue Mar 19 06:36:45 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ROUTERSTATION completed on Tue Mar 19 06:41:18 UTC 2013 TB --- 2013-03-19 06:41:18 - cd /src/sys/mips/conf TB --- 2013-03-19 06:41:18 - /usr/sbin/config -m ROUTERSTATION_MFS TB --- 2013-03-19 06:41:18 - building ROUTERSTATION_MFS kernel TB --- 2013-03-19 06:41:18 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 06:41:18 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 06:41:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 06:41:18 - SRCCONF=/dev/null TB --- 2013-03-19 06:41:18 - TARGET=mips TB --- 2013-03-19 06:41:18 - TARGET_ARCH=mips TB --- 2013-03-19 06:41:18 - TZ=UTC TB --- 2013-03-19 06:41:18 - __MAKE_CONF=/dev/null TB --- 2013-03-19 06:41:18 - cd /src TB --- 2013-03-19 06:41:18 - /usr/bin/make -B buildkernel KERNCONF=ROUTERSTATION_MFS >>> Kernel build for ROUTERSTATION_MFS started on Tue Mar 19 06:41:18 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ROUTERSTATION_MFS completed on Tue Mar 19 06:45:59 UTC 2013 TB --- 2013-03-19 06:45:59 - cd /src/sys/mips/conf TB --- 2013-03-19 06:45:59 - /usr/sbin/config -m RSPRO TB --- 2013-03-19 06:45:59 - building RSPRO kernel TB --- 2013-03-19 06:45:59 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 06:45:59 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 06:45:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 06:45:59 - SRCCONF=/dev/null TB --- 2013-03-19 06:45:59 - TARGET=mips TB --- 2013-03-19 06:45:59 - TARGET_ARCH=mips TB --- 2013-03-19 06:45:59 - TZ=UTC TB --- 2013-03-19 06:45:59 - __MAKE_CONF=/dev/null TB --- 2013-03-19 06:45:59 - cd /src TB --- 2013-03-19 06:45:59 - /usr/bin/make -B buildkernel KERNCONF=RSPRO >>> Kernel build for RSPRO started on Tue Mar 19 06:45:59 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for RSPRO completed on Tue Mar 19 06:50:38 UTC 2013 TB --- 2013-03-19 06:50:38 - cd /src/sys/mips/conf TB --- 2013-03-19 06:50:38 - /usr/sbin/config -m RSPRO_MFS TB --- 2013-03-19 06:50:38 - building RSPRO_MFS kernel TB --- 2013-03-19 06:50:38 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 06:50:38 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 06:50:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 06:50:38 - SRCCONF=/dev/null TB --- 2013-03-19 06:50:38 - TARGET=mips TB --- 2013-03-19 06:50:38 - TARGET_ARCH=mips TB --- 2013-03-19 06:50:38 - TZ=UTC TB --- 2013-03-19 06:50:38 - __MAKE_CONF=/dev/null TB --- 2013-03-19 06:50:38 - cd /src TB --- 2013-03-19 06:50:38 - /usr/bin/make -B buildkernel KERNCONF=RSPRO_MFS >>> Kernel build for RSPRO_MFS started on Tue Mar 19 06:50:38 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for RSPRO_MFS completed on Tue Mar 19 06:55:08 UTC 2013 TB --- 2013-03-19 06:55:08 - cd /src/sys/mips/conf TB --- 2013-03-19 06:55:08 - /usr/sbin/config -m RSPRO_STANDALONE TB --- 2013-03-19 06:55:08 - building RSPRO_STANDALONE kernel TB --- 2013-03-19 06:55:08 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 06:55:08 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 06:55:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 06:55:08 - SRCCONF=/dev/null TB --- 2013-03-19 06:55:08 - TARGET=mips TB --- 2013-03-19 06:55:08 - TARGET_ARCH=mips TB --- 2013-03-19 06:55:08 - TZ=UTC TB --- 2013-03-19 06:55:08 - __MAKE_CONF=/dev/null TB --- 2013-03-19 06:55:08 - cd /src TB --- 2013-03-19 06:55:08 - /usr/bin/make -B buildkernel KERNCONF=RSPRO_STANDALONE >>> Kernel build for RSPRO_STANDALONE started on Tue Mar 19 06:55:09 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for RSPRO_STANDALONE completed on Tue Mar 19 07:00:09 UTC 2013 TB --- 2013-03-19 07:00:09 - cd /src/sys/mips/conf TB --- 2013-03-19 07:00:09 - /usr/sbin/config -m RT305X TB --- 2013-03-19 07:00:09 - skipping RT305X kernel TB --- 2013-03-19 07:00:09 - cd /src/sys/mips/conf TB --- 2013-03-19 07:00:09 - /usr/sbin/config -m SENTRY5 TB --- 2013-03-19 07:00:09 - skipping SENTRY5 kernel TB --- 2013-03-19 07:00:09 - cd /src/sys/mips/conf TB --- 2013-03-19 07:00:09 - /usr/sbin/config -m SWARM TB --- 2013-03-19 07:00:09 - building SWARM kernel TB --- 2013-03-19 07:00:09 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 07:00:09 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 07:00:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 07:00:09 - SRCCONF=/dev/null TB --- 2013-03-19 07:00:09 - TARGET=mips TB --- 2013-03-19 07:00:09 - TARGET_ARCH=mips TB --- 2013-03-19 07:00:09 - TZ=UTC TB --- 2013-03-19 07:00:09 - __MAKE_CONF=/dev/null TB --- 2013-03-19 07:00:09 - cd /src TB --- 2013-03-19 07:00:09 - /usr/bin/make -B buildkernel KERNCONF=SWARM >>> Kernel build for SWARM started on Tue Mar 19 07:00:09 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for SWARM completed on Tue Mar 19 07:02:57 UTC 2013 TB --- 2013-03-19 07:02:57 - cd /src/sys/mips/conf TB --- 2013-03-19 07:02:57 - /usr/sbin/config -m SWARM64 TB --- 2013-03-19 07:02:57 - skipping SWARM64 kernel TB --- 2013-03-19 07:02:57 - cd /src/sys/mips/conf TB --- 2013-03-19 07:02:57 - /usr/sbin/config -m SWARM64_SMP TB --- 2013-03-19 07:02:57 - skipping SWARM64_SMP kernel TB --- 2013-03-19 07:02:57 - cd /src/sys/mips/conf TB --- 2013-03-19 07:02:57 - /usr/sbin/config -m SWARM_SMP TB --- 2013-03-19 07:02:57 - building SWARM_SMP kernel TB --- 2013-03-19 07:02:57 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 07:02:57 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 07:02:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 07:02:57 - SRCCONF=/dev/null TB --- 2013-03-19 07:02:57 - TARGET=mips TB --- 2013-03-19 07:02:57 - TARGET_ARCH=mips TB --- 2013-03-19 07:02:57 - TZ=UTC TB --- 2013-03-19 07:02:57 - __MAKE_CONF=/dev/null TB --- 2013-03-19 07:02:57 - cd /src TB --- 2013-03-19 07:02:57 - /usr/bin/make -B buildkernel KERNCONF=SWARM_SMP >>> Kernel build for SWARM_SMP started on Tue Mar 19 07:02:57 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for SWARM_SMP completed on Tue Mar 19 07:05:50 UTC 2013 TB --- 2013-03-19 07:05:50 - cd /src/sys/mips/conf TB --- 2013-03-19 07:05:50 - /usr/sbin/config -m TP-WN1043ND TB --- 2013-03-19 07:05:50 - building TP-WN1043ND kernel TB --- 2013-03-19 07:05:50 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 07:05:50 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 07:05:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 07:05:50 - SRCCONF=/dev/null TB --- 2013-03-19 07:05:50 - TARGET=mips TB --- 2013-03-19 07:05:50 - TARGET_ARCH=mips TB --- 2013-03-19 07:05:50 - TZ=UTC TB --- 2013-03-19 07:05:50 - __MAKE_CONF=/dev/null TB --- 2013-03-19 07:05:50 - cd /src TB --- 2013-03-19 07:05:50 - /usr/bin/make -B buildkernel KERNCONF=TP-WN1043ND >>> Kernel build for TP-WN1043ND started on Tue Mar 19 07:05:50 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for TP-WN1043ND completed on Tue Mar 19 07:10:32 UTC 2013 TB --- 2013-03-19 07:10:32 - cd /src/sys/mips/conf TB --- 2013-03-19 07:10:32 - /usr/sbin/config -m XLP TB --- 2013-03-19 07:10:32 - building XLP kernel TB --- 2013-03-19 07:10:32 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 07:10:32 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 07:10:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 07:10:32 - SRCCONF=/dev/null TB --- 2013-03-19 07:10:32 - TARGET=mips TB --- 2013-03-19 07:10:32 - TARGET_ARCH=mips TB --- 2013-03-19 07:10:32 - TZ=UTC TB --- 2013-03-19 07:10:32 - __MAKE_CONF=/dev/null TB --- 2013-03-19 07:10:32 - cd /src TB --- 2013-03-19 07:10:32 - /usr/bin/make -B buildkernel KERNCONF=XLP >>> Kernel build for XLP started on Tue Mar 19 07:10:33 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80100000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/dev/e1000/e1000_phy.c -I/src/sys/dev/e1000 cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80100000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/dev/e1000/e1000_vf.c -I/src/sys/dev/e1000 cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80100000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/dev/e1000/e1000_mbx.c -I/src/sys/dev/e1000 cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80100000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/dev/e1000/e1000_osdep.c -I/src/sys/dev/e1000 cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80100000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/dev/fdt/fdt_common.c cc1: warnings being treated as errors /src/sys/dev/fdt/fdt_common.c: In function 'fdt_reg_to_rl': /src/sys/dev/fdt/fdt_common.c:451: warning: passing argument 4 of 'fdt_data_to_res' from incompatible pointer type *** [fdt_common.o] Error code 1 Stop in /obj/mips.mips/src/sys/XLP. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-19 07:11:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-19 07:11:16 - ERROR: failed to build XLP kernel TB --- 2013-03-19 07:11:16 - 6435.88 user 1184.38 system 8495.88 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Tue Mar 19 08:37:22 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6EFFCD8; Tue, 19 Mar 2013 08:37:22 +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 32921E28; Tue, 19 Mar 2013 08:37:21 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2J8bLq5065987; Tue, 19 Mar 2013 04:37:21 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2J8bLx5065986; Tue, 19 Mar 2013 08:37:21 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 19 Mar 2013 08:37:21 GMT Message-Id: <201303190837.r2J8bLx5065986@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 08:37:22 -0000 TB --- 2013-03-19 05:36:04 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-19 05:36:04 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-19 05:36:04 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-03-19 05:36:04 - cleaning the object tree TB --- 2013-03-19 05:36:04 - /usr/local/bin/svn stat /src TB --- 2013-03-19 05:36:07 - At svn revision 248477 TB --- 2013-03-19 05:36:08 - building world TB --- 2013-03-19 05:36:08 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 05:36:08 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 05:36:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 05:36:08 - SRCCONF=/dev/null TB --- 2013-03-19 05:36:08 - TARGET=powerpc TB --- 2013-03-19 05:36:08 - TARGET_ARCH=powerpc TB --- 2013-03-19 05:36:08 - TZ=UTC TB --- 2013-03-19 05:36:08 - __MAKE_CONF=/dev/null TB --- 2013-03-19 05:36:08 - cd /src TB --- 2013-03-19 05:36:08 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Mar 19 05:36:13 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Mar 19 08:02:04 UTC 2013 TB --- 2013-03-19 08:02:04 - generating LINT kernel config TB --- 2013-03-19 08:02:04 - cd /src/sys/powerpc/conf TB --- 2013-03-19 08:02:04 - /usr/bin/make -B LINT TB --- 2013-03-19 08:02:04 - cd /src/sys/powerpc/conf TB --- 2013-03-19 08:02:04 - /usr/sbin/config -m LINT TB --- 2013-03-19 08:02:04 - building LINT kernel TB --- 2013-03-19 08:02:04 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 08:02:04 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 08:02:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 08:02:04 - SRCCONF=/dev/null TB --- 2013-03-19 08:02:04 - TARGET=powerpc TB --- 2013-03-19 08:02:04 - TARGET_ARCH=powerpc TB --- 2013-03-19 08:02:04 - TZ=UTC TB --- 2013-03-19 08:02:04 - __MAKE_CONF=/dev/null TB --- 2013-03-19 08:02:04 - cd /src TB --- 2013-03-19 08:02:04 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Mar 19 08:02:04 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Tue Mar 19 08:20:50 UTC 2013 TB --- 2013-03-19 08:20:50 - cd /src/sys/powerpc/conf TB --- 2013-03-19 08:20:50 - /usr/sbin/config -m GENERIC TB --- 2013-03-19 08:20:50 - building GENERIC kernel TB --- 2013-03-19 08:20:50 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 08:20:50 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 08:20:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 08:20:50 - SRCCONF=/dev/null TB --- 2013-03-19 08:20:50 - TARGET=powerpc TB --- 2013-03-19 08:20:50 - TARGET_ARCH=powerpc TB --- 2013-03-19 08:20:50 - TZ=UTC TB --- 2013-03-19 08:20:50 - __MAKE_CONF=/dev/null TB --- 2013-03-19 08:20:50 - cd /src TB --- 2013-03-19 08:20:50 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Mar 19 08:20:50 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Tue Mar 19 08:36:40 UTC 2013 TB --- 2013-03-19 08:36:40 - cd /src/sys/powerpc/conf TB --- 2013-03-19 08:36:40 - /usr/sbin/config -m GENERIC64 TB --- 2013-03-19 08:36:40 - skipping GENERIC64 kernel TB --- 2013-03-19 08:36:40 - cd /src/sys/powerpc/conf TB --- 2013-03-19 08:36:40 - /usr/sbin/config -m MPC85XX TB --- 2013-03-19 08:36:40 - building MPC85XX kernel TB --- 2013-03-19 08:36:40 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 08:36:40 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 08:36:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 08:36:40 - SRCCONF=/dev/null TB --- 2013-03-19 08:36:40 - TARGET=powerpc TB --- 2013-03-19 08:36:40 - TARGET_ARCH=powerpc TB --- 2013-03-19 08:36:40 - TZ=UTC TB --- 2013-03-19 08:36:40 - __MAKE_CONF=/dev/null TB --- 2013-03-19 08:36:40 - cd /src TB --- 2013-03-19 08:36:40 - /usr/bin/make -B buildkernel KERNCONF=MPC85XX >>> Kernel build for MPC85XX started on Tue Mar 19 08:36:40 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wa,-me500 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/e1000/e1000_phy.c -I/src/sys/dev/e1000 cc -c -O -pipe -std=c99 -Wa,-me500 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/e1000/e1000_vf.c -I/src/sys/dev/e1000 cc -c -O -pipe -std=c99 -Wa,-me500 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/e1000/e1000_mbx.c -I/src/sys/dev/e1000 cc -c -O -pipe -std=c99 -Wa,-me500 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/e1000/e1000_osdep.c -I/src/sys/dev/e1000 cc -c -O -pipe -std=c99 -Wa,-me500 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/fdt/fdt_common.c cc1: warnings being treated as errors /src/sys/dev/fdt/fdt_common.c: In function 'fdt_reg_to_rl': /src/sys/dev/fdt/fdt_common.c:451: warning: passing argument 4 of 'fdt_data_to_res' from incompatible pointer type *** [fdt_common.o] Error code 1 Stop in /obj/powerpc.powerpc/src/sys/MPC85XX. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-19 08:37:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-19 08:37:21 - ERROR: failed to build MPC85XX kernel TB --- 2013-03-19 08:37:21 - 9357.45 user 1155.62 system 10876.59 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Mar 19 08:51:17 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B59685B1; Tue, 19 Mar 2013 08:51:17 +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 86549EA8; Tue, 19 Mar 2013 08:51:17 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2J8pHYU096692; Tue, 19 Mar 2013 04:51:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2J8pGHr096691; Tue, 19 Mar 2013 08:51:16 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 19 Mar 2013 08:51:16 GMT Message-Id: <201303190851.r2J8pGHr096691@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 08:51:17 -0000 TB --- 2013-03-19 05:44:29 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-19 05:44:29 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-19 05:44:29 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-03-19 05:44:29 - cleaning the object tree TB --- 2013-03-19 05:46:52 - /usr/local/bin/svn stat /src TB --- 2013-03-19 05:46:56 - At svn revision 248477 TB --- 2013-03-19 05:46:57 - building world TB --- 2013-03-19 05:46:57 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 05:46:57 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 05:46:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 05:46:57 - SRCCONF=/dev/null TB --- 2013-03-19 05:46:57 - TARGET=powerpc TB --- 2013-03-19 05:46:57 - TARGET_ARCH=powerpc64 TB --- 2013-03-19 05:46:57 - TZ=UTC TB --- 2013-03-19 05:46:57 - __MAKE_CONF=/dev/null TB --- 2013-03-19 05:46:57 - cd /src TB --- 2013-03-19 05:46:57 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Mar 19 05:47:01 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Tue Mar 19 08:42:35 UTC 2013 TB --- 2013-03-19 08:42:35 - generating LINT kernel config TB --- 2013-03-19 08:42:35 - cd /src/sys/powerpc/conf TB --- 2013-03-19 08:42:35 - /usr/bin/make -B LINT TB --- 2013-03-19 08:42:35 - cd /src/sys/powerpc/conf TB --- 2013-03-19 08:42:35 - /usr/sbin/config -m LINT TB --- 2013-03-19 08:42:35 - skipping LINT kernel TB --- 2013-03-19 08:42:35 - cd /src/sys/powerpc/conf TB --- 2013-03-19 08:42:35 - /usr/sbin/config -m GENERIC TB --- 2013-03-19 08:42:35 - skipping GENERIC kernel TB --- 2013-03-19 08:42:35 - cd /src/sys/powerpc/conf TB --- 2013-03-19 08:42:35 - /usr/sbin/config -m GENERIC64 TB --- 2013-03-19 08:42:35 - building GENERIC64 kernel TB --- 2013-03-19 08:42:35 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 08:42:35 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 08:42:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 08:42:35 - SRCCONF=/dev/null TB --- 2013-03-19 08:42:35 - TARGET=powerpc TB --- 2013-03-19 08:42:35 - TARGET_ARCH=powerpc64 TB --- 2013-03-19 08:42:35 - TZ=UTC TB --- 2013-03-19 08:42:35 - __MAKE_CONF=/dev/null TB --- 2013-03-19 08:42:35 - cd /src TB --- 2013-03-19 08:42:35 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64 >>> Kernel build for GENERIC64 started on Tue Mar 19 08:42:35 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/modules/dtrace/fbt/../../../cddl/dev/fbt/fbt.c:291: error: 'DTRACE_INVOP_PUSHL_EBP' undeclared (first use in this function) /src/sys/modules/dtrace/fbt/../../../cddl/dev/fbt/fbt.c:291: error: (Each undeclared identifier is reported only once /src/sys/modules/dtrace/fbt/../../../cddl/dev/fbt/fbt.c:291: error: for each function it appears in.) cc1: warnings being treated as errors /src/sys/modules/dtrace/fbt/../../../cddl/dev/fbt/fbt.c:311: warning: implicit declaration of function 'dtrace_instr_size' /src/sys/modules/dtrace/fbt/../../../cddl/dev/fbt/fbt.c:311: warning: nested extern declaration of 'dtrace_instr_size' [-Wnested-externs] /src/sys/modules/dtrace/fbt/../../../cddl/dev/fbt/fbt.c:385: error: 'DTRACE_INVOP_POPL_EBP' undeclared (first use in this function) /src/sys/modules/dtrace/fbt/../../../cddl/dev/fbt/fbt.c:388: error: 'DTRACE_INVOP_LEAVE' undeclared (first use in this function) *** [fbt.o] Error code 1 Stop in /src/sys/modules/dtrace/fbt. *** [all] Error code 1 Stop in /src/sys/modules/dtrace. *** [all] Error code 1 Stop in /src/sys/modules. *** [modules-all] Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/GENERIC64. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-19 08:51:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-19 08:51:16 - ERROR: failed to build GENERIC64 kernel TB --- 2013-03-19 08:51:16 - 9516.88 user 1261.05 system 11207.23 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Mar 19 09:55:49 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 41941657; Tue, 19 Mar 2013 09:55:49 +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 6097165B; Tue, 19 Mar 2013 09:55:47 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA09365; Tue, 19 Mar 2013 11:55:46 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UHtGk-000IJe-H6; Tue, 19 Mar 2013 11:55:46 +0200 Message-ID: <51483621.2060503@FreeBSD.org> Date: Tue, 19 Mar 2013 11:55:45 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Subject: Re: gptzfsboot problem on HP P410i Smart Array References: <50311741.3000204@yandex.ru> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Bjorn Larsson , Sergey Dyatko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 09:55:49 -0000 on 19/03/2013 07:41 Sergey Dyatko said the following: > I was faced with same problem on my laptop. Adding printf() into main() > before dsk = malloc(sizeof(struct dsk)); fix boot. Yesterday, avg@ proposed > patch: > Index: /usr/src/sys/boot/i386/zfsboot/zfsboot.c > =================================================================== > --- /usr/src/sys/boot/i386/zfsboot/zfsboot.c (revision 248421) > +++ /usr/src/sys/boot/i386/zfsboot/zfsboot.c (working copy) > @@ -302,6 +302,7 @@ > * region in the SMAP, use the last 3MB of 'extended' memory as a > * high heap candidate. > */ > + high_heap_size = 0; > if (bios_extmem >= HEAP_MIN && high_heap_size < HEAP_MIN) { > high_heap_size = HEAP_MIN; > high_heap_base = bios_extmem + 0x100000 - HEAP_MIN; > > it works for me, without printf() :) Can you test it ? A comment about a nature of this patch. Based on the previous investigation by Christoph Hoffmann and jhb: http://thread.gmane.org/gmane.os.freebsd.current/134199/focus=134309 I made a guess that either BIOS/firmware provides incorrect memory map or some agent in the BIOS/firmware (e.g. SMM handler) or controller firmware writes outside of a memory range reserved for it. I think that jhb made a similar guess at the time while Christoph conjectured that memory corruption was related to CPU caches or some such. My conjecture is that it is simply a combination of timing and a particular memory range. Just in case, here is how the memory map looks on the Sergey's system: SMAP type=01 base=0000000000000000 end=000000000009fc00 len=000000000009fc00 SMAP type=02 base=000000000009fc00 end=00000000000a0000 len=0000000000000400 SMAP type=02 base=00000000000e0000 end=0000000000100000 len=0000000000020000 SMAP type=01 base=0000000000100000 end=00000000bc1a1000 len=00000000bc0a1000 SMAP type=04 base=00000000bc1a1000 end=00000000bc1a4000 len=0000000000003000 SMAP type=01 base=00000000bc1a4000 end=00000000bdf04000 len=0000000001d60000 SMAP type=04 base=00000000bdf04000 end=00000000bdf3f000 len=000000000003b000 SMAP type=01 base=00000000bdf3f000 end=00000000bdf6a000 len=000000000002b000 SMAP type=02 base=00000000bdf6a000 end=00000000bdfbf000 len=0000000000055000 SMAP type=01 base=00000000bdfbf000 end=00000000bdfeb000 len=000000000002c000 SMAP type=03 base=00000000bdfeb000 end=00000000bdfff000 len=0000000000014000 SMAP type=01 base=00000000bdfff000 end=00000000be000000 len=0000000000001000 SMAP type=02 base=00000000be000000 end=00000000c0000000 len=0000000002000000 SMAP type=02 base=00000000f8000000 end=00000000fc000000 len=0000000004000000 SMAP type=02 base=00000000fec00000 end=00000000fec01000 len=0000000000001000 SMAP type=02 base=00000000fed10000 end=00000000fed14000 len=0000000000004000 SMAP type=02 base=00000000fed18000 end=00000000fed1a000 len=0000000000002000 SMAP type=02 base=00000000fed1c000 end=00000000fed20000 len=0000000000004000 SMAP type=02 base=00000000fee00000 end=00000000fee01000 len=0000000000001000 SMAP type=02 base=00000000ffe00000 end=0000000100000000 len=0000000000200000 SMAP type=01 base=0000000100000000 end=0000000140000000 len=0000000040000000 The algorithm for placing the heap picks up a range at bc1a4000, which is between two ranges of type '4' (ACPI NVS memory). So my idea was just to try a different memory range. Seems that it worked. P.S. I am not sure why our algorithm for selecting heap location is what it is. On all systems that I have I see that the "bios_extmem" range (the one starting at 0x100000) is usually the largest one and has more than enough space for both the heap and other things that are placed there. Additionally, in the case of zfsboot I think that we do not use memory above 1MB for anything else besides the heap. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Mar 19 14:44:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4803464A; Tue, 19 Mar 2013 14:44:35 +0000 (UTC) (envelope-from zhao6014@gmail.com) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 83BFCB3B; Tue, 19 Mar 2013 14:44:34 +0000 (UTC) Received: by mail-wg0-f54.google.com with SMTP id fm10so424461wgb.21 for ; Tue, 19 Mar 2013 07:44:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=uXF+1+13j/YtdnDXUrPXaNqShIvplRclOz59YssIF54=; b=AtnfsG5i1rW1CT5qwyLX9o3vcxrd55l5Vlpc2RWhwQoBSkeSe7Bpzye3pKPgg9dN20 cky2rr1XTzQ36fF9CUU87+CWgruB9Jl8PsiFupcV992SloFSs/htTGu74PGOsKsv1iI5 36O1rS5Goe4nWCaCvpwgKdyzLpOaG5yTjS6u7iBTE1xYTBsvz9GlsMG/YGp72H1JnI7c HVrb9uEm6/7ipMpCtURiboy5c1GNHTReIBUOyJv1mv55skLtaKEXHKZ9Buxl/3oWKNyC QR9azYsho1ixQn5njf73r9lDPRKSYAzzBj3TZ0okcZe+Ik+aO2RH8WoTIjbD3XVk6AUo crsA== X-Received: by 10.180.74.131 with SMTP id t3mr3670598wiv.26.1363704267319; Tue, 19 Mar 2013 07:44:27 -0700 (PDT) MIME-Version: 1.0 Sender: zhao6014@gmail.com Received: by 10.194.153.98 with HTTP; Tue, 19 Mar 2013 07:44:07 -0700 (PDT) In-Reply-To: <51474796.1030808@a1poweruser.com> References: <51474796.1030808@a1poweruser.com> From: Jov Date: Tue, 19 Mar 2013 22:44:07 +0800 X-Google-Sender-Auth: rKNwB-9oUbKMy70PmGgcOucpza0 Message-ID: Subject: Re: Handbook Jail Chapter rewrite available for critique To: Fbsd8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-doc@freebsd.org, FreeBSD questions , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 14:44:35 -0000 useful doc=EF=BC=8Cgreate job=EF=BC=81 find a mybe copy/past mistake in 16.7.1=EF=BC=9A > *exec.stop* This is the normal script used to *start *the jail. should be=EF=BC=9A *exec.stop* This is the normal script used to *stop *the jail. regards, 2013/3/19 Fbsd8 > To all interested parties; > > I have completed the final draft of the total rewrite of FreeBSD's > handbook Chapter 16 on Jails. > > Before submitting my work for submission to the documentation group for > insertion in the handbook I am looking for critique of the work to find > errors in concept, wrong use of words, or anything to make it better. > > All feedback welcomed. > > Use this URL to access it http://www.jails.a1poweruser.**com/ > > > Thank You. > > ______________________________**_________________ > 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 " > --=20 Jov blog: http:amutu.com/blog From owner-freebsd-current@FreeBSD.ORG Tue Mar 19 17:19:28 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3F87261A; Tue, 19 Mar 2013 17:19: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 F261878D; Tue, 19 Mar 2013 17:19:27 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2JHJL7S000216; Tue, 19 Mar 2013 13:19:21 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2JHJLKK000215; Tue, 19 Mar 2013 17:19:21 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 19 Mar 2013 17:19:21 GMT Message-Id: <201303191719.r2JHJLKK000215@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 17:19:28 -0000 TB --- 2013-03-19 14:58:05 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-19 14:58:05 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-19 14:58:05 - starting HEAD tinderbox run for mips/mips TB --- 2013-03-19 14:58:05 - cleaning the object tree TB --- 2013-03-19 15:01:02 - /usr/local/bin/svn stat /src TB --- 2013-03-19 15:01:22 - At svn revision 248493 TB --- 2013-03-19 15:01:23 - building world TB --- 2013-03-19 15:01:23 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 15:01:23 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 15:01:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 15:01:23 - SRCCONF=/dev/null TB --- 2013-03-19 15:01:23 - TARGET=mips TB --- 2013-03-19 15:01:23 - TARGET_ARCH=mips TB --- 2013-03-19 15:01:23 - TZ=UTC TB --- 2013-03-19 15:01:23 - __MAKE_CONF=/dev/null TB --- 2013-03-19 15:01:23 - cd /src TB --- 2013-03-19 15:01:23 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Mar 19 15:01:29 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Mar 19 16:03:13 UTC 2013 TB --- 2013-03-19 16:03:13 - cd /src/sys/mips/conf TB --- 2013-03-19 16:03:13 - /usr/sbin/config -m ADM5120 TB --- 2013-03-19 16:03:13 - skipping ADM5120 kernel TB --- 2013-03-19 16:03:13 - cd /src/sys/mips/conf TB --- 2013-03-19 16:03:13 - /usr/sbin/config -m ALCHEMY TB --- 2013-03-19 16:03:13 - skipping ALCHEMY kernel TB --- 2013-03-19 16:03:13 - cd /src/sys/mips/conf TB --- 2013-03-19 16:03:13 - /usr/sbin/config -m AP91 TB --- 2013-03-19 16:03:13 - building AP91 kernel TB --- 2013-03-19 16:03:13 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 16:03:13 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 16:03:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 16:03:13 - SRCCONF=/dev/null TB --- 2013-03-19 16:03:13 - TARGET=mips TB --- 2013-03-19 16:03:13 - TARGET_ARCH=mips TB --- 2013-03-19 16:03:13 - TZ=UTC TB --- 2013-03-19 16:03:13 - __MAKE_CONF=/dev/null TB --- 2013-03-19 16:03:13 - cd /src TB --- 2013-03-19 16:03:13 - /usr/bin/make -B buildkernel KERNCONF=AP91 >>> Kernel build for AP91 started on Tue Mar 19 16:03:13 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for AP91 completed on Tue Mar 19 16:07:16 UTC 2013 TB --- 2013-03-19 16:07:16 - cd /src/sys/mips/conf TB --- 2013-03-19 16:07:16 - /usr/sbin/config -m AP93 TB --- 2013-03-19 16:07:16 - building AP93 kernel TB --- 2013-03-19 16:07:16 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 16:07:16 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 16:07:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 16:07:16 - SRCCONF=/dev/null TB --- 2013-03-19 16:07:16 - TARGET=mips TB --- 2013-03-19 16:07:16 - TARGET_ARCH=mips TB --- 2013-03-19 16:07:16 - TZ=UTC TB --- 2013-03-19 16:07:16 - __MAKE_CONF=/dev/null TB --- 2013-03-19 16:07:16 - cd /src TB --- 2013-03-19 16:07:16 - /usr/bin/make -B buildkernel KERNCONF=AP93 >>> Kernel build for AP93 started on Tue Mar 19 16:07:16 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for AP93 completed on Tue Mar 19 16:11:09 UTC 2013 TB --- 2013-03-19 16:11:09 - cd /src/sys/mips/conf TB --- 2013-03-19 16:11:09 - /usr/sbin/config -m AP94 TB --- 2013-03-19 16:11:09 - building AP94 kernel TB --- 2013-03-19 16:11:09 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 16:11:09 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 16:11:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 16:11:09 - SRCCONF=/dev/null TB --- 2013-03-19 16:11:09 - TARGET=mips TB --- 2013-03-19 16:11:09 - TARGET_ARCH=mips TB --- 2013-03-19 16:11:09 - TZ=UTC TB --- 2013-03-19 16:11:09 - __MAKE_CONF=/dev/null TB --- 2013-03-19 16:11:09 - cd /src TB --- 2013-03-19 16:11:09 - /usr/bin/make -B buildkernel KERNCONF=AP94 >>> Kernel build for AP94 started on Tue Mar 19 16:11:09 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for AP94 completed on Tue Mar 19 16:15:44 UTC 2013 TB --- 2013-03-19 16:15:44 - cd /src/sys/mips/conf TB --- 2013-03-19 16:15:44 - /usr/sbin/config -m AP96 TB --- 2013-03-19 16:15:44 - building AP96 kernel TB --- 2013-03-19 16:15:44 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 16:15:44 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 16:15:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 16:15:44 - SRCCONF=/dev/null TB --- 2013-03-19 16:15:44 - TARGET=mips TB --- 2013-03-19 16:15:44 - TARGET_ARCH=mips TB --- 2013-03-19 16:15:44 - TZ=UTC TB --- 2013-03-19 16:15:44 - __MAKE_CONF=/dev/null TB --- 2013-03-19 16:15:44 - cd /src TB --- 2013-03-19 16:15:44 - /usr/bin/make -B buildkernel KERNCONF=AP96 >>> Kernel build for AP96 started on Tue Mar 19 16:15:44 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for AP96 completed on Tue Mar 19 16:20:50 UTC 2013 TB --- 2013-03-19 16:20:50 - cd /src/sys/mips/conf TB --- 2013-03-19 16:20:50 - /usr/sbin/config -m AR71XX_BASE TB --- 2013-03-19 16:20:50 - building AR71XX_BASE kernel TB --- 2013-03-19 16:20:50 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 16:20:50 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 16:20:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 16:20:50 - SRCCONF=/dev/null TB --- 2013-03-19 16:20:50 - TARGET=mips TB --- 2013-03-19 16:20:50 - TARGET_ARCH=mips TB --- 2013-03-19 16:20:50 - TZ=UTC TB --- 2013-03-19 16:20:50 - __MAKE_CONF=/dev/null TB --- 2013-03-19 16:20:50 - cd /src TB --- 2013-03-19 16:20:50 - /usr/bin/make -B buildkernel KERNCONF=AR71XX_BASE >>> Kernel build for AR71XX_BASE started on Tue Mar 19 16:20:50 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for AR71XX_BASE completed on Tue Mar 19 16:25:20 UTC 2013 TB --- 2013-03-19 16:25:20 - cd /src/sys/mips/conf TB --- 2013-03-19 16:25:20 - /usr/sbin/config -m AR724X_BASE TB --- 2013-03-19 16:25:20 - building AR724X_BASE kernel TB --- 2013-03-19 16:25:20 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 16:25:20 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 16:25:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 16:25:20 - SRCCONF=/dev/null TB --- 2013-03-19 16:25:20 - TARGET=mips TB --- 2013-03-19 16:25:20 - TARGET_ARCH=mips TB --- 2013-03-19 16:25:20 - TZ=UTC TB --- 2013-03-19 16:25:20 - __MAKE_CONF=/dev/null TB --- 2013-03-19 16:25:20 - cd /src TB --- 2013-03-19 16:25:20 - /usr/bin/make -B buildkernel KERNCONF=AR724X_BASE >>> Kernel build for AR724X_BASE started on Tue Mar 19 16:25:20 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for AR724X_BASE completed on Tue Mar 19 16:29:12 UTC 2013 TB --- 2013-03-19 16:29:12 - cd /src/sys/mips/conf TB --- 2013-03-19 16:29:12 - /usr/sbin/config -m AR91XX_BASE TB --- 2013-03-19 16:29:12 - building AR91XX_BASE kernel TB --- 2013-03-19 16:29:12 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 16:29:12 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 16:29:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 16:29:12 - SRCCONF=/dev/null TB --- 2013-03-19 16:29:12 - TARGET=mips TB --- 2013-03-19 16:29:12 - TARGET_ARCH=mips TB --- 2013-03-19 16:29:12 - TZ=UTC TB --- 2013-03-19 16:29:12 - __MAKE_CONF=/dev/null TB --- 2013-03-19 16:29:12 - cd /src TB --- 2013-03-19 16:29:12 - /usr/bin/make -B buildkernel KERNCONF=AR91XX_BASE >>> Kernel build for AR91XX_BASE started on Tue Mar 19 16:29:12 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for AR91XX_BASE completed on Tue Mar 19 16:33:30 UTC 2013 TB --- 2013-03-19 16:33:30 - cd /src/sys/mips/conf TB --- 2013-03-19 16:33:30 - /usr/sbin/config -m BERI_DE4_MDROOT TB --- 2013-03-19 16:33:30 - skipping BERI_DE4_MDROOT kernel TB --- 2013-03-19 16:33:30 - cd /src/sys/mips/conf TB --- 2013-03-19 16:33:30 - /usr/sbin/config -m BERI_DE4_SDROOT TB --- 2013-03-19 16:33:30 - skipping BERI_DE4_SDROOT kernel TB --- 2013-03-19 16:33:30 - cd /src/sys/mips/conf TB --- 2013-03-19 16:33:30 - /usr/sbin/config -m BERI_SIM_MDROOT TB --- 2013-03-19 16:33:30 - skipping BERI_SIM_MDROOT kernel TB --- 2013-03-19 16:33:30 - cd /src/sys/mips/conf TB --- 2013-03-19 16:33:30 - /usr/sbin/config -m BERI_TEMPLATE TB --- 2013-03-19 16:33:30 - skipping BERI_TEMPLATE kernel TB --- 2013-03-19 16:33:30 - cd /src/sys/mips/conf TB --- 2013-03-19 16:33:30 - /usr/sbin/config -m DIR-825 TB --- 2013-03-19 16:33:30 - building DIR-825 kernel TB --- 2013-03-19 16:33:30 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 16:33:30 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 16:33:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 16:33:30 - SRCCONF=/dev/null TB --- 2013-03-19 16:33:30 - TARGET=mips TB --- 2013-03-19 16:33:30 - TARGET_ARCH=mips TB --- 2013-03-19 16:33:30 - TZ=UTC TB --- 2013-03-19 16:33:30 - __MAKE_CONF=/dev/null TB --- 2013-03-19 16:33:30 - cd /src TB --- 2013-03-19 16:33:30 - /usr/bin/make -B buildkernel KERNCONF=DIR-825 >>> Kernel build for DIR-825 started on Tue Mar 19 16:33:30 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DIR-825 completed on Tue Mar 19 16:37:06 UTC 2013 TB --- 2013-03-19 16:37:06 - cd /src/sys/mips/conf TB --- 2013-03-19 16:37:06 - /usr/sbin/config -m GXEMUL TB --- 2013-03-19 16:37:06 - skipping GXEMUL kernel TB --- 2013-03-19 16:37:06 - cd /src/sys/mips/conf TB --- 2013-03-19 16:37:06 - /usr/sbin/config -m IDT TB --- 2013-03-19 16:37:06 - skipping IDT kernel TB --- 2013-03-19 16:37:06 - cd /src/sys/mips/conf TB --- 2013-03-19 16:37:06 - /usr/sbin/config -m MALTA TB --- 2013-03-19 16:37:06 - skipping MALTA kernel TB --- 2013-03-19 16:37:06 - cd /src/sys/mips/conf TB --- 2013-03-19 16:37:06 - /usr/sbin/config -m MALTA64 TB --- 2013-03-19 16:37:06 - skipping MALTA64 kernel TB --- 2013-03-19 16:37:06 - cd /src/sys/mips/conf TB --- 2013-03-19 16:37:06 - /usr/sbin/config -m OCTEON1 TB --- 2013-03-19 16:37:06 - skipping OCTEON1 kernel TB --- 2013-03-19 16:37:06 - cd /src/sys/mips/conf TB --- 2013-03-19 16:37:06 - /usr/sbin/config -m PB47 TB --- 2013-03-19 16:37:06 - building PB47 kernel TB --- 2013-03-19 16:37:06 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 16:37:06 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 16:37:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 16:37:06 - SRCCONF=/dev/null TB --- 2013-03-19 16:37:06 - TARGET=mips TB --- 2013-03-19 16:37:06 - TARGET_ARCH=mips TB --- 2013-03-19 16:37:06 - TZ=UTC TB --- 2013-03-19 16:37:06 - __MAKE_CONF=/dev/null TB --- 2013-03-19 16:37:06 - cd /src TB --- 2013-03-19 16:37:06 - /usr/bin/make -B buildkernel KERNCONF=PB47 >>> Kernel build for PB47 started on Tue Mar 19 16:37:06 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PB47 completed on Tue Mar 19 16:42:08 UTC 2013 TB --- 2013-03-19 16:42:08 - cd /src/sys/mips/conf TB --- 2013-03-19 16:42:08 - /usr/sbin/config -m PB92 TB --- 2013-03-19 16:42:08 - building PB92 kernel TB --- 2013-03-19 16:42:08 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 16:42:08 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 16:42:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 16:42:08 - SRCCONF=/dev/null TB --- 2013-03-19 16:42:08 - TARGET=mips TB --- 2013-03-19 16:42:08 - TARGET_ARCH=mips TB --- 2013-03-19 16:42:08 - TZ=UTC TB --- 2013-03-19 16:42:08 - __MAKE_CONF=/dev/null TB --- 2013-03-19 16:42:08 - cd /src TB --- 2013-03-19 16:42:08 - /usr/bin/make -B buildkernel KERNCONF=PB92 >>> Kernel build for PB92 started on Tue Mar 19 16:42:08 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PB92 completed on Tue Mar 19 16:45:35 UTC 2013 TB --- 2013-03-19 16:45:35 - cd /src/sys/mips/conf TB --- 2013-03-19 16:45:35 - /usr/sbin/config -m QEMU TB --- 2013-03-19 16:45:35 - skipping QEMU kernel TB --- 2013-03-19 16:45:35 - cd /src/sys/mips/conf TB --- 2013-03-19 16:45:35 - /usr/sbin/config -m ROUTERSTATION TB --- 2013-03-19 16:45:35 - building ROUTERSTATION kernel TB --- 2013-03-19 16:45:35 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 16:45:35 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 16:45:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 16:45:35 - SRCCONF=/dev/null TB --- 2013-03-19 16:45:35 - TARGET=mips TB --- 2013-03-19 16:45:35 - TARGET_ARCH=mips TB --- 2013-03-19 16:45:35 - TZ=UTC TB --- 2013-03-19 16:45:35 - __MAKE_CONF=/dev/null TB --- 2013-03-19 16:45:35 - cd /src TB --- 2013-03-19 16:45:35 - /usr/bin/make -B buildkernel KERNCONF=ROUTERSTATION >>> Kernel build for ROUTERSTATION started on Tue Mar 19 16:45:35 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ROUTERSTATION completed on Tue Mar 19 16:50:03 UTC 2013 TB --- 2013-03-19 16:50:03 - cd /src/sys/mips/conf TB --- 2013-03-19 16:50:03 - /usr/sbin/config -m ROUTERSTATION_MFS TB --- 2013-03-19 16:50:03 - building ROUTERSTATION_MFS kernel TB --- 2013-03-19 16:50:03 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 16:50:03 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 16:50:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 16:50:03 - SRCCONF=/dev/null TB --- 2013-03-19 16:50:03 - TARGET=mips TB --- 2013-03-19 16:50:03 - TARGET_ARCH=mips TB --- 2013-03-19 16:50:03 - TZ=UTC TB --- 2013-03-19 16:50:03 - __MAKE_CONF=/dev/null TB --- 2013-03-19 16:50:03 - cd /src TB --- 2013-03-19 16:50:03 - /usr/bin/make -B buildkernel KERNCONF=ROUTERSTATION_MFS >>> Kernel build for ROUTERSTATION_MFS started on Tue Mar 19 16:50:03 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ROUTERSTATION_MFS completed on Tue Mar 19 16:54:29 UTC 2013 TB --- 2013-03-19 16:54:29 - cd /src/sys/mips/conf TB --- 2013-03-19 16:54:29 - /usr/sbin/config -m RSPRO TB --- 2013-03-19 16:54:29 - building RSPRO kernel TB --- 2013-03-19 16:54:29 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 16:54:29 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 16:54:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 16:54:29 - SRCCONF=/dev/null TB --- 2013-03-19 16:54:29 - TARGET=mips TB --- 2013-03-19 16:54:29 - TARGET_ARCH=mips TB --- 2013-03-19 16:54:29 - TZ=UTC TB --- 2013-03-19 16:54:29 - __MAKE_CONF=/dev/null TB --- 2013-03-19 16:54:29 - cd /src TB --- 2013-03-19 16:54:29 - /usr/bin/make -B buildkernel KERNCONF=RSPRO >>> Kernel build for RSPRO started on Tue Mar 19 16:54:29 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for RSPRO completed on Tue Mar 19 16:58:59 UTC 2013 TB --- 2013-03-19 16:58:59 - cd /src/sys/mips/conf TB --- 2013-03-19 16:58:59 - /usr/sbin/config -m RSPRO_MFS TB --- 2013-03-19 16:58:59 - building RSPRO_MFS kernel TB --- 2013-03-19 16:58:59 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 16:58:59 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 16:58:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 16:58:59 - SRCCONF=/dev/null TB --- 2013-03-19 16:58:59 - TARGET=mips TB --- 2013-03-19 16:58:59 - TARGET_ARCH=mips TB --- 2013-03-19 16:58:59 - TZ=UTC TB --- 2013-03-19 16:58:59 - __MAKE_CONF=/dev/null TB --- 2013-03-19 16:58:59 - cd /src TB --- 2013-03-19 16:58:59 - /usr/bin/make -B buildkernel KERNCONF=RSPRO_MFS >>> Kernel build for RSPRO_MFS started on Tue Mar 19 16:58:59 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for RSPRO_MFS completed on Tue Mar 19 17:03:53 UTC 2013 TB --- 2013-03-19 17:03:53 - cd /src/sys/mips/conf TB --- 2013-03-19 17:03:53 - /usr/sbin/config -m RSPRO_STANDALONE TB --- 2013-03-19 17:03:53 - building RSPRO_STANDALONE kernel TB --- 2013-03-19 17:03:53 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 17:03:53 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 17:03:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 17:03:53 - SRCCONF=/dev/null TB --- 2013-03-19 17:03:53 - TARGET=mips TB --- 2013-03-19 17:03:53 - TARGET_ARCH=mips TB --- 2013-03-19 17:03:53 - TZ=UTC TB --- 2013-03-19 17:03:53 - __MAKE_CONF=/dev/null TB --- 2013-03-19 17:03:53 - cd /src TB --- 2013-03-19 17:03:53 - /usr/bin/make -B buildkernel KERNCONF=RSPRO_STANDALONE >>> Kernel build for RSPRO_STANDALONE started on Tue Mar 19 17:03:53 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for RSPRO_STANDALONE completed on Tue Mar 19 17:08:31 UTC 2013 TB --- 2013-03-19 17:08:31 - cd /src/sys/mips/conf TB --- 2013-03-19 17:08:31 - /usr/sbin/config -m RT305X TB --- 2013-03-19 17:08:31 - skipping RT305X kernel TB --- 2013-03-19 17:08:31 - cd /src/sys/mips/conf TB --- 2013-03-19 17:08:31 - /usr/sbin/config -m SENTRY5 TB --- 2013-03-19 17:08:31 - skipping SENTRY5 kernel TB --- 2013-03-19 17:08:31 - cd /src/sys/mips/conf TB --- 2013-03-19 17:08:31 - /usr/sbin/config -m SWARM TB --- 2013-03-19 17:08:31 - building SWARM kernel TB --- 2013-03-19 17:08:31 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 17:08:31 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 17:08:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 17:08:31 - SRCCONF=/dev/null TB --- 2013-03-19 17:08:31 - TARGET=mips TB --- 2013-03-19 17:08:31 - TARGET_ARCH=mips TB --- 2013-03-19 17:08:31 - TZ=UTC TB --- 2013-03-19 17:08:31 - __MAKE_CONF=/dev/null TB --- 2013-03-19 17:08:31 - cd /src TB --- 2013-03-19 17:08:31 - /usr/bin/make -B buildkernel KERNCONF=SWARM >>> Kernel build for SWARM started on Tue Mar 19 17:08:31 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for SWARM completed on Tue Mar 19 17:11:09 UTC 2013 TB --- 2013-03-19 17:11:09 - cd /src/sys/mips/conf TB --- 2013-03-19 17:11:09 - /usr/sbin/config -m SWARM64 TB --- 2013-03-19 17:11:09 - skipping SWARM64 kernel TB --- 2013-03-19 17:11:09 - cd /src/sys/mips/conf TB --- 2013-03-19 17:11:09 - /usr/sbin/config -m SWARM64_SMP TB --- 2013-03-19 17:11:09 - skipping SWARM64_SMP kernel TB --- 2013-03-19 17:11:09 - cd /src/sys/mips/conf TB --- 2013-03-19 17:11:09 - /usr/sbin/config -m SWARM_SMP TB --- 2013-03-19 17:11:09 - building SWARM_SMP kernel TB --- 2013-03-19 17:11:09 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 17:11:09 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 17:11:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 17:11:09 - SRCCONF=/dev/null TB --- 2013-03-19 17:11:09 - TARGET=mips TB --- 2013-03-19 17:11:09 - TARGET_ARCH=mips TB --- 2013-03-19 17:11:09 - TZ=UTC TB --- 2013-03-19 17:11:09 - __MAKE_CONF=/dev/null TB --- 2013-03-19 17:11:09 - cd /src TB --- 2013-03-19 17:11:09 - /usr/bin/make -B buildkernel KERNCONF=SWARM_SMP >>> Kernel build for SWARM_SMP started on Tue Mar 19 17:11:09 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for SWARM_SMP completed on Tue Mar 19 17:14:01 UTC 2013 TB --- 2013-03-19 17:14:01 - cd /src/sys/mips/conf TB --- 2013-03-19 17:14:01 - /usr/sbin/config -m TP-WN1043ND TB --- 2013-03-19 17:14:01 - building TP-WN1043ND kernel TB --- 2013-03-19 17:14:01 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 17:14:01 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 17:14:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 17:14:01 - SRCCONF=/dev/null TB --- 2013-03-19 17:14:01 - TARGET=mips TB --- 2013-03-19 17:14:01 - TARGET_ARCH=mips TB --- 2013-03-19 17:14:01 - TZ=UTC TB --- 2013-03-19 17:14:01 - __MAKE_CONF=/dev/null TB --- 2013-03-19 17:14:01 - cd /src TB --- 2013-03-19 17:14:01 - /usr/bin/make -B buildkernel KERNCONF=TP-WN1043ND >>> Kernel build for TP-WN1043ND started on Tue Mar 19 17:14:01 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for TP-WN1043ND completed on Tue Mar 19 17:18:40 UTC 2013 TB --- 2013-03-19 17:18:40 - cd /src/sys/mips/conf TB --- 2013-03-19 17:18:40 - /usr/sbin/config -m XLP TB --- 2013-03-19 17:18:40 - building XLP kernel TB --- 2013-03-19 17:18:40 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 17:18:40 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 17:18:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 17:18:40 - SRCCONF=/dev/null TB --- 2013-03-19 17:18:40 - TARGET=mips TB --- 2013-03-19 17:18:40 - TARGET_ARCH=mips TB --- 2013-03-19 17:18:40 - TZ=UTC TB --- 2013-03-19 17:18:40 - __MAKE_CONF=/dev/null TB --- 2013-03-19 17:18:40 - cd /src TB --- 2013-03-19 17:18:40 - /usr/bin/make -B buildkernel KERNCONF=XLP >>> Kernel build for XLP started on Tue Mar 19 17:18:40 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80100000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/dev/e1000/e1000_phy.c -I/src/sys/dev/e1000 cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80100000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/dev/e1000/e1000_vf.c -I/src/sys/dev/e1000 cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80100000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/dev/e1000/e1000_mbx.c -I/src/sys/dev/e1000 cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80100000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/dev/e1000/e1000_osdep.c -I/src/sys/dev/e1000 cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80100000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/dev/fdt/fdt_common.c cc1: warnings being treated as errors /src/sys/dev/fdt/fdt_common.c: In function 'fdt_reg_to_rl': /src/sys/dev/fdt/fdt_common.c:451: warning: passing argument 4 of 'fdt_data_to_res' from incompatible pointer type *** [fdt_common.o] Error code 1 Stop in /obj/mips.mips/src/sys/XLP. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-19 17:19:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-19 17:19:21 - ERROR: failed to build XLP kernel TB --- 2013-03-19 17:19:21 - 6349.12 user 1191.66 system 8475.98 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Tue Mar 19 17:32:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 61BCCA3E; Tue, 19 Mar 2013 17:32:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0ED5287F; Tue, 19 Mar 2013 17:32:24 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4CEF3B943; Tue, 19 Mar 2013 13:32:23 -0400 (EDT) From: John Baldwin To: Andriy Gapon Subject: Re: gptzfsboot problem on HP P410i Smart Array Date: Tue, 19 Mar 2013 12:20:33 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <51483621.2060503@FreeBSD.org> In-Reply-To: <51483621.2060503@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Message-Id: <201303191220.34088.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 19 Mar 2013 13:32:23 -0400 (EDT) Cc: Bjorn Larsson , freebsd-current@freebsd.org, Sergey Dyatko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 17:32:24 -0000 On Tuesday, March 19, 2013 5:55:45 am Andriy Gapon wrote: > on 19/03/2013 07:41 Sergey Dyatko said the following: > > I was faced with same problem on my laptop. Adding printf() into main() > > before dsk = malloc(sizeof(struct dsk)); fix boot. Yesterday, avg@ proposed > > patch: > > Index: /usr/src/sys/boot/i386/zfsboot/zfsboot.c > > =================================================================== > > --- /usr/src/sys/boot/i386/zfsboot/zfsboot.c (revision 248421) > > +++ /usr/src/sys/boot/i386/zfsboot/zfsboot.c (working copy) > > @@ -302,6 +302,7 @@ > > * region in the SMAP, use the last 3MB of 'extended' memory as a > > * high heap candidate. > > */ > > + high_heap_size = 0; > > if (bios_extmem >= HEAP_MIN && high_heap_size < HEAP_MIN) { > > high_heap_size = HEAP_MIN; > > high_heap_base = bios_extmem + 0x100000 - HEAP_MIN; > > > > it works for me, without printf() :) Can you test it ? > > A comment about a nature of this patch. > > Based on the previous investigation by Christoph Hoffmann and jhb: > http://thread.gmane.org/gmane.os.freebsd.current/134199/focus=134309 > I made a guess that either BIOS/firmware provides incorrect memory map or some > agent in the BIOS/firmware (e.g. SMM handler) or controller firmware writes > outside of a memory range reserved for it. > I think that jhb made a similar guess at the time while Christoph conjectured > that memory corruption was related to CPU caches or some such. > My conjecture is that it is simply a combination of timing and a particular > memory range. > > Just in case, here is how the memory map looks on the Sergey's system: > SMAP type=01 base=0000000000000000 end=000000000009fc00 len=000000000009fc00 > SMAP type=02 base=000000000009fc00 end=00000000000a0000 len=0000000000000400 > SMAP type=02 base=00000000000e0000 end=0000000000100000 len=0000000000020000 > SMAP type=01 base=0000000000100000 end=00000000bc1a1000 len=00000000bc0a1000 > SMAP type=04 base=00000000bc1a1000 end=00000000bc1a4000 len=0000000000003000 > SMAP type=01 base=00000000bc1a4000 end=00000000bdf04000 len=0000000001d60000 > SMAP type=04 base=00000000bdf04000 end=00000000bdf3f000 len=000000000003b000 > SMAP type=01 base=00000000bdf3f000 end=00000000bdf6a000 len=000000000002b000 > SMAP type=02 base=00000000bdf6a000 end=00000000bdfbf000 len=0000000000055000 > SMAP type=01 base=00000000bdfbf000 end=00000000bdfeb000 len=000000000002c000 > SMAP type=03 base=00000000bdfeb000 end=00000000bdfff000 len=0000000000014000 > SMAP type=01 base=00000000bdfff000 end=00000000be000000 len=0000000000001000 > SMAP type=02 base=00000000be000000 end=00000000c0000000 len=0000000002000000 > SMAP type=02 base=00000000f8000000 end=00000000fc000000 len=0000000004000000 > SMAP type=02 base=00000000fec00000 end=00000000fec01000 len=0000000000001000 > SMAP type=02 base=00000000fed10000 end=00000000fed14000 len=0000000000004000 > SMAP type=02 base=00000000fed18000 end=00000000fed1a000 len=0000000000002000 > SMAP type=02 base=00000000fed1c000 end=00000000fed20000 len=0000000000004000 > SMAP type=02 base=00000000fee00000 end=00000000fee01000 len=0000000000001000 > SMAP type=02 base=00000000ffe00000 end=0000000100000000 len=0000000000200000 > SMAP type=01 base=0000000100000000 end=0000000140000000 len=0000000040000000 > > The algorithm for placing the heap picks up a range at bc1a4000, which is > between two ranges of type '4' (ACPI NVS memory). > So my idea was just to try a different memory range. Seems that it worked. > > P.S. I am not sure why our algorithm for selecting heap location is what it is. > On all systems that I have I see that the "bios_extmem" range (the one starting > at 0x100000) is usually the largest one and has more than enough space for both > the heap and other things that are placed there. Yes, we likely could start using that, we would just need to ensure it has some sort of minimum size. However, maybe it would always have that minimum size as you are only going to have additional ranges if you have more than 4GB of RAM anyway. I think though that there were some odd BIOSes that would place a hole at 15-16MB, and for those the memory region at 1MB is too small. A minimum size of 16MB might handle that case correctly while using the first extended region in the common case. > Additionally, in the case of zfsboot I think that we do not use memory above 1MB > for anything else besides the heap. You load either /boot/zfsloader or the kernel there. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Mar 19 18:46:14 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A975EC11; Tue, 19 Mar 2013 18:46: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 6A083D88; Tue, 19 Mar 2013 18:46:13 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2JIkDNC055677; Tue, 19 Mar 2013 14:46:13 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2JIkDjW055673; Tue, 19 Mar 2013 18:46:13 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 19 Mar 2013 18:46:13 GMT Message-Id: <201303191846.r2JIkDjW055673@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 18:46:14 -0000 TB --- 2013-03-19 15:44:46 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-19 15:44:46 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-19 15:44:46 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-03-19 15:44:46 - cleaning the object tree TB --- 2013-03-19 15:47:23 - /usr/local/bin/svn stat /src TB --- 2013-03-19 15:47:27 - At svn revision 248493 TB --- 2013-03-19 15:47:28 - building world TB --- 2013-03-19 15:47:28 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 15:47:28 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 15:47:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 15:47:28 - SRCCONF=/dev/null TB --- 2013-03-19 15:47:28 - TARGET=powerpc TB --- 2013-03-19 15:47:28 - TARGET_ARCH=powerpc TB --- 2013-03-19 15:47:28 - TZ=UTC TB --- 2013-03-19 15:47:28 - __MAKE_CONF=/dev/null TB --- 2013-03-19 15:47:28 - cd /src TB --- 2013-03-19 15:47:28 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Mar 19 15:47:33 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Mar 19 18:10:45 UTC 2013 TB --- 2013-03-19 18:10:45 - generating LINT kernel config TB --- 2013-03-19 18:10:45 - cd /src/sys/powerpc/conf TB --- 2013-03-19 18:10:45 - /usr/bin/make -B LINT TB --- 2013-03-19 18:10:45 - cd /src/sys/powerpc/conf TB --- 2013-03-19 18:10:45 - /usr/sbin/config -m LINT TB --- 2013-03-19 18:10:45 - building LINT kernel TB --- 2013-03-19 18:10:45 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 18:10:45 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 18:10:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 18:10:45 - SRCCONF=/dev/null TB --- 2013-03-19 18:10:45 - TARGET=powerpc TB --- 2013-03-19 18:10:45 - TARGET_ARCH=powerpc TB --- 2013-03-19 18:10:45 - TZ=UTC TB --- 2013-03-19 18:10:45 - __MAKE_CONF=/dev/null TB --- 2013-03-19 18:10:45 - cd /src TB --- 2013-03-19 18:10:45 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Mar 19 18:10:45 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Tue Mar 19 18:29:54 UTC 2013 TB --- 2013-03-19 18:29:54 - cd /src/sys/powerpc/conf TB --- 2013-03-19 18:29:54 - /usr/sbin/config -m GENERIC TB --- 2013-03-19 18:29:54 - building GENERIC kernel TB --- 2013-03-19 18:29:54 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 18:29:54 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 18:29:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 18:29:54 - SRCCONF=/dev/null TB --- 2013-03-19 18:29:54 - TARGET=powerpc TB --- 2013-03-19 18:29:54 - TARGET_ARCH=powerpc TB --- 2013-03-19 18:29:54 - TZ=UTC TB --- 2013-03-19 18:29:54 - __MAKE_CONF=/dev/null TB --- 2013-03-19 18:29:54 - cd /src TB --- 2013-03-19 18:29:54 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Mar 19 18:29:54 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Tue Mar 19 18:45:33 UTC 2013 TB --- 2013-03-19 18:45:33 - cd /src/sys/powerpc/conf TB --- 2013-03-19 18:45:33 - /usr/sbin/config -m GENERIC64 TB --- 2013-03-19 18:45:33 - skipping GENERIC64 kernel TB --- 2013-03-19 18:45:33 - cd /src/sys/powerpc/conf TB --- 2013-03-19 18:45:33 - /usr/sbin/config -m MPC85XX TB --- 2013-03-19 18:45:33 - building MPC85XX kernel TB --- 2013-03-19 18:45:33 - CROSS_BUILD_TESTING=YES TB --- 2013-03-19 18:45:33 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-19 18:45:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 18:45:33 - SRCCONF=/dev/null TB --- 2013-03-19 18:45:33 - TARGET=powerpc TB --- 2013-03-19 18:45:33 - TARGET_ARCH=powerpc TB --- 2013-03-19 18:45:33 - TZ=UTC TB --- 2013-03-19 18:45:33 - __MAKE_CONF=/dev/null TB --- 2013-03-19 18:45:33 - cd /src TB --- 2013-03-19 18:45:33 - /usr/bin/make -B buildkernel KERNCONF=MPC85XX >>> Kernel build for MPC85XX started on Tue Mar 19 18:45:33 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wa,-me500 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/e1000/e1000_phy.c -I/src/sys/dev/e1000 cc -c -O -pipe -std=c99 -Wa,-me500 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/e1000/e1000_vf.c -I/src/sys/dev/e1000 cc -c -O -pipe -std=c99 -Wa,-me500 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/e1000/e1000_mbx.c -I/src/sys/dev/e1000 cc -c -O -pipe -std=c99 -Wa,-me500 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/e1000/e1000_osdep.c -I/src/sys/dev/e1000 cc -c -O -pipe -std=c99 -Wa,-me500 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/fdt/fdt_common.c cc1: warnings being treated as errors /src/sys/dev/fdt/fdt_common.c: In function 'fdt_reg_to_rl': /src/sys/dev/fdt/fdt_common.c:451: warning: passing argument 4 of 'fdt_data_to_res' from incompatible pointer type *** [fdt_common.o] Error code 1 Stop in /obj/powerpc.powerpc/src/sys/MPC85XX. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-19 18:46:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-19 18:46:13 - ERROR: failed to build MPC85XX kernel TB --- 2013-03-19 18:46:13 - 9298.86 user 1161.66 system 10887.10 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 20 08:30:33 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 05DC9CCE; Wed, 20 Mar 2013 08:30:33 +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 05EE5382; Wed, 20 Mar 2013 08:30:31 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA27157; Wed, 20 Mar 2013 10:30:30 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UIEPm-000NHo-5e; Wed, 20 Mar 2013 10:30:30 +0200 Message-ID: <514973A3.9030706@FreeBSD.org> Date: Wed, 20 Mar 2013 10:30:27 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: FreeBSD Current , freebsd-hackers@FreeBSD.org Subject: mountroot event X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 08:30:33 -0000 I would like to propose the following change. My understanding is that it was never a true intention to post 'mountroot' event on every set_rootvnode() call, but rather an accident in the original commit. But I could be wrong here. In either case I think that it is more appropriate to post the event only once. I do not expect that there could be any consumers interested in all the details of root fs manipulations. It looks like there is just a single subscriber to this event in subr_firmware.c. I am not familiar with that code, so I would like to ask for confirmation that the proposed change won't break anything there. Thank you. commit 9dc8eaa50afa6ac88c44fbaad82509721e106f1a Author: Andriy Gapon Date: Wed Mar 6 08:57:35 2013 +0200 post mountroot event after a real/final root is mounted not every time an intermediate root (including the first devfs) is mounted. diff --git a/sys/kern/vfs_mountroot.c b/sys/kern/vfs_mountroot.c index 147926e..162738d 100644 --- a/sys/kern/vfs_mountroot.c +++ b/sys/kern/vfs_mountroot.c @@ -199,8 +199,6 @@ set_rootvnode(void) VREF(rootvnode); FILEDESC_XUNLOCK(p->p_fd); - - EVENTHANDLER_INVOKE(mountroot); } static int @@ -991,6 +989,8 @@ vfs_mountroot(void) atomic_store_rel_int(&root_mount_complete, 1); wakeup(&root_mount_complete); mtx_unlock(&mountlist_mtx); + + EVENTHANDLER_INVOKE(mountroot); } static struct mntarg * -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Mar 20 15:20:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EEEE7C7; Wed, 20 Mar 2013 15:20:34 +0000 (UTC) (envelope-from mgamsjager@gmail.com) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id BBC46E37; Wed, 20 Mar 2013 15:20:33 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id er20so3126129lab.4 for ; Wed, 20 Mar 2013 08:20:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=1mBaIUo79xEB7r0O6QXCcZttSx2kmgEbIhi7ZP6Ytmg=; b=DvOVC0wvJM16ssRnNbKw05oU4/UseL7ESlNwj6ixOrx24XtAf/cCfngdtR1DW+blJe Q7WJxYhkQahCryRktwcPK+UvOuA0vLFQ720oCwT82zsYdzM7KUfBnLqK8tHodSqaZQ6x 2U31KwS/f6soGfF0U6YwA4GWeviifAbFfmVcuazZcgl1jsThAGtcO+03tVEQq82EYfuQ /HxWlfKCgxSddvWJqfQ5itZVvwre51eqLLoDZ1Rb6cFSwba4E4bQriAvUv1hNw3hvN1H v4xm5/y/IDhmgfSu6CP61G+hD7zuTJv7VAv5xStRNjHmHMJth7e3HY5zQJW7imrlmdpR yJRA== X-Received: by 10.152.46.131 with SMTP id v3mr5641905lam.57.1363792832581; Wed, 20 Mar 2013 08:20:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.226 with HTTP; Wed, 20 Mar 2013 08:20:02 -0700 (PDT) In-Reply-To: <5141B491.1010800@FreeBSD.org> References: <5141B491.1010800@FreeBSD.org> From: Matthias Gamsjager Date: Wed, 20 Mar 2013 16:20:02 +0100 Message-ID: Subject: Re: [HEADS UP] pkgng binary packages regression in 1.0.9. Fixed in 1.0.9_1 To: Bryan Drewery Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Ports , FreeBSD Current , freebsd-stable@freebsd.org, freebsd-pkg@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 15:20:35 -0000 > Due to the security incident, there are still no official FreeBSD > packages. > Do you know what the status is on that issue? From owner-freebsd-current@FreeBSD.ORG Wed Mar 20 16:01:03 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BCCCAD91 for ; Wed, 20 Mar 2013 16:01:03 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 8E38F10E for ; Wed, 20 Mar 2013 16:01:02 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.6/8.14.6) with ESMTP id r2KG0uOY041234 for ; Wed, 20 Mar 2013 09:00:56 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.6/8.14.6/Submit) id r2KG0uMX041233 for current@freebsd.org; Wed, 20 Mar 2013 09:00:56 -0700 (PDT) (envelope-from david) Date: Wed, 20 Mar 2013 09:00:56 -0700 From: David Wolfskill To: current@freebsd.org Subject: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver Message-ID: <20130320160056.GG32811@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1giRMj6yz/+FOIRq" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 16:01:03 -0000 --1giRMj6yz/+FOIRq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Yesterday, I built head & ran it without incident (as has been the daily norm for some time now): FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #843 r2484= 93M/248493: Tue Mar 19 05:57:09 PDT 2013 root@g1-235.catwhisker.org:/us= r/obj/usr/src/sys/CANARY i386 Today, after updating to: FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #844 r2485= 50M/248551: Wed Mar 20 06:59:32 PDT 2013 root@g1-235.catwhisker.org:/us= r/obj/usr/src/sys/CANARY i386 I find that booting to single-user mode is OK, and I can even start xdm -- as long as I did not kldload nvidia.ko first. (Indeed, I find that once loaded, the attempt to unload nvidia.ko appears to hang.) If (as has been my practice for the last several years) I loaded nvidia.ko (via /boot/loader.conf) before attempting to start xdm, when I do try starting xdm, the machine (my laptop -- no serial console) quietly initiates a reboot. Mounted file systems don't get unmounted first, so that tends to be mildly annoying -- and provides some evidence that the reboot isn't exactly being performed under ideal conditions (which, I admit, is not all that much of a surprise). Here's what happened during the "svn update," so folks can see what files changed: Script started on Wed Mar 20 06:01:32 2013 svn update /usr/src Updating '/usr/src': U /usr/src/contrib/llvm/tools/clang/lib/Driver/Tools.cpp U /usr/src/share/man/man4/unix.4 U /usr/src/share/man/man4/iwn.4 U /usr/src/lib/libc/sys/recv.2 U /usr/src/lib/libc/sys/socket.2 U /usr/src/lib/libc/sys/socketpair.2 U /usr/src/sys/ia64/ia64/pmap.c U /usr/src/sys/mips/mips/pmap.c U /usr/src/sys/fs/nfsclient/nfs_clbio.c U /usr/src/sys/amd64/amd64/pmap.c U /usr/src/sys/sys/mount.h U /usr/src/sys/sys/systm.h U /usr/src/sys/sys/bio.h U /usr/src/sys/sys/socket.h U /usr/src/sys/sys/domain.h U /usr/src/sys/sys/buf.h U /usr/src/sys/powerpc/powerpc/pmap_dispatch.c U /usr/src/sys/powerpc/aim/mmu_oea64.c U /usr/src/sys/arm/arm/pmap-v6.c U /usr/src/sys/arm/arm/pmap.c U /usr/src/sys/vm/vm_kern.c U /usr/src/sys/vm/vm.h U /usr/src/sys/vm/vm_init.c U /usr/src/sys/vm/swap_pager.c U /usr/src/sys/vm/vnode_pager.c U /usr/src/sys/vm/swap_pager.h U /usr/src/sys/sparc64/sparc64/pmap.c U /usr/src/sys/net80211/ieee80211_freebsd.c U /usr/src/sys/nfsclient/nfs_bio.c U /usr/src/sys/geom/geom_io.c U /usr/src/sys/geom/geom_disk.c U /usr/src/sys/geom/geom_disk.h U /usr/src/sys/geom/part/g_part.c U /usr/src/sys/geom/geom.h U /usr/src/sys/geom/geom_vfs.c U /usr/src/sys/i386/i386/pmap.c U /usr/src/sys/i386/xen/pmap.c U /usr/src/sys/ufs/ufs/ufs_extern.h U /usr/src/sys/ufs/ffs/ffs_alloc.c U /usr/src/sys/ufs/ffs/ffs_balloc.c U /usr/src/sys/ufs/ffs/ffs_vfsops.c U /usr/src/sys/ufs/ffs/ffs_rawread.c U /usr/src/sys/ufs/ffs/ffs_vnops.c U /usr/src/sys/cam/cam_periph.c U /usr/src/sys/cam/cam_ccb.h U /usr/src/sys/cam/scsi/scsi_da.c U /usr/src/sys/cam/scsi/scsi_all.c U /usr/src/sys/cam/scsi/scsi_all.h U /usr/src/sys/cam/scsi/scsi_cd.c U /usr/src/sys/cam/ata/ata_da.c U /usr/src/sys/dev/mii/rgephyreg.h U /usr/src/sys/dev/mii/rgephy.c U /usr/src/sys/dev/usb/usbdevs U /usr/src/sys/dev/usb/serial/u3g.c U /usr/src/sys/dev/ath/if_ath_beacon.c U /usr/src/sys/dev/ath/if_ath_rx.c U /usr/src/sys/dev/ath/if_ath_tx.c U /usr/src/sys/dev/ath/if_ath.c U /usr/src/sys/dev/ath/if_athvar.h U /usr/src/sys/dev/ath/if_ath_rx_edma.c U /usr/src/sys/dev/ath/if_ath_tx_edma.c U /usr/src/sys/dev/siis/siis.c U /usr/src/sys/dev/fdt/fdt_common.c U /usr/src/sys/dev/ahci/ahci.c U /usr/src/sys/dev/md/md.c U /usr/src/sys/kern/kern_physio.c U /usr/src/sys/kern/subr_bus_dma.c U /usr/src/sys/kern/vfs_bio.c U /usr/src/sys/kern/subr_param.c U /usr/src/sys/kern/uipc_usrreq.c U /usr/src/sys/kern/uipc_socket.c U /usr/src/sys/kern/vfs_cluster.c U /usr/src/sys/kern/uipc_syscalls.c U /usr/src/sys/kern/vfs_aio.c U /usr/src/sbin/shutdown/shutdown.8 U /usr/src/sbin/ldconfig/ldconfig.c U /usr/src/sbin/ldconfig/ldconfig.8 Updated to revision 248551. I note that r248084 made some changes in src/sys/vm/ that broke x11/nvidia-driver a few days ago, and I hacked up a patch for that (which sbruno@ committed recently). Still, I had been running (without incident) using that patch.... And I freely admit that I'm far more of a hacker than a developer; I don't claim familiarity with the VM subsystem at all. But given that nvidia-driver is (evidently) somewhat sensitive with respect to the VM subsystem, I would be unsurprised to find that there might be some undesirable interactions between that and the changes kib@ recently committed to head (e.g., r248508). Unfortunately, I'm just about clueless as to how to get any debugging information out of the system. I'm open to suggestions, and willing to hack and test (and report, of course). Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --1giRMj6yz/+FOIRq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFJ3TcACgkQmprOCmdXAD1VvACfbRV3ylzEhAb/R7r6EcLmlMxV FokAn1mzsJt2CH4kVtll0FShnRHZl8Fp =zLgJ -----END PGP SIGNATURE----- --1giRMj6yz/+FOIRq-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 20 16:02:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 037C8EB8 for ; Wed, 20 Mar 2013 16:02:44 +0000 (UTC) (envelope-from matthew@freebsd.org) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id 95218130 for ; Wed, 20 Mar 2013 16:02:43 +0000 (UTC) Received: from rufus.webfusion.com (mail.heartinternet.co.uk [79.170.40.31]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.6/8.14.6) with ESMTP id r2KG2Qvn060769 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 20 Mar 2013 16:02:38 GMT (envelope-from matthew@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.8.0 smtp.infracaninophile.co.uk r2KG2Qvn060769 Authentication-Results: smtp.infracaninophile.co.uk/r2KG2Qvn060769; dkim=none reason="no signature"; dkim-adsp=none (unprotected policy) X-Authentication-Warning: lucid-nonsense.infracaninophile.co.uk: Host mail.heartinternet.co.uk [79.170.40.31] claimed to be rufus.webfusion.com Message-ID: <5149DD91.8070207@freebsd.org> Date: Wed, 20 Mar 2013 16:02:25 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130312 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: [HEADS UP] pkgng binary packages regression in 1.0.9. Fixed in 1.0.9_1 References: <5141B491.1010800@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.6 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 16:02:44 -0000 On 20/03/2013 15:20, Matthias Gamsjager wrote: >> Due to the security incident, there are still no official FreeBSD >> packages. >> > > > Do you know what the status is on that issue? Unchanged so far. No official pkgng packages yet. However, an end to the wait is apparently in sight. There has been mention of work on pkgng building systems. Cheers, Matthew From owner-freebsd-current@FreeBSD.ORG Wed Mar 20 16:06:58 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 32586189 for ; Wed, 20 Mar 2013 16:06:58 +0000 (UTC) (envelope-from lattera@gmail.com) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) by mx1.freebsd.org (Postfix) with ESMTP id E8766189 for ; Wed, 20 Mar 2013 16:06:57 +0000 (UTC) Received: by mail-vc0-f177.google.com with SMTP id ia10so1455624vcb.22 for ; Wed, 20 Mar 2013 09:06:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=2+4TdwkTNNaJCE5HpY0/S3OoMeThS8WHZk94C6wphWc=; b=DAvY8uC/03Mwn+fbJow64LRwr/RIqkFgivNX58XKsh0woRcimo67IrJgzKLI5OxgDr 5AXUjfQad30nIaGoTUmdNiFQWpJBw2G97y4OKwARwmFWG529TxNqeXKGeTUikr6ZVtWS eY57oLDhLejiHIqMe4crVVjFVoKhv+uKM4opSm+eDSozdt8XJH8u6lDlz/N2fE4TgtBW jAEe7mZhUIbFmygOnoq5PCDg4PZRz2TAUe8r3saQpRgsQqFsFOLNEVCyvMTEtHjLoHYx 3HDMwVBhrLfRrlsIoumu8TYev/Jp12vXOjh2nh+VXi/ZVj1bFt5AvEdBRFpALMNJPlfN /T7A== MIME-Version: 1.0 X-Received: by 10.52.88.197 with SMTP id bi5mr7373179vdb.58.1363795616850; Wed, 20 Mar 2013 09:06:56 -0700 (PDT) Received: by 10.58.237.163 with HTTP; Wed, 20 Mar 2013 09:06:56 -0700 (PDT) In-Reply-To: <20130320160056.GG32811@albert.catwhisker.org> References: <20130320160056.GG32811@albert.catwhisker.org> Date: Wed, 20 Mar 2013 12:06:56 -0400 Message-ID: Subject: Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver From: Shawn Webb To: David Wolfskill Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 16:06:58 -0000 I've been having random panics since the VM changes. I'm stuck running r247527. If I try to install a newer kernel/world, I get random panics (I really should enable crashdumps). Not a big deal, but I'm mostly interested in epair fixes and bhyve enhancements. On Wed, Mar 20, 2013 at 12:00 PM, David Wolfskill wrote: > Yesterday, I built head & ran it without incident (as has been the > daily norm for some time now): > > FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #843 > r248493M/248493: Tue Mar 19 05:57:09 PDT 2013 > root@g1-235.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 > > Today, after updating to: > > FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #844 > r248550M/248551: Wed Mar 20 06:59:32 PDT 2013 > root@g1-235.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 > > I find that booting to single-user mode is OK, and I can even start xdm -- > as long as I did not kldload nvidia.ko first. (Indeed, I find that > once loaded, the attempt to unload nvidia.ko appears to hang.) > > If (as has been my practice for the last several years) I loaded > nvidia.ko (via /boot/loader.conf) before attempting to start xdm, > when I do try starting xdm, the machine (my laptop -- no serial > console) quietly initiates a reboot. Mounted file systems don't get > unmounted first, so that tends to be mildly annoying -- and provides > some evidence that the reboot isn't exactly being performed under ideal > conditions (which, I admit, is not all that much of a surprise). > > Here's what happened during the "svn update," so folks can see what > files changed: > > Script started on Wed Mar 20 06:01:32 2013 > svn update /usr/src > Updating '/usr/src': > U /usr/src/contrib/llvm/tools/clang/lib/Driver/Tools.cpp > U /usr/src/share/man/man4/unix.4 > U /usr/src/share/man/man4/iwn.4 > U /usr/src/lib/libc/sys/recv.2 > U /usr/src/lib/libc/sys/socket.2 > U /usr/src/lib/libc/sys/socketpair.2 > U /usr/src/sys/ia64/ia64/pmap.c > U /usr/src/sys/mips/mips/pmap.c > U /usr/src/sys/fs/nfsclient/nfs_clbio.c > U /usr/src/sys/amd64/amd64/pmap.c > U /usr/src/sys/sys/mount.h > U /usr/src/sys/sys/systm.h > U /usr/src/sys/sys/bio.h > U /usr/src/sys/sys/socket.h > U /usr/src/sys/sys/domain.h > U /usr/src/sys/sys/buf.h > U /usr/src/sys/powerpc/powerpc/pmap_dispatch.c > U /usr/src/sys/powerpc/aim/mmu_oea64.c > U /usr/src/sys/arm/arm/pmap-v6.c > U /usr/src/sys/arm/arm/pmap.c > U /usr/src/sys/vm/vm_kern.c > U /usr/src/sys/vm/vm.h > U /usr/src/sys/vm/vm_init.c > U /usr/src/sys/vm/swap_pager.c > U /usr/src/sys/vm/vnode_pager.c > U /usr/src/sys/vm/swap_pager.h > U /usr/src/sys/sparc64/sparc64/pmap.c > U /usr/src/sys/net80211/ieee80211_freebsd.c > U /usr/src/sys/nfsclient/nfs_bio.c > U /usr/src/sys/geom/geom_io.c > U /usr/src/sys/geom/geom_disk.c > U /usr/src/sys/geom/geom_disk.h > U /usr/src/sys/geom/part/g_part.c > U /usr/src/sys/geom/geom.h > U /usr/src/sys/geom/geom_vfs.c > U /usr/src/sys/i386/i386/pmap.c > U /usr/src/sys/i386/xen/pmap.c > U /usr/src/sys/ufs/ufs/ufs_extern.h > U /usr/src/sys/ufs/ffs/ffs_alloc.c > U /usr/src/sys/ufs/ffs/ffs_balloc.c > U /usr/src/sys/ufs/ffs/ffs_vfsops.c > U /usr/src/sys/ufs/ffs/ffs_rawread.c > U /usr/src/sys/ufs/ffs/ffs_vnops.c > U /usr/src/sys/cam/cam_periph.c > U /usr/src/sys/cam/cam_ccb.h > U /usr/src/sys/cam/scsi/scsi_da.c > U /usr/src/sys/cam/scsi/scsi_all.c > U /usr/src/sys/cam/scsi/scsi_all.h > U /usr/src/sys/cam/scsi/scsi_cd.c > U /usr/src/sys/cam/ata/ata_da.c > U /usr/src/sys/dev/mii/rgephyreg.h > U /usr/src/sys/dev/mii/rgephy.c > U /usr/src/sys/dev/usb/usbdevs > U /usr/src/sys/dev/usb/serial/u3g.c > U /usr/src/sys/dev/ath/if_ath_beacon.c > U /usr/src/sys/dev/ath/if_ath_rx.c > U /usr/src/sys/dev/ath/if_ath_tx.c > U /usr/src/sys/dev/ath/if_ath.c > U /usr/src/sys/dev/ath/if_athvar.h > U /usr/src/sys/dev/ath/if_ath_rx_edma.c > U /usr/src/sys/dev/ath/if_ath_tx_edma.c > U /usr/src/sys/dev/siis/siis.c > U /usr/src/sys/dev/fdt/fdt_common.c > U /usr/src/sys/dev/ahci/ahci.c > U /usr/src/sys/dev/md/md.c > U /usr/src/sys/kern/kern_physio.c > U /usr/src/sys/kern/subr_bus_dma.c > U /usr/src/sys/kern/vfs_bio.c > U /usr/src/sys/kern/subr_param.c > U /usr/src/sys/kern/uipc_usrreq.c > U /usr/src/sys/kern/uipc_socket.c > U /usr/src/sys/kern/vfs_cluster.c > U /usr/src/sys/kern/uipc_syscalls.c > U /usr/src/sys/kern/vfs_aio.c > U /usr/src/sbin/shutdown/shutdown.8 > U /usr/src/sbin/ldconfig/ldconfig.c > U /usr/src/sbin/ldconfig/ldconfig.8 > Updated to revision 248551. > > I note that r248084 made some changes in src/sys/vm/ that broke > x11/nvidia-driver a few days ago, and I hacked up a patch for that > (which sbruno@ committed recently). Still, I had been running > (without incident) using that patch.... And I freely admit that > I'm far more of a hacker than a developer; I don't claim familiarity > with the VM subsystem at all. But given that nvidia-driver is > (evidently) somewhat sensitive with respect to the VM subsystem, I > would be unsurprised to find that there might be some undesirable > interactions between that and the changes kib@ recently committed > to head (e.g., r248508). > > Unfortunately, I'm just about clueless as to how to get any debugging > information out of the system. > > I'm open to suggestions, and willing to hack and test (and report, > of course). > > Peace, > david > -- > David H. Wolfskill david@catwhisker.org > Taliban: Evil men with guns afraid of truth from a 14-year old girl. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. > From owner-freebsd-current@FreeBSD.ORG Wed Mar 20 16:29:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 245A7B6C for ; Wed, 20 Mar 2013 16:29:32 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by mx1.freebsd.org (Postfix) with ESMTP id 06CE92CE for ; Wed, 20 Mar 2013 16:29:31 +0000 (UTC) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta12.emeryville.ca.mail.comcast.net with comcast id Dosc1l0040lTkoCACsVXin; Wed, 20 Mar 2013 16:29:31 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta04.emeryville.ca.mail.comcast.net with comcast id DsVW1l00K1t3BNj8QsVWTR; Wed, 20 Mar 2013 16:29:30 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 5732B73A1C; Wed, 20 Mar 2013 09:29:30 -0700 (PDT) Date: Wed, 20 Mar 2013 09:29:30 -0700 From: Jeremy Chadwick To: Matthias Gamsjager Subject: Re: [HEADS UP] pkgng binary packages regression in 1.0.9. Fixed in 1.0.9_1 Message-ID: <20130320162930.GA5230@icarus.home.lan> References: <5141B491.1010800@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1363796971; bh=SDfLa+6JNcfYqWmz7ahlU5fycNVEh8kb5Zr318srBl0=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=G3UDcLWiy2gxbJVm8u6/ixm/JIdBIt94i60xe4xa6QCNYqFSg2zk3gmPjEPXCzPMp zUEJWHB7vwl5fP8oGveQ5uf9dkCbUqhPT2Q6s343KJegjcFjPsHL5RPdIISdNtU3PE iMQSKwYEC90XfxS9kJLiZKcLIZG9xDWQ5Ym+m1S5ObOGCo8YovE22AS1+3xjQtDUYI l/LEGD1adWrv1P/n/PURNNhz+b67xiW/o2Y+bUaW1GDKmUew8hnixdWbXS7jvnYLBP MEQwei/zDbUsKLzU+JSrjjHTrXM8lY64heuDcv9SY2NiKyD6jGjeKQ6IbDSY0NXYYr u1R/z/iNGI7rA== X-Mailman-Approved-At: Wed, 20 Mar 2013 16:35:36 +0000 Cc: FreeBSD Ports , FreeBSD Current , freebsd-stable@freebsd.org, freebsd-pkg@freebsd.org, Bryan Drewery X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 16:29:32 -0000 On Wed, Mar 20, 2013 at 04:20:02PM +0100, Matthias Gamsjager wrote: > > Due to the security incident, there are still no official FreeBSD > > packages. > > Do you know what the status is on that issue? I'd also like to find out what the status of this is. The packages at: ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/ Are still circa October 2012 -- that's 4-5 months ago. While I truly and deeply understand that proper engineering design and infrastructure changes take time, there has been absolutely no communication presented to the community as to what has (or hasn't) transpired, if there is (or isn't) a plan, or if people are simply waiting until future in-person BSD* events to work things out. freebsd-ops-announce has been silent on this matter as well: http://lists.freebsd.org/mailman/listinfo/freebsd-ops-announce At this point users and administrators do not know if newer packages will be made available or if they should stick to building purely from source. Deep down I'm worried that this will solicit a response of "switch to ports-mgmt/pkg and ports-mgmt/poudriere". While I'm not opposed to the tools themselves, I'm strongly opposed to that kind of response as I'm tired of seeing the security incident being used as a opportunistic crutch (as it was for the sudden cvsup/csup deprecation). -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Wed Mar 20 17:13:56 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 65F789DC for ; Wed, 20 Mar 2013 17:13:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id B7B0F6BA for ; Wed, 20 Mar 2013 17:13:55 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2KHDfMH048380; Wed, 20 Mar 2013 19:13:41 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2KHDfMH048380 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2KHDfBb048379; Wed, 20 Mar 2013 19:13:41 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 20 Mar 2013 19:13:41 +0200 From: Konstantin Belousov To: David Wolfskill Subject: Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver Message-ID: <20130320171340.GE3794@kib.kiev.ua> References: <20130320160056.GG32811@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2b5bRed07meAXa2o" Content-Disposition: inline In-Reply-To: <20130320160056.GG32811@albert.catwhisker.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 17:13:56 -0000 --2b5bRed07meAXa2o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 20, 2013 at 09:00:56AM -0700, David Wolfskill wrote: > Yesterday, I built head & ran it without incident (as has been the > daily norm for some time now): >=20 > FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #843 r24= 8493M/248493: Tue Mar 19 05:57:09 PDT 2013 root@g1-235.catwhisker.org:/= usr/obj/usr/src/sys/CANARY i386 >=20 > Today, after updating to: >=20 > FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #844 r24= 8550M/248551: Wed Mar 20 06:59:32 PDT 2013 root@g1-235.catwhisker.org:/= usr/obj/usr/src/sys/CANARY i386 >=20 > I find that booting to single-user mode is OK, and I can even start xdm -- > as long as I did not kldload nvidia.ko first. (Indeed, I find that > once loaded, the attempt to unload nvidia.ko appears to hang.) >=20 > If (as has been my practice for the last several years) I loaded > nvidia.ko (via /boot/loader.conf) before attempting to start xdm, > when I do try starting xdm, the machine (my laptop -- no serial > console) quietly initiates a reboot. Mounted file systems don't get > unmounted first, so that tends to be mildly annoying -- and provides > some evidence that the reboot isn't exactly being performed under ideal > conditions (which, I admit, is not all that much of a surprise). >=20 > Here's what happened during the "svn update," so folks can see what > files changed: >=20 > Script started on Wed Mar 20 06:01:32 2013 > svn update /usr/src > Updating '/usr/src': > U /usr/src/contrib/llvm/tools/clang/lib/Driver/Tools.cpp > U /usr/src/share/man/man4/unix.4 > U /usr/src/share/man/man4/iwn.4 > U /usr/src/lib/libc/sys/recv.2 > U /usr/src/lib/libc/sys/socket.2 > U /usr/src/lib/libc/sys/socketpair.2 > U /usr/src/sys/ia64/ia64/pmap.c > U /usr/src/sys/mips/mips/pmap.c > U /usr/src/sys/fs/nfsclient/nfs_clbio.c > U /usr/src/sys/amd64/amd64/pmap.c > U /usr/src/sys/sys/mount.h > U /usr/src/sys/sys/systm.h > U /usr/src/sys/sys/bio.h > U /usr/src/sys/sys/socket.h > U /usr/src/sys/sys/domain.h > U /usr/src/sys/sys/buf.h > U /usr/src/sys/powerpc/powerpc/pmap_dispatch.c > U /usr/src/sys/powerpc/aim/mmu_oea64.c > U /usr/src/sys/arm/arm/pmap-v6.c > U /usr/src/sys/arm/arm/pmap.c > U /usr/src/sys/vm/vm_kern.c > U /usr/src/sys/vm/vm.h > U /usr/src/sys/vm/vm_init.c > U /usr/src/sys/vm/swap_pager.c > U /usr/src/sys/vm/vnode_pager.c > U /usr/src/sys/vm/swap_pager.h > U /usr/src/sys/sparc64/sparc64/pmap.c > U /usr/src/sys/net80211/ieee80211_freebsd.c > U /usr/src/sys/nfsclient/nfs_bio.c > U /usr/src/sys/geom/geom_io.c > U /usr/src/sys/geom/geom_disk.c > U /usr/src/sys/geom/geom_disk.h > U /usr/src/sys/geom/part/g_part.c > U /usr/src/sys/geom/geom.h > U /usr/src/sys/geom/geom_vfs.c > U /usr/src/sys/i386/i386/pmap.c > U /usr/src/sys/i386/xen/pmap.c > U /usr/src/sys/ufs/ufs/ufs_extern.h > U /usr/src/sys/ufs/ffs/ffs_alloc.c > U /usr/src/sys/ufs/ffs/ffs_balloc.c > U /usr/src/sys/ufs/ffs/ffs_vfsops.c > U /usr/src/sys/ufs/ffs/ffs_rawread.c > U /usr/src/sys/ufs/ffs/ffs_vnops.c > U /usr/src/sys/cam/cam_periph.c > U /usr/src/sys/cam/cam_ccb.h > U /usr/src/sys/cam/scsi/scsi_da.c > U /usr/src/sys/cam/scsi/scsi_all.c > U /usr/src/sys/cam/scsi/scsi_all.h > U /usr/src/sys/cam/scsi/scsi_cd.c > U /usr/src/sys/cam/ata/ata_da.c > U /usr/src/sys/dev/mii/rgephyreg.h > U /usr/src/sys/dev/mii/rgephy.c > U /usr/src/sys/dev/usb/usbdevs > U /usr/src/sys/dev/usb/serial/u3g.c > U /usr/src/sys/dev/ath/if_ath_beacon.c > U /usr/src/sys/dev/ath/if_ath_rx.c > U /usr/src/sys/dev/ath/if_ath_tx.c > U /usr/src/sys/dev/ath/if_ath.c > U /usr/src/sys/dev/ath/if_athvar.h > U /usr/src/sys/dev/ath/if_ath_rx_edma.c > U /usr/src/sys/dev/ath/if_ath_tx_edma.c > U /usr/src/sys/dev/siis/siis.c > U /usr/src/sys/dev/fdt/fdt_common.c > U /usr/src/sys/dev/ahci/ahci.c > U /usr/src/sys/dev/md/md.c > U /usr/src/sys/kern/kern_physio.c > U /usr/src/sys/kern/subr_bus_dma.c > U /usr/src/sys/kern/vfs_bio.c > U /usr/src/sys/kern/subr_param.c > U /usr/src/sys/kern/uipc_usrreq.c > U /usr/src/sys/kern/uipc_socket.c > U /usr/src/sys/kern/vfs_cluster.c > U /usr/src/sys/kern/uipc_syscalls.c > U /usr/src/sys/kern/vfs_aio.c > U /usr/src/sbin/shutdown/shutdown.8 > U /usr/src/sbin/ldconfig/ldconfig.c > U /usr/src/sbin/ldconfig/ldconfig.8 > Updated to revision 248551. >=20 > I note that r248084 made some changes in src/sys/vm/ that broke > x11/nvidia-driver a few days ago, and I hacked up a patch for that > (which sbruno@ committed recently). Still, I had been running > (without incident) using that patch.... And I freely admit that > I'm far more of a hacker than a developer; I don't claim familiarity > with the VM subsystem at all. But given that nvidia-driver is > (evidently) somewhat sensitive with respect to the VM subsystem, I > would be unsurprised to find that there might be some undesirable > interactions between that and the changes kib@ recently committed > to head (e.g., r248508). >=20 > Unfortunately, I'm just about clueless as to how to get any debugging > information out of the system. >=20 > I'm open to suggestions, and willing to hack and test (and report, > of course). Did you rebuild the nvidia driver after the update ? Do you have a core dump partition configured ? Try to set vfs.unmapped_buf_allowed=3D0 at the loader prompt and see does it change anything. --2b5bRed07meAXa2o Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRSe5EAAoJEJDCuSvBvK1BkWcP/0pTeYs44z9eZEyOfnYxTRwH F/RwbbSTmvGoBSwey0YuQzd1YvxqCWJWviKyFML73u7dzXXYmmHdFfE3QUi723Qw As88mpnOMgH42SVnVpgZGSx8bO3fwXdCUzwbrewSEJ3+OHcGHFRggxHDQIv3GOMX NNNmP3Hykm0qEoYxpIy1BUO7bCrUfcC5W9sAMJUW69GKpoqb5t24eZ2rb2RcEMFo X5i6vyPulALGzsMViT+kQDdHvnqXs9k6YVE8CZCihUSEj2zSICawHz5xQRWTTu2+ OB8thetQXYD+zhJSTnTG81h+R1Rf90g8TnrcNvfdbPf8z723HwoROHe0/FCeSoek 60dVnDWK7VvHH9tIpHNaRHBy3xIWSiDpHilwdOXbr+HMw1BczQB0bbz1Q1ausOnI hdjFzSAXGqtoRpgKKv9SvodezzBl3s6lPf54P/L2eYRF/DMQziqbcSe0xA+nXxN0 +i40PMHol2pkUEvYP6nOlMbt+CyR0jZKkpy503otIiseUYcB2irCQWunwAYZxRW9 kBhKmrrMvzy35kvgajGYODVPKOYrA9/6uK6MI6vWZKoxxbmsJDmAa91iKImjVGfm 7jVVRia5u6gmH0pXsTXmVi/4P10ZNTwQNhYd1vin+NCJFJNkFSg4uJ/itARVypcs p/oUqWItQr+DXKbCVT2h =9uT4 -----END PGP SIGNATURE----- --2b5bRed07meAXa2o-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 20 17:18:14 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8645AB2F for ; Wed, 20 Mar 2013 17:18:14 +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 496C16FA for ; Wed, 20 Mar 2013 17:18:13 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.6/8.14.6) with ESMTP id r2KHIDEs041682; Wed, 20 Mar 2013 10:18:13 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.6/8.14.6/Submit) id r2KHIDBc041681; Wed, 20 Mar 2013 10:18:13 -0700 (PDT) (envelope-from david) Date: Wed, 20 Mar 2013 10:18:13 -0700 From: David Wolfskill To: Konstantin Belousov Subject: Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver Message-ID: <20130320171813.GJ32811@albert.catwhisker.org> References: <20130320160056.GG32811@albert.catwhisker.org> <20130320171340.GE3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cN519qCC4CN1mUcX" Content-Disposition: inline In-Reply-To: <20130320171340.GE3794@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 17:18:14 -0000 --cN519qCC4CN1mUcX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 20, 2013 at 07:13:41PM +0200, Konstantin Belousov wrote: > ... > > I'm open to suggestions, and willing to hack and test (and report, > > of course). >=20 > Did you rebuild the nvidia driver after the update ? Yes; src.conf includes the line: PORTS_MODULES=3Dx11/nvidia-driver > Do you have a core dump partition configured ? d129(10.0-C)[2] grep dump /etc/rc.conf=20 dumpdev=3D"AUTO" > Try to set vfs.unmapped_buf_allowed=3D0 at the loader prompt and see > does it change anything. OK; will report shortly. Thanks! Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --cN519qCC4CN1mUcX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFJ71QACgkQmprOCmdXAD35sQCcClco6hWAvi6loz2DOuE+74zk DkQAn0476ZV3bvGmUFPVLGT3upN4Wovt =HS6r -----END PGP SIGNATURE----- --cN519qCC4CN1mUcX-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 20 17:24:14 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A4B14F36 for ; Wed, 20 Mar 2013 17:24:14 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by mx1.freebsd.org (Postfix) with ESMTP id 795F8798 for ; Wed, 20 Mar 2013 17:24:14 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id j6so2104744oag.36 for ; Wed, 20 Mar 2013 10:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=fwworPv2m2+MsZosVM7mpTwMNDV4jyxUvzQnw4vdYMY=; b=KxbKCRpWIFHgVQteCqTWIcm7bwykBJ4IoBh09euIItfW3aiH/CyygQy04YctDWt6cc crLup2XUH9PKBBGVgvYwG4DUVClbCFARkX9PXl9SxbuM55q4F9oXUNNsoEBdvrY6UY8g fhAWjQCx4+TJURWao/SXW96twdnJwUXavtvkIO1yw4niT2kKSMZxfTFRwEVVD0JDntS7 7Op1u0eU9fmy//Hz7UpssW2Wp+fi7wPWC+qNqAR6lzUmm/9kuPHGEZsrS3e7inuP0TMT PlbE71RQAvDON7hZd3zIcULaHSMBai0ugohtcKEb2HnIz7ISD4G22yzmDjoYDfj6mnAH LEjw== MIME-Version: 1.0 X-Received: by 10.60.7.67 with SMTP id h3mr4679766oea.69.1363800253771; Wed, 20 Mar 2013 10:24:13 -0700 (PDT) Sender: maksim.yevmenkin@gmail.com Received: by 10.76.108.7 with HTTP; Wed, 20 Mar 2013 10:24:13 -0700 (PDT) Date: Wed, 20 Mar 2013 10:24:13 -0700 X-Google-Sender-Auth: PGVKKAASAyvhY5UlKxHz9s2CAGk Message-ID: Subject: [RFC] small VM patch to review From: Maksim Yevmenkin To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 17:24:14 -0000 hello, would anyone object to the following small patch? == Index: vm_pageout.c =================================================================== --- vm_pageout.c (revision 248560) +++ vm_pageout.c (working copy) @@ -882,14 +882,17 @@ vm_pageout_init_marker(&marker, PQ_INACTIVE); - /* - * Decrease registered cache sizes. - */ - EVENTHANDLER_INVOKE(vm_lowmem, 0); - /* - * We do this explicitly after the caches have been drained above. - */ - uma_reclaim(); + if (pass) { + /* + * Decrease registered cache sizes. + */ + EVENTHANDLER_INVOKE(vm_lowmem, 0); + /* + * We do this explicitly after the caches have + * been drained above. + */ + uma_reclaim(); + } /* * The addl_page_shortage is the number of temporarily == the idea is to not invoke lowmem handler etc. on first pass in vm_pageout_scan(). it saves a few CPU cycles on a relatively busy webserver with moderate amount of RAM serving large-ish files. thanks, max From owner-freebsd-current@FreeBSD.ORG Wed Mar 20 17:24:39 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E902F1AA for ; Wed, 20 Mar 2013 17:24:39 +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 253997B0 for ; Wed, 20 Mar 2013 17:24:38 +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 TAA05286; Wed, 20 Mar 2013 19:24:30 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <5149F0CE.2050509@FreeBSD.org> Date: Wed, 20 Mar 2013 19:24:30 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130313 Thunderbird/17.0.4 MIME-Version: 1.0 To: David Wolfskill Subject: Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver References: <20130320160056.GG32811@albert.catwhisker.org> <20130320171340.GE3794@kib.kiev.ua> <20130320171813.GJ32811@albert.catwhisker.org> In-Reply-To: <20130320171813.GJ32811@albert.catwhisker.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 17:24:40 -0000 on 20/03/2013 19:18 David Wolfskill said the following: > Yes; src.conf includes the line: > > PORTS_MODULES=x11/nvidia-driver Have you double-checked that this actually works according to your intention? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Mar 20 17:37:59 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CF9B652D for ; Wed, 20 Mar 2013 17:37:59 +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 8F48485F for ; Wed, 20 Mar 2013 17:37:59 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.6/8.14.6) with ESMTP id r2KHbxHR041778; Wed, 20 Mar 2013 10:37:59 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.6/8.14.6/Submit) id r2KHbxb0041777; Wed, 20 Mar 2013 10:37:59 -0700 (PDT) (envelope-from david) Date: Wed, 20 Mar 2013 10:37:59 -0700 From: David Wolfskill To: Konstantin Belousov Subject: Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver Message-ID: <20130320173759.GK32811@albert.catwhisker.org> References: <20130320160056.GG32811@albert.catwhisker.org> <20130320171340.GE3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rnP2AJ7yb1j09OW/" Content-Disposition: inline In-Reply-To: <20130320171340.GE3794@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 17:37:59 -0000 --rnP2AJ7yb1j09OW/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 20, 2013 at 07:13:41PM +0200, Konstantin Belousov wrote: > ... > Did you rebuild the nvidia driver after the update ? > Do you have a core dump partition configured ? (I note that I have, in the past, captured crash dumps from head running on this machine with this configuration.) > Try to set vfs.unmapped_buf_allowed=3D0 at the loader prompt and see > does it change anything. OK; I tried this, then booted without attempting to start X in any way. I then logged in as root and verified that sysctl vfs.unmapped_buf_allowed reported "0". I then issued "kldload nvidia.ko" (and verified that it was loaded via kldstat). I then started xdm, and (as before), got an unclean reboot. (So: no difference in behavior as far as I can tell.) Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --rnP2AJ7yb1j09OW/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFJ8/YACgkQmprOCmdXAD03mACaAzJmGdhvbrC3D6If4Wuy84At 6fwAniEq9lOO9xB8e3FVlmnM7sCUWOx1 =TyCa -----END PGP SIGNATURE----- --rnP2AJ7yb1j09OW/-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 20 17:45:07 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EAFF272E for ; Wed, 20 Mar 2013 17:45:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 5C0B28B6 for ; Wed, 20 Mar 2013 17:45:07 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2KHiwwP053738; Wed, 20 Mar 2013 19:44:58 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2KHiwwP053738 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2KHiwGL053737; Wed, 20 Mar 2013 19:44:58 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 20 Mar 2013 19:44:58 +0200 From: Konstantin Belousov To: David Wolfskill Subject: Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver Message-ID: <20130320174458.GG3794@kib.kiev.ua> References: <20130320160056.GG32811@albert.catwhisker.org> <20130320171340.GE3794@kib.kiev.ua> <20130320173759.GK32811@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MOlTsKDG63roIlK2" Content-Disposition: inline In-Reply-To: <20130320173759.GK32811@albert.catwhisker.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 17:45:08 -0000 --MOlTsKDG63roIlK2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 20, 2013 at 10:37:59AM -0700, David Wolfskill wrote: > On Wed, Mar 20, 2013 at 07:13:41PM +0200, Konstantin Belousov wrote: > > ... > > Did you rebuild the nvidia driver after the update ? > > Do you have a core dump partition configured ? >=20 > (I note that I have, in the past, captured crash dumps from head running > on this machine with this configuration.) >=20 > > Try to set vfs.unmapped_buf_allowed=3D0 at the loader prompt and see > > does it change anything. >=20 > OK; I tried this, then booted without attempting to start X in any way. > I then logged in as root and verified that >=20 > sysctl vfs.unmapped_buf_allowed >=20 > reported "0". >=20 > I then issued "kldload nvidia.ko" (and verified that it was loaded via > kldstat). >=20 > I then started xdm, and (as before), got an unclean reboot. (So: no > difference in behavior as far as I can tell.) Ok. The best idea I have right now is to rebuild the nvidia.ko. Do you have a firewire port on the laptop ? --MOlTsKDG63roIlK2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRSfWZAAoJEJDCuSvBvK1BQCoQAISCviZTt6XOEBDXlluk6th3 Bd78OI5qC/IwH4MQfBvp2H1tYCYgMZvFWSG7zD85x5ziPalh4dI3FgD1PpQB7kGe VPag1y6CIYQSDkBB4I93zDnNAfgShgRcnsy12G9bTQmSnHxNRh4PCaerNVdfjNkE QCzw96Q84NC47mAzC9WCuYwBebSDVy48c+pBvpGc8Ez56WBKqGhJ5YE6fUXbOvnv lalfbuowGbehyM8d1w027wDkDhqsSsv1vx891knWFsXwfABGCTFsy7elCq4cWFEZ Tv9oJoq3m6oXSnQBlSB5VJFuppg+XHSloAw1wCfTLl7Pbi1KugeIORiXs/xr2aAU 3snfjFuQH5VaEqQT2d248e/xNHD6DxDmU/N3uQ8rST+w5/bCmDg/ZvBaYrHmvtL1 dbrQOlzSwUYPjnMHDk7fn84gsKotfsRrJQ5t3834/Dq8vE+b3F07J726RnsjoreB cKwcgL0F1P8DofRYylAS6WNlMZv7oK8JimHFkDqWVm/646Doedr9Q2C5OcAoUxhX QVhpDChLDrKOx2TrhriiLtoeiap6xPtjLhJwu6l1+1KYBv5FOvOKZ0RrgoeY9Lgp 7wu9oHEFuMZ8kMdIoWLOqWqdp2SLlREEJkPykCTCYDtWmCdYBGFcZyYCkTQQyQjB 8/xyJsehBq/k0+08f+zD =g7EN -----END PGP SIGNATURE----- --MOlTsKDG63roIlK2-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 20 17:51:44 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6733E961; Wed, 20 Mar 2013 17:51:44 +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 2B1B28FB; Wed, 20 Mar 2013 17:51:43 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.6/8.14.6) with ESMTP id r2KHph2f041837; Wed, 20 Mar 2013 10:51:43 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.6/8.14.6/Submit) id r2KHphQo041836; Wed, 20 Mar 2013 10:51:43 -0700 (PDT) (envelope-from david) Date: Wed, 20 Mar 2013 10:51:43 -0700 From: David Wolfskill To: Andriy Gapon Subject: Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver Message-ID: <20130320175143.GL32811@albert.catwhisker.org> References: <20130320160056.GG32811@albert.catwhisker.org> <20130320171340.GE3794@kib.kiev.ua> <20130320171813.GJ32811@albert.catwhisker.org> <5149F0CE.2050509@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YIleam+9adpUeYf+" Content-Disposition: inline In-Reply-To: <5149F0CE.2050509@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 17:51:44 -0000 --YIleam+9adpUeYf+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 20, 2013 at 07:24:30PM +0200, Andriy Gapon wrote: > on 20/03/2013 19:18 David Wolfskill said the following: > > Yes; src.conf includes the line: > >=20 > > PORTS_MODULES=3Dx11/nvidia-driver >=20 > Have you double-checked that this actually works according to your intent= ion? > ... Until I started specifying that, the attempt to load nvidia.ko would fail (under head), as the module resides in /boot/modules. Note that I have the (single) drive on this machine split into 4 bootable slices, each of which has its own root and /usr file system. (Slice 4 has the partitions that are "common" to all images -- one for swap; another for the /var FS; one for local SVN mirrors mounted on /repo; one for miscellaneous stuff, such as home directories, ports tree, and /usr/local, which I mount under /common. There's another FS called /bkp, but it's not actually used for much usually.) Since /usr/local is the same FS regardless of which slice is booted (thanks to symlinks), I build the ports under stable/9 (which is on slice 1). On the other hand, head is on slice 4. So building x11/nvidia-driver would populate /usr/local/lib and slice 1's /boot/modules, but would not populate any other slice's /boot/*. This is something I have been doing (in the general sense of multiple bootable slices) for over a decade, and have been doing it for x11/nvidia-driver (in particular) for a few years. I have been tracking stable/9 & head daily for quite a while (years -- note the iteration number in the uname output), and after the smoke-test for stable/9, I update all installed ports that have been updated in the last 24 hrs. -- daily. Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --YIleam+9adpUeYf+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFJ9y4ACgkQmprOCmdXAD0/AgCfWRK9SUsNHezlHcKmPrSSp2Ur Pb4AnA1NQW2iLfAGRJKuY+cuxdtPM7i0 =x0Ag -----END PGP SIGNATURE----- --YIleam+9adpUeYf+-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 20 17:53:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 07E0BA82 for ; Wed, 20 Mar 2013 17:53:18 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-ee0-f51.google.com (mail-ee0-f51.google.com [74.125.83.51]) by mx1.freebsd.org (Postfix) with ESMTP id 801CA919 for ; Wed, 20 Mar 2013 17:53:16 +0000 (UTC) Received: by mail-ee0-f51.google.com with SMTP id d17so1234838eek.38 for ; Wed, 20 Mar 2013 10:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=C4DuI16kVOdB7F8vX9753AgBpqK/UFoXGOsKb+BlTs0=; b=S7Apiu/9/qIR4YpxW18OnWf0v+o8zawouFeQTDbc3XNskOK4PTiV3VzghXeu+aWpeB +hVW4Mq1HQb5O0V5E++kcs7lLlF90Ms8cr1hGVfThKnqrA8iOvOoQe1f+2dY3LUMzXZR 9bMbLIVPH2c50VDyrOHr6+5jaZPphMk/vMhSf8+pnZwiAYCu6XO5LGf6cTFkTqr6awsC jSLBLVEDiSJCxyLCDQzPPaKT1SkBO+Zt6burVcb+JNm0jaenzEwU/ZGu8ayzBLd8QZ0l PTZPBxNVAiCo6UCicL+1iiuVxx9KHN5iLZevgII8VZni0DHJ407N0gHtKZiF4IHiye4O vcZg== X-Received: by 10.14.5.6 with SMTP id 6mr74002027eek.42.1363801989789; Wed, 20 Mar 2013 10:53:09 -0700 (PDT) Received: from [192.168.1.80] (91EC574C.dsl.pool.telekom.hu. [145.236.87.76]) by mx.google.com with ESMTPS id 3sm3997213eej.6.2013.03.20.10.53.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Mar 2013 10:53:08 -0700 (PDT) Message-ID: <5149F77F.2000900@gmail.com> Date: Wed, 20 Mar 2013 18:53:03 +0100 From: deeptech71 User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:18.0) Gecko/20100101 SeaMonkey/2.15 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: access to hard drives is "blocked" by writes to a flash drive References: <201303040301.r2431Rjm008175@gw.catspoiler.org> <51341AA6.7080601@gmail.com> <20130319172617.GA44701@blazingdot.com> In-Reply-To: <20130319172617.GA44701@blazingdot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 17:53:18 -0000 On 03/19/2013 18:26, Marcus Reid wrote: > On Mon, Mar 04, 2013 at 04:53:10AM +0100, deeptech71 wrote: > I use atimes all the time to get to the bottom of lots of common > problems. Details ! It sounds like in your case, atime is a debugging feature (which are generally to be turned off on production systems). > Turning off atime system-wide is a really bad move. Your bikeshed. Turning off atime works for me. SUPPORT_ATIME=0 would be an *optional* kernel option. Additionally a DEFAULT_NOATIME=1 may be provided. From owner-freebsd-current@FreeBSD.ORG Wed Mar 20 17:57:16 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E87B7E46 for ; Wed, 20 Mar 2013 17:57:16 +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 C7C2F953 for ; Wed, 20 Mar 2013 17:57:16 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.6/8.14.6) with ESMTP id r2KHvGjr041914; Wed, 20 Mar 2013 10:57:16 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.6/8.14.6/Submit) id r2KHvGCE041913; Wed, 20 Mar 2013 10:57:16 -0700 (PDT) (envelope-from david) Date: Wed, 20 Mar 2013 10:57:16 -0700 From: David Wolfskill To: Konstantin Belousov Subject: Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver Message-ID: <20130320175716.GM32811@albert.catwhisker.org> References: <20130320160056.GG32811@albert.catwhisker.org> <20130320171340.GE3794@kib.kiev.ua> <20130320173759.GK32811@albert.catwhisker.org> <20130320174458.GG3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HVCoas+krw6dou6l" Content-Disposition: inline In-Reply-To: <20130320174458.GG3794@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 17:57:17 -0000 --HVCoas+krw6dou6l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 20, 2013 at 07:44:58PM +0200, Konstantin Belousov wrote: > ... > > I then started xdm, and (as before), got an unclean reboot. (So: no > > difference in behavior as far as I can tell.) >=20 > Ok. The best idea I have right now is to rebuild the nvidia.ko. Again? OK.... > Do you have a firewire port on the laptop ? I do: ... none2@pci0:3:1:1: class=3D0x0c0010 card=3D0x02501028 chip=3D0x08321180 rev= =3D0x04 hdr=3D0x00 vendor =3D 'Ricoh Co Ltd' device =3D 'R5C832 IEEE 1394 Controller' class =3D serial bus subclass =3D FireWire ... On the other hand, I'm less sure about any other machines around, or cables that would work. Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --HVCoas+krw6dou6l Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFJ+HsACgkQmprOCmdXAD3x/wCfbsvsel4evJ5eqSD+JfaUm8Bh 4gEAn3cwicIdJmwGUoNWAYmFyNV8qqoN =rp/A -----END PGP SIGNATURE----- --HVCoas+krw6dou6l-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 20 18:02:39 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EECE3CB for ; Wed, 20 Mar 2013 18:02:39 +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 BFF459A5 for ; Wed, 20 Mar 2013 18:02:39 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.6/8.14.6) with ESMTP id r2KI2dsU041965; Wed, 20 Mar 2013 11:02:39 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.6/8.14.6/Submit) id r2KI2dx6041964; Wed, 20 Mar 2013 11:02:39 -0700 (PDT) (envelope-from david) Date: Wed, 20 Mar 2013 11:02:39 -0700 From: David Wolfskill To: Konstantin Belousov Subject: Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver Message-ID: <20130320180239.GN32811@albert.catwhisker.org> References: <20130320160056.GG32811@albert.catwhisker.org> <20130320171340.GE3794@kib.kiev.ua> <20130320173759.GK32811@albert.catwhisker.org> <20130320174458.GG3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/TUrtqMIkCP4YtJm" Content-Disposition: inline In-Reply-To: <20130320174458.GG3794@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 18:02:40 -0000 --/TUrtqMIkCP4YtJm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 20, 2013 at 07:44:58PM +0200, Konstantin Belousov wrote: > ... > Ok. The best idea I have right now is to rebuild the nvidia.ko. OK; I did this: After rebooting (without attempting to either load nvidia.ko or start X in any way), I issued: sudo portmaster x11/nvidia-driver which rebuilt & reinstalled the driver. I then loaded nvidia.ko, and started xdm -- and as before, the machine performed a fairly hard reset. Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --/TUrtqMIkCP4YtJm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFJ+b4ACgkQmprOCmdXAD1XVwCfdUtkL4LwVMp7rStTa4XTH4pv qHEAn3OYoyn8bLU8iZDNqyFGeHVjK9gj =CvFW -----END PGP SIGNATURE----- --/TUrtqMIkCP4YtJm-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 20 18:43:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C57CEACE; Wed, 20 Mar 2013 18:43:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id A49D9D2B; Wed, 20 Mar 2013 18:43:56 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D5F99B939; Wed, 20 Mar 2013 14:43:55 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: mountroot event Date: Wed, 20 Mar 2013 09:30:00 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <514973A3.9030706@FreeBSD.org> In-Reply-To: <514973A3.9030706@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201303200930.01080.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 20 Mar 2013 14:43:55 -0400 (EDT) Cc: freebsd-hackers@freebsd.org, Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 18:43:56 -0000 On Wednesday, March 20, 2013 4:30:27 am Andriy Gapon wrote: > > I would like to propose the following change. > > My understanding is that it was never a true intention to post 'mountroot' event > on every set_rootvnode() call, but rather an accident in the original commit. > But I could be wrong here. In either case I think that it is more appropriate > to post the event only once. I do not expect that there could be any consumers > interested in all the details of root fs manipulations. The firmware code only needs the final call for the "real" root. I think your change is fine. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Mar 20 18:54:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6DFE228B for ; Wed, 20 Mar 2013 18:54:59 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-ee0-f51.google.com (mail-ee0-f51.google.com [74.125.83.51]) by mx1.freebsd.org (Postfix) with ESMTP id D4B48DE7 for ; Wed, 20 Mar 2013 18:54:58 +0000 (UTC) Received: by mail-ee0-f51.google.com with SMTP id d17so1293004eek.24 for ; Wed, 20 Mar 2013 11:54:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=g6mTi3rxQ3UQx5wUU7On5kVpH5bd+V8zCUGqXWQ5o4U=; b=WAk3RX3ZhEnYzqkvuO+J9eeZkl9Zm8eisdzY3pGhvhdhbFJj2cQWPiLVLDeqdZX0M3 VS9H9qJnmWTH6dzIO3k8TluRuAM48L6xxyo9darHPGj988+BWgpNuTM0SXnIYs62wBqo A9EhyUSJh83yzdm/QSxzfw2JnC6k89jjbuCUeVYvKf+hK9tztHbTVwI5UaIW3rInsPEe xKyjR25Zj+l5T2A3VzcaCUCrhhFLy98nFwgaMb6t7l3CDLa/Md5V3/MU4aAuX2UsFF5y 2vU6hIXRRAEe//4SdHkA7LyG69oxoH74OwSCoOJm+7yUZe9RUt9quGey70dNis6wZ3/C jDjw== X-Received: by 10.14.182.137 with SMTP id o9mr74101946eem.13.1363805697752; Wed, 20 Mar 2013 11:54:57 -0700 (PDT) Received: from [192.168.1.80] (91EC574C.dsl.pool.telekom.hu. [145.236.87.76]) by mx.google.com with ESMTPS id m46sm4287236eeo.16.2013.03.20.11.54.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Mar 2013 11:54:56 -0700 (PDT) Message-ID: <514A05FB.7020608@gmail.com> Date: Wed, 20 Mar 2013 19:54:51 +0100 From: deeptech71 User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:18.0) Gecko/20100101 SeaMonkey/2.15 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: net/xmlrpc-c-devel port with GCC 4.8 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 18:54:59 -0000 /usr/local/bin/g++48 -o test test.o base64.o registry.o server_abyss.o server_pstream.o tools.o value.o xml.o testclient.o /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/src/cpp/libxmlrpc_server_abyss++.a /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/src/cpp/libxmlrpc_server_pstream++.a /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/src/cpp/libxmlrpc_server++.a /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/src/cpp/libxmlrpc_client++.a /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/src/libxmlrpc_client.a /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/src/cpp/libxmlrpc++.a /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/src/cpp/libxmlrpc_cpp.a /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/src/libxmlrpc_server_abyss.a /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/src/libxmlrpc_server.a /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/src/libxmlrpc.a /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/lib/abyss/src/libxmlrpc_abyss.a /u s r/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/src/cpp/libxmlrpc_packetsocket.a /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/lib/libutil/libxmlrpc_util.a /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/lib/expat/xmlparse/libxmlrpc_xmlparse.a /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/lib/expat/xmltok/libxmlrpc_xmltok.a -pthread /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/src/libxmlrpc_client.a /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/src/libxmlrpc.a /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/lib/expat/xmlparse/libxmlrpc_xmlparse.a /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/lib/expat/xmltok/libxmlrpc_xmltok.a /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/lib/libutil/libxmlrpc_util.a -L/usr/local/lib -lcurl -Wl,-rpath=/usr/lib:/usr/local/lib -L/usr/local/lib -lssh2 -lssl -lcrypto -lz -lssh2 -L/usr/local/lib -lwwwxml -lxmltok -lxmlparse -lwwwzip -lwwwssl -lwwwinit -lwwwapp -lwwwhtml -lwwwtelnet -lwwwnews -lwwwhttp -lww w mime -lwwwgopher -lwwwftp -lwwwfile -lwwwdir -lwwwcache -lwwwstream -lwwwmux -lwwwtrans -lwwwcore -lwwwutils -lmd5 -lz -L/usr/lib -lssl -lcrypto [...] /usr/local/lib/gcc48/include/c++/bits/locale_facets.h:869: undefined reference to `std::ctype::_M_widen_init() const' [...] /usr/local/lib/gcc48/include/c++/bits/stl_list.h:1550: undefined reference to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)' [...] I worked around this by adding "/usr/local/lib/gcc48/libstdc++.so" to the make-rule. Weird. Why does this work? Should it? From owner-freebsd-current@FreeBSD.ORG Wed Mar 20 19:49:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 19C16F4 for ; Wed, 20 Mar 2013 19:49:56 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id D6F7BF6 for ; Wed, 20 Mar 2013 19:49:55 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::71ee:ef04:1f42:971d] (unknown [IPv6:2001:7b8:3a7:0:71ee:ef04:1f42:971d]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id DD3005C5B; Wed, 20 Mar 2013 20:49:53 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: net/xmlrpc-c-devel port with GCC 4.8 From: Dimitry Andric In-Reply-To: <514A05FB.7020608@gmail.com> Date: Wed, 20 Mar 2013 20:49:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <45FF4CDD-66C2-4AA5-8A8D-B39677A4D6B1@FreeBSD.org> References: <514A05FB.7020608@gmail.com> To: deeptech71 X-Mailer: Apple Mail (2.1503) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 19:49:56 -0000 On Mar 20, 2013, at 19:54, deeptech71 wrote: > /usr/local/lib/gcc48/include/c++/bits/locale_facets.h:869: undefined = reference to `std::ctype::_M_widen_init() const' > [...] > /usr/local/lib/gcc48/include/c++/bits/stl_list.h:1550: undefined = reference to = `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'= > [...] >=20 > I worked around this by adding "/usr/local/lib/gcc48/libstdc++.so" to = the make-rule. Weird. Why does this work? Should it? The link step is erroneously pulling in /usr/lib/libstdc++.so by default. Since that is an older version of libstdc++, it does not contain the symbols you listed. As you saw, forcing the link stage to use gcc 4.8's version of libstdc++ at least produces an executable. However, there is very likely still a problem at runtime, because the resulting executable probably does not have the correct rpath entry. This is a general problem with the gcc ports: they should all pull in their own version(s) of libstdc++.so instead of using the default linker path. And possibly add rpath entries, to make sure the correct version of libstdc++.so is used at runtime. From owner-freebsd-current@FreeBSD.ORG Wed Mar 20 20:09:07 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E8FCD42E for ; Wed, 20 Mar 2013 20:09:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 79C7F1AC for ; Wed, 20 Mar 2013 20:09:07 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2KK8wwZ083815; Wed, 20 Mar 2013 22:08:58 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2KK8wwZ083815 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2KK8vVA083814; Wed, 20 Mar 2013 22:08:57 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 20 Mar 2013 22:08:57 +0200 From: Konstantin Belousov To: David Wolfskill Subject: Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver Message-ID: <20130320200857.GN3794@kib.kiev.ua> References: <20130320160056.GG32811@albert.catwhisker.org> <20130320171340.GE3794@kib.kiev.ua> <20130320173759.GK32811@albert.catwhisker.org> <20130320174458.GG3794@kib.kiev.ua> <20130320180239.GN32811@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BlSXMmufQQBIrxDX" Content-Disposition: inline In-Reply-To: <20130320180239.GN32811@albert.catwhisker.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 20:09:08 -0000 --BlSXMmufQQBIrxDX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 20, 2013 at 11:02:39AM -0700, David Wolfskill wrote: > On Wed, Mar 20, 2013 at 07:44:58PM +0200, Konstantin Belousov wrote: > > ... > > Ok. The best idea I have right now is to rebuild the nvidia.ko. >=20 > OK; I did this: After rebooting (without attempting to either load > nvidia.ko or start X in any way), I issued: >=20 > sudo portmaster x11/nvidia-driver >=20 > which rebuilt & reinstalled the driver. >=20 > I then loaded nvidia.ko, and started xdm -- and as before, the machine > performed a fairly hard reset. I looked at the nvidia sources to check that the driver does not use the interfaces which KBI was changed, and this is indeed the case, as expected. I must admit that I have no idea why buffer cache changes could affect nvidia driver, and with no input on the panic (I hope that it is panic, and not a reset) have no idea even to speculate. So firewire cable is probably the must. Note that I split that import of the work into the series of commits. The split was done to ease the reading of the chunks, and individual commits were not functionally tested. Still, you might try to do the bisect. --BlSXMmufQQBIrxDX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRShdZAAoJEJDCuSvBvK1BkyAP/0eYepmislGuLChxPFuiybsT VkRdDsmsWR2dIwFeFhoSkGgE5WIjm5hI0GnavlPWHY3yTFCn07o6OLHXUu1YZWFE 2xliQJzUUwuCjp/zDnyW2tnCMo8/VGKShZn+ruOBvOphe9dfx2nuV0PHF4OAPb4e PowN2nFWO5OmDEHZZoF5POrRJn3Id6JKkhzE2tR1EOHKNGvStuNe5E7MvLfhqWYV VzUnMgK6a72vOYfC6tClOAYjWarNzZkcmK9Em8UyWuG1oNT0YJbFphmhShGrTJ0V bJ/GN4nDdHPjCUa5nr1XsYyElDv1ibHLx82rhSM0ZZsW+yIY0LlnW21MNk5aWEur 8z16s3B1Ls5AQtqYZWDX+yzdrUS9lqy6BGKkSPZeavrltiDdXRlp4/nwQ9LbOW6E X8ioBmmGpPXHQoOQGt1DqBhRlNMMv4yOfSdsvaOv6yzkdg9SYmGOZ+1m95GQvMdp N4AFFWbDOuVGywkL1ucovgsflVEKmqcBKXlHVLlSYZBaggXQmU1QXpnrStCKEPtx UroRubsCzd58+X1CP4HuzVPQ3xo+hSlQk+PYtU1xR4FX+5pZFzDUQN6/hgirtUlZ 6NXQJNBzygQiryP6KCGV1eEvvT1e2iTtAnQyY/BiVfTZBRULYWgfowj3hYBd84Fb WC0OVQfh0iGslpLlmLG1 =MFGk -----END PGP SIGNATURE----- --BlSXMmufQQBIrxDX-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 20 20:13:25 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9EFEF5B6 for ; Wed, 20 Mar 2013 20:13:25 +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 798B71E3 for ; Wed, 20 Mar 2013 20:13:25 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.6/8.14.6) with ESMTP id r2KKDOJc042758; Wed, 20 Mar 2013 13:13:24 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.6/8.14.6/Submit) id r2KKDOp7042757; Wed, 20 Mar 2013 13:13:24 -0700 (PDT) (envelope-from david) Date: Wed, 20 Mar 2013 13:13:24 -0700 From: David Wolfskill To: Konstantin Belousov Subject: Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver Message-ID: <20130320201324.GP32811@albert.catwhisker.org> References: <20130320160056.GG32811@albert.catwhisker.org> <20130320171340.GE3794@kib.kiev.ua> <20130320173759.GK32811@albert.catwhisker.org> <20130320174458.GG3794@kib.kiev.ua> <20130320180239.GN32811@albert.catwhisker.org> <20130320200857.GN3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FRaepaAnLTQkJ4tS" Content-Disposition: inline In-Reply-To: <20130320200857.GN3794@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 20:13:25 -0000 --FRaepaAnLTQkJ4tS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 20, 2013 at 10:08:57PM +0200, Konstantin Belousov wrote: > ... > I looked at the nvidia sources to check that the driver does not use > the interfaces which KBI was changed, and this is indeed the case, as > expected. OK; thank you for checking & reporting. > I must admit that I have no idea why buffer cache changes could affect > nvidia driver, and with no input on the panic (I hope that it is panic, > and not a reset) have no idea even to speculate. So firewire cable is > probably the must. OK. > Note that I split that import of the work into the series of commits. > The split was done to ease the reading of the chunks, and individual > commits were not functionally tested. Still, you might try to do the > bisect. OK; I'll see what I can do. (It's a little awkward, as I use the laptop to access ... well, just about everything.) Thanks again! Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --FRaepaAnLTQkJ4tS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFKGGMACgkQmprOCmdXAD0mggCeIufDTr241IQSSu4mhEPr5Oi7 cC0AoISH1y7q9HsNZIT3jkbzldps95Lx =7dh+ -----END PGP SIGNATURE----- --FRaepaAnLTQkJ4tS-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 20 21:17:25 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A514C81A for ; Wed, 20 Mar 2013 21:17:25 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 1B64A650 for ; Wed, 20 Mar 2013 21:17:24 +0000 (UTC) Received: by mail-la0-f46.google.com with SMTP id fq12so3880033lab.33 for ; Wed, 20 Mar 2013 14:17:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=yJmio1D2a7dzM/tvnHE665B48f4cx9Coj03Kq6I6JPc=; b=mvzAO/SPokS+1/NxKFoCPcDsQnKa0CvHy1jhqwSij8/ItNsawe5YXnnKHh8KPf1ici ctOyMT5cJTsv7o6P41MG6FbYoiDjlZguHoK5mzZCTUutP1/tpSpbuCprEwGVxEtV/cz4 vW08e4qFHMJQUC0kMTAO52bDEWDLCLkLw2P87Nt/6A/U5uvegf3SbXZJQ5eLLRL139i9 14lRKF4RSrHM3AbecHRajcsr/z0iFV1CmPv/PObvrbhuS4cZJ1AP+RMRil3hEYyv6U1F 5E7yheodb/3rNrpjxquUjWkQEI+KMTixKwqsCg7sQTRPAZf3zQVyDEt9DlEi4x50dj5q ozyA== MIME-Version: 1.0 X-Received: by 10.152.123.34 with SMTP id lx2mr6289664lab.52.1363814244053; Wed, 20 Mar 2013 14:17:24 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.85.198 with HTTP; Wed, 20 Mar 2013 14:17:23 -0700 (PDT) In-Reply-To: <20130320201324.GP32811@albert.catwhisker.org> References: <20130320160056.GG32811@albert.catwhisker.org> <20130320171340.GE3794@kib.kiev.ua> <20130320173759.GK32811@albert.catwhisker.org> <20130320174458.GG3794@kib.kiev.ua> <20130320180239.GN32811@albert.catwhisker.org> <20130320200857.GN3794@kib.kiev.ua> <20130320201324.GP32811@albert.catwhisker.org> Date: Wed, 20 Mar 2013 14:17:23 -0700 X-Google-Sender-Auth: CcYZcZbpVqC8WW4KiH76hOk2ap8 Message-ID: Subject: Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver From: Craig Rodrigues To: David Wolfskill Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Konstantin Belousov , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 21:17:25 -0000 I would advise that you try the following: (1) On a machine which is not your laptop, build a CURRENT chroot (2) Follow the instructions at: http://www.freebsd.org/doc/handbook/network-pxe-nfs.html to NFS export the chroot and set up a TFTP server. (3) Set up your laptop to PXE boot using (2). This is one quick way you can test your laptop with CURRENT, without installing all the bits on the disk of your laptop. -- Craig On Wed, Mar 20, 2013 at 1:13 PM, David Wolfskill wrote: > On Wed, Mar 20, 2013 at 10:08:57PM +0200, Konstantin Belousov wrote: > > ... > > I looked at the nvidia sources to check that the driver does not use > > the interfaces which KBI was changed, and this is indeed the case, as > > expected. > > OK; thank you for checking & reporting. > > > I must admit that I have no idea why buffer cache changes could affect > > nvidia driver, and with no input on the panic (I hope that it is panic, > > and not a reset) have no idea even to speculate. So firewire cable is > > probably the must. > > OK. > > > Note that I split that import of the work into the series of commits. > > The split was done to ease the reading of the chunks, and individual > > commits were not functionally tested. Still, you might try to do the > > bisect. > > OK; I'll see what I can do. (It's a little awkward, as I use the laptop > to access ... well, just about everything.) > > Thanks again! > > Peace, > david > -- > David H. Wolfskill david@catwhisker.org > Taliban: Evil men with guns afraid of truth from a 14-year old girl. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. > -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Wed Mar 20 22:56:30 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D6C983E2; Wed, 20 Mar 2013 22:56:30 +0000 (UTC) (envelope-from christoph_hoffmann@me.com) Received: from nk11p04mm-asmtp001.mac.com (nk11p04mm-asmtpout001.mac.com [17.158.236.236]) by mx1.freebsd.org (Postfix) with ESMTP id C06869B8; Wed, 20 Mar 2013 22:56:30 +0000 (UTC) Received: from tunnel8.sec101.ch ([62.2.44.120]) by nk11p04mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-26.01(7.0.4.26.0) 64bit (built Jul 13 2012)) with ESMTPSA id <0MJZ0070WBLK0I80@nk11p04mm-asmtp001.mac.com>; Wed, 20 Mar 2013 21:56:12 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-03-20_06:2013-03-20,2013-03-20,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=4 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1302030000 definitions=main-1303200197 Subject: Re: gptzfsboot problem on HP P410i Smart Array MIME-version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-type: text/plain; charset=us-ascii From: Christoph Hoffmann In-reply-to: <201303191220.34088.jhb@freebsd.org> Date: Wed, 20 Mar 2013 22:56:07 +0100 Content-transfer-encoding: quoted-printable Message-id: References: <51483621.2060503@FreeBSD.org> <201303191220.34088.jhb@freebsd.org> To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.1503) Cc: Bjorn Larsson , Sergey Dyatko , Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 22:56:30 -0000 Dear All, At present I do not have access to a HP box with a SmartArray=20 but zfsboot works perfectly with FreeBSD 9.1-RELEASE #0 r245668=20 (including EDD fix) on: hpiLO-> show system1 [...] Properties name=3DProLiant DL160 Gen8 [...] with the following firmware hpiLO-> show system1/firmware1=20 [...] /system1/firmware1 Targets Properties version=3DJ03 date=3D08/20/2012 [...] I know it is not much help, but hope it might give you=20 some input.=20 Thank you very much indeed for your work on this issue. Best Regards, Christoph -- Christoph Hoffmann e-mail: christoph_hoffmann@me.com On Mar 19, 2013, at 5:20 PM, John Baldwin wrote: > On Tuesday, March 19, 2013 5:55:45 am Andriy Gapon wrote: >> on 19/03/2013 07:41 Sergey Dyatko said the following: >>> I was faced with same problem on my laptop. Adding printf() into = main() >>> before dsk =3D malloc(sizeof(struct dsk)); fix boot. Yesterday, avg@ = proposed >>> patch: >>> Index: /usr/src/sys/boot/i386/zfsboot/zfsboot.c >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- /usr/src/sys/boot/i386/zfsboot/zfsboot.c (revision 248421) >>> +++ /usr/src/sys/boot/i386/zfsboot/zfsboot.c (working copy) >>> @@ -302,6 +302,7 @@ >>> * region in the SMAP, use the last 3MB of 'extended' memory as = a >>> * high heap candidate. >>> */ >>> + high_heap_size =3D 0; >>> if (bios_extmem >=3D HEAP_MIN && high_heap_size < HEAP_MIN) { >>> high_heap_size =3D HEAP_MIN; >>> high_heap_base =3D bios_extmem + 0x100000 - HEAP_MIN; >>>=20 >>> it works for me, without printf() :) Can you test it ? >>=20 >> A comment about a nature of this patch. >>=20 >> Based on the previous investigation by Christoph Hoffmann and jhb: >> http://thread.gmane.org/gmane.os.freebsd.current/134199/focus=3D134309 >> I made a guess that either BIOS/firmware provides incorrect memory = map or some >> agent in the BIOS/firmware (e.g. SMM handler) or controller firmware = writes >> outside of a memory range reserved for it. >> I think that jhb made a similar guess at the time while Christoph = conjectured >> that memory corruption was related to CPU caches or some such. >> My conjecture is that it is simply a combination of timing and a = particular >> memory range. >>=20 >> Just in case, here is how the memory map looks on the Sergey's = system: >> SMAP type=3D01 base=3D0000000000000000 end=3D000000000009fc00 = len=3D000000000009fc00 >> SMAP type=3D02 base=3D000000000009fc00 end=3D00000000000a0000 = len=3D0000000000000400 >> SMAP type=3D02 base=3D00000000000e0000 end=3D0000000000100000 = len=3D0000000000020000 >> SMAP type=3D01 base=3D0000000000100000 end=3D00000000bc1a1000 = len=3D00000000bc0a1000 >> SMAP type=3D04 base=3D00000000bc1a1000 end=3D00000000bc1a4000 = len=3D0000000000003000 >> SMAP type=3D01 base=3D00000000bc1a4000 end=3D00000000bdf04000 = len=3D0000000001d60000 >> SMAP type=3D04 base=3D00000000bdf04000 end=3D00000000bdf3f000 = len=3D000000000003b000 >> SMAP type=3D01 base=3D00000000bdf3f000 end=3D00000000bdf6a000 = len=3D000000000002b000 >> SMAP type=3D02 base=3D00000000bdf6a000 end=3D00000000bdfbf000 = len=3D0000000000055000 >> SMAP type=3D01 base=3D00000000bdfbf000 end=3D00000000bdfeb000 = len=3D000000000002c000 >> SMAP type=3D03 base=3D00000000bdfeb000 end=3D00000000bdfff000 = len=3D0000000000014000 >> SMAP type=3D01 base=3D00000000bdfff000 end=3D00000000be000000 = len=3D0000000000001000 >> SMAP type=3D02 base=3D00000000be000000 end=3D00000000c0000000 = len=3D0000000002000000 >> SMAP type=3D02 base=3D00000000f8000000 end=3D00000000fc000000 = len=3D0000000004000000 >> SMAP type=3D02 base=3D00000000fec00000 end=3D00000000fec01000 = len=3D0000000000001000 >> SMAP type=3D02 base=3D00000000fed10000 end=3D00000000fed14000 = len=3D0000000000004000 >> SMAP type=3D02 base=3D00000000fed18000 end=3D00000000fed1a000 = len=3D0000000000002000 >> SMAP type=3D02 base=3D00000000fed1c000 end=3D00000000fed20000 = len=3D0000000000004000 >> SMAP type=3D02 base=3D00000000fee00000 end=3D00000000fee01000 = len=3D0000000000001000 >> SMAP type=3D02 base=3D00000000ffe00000 end=3D0000000100000000 = len=3D0000000000200000 >> SMAP type=3D01 base=3D0000000100000000 end=3D0000000140000000 = len=3D0000000040000000 >>=20 >> The algorithm for placing the heap picks up a range at bc1a4000, = which is >> between two ranges of type '4' (ACPI NVS memory). >> So my idea was just to try a different memory range. Seems that it = worked. >>=20 >> P.S. I am not sure why our algorithm for selecting heap location is = what it is. >> On all systems that I have I see that the "bios_extmem" range (the = one starting >> at 0x100000) is usually the largest one and has more than enough = space for both >> the heap and other things that are placed there. >=20 > Yes, we likely could start using that, we would just need to ensure it = has some > sort of minimum size. However, maybe it would always have that = minimum size as you > are only going to have additional ranges if you have more than 4GB of = RAM anyway. > I think though that there were some odd BIOSes that would place a hole = at 15-16MB, > and for those the memory region at 1MB is too small. A minimum size = of 16MB might > handle that case correctly while using the first extended region in = the common > case. >=20 >> Additionally, in the case of zfsboot I think that we do not use = memory above 1MB >> for anything else besides the heap. >=20 > You load either /boot/zfsloader or the kernel there. >=20 > --=20 > John Baldwin > _______________________________________________ > 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 Mar 21 01:36:11 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 628B4A76 for ; Thu, 21 Mar 2013 01:36:11 +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 24D33F89 for ; Thu, 21 Mar 2013 01:36:10 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.6/8.14.6) with ESMTP id r2L1aAos045278; Wed, 20 Mar 2013 18:36:10 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.6/8.14.6/Submit) id r2L1aAWp045277; Wed, 20 Mar 2013 18:36:10 -0700 (PDT) (envelope-from david) Date: Wed, 20 Mar 2013 18:36:10 -0700 From: David Wolfskill To: Konstantin Belousov Subject: Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver Message-ID: <20130321013610.GB42912@albert.catwhisker.org> References: <20130320160056.GG32811@albert.catwhisker.org> <20130320171340.GE3794@kib.kiev.ua> <20130320173759.GK32811@albert.catwhisker.org> <20130320174458.GG3794@kib.kiev.ua> <20130320180239.GN32811@albert.catwhisker.org> <20130320200857.GN3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="A6N2fC+uXW/VQSAv" Content-Disposition: inline In-Reply-To: <20130320200857.GN3794@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 01:36:11 -0000 --A6N2fC+uXW/VQSAv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 20, 2013 at 10:08:57PM +0200, Konstantin Belousov wrote: > ... > I looked at the nvidia sources to check that the driver does not use > the interfaces which KBI was changed, and this is indeed the case, as > expected. >=20 > I must admit that I have no idea why buffer cache changes could affect > nvidia driver, and with no input on the panic (I hope that it is panic, > and not a reset) have no idea even to speculate. So firewire cable is > probably the must. >=20 > Note that I split that import of the work into the series of commits. > The split was done to ease the reading of the chunks, and individual > commits were not functionally tested. Still, you might try to do the > bisect. I elected to go ahead and try the bisection; here are my results: r248493M/248493: OK r248550M/248551: resets on X startup with nvidia.ko r248521M/248521: resets on X startup with nvidia.ko r248507M/248507: OK r248508M/248508: resets on X startup with nvidia.ko r248493M/248493 was my last working point (built yesterday morning). r248550M/248551 was what failed for me this morning. r248521M/248521 was a convenient mid-point between the above two. r248507M/248507 was the next natural test-point. r248508M/248508 was a guess on my part -- I would normally have gone to r248514, but since I had previously noted that r248508 touched some things that nvidia-driver uses, I thought that test might be worthwhile. I am, however, mildly concerned that no one else appears to be reporting similar symptoms (though I have it on good authority that someone is about to test). Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --A6N2fC+uXW/VQSAv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFKZAgACgkQmprOCmdXAD1gnwCfflzaiQx4WWuLzpsz1vLQKYGY cE4An1SqDuvyg8z7gNGB5KkRYQZRD3pg =S9Gp -----END PGP SIGNATURE----- --A6N2fC+uXW/VQSAv-- From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 08:04:51 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EB104903 for ; Thu, 21 Mar 2013 08:04:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 8DE31FF0 for ; Thu, 21 Mar 2013 08:04:51 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2L84fYg012881; Thu, 21 Mar 2013 10:04:41 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2L84fYg012881 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2L84f7Y012880; Thu, 21 Mar 2013 10:04:41 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 21 Mar 2013 10:04:41 +0200 From: Konstantin Belousov To: David Wolfskill Subject: Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver Message-ID: <20130321080441.GS3794@kib.kiev.ua> References: <20130320160056.GG32811@albert.catwhisker.org> <20130320171340.GE3794@kib.kiev.ua> <20130320173759.GK32811@albert.catwhisker.org> <20130320174458.GG3794@kib.kiev.ua> <20130320180239.GN32811@albert.catwhisker.org> <20130320200857.GN3794@kib.kiev.ua> <20130321013610.GB42912@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9LnT2hzikWZ9nuHF" Content-Disposition: inline In-Reply-To: <20130321013610.GB42912@albert.catwhisker.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 08:04:52 -0000 --9LnT2hzikWZ9nuHF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 20, 2013 at 06:36:10PM -0700, David Wolfskill wrote: > I elected to go ahead and try the bisection; here are my results: >=20 > r248493M/248493: OK > r248550M/248551: resets on X startup with nvidia.ko > r248521M/248521: resets on X startup with nvidia.ko > r248507M/248507: OK > r248508M/248508: resets on X startup with nvidia.ko >=20 > r248493M/248493 was my last working point (built yesterday morning). > r248550M/248551 was what failed for me this morning. > r248521M/248521 was a convenient mid-point between the above two. > r248507M/248507 was the next natural test-point. > r248508M/248508 was a guess on my part -- I would normally have gone to > r248514, but since I had previously noted that r248508 touched some > things that nvidia-driver uses, I thought that test might be worthwhile. >=20 > I am, however, mildly concerned that no one else appears to be reporting > similar symptoms (though I have it on good authority that someone is > about to test). This gives me an idea. The only so to say 'vm' change in r248508 was an addition of the bio_transient_map submap. The vfs.unmapped_buf_allowed tunable did not eliminated the submap creation. Please try r248569 with vfs.unmapped_buf_allowed set to 0. If this combination allows the nvidia driver to start, please revert the setting of vfs.unmapped_buf_allowed, and instead set kern.bio_transient_maxcnt e.g. to 256 or even 128. Also, on the machine without the tunables customization, please show the output of sysctl kern.nbuf, kern.bio_transient_maxcnt. Also show the output of pciconf -lvb. =46rom what I see in your report, you use i386 arch. What is the amount of memory installed in the machine ? --9LnT2hzikWZ9nuHF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRSr8ZAAoJEJDCuSvBvK1BBAYP/0dSVkmp1eplRKRqgYTkOtjQ C/b5ZoWRavqkHR9kE0wJdBb89Ofu9RD86/Ae/x9XkGozdrBFlB+iBjHI8zwBO5Lj e181DBZm3ti/YDmJ1ZjMhTW2DakHh7IlHVnlvY/4qFEA99ogdITz8eEnRG62RpEv mUTh0+0+i5ky5DaY/dmE5WT+aMdrap4Y2ru1gkDaPz49x5VG2GuhjYNOJP2SX5py 1Q129jg3fUMRzWNJ5Y3o2EFJZEG2+BomcImWeB/NJsB6o+4B4/LaxdWgKD+IiBYY g0fSLfVsmcCYXTQNhK10Xyw6CJLIALX6t1d0X1U0hE7RzbLafvpqdod7mkvEr9a2 U1I5HOnhRapfN7Qy9nZvCjPPyCyEZKP2w2Q4TVfPk6mPygyyMRoIwBjUFb3SINbr /hDWNjHymSAHbociBNi4XtIpgyMiJfgTxES3By1k+kIVyNLg+OwEBzKejec0f/O8 WlXF/pDpNm5JZjtbXZYm2CqylGqMODjGpYS0qeLvCk5dgIxuIJOZ82+gGB14bVyv UNZOwKSskRZE9phfCl6iVwQMK0Lf5Xi1DmRAv/8YMmQ20azFoVG13V5lyn9b2COT MTLvmslw5job94ElbGROKN236O8jnCL9E4zP81CV7/7MtzAEfkwLAPtp/39XI0JP ZRyOB7bBVFmEwiZ1ydG1 =kuA/ -----END PGP SIGNATURE----- --9LnT2hzikWZ9nuHF-- From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 08:16:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 94C08E9F for ; Thu, 21 Mar 2013 08:16:12 +0000 (UTC) (envelope-from jean-sebastien.pedron@dumbbell.fr) Received: from mail.made4.biz (ns25270.ovh.net [91.121.29.24]) by mx1.freebsd.org (Postfix) with ESMTP id 5A4FA140 for ; Thu, 21 Mar 2013 08:16:11 +0000 (UTC) Received: from [46.255.176.2] (helo=viking.yzserv.com) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UIae6-000Iii-Tr for freebsd-current@freebsd.org; Thu, 21 Mar 2013 09:14:47 +0100 Message-ID: <514AC172.5010807@dumbbell.fr> Date: Thu, 21 Mar 2013 09:14:42 +0100 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver References: <20130320160056.GG32811@albert.catwhisker.org> <20130320171340.GE3794@kib.kiev.ua> <20130320173759.GK32811@albert.catwhisker.org> <20130320174458.GG3794@kib.kiev.ua> <20130320180239.GN32811@albert.catwhisker.org> <20130320200857.GN3794@kib.kiev.ua> <20130321013610.GB42912@albert.catwhisker.org> <20130321080441.GS3794@kib.kiev.ua> In-Reply-To: <20130321080441.GS3794@kib.kiev.ua> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2AONMELQOEODUVPJEBPVU" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 08:16:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2AONMELQOEODUVPJEBPVU Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 21.03.2013 09:04, Konstantin Belousov wrote: > On Wed, Mar 20, 2013 at 06:36:10PM -0700, David Wolfskill wrote: >> I elected to go ahead and try the bisection; here are my results: >> >> r248493M/248493: OK >> r248550M/248551: resets on X startup with nvidia.ko >> r248521M/248521: resets on X startup with nvidia.ko >> r248507M/248507: OK >> r248508M/248508: resets on X startup with nvidia.ko >> >> r248493M/248493 was my last working point (built yesterday morning). >> r248550M/248551 was what failed for me this morning. >> r248521M/248521 was a convenient mid-point between the above two. >> r248507M/248507 was the next natural test-point. >> r248508M/248508 was a guess on my part -- I would normally have gone= to >> r248514, but since I had previously noted that r248508 touched some >> things that nvidia-driver uses, I thought that test might be worthwh= ile. >> >> I am, however, mildly concerned that no one else appears to be reporti= ng >> similar symptoms (though I have it on good authority that someone is >> about to test). >=20 > This gives me an idea. The only so to say 'vm' change in r248508 was an= > addition of the bio_transient_map submap. The vfs.unmapped_buf_allowed > tunable did not eliminated the submap creation. Please try r248569 > with vfs.unmapped_buf_allowed set to 0. >=20 > If this combination allows the nvidia driver to start, please revert > the setting of vfs.unmapped_buf_allowed, and instead set > kern.bio_transient_maxcnt e.g. to 256 or even 128. >=20 > Also, on the machine without the tunables customization, please show > the output of sysctl kern.nbuf, kern.bio_transient_maxcnt. Also show > the output of pciconf -lvb. To be able to have kernel core dumps while X.Org is running, I need to set the "debug.debugger_on_panic=3D0" sysctl. Otherwise, the computer onl= y reboots (it doesn't honor the ddb script). Maybe it can help here? --=20 Jean-S=E9bastien P=E9dron ------enig2AONMELQOEODUVPJEBPVU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFKwXYACgkQa+xGJsFYOlM0OwCgmRp0hi7KEuFKG4BQLsvrhEpC tsgAnAjbZWbJaA42pMkBRDoI1Ph2MCjT =AQw2 -----END PGP SIGNATURE----- ------enig2AONMELQOEODUVPJEBPVU-- From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 08:28:46 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A91EF1E7 for ; Thu, 21 Mar 2013 08:28:46 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep14.mx.upcmail.net (fep14.mx.upcmail.net [62.179.121.34]) by mx1.freebsd.org (Postfix) with ESMTP id 251E41E6 for ; Thu, 21 Mar 2013 08:28:45 +0000 (UTC) Received: from edge02.upcmail.net ([192.168.13.237]) by viefep14-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20130321082839.WFPX1854.viefep14-int.chello.at@edge02.upcmail.net> for ; Thu, 21 Mar 2013 09:28:39 +0100 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge02.upcmail.net with edge id E8Uf1l0042xdvHc018UfRf; Thu, 21 Mar 2013 09:28:39 +0100 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id C513E6D449; Thu, 21 Mar 2013 09:28:38 +0100 (CET) Date: Thu, 21 Mar 2013 09:28:38 +0100 From: Stefan Farfeleder To: freebsd-current@freebsd.org Subject: sysctl panic on cold boot Message-ID: <20130321082838.GA1468@mole.fafoe.narf.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 08:28:46 -0000 Hi, since r247617 my notebook consistently crashes with a page fault when I turn it on. If I then reboot from the debugger, the system will boot just fine. The last known working revision is r247186. I tried backing out r247561 as this last touched kern_sysctl.c, but to no avail. This is on amd64. As can be seen below, gdb isn't really a big help. Does anyone know what's going on? [...] <118>Entropy harvesting: interrupts ethernet point_to_point Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x1011e fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff804a15c0 stack pointer = 0x28:0xffffff811561c670 frame pointer = 0x28:0xffffff811561c6e0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 47 (sysctl) Reading symbols from /boot/kernel/if_iwn.ko...Reading symbols from /boot/kernel/if_iwn.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_iwn.ko Reading symbols from /boot/kernel/iwn5000fw.ko...Reading symbols from /boot/kernel/iwn5000fw.ko.symbols...done. done. Loaded symbols for /boot/kernel/iwn5000fw.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko #0 doadump (textdump=0) at pcpu.h:229 229 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump (textdump=0) at pcpu.h:229 #1 0xffffffff802c0bbe in db_dump (dummy=, dummy2=0, dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:543 #2 0xffffffff802c06ba in db_command (last_cmdp=, cmd_table=, dopager=1) at /usr/src/sys/ddb/db_command.c:449 #3 0xffffffff802c0472 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502 #4 0xffffffff802c2dc0 in db_trap (type=, code=0) at /usr/src/sys/ddb/db_main.c:231 #5 0xffffffff804cad23 in kdb_trap (type=12, code=0, tf=) at /usr/src/sys/kern/subr_kdb.c:654 #6 0xffffffff806fd1c5 in trap_fatal (frame=0xffffff811561c5c0, eva=) at /usr/src/sys/amd64/amd64/trap.c:867 #7 0xffffffff806fd466 in trap_pfault (frame=0x0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:698 #8 0xffffffff806fccba in trap (frame=0xffffff811561c5c0) at /usr/src/sys/amd64/amd64/trap.c:463 #9 0xffffffff806e6eb3 in calltrap () at exception.S:228 #10 0xffffffff804a15c0 in sysctl_sysctl_next_ls (lsp=, name=0xffffff811561ca44, namelen=, next=0xffffff811561c85c, len=0xffffff811561c8c4, level=4) at /usr/src/sys/kern/kern_sysctl.c:745 ---Type to continue, or q to quit--- #11 0xffffffff804a16ce in sysctl_sysctl_next_ls (lsp=0xfffffe0002a335b0, name=0xffffff811561ca40, namelen=, next=0xffffff811561c858, len=0xffffff811561c8c4, level=3) at /usr/src/sys/kern/kern_sysctl.c:772 #12 0xffffffff804a16ce in sysctl_sysctl_next_ls (lsp=0xfffffe0002a335b0, name=0xffffff811561ca3c, namelen=, next=0xffffff811561c854, len=0xffffff811561c8c4, level=2) at /usr/src/sys/kern/kern_sysctl.c:772 #13 0xffffffff804a16ce in sysctl_sysctl_next_ls (lsp=0xfffffe0002a335b0, name=0xffffff811561ca38, namelen=, next=0xffffff811561c850, len=0xffffff811561c8c4, level=1) at /usr/src/sys/kern/kern_sysctl.c:772 #14 0xffffffff804a1513 in sysctl_sysctl_next (oidp=, arg1=0xffffff811561ca38, arg2=4, req=0xffffff811561c968) at /usr/src/sys/kern/kern_sysctl.c:794 #15 0xffffffff804a090d in sysctl_root (arg1=, arg2=) at /usr/src/sys/kern/kern_sysctl.c:1493 #16 0xffffffff804a0ea8 in userland_sysctl (td=, name=0xffffff811561ca30, namelen=, old=, oldlenp=, inkernel=, new=, newlen=, retval=, flags=358730064) at /usr/src/sys/kern/kern_sysctl.c:1603 ---Type to continue, or q to quit--- #17 0xffffffff804a0c94 in sys___sysctl (td=0xfffffe0006037920, uap=0xffffff811561cb40) at /usr/src/sys/kern/kern_sysctl.c:1529 #18 0xffffffff806fd88e in amd64_syscall (td=0xfffffe0006037920, traced=0) at subr_syscall.c:134 #19 0xffffffff806e719b in Xfast_syscall () at exception.S:387 #20 0x000000080094a30a in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) f 10 #10 0xffffffff804a15c0 in sysctl_sysctl_next_ls (lsp=, name=0xffffff811561ca44, namelen=, next=0xffffff811561c85c, len=0xffffff811561c8c4, level=4) at /usr/src/sys/kern/kern_sysctl.c:745 745 if (!sysctl_sysctl_next_ls(lsp, 0, 0, next+1, (kgdb) l 740 return (0); 741 if (oidp->oid_handler) 742 /* We really should call the handler here...*/ 743 return (0); 744 lsp = SYSCTL_CHILDREN(oidp); 745 if (!sysctl_sysctl_next_ls(lsp, 0, 0, next+1, 746 len, level+1, oidpp)) 747 return (0); 748 goto emptynode; 749 } (kgdb) p lsp $1 = (kgdb) p next $2 = (int *) 0xffffff811561c85c (kgdb) p oidp No symbol "oidp" in current context. (kgdb) p oidpp Cannot access memory at address 0x0 (kgdb) p name $3 = (int *) 0xffffff811561ca44 (kgdb) p len $4 = (int *) 0xffffff811561c8c4 (kgdb) p level $5 = 4 Stefan From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 12:57:54 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BFD8CFE0; Thu, 21 Mar 2013 12:57: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 8B0FE645; Thu, 21 Mar 2013 12:57:54 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2LCvmOh064841; Thu, 21 Mar 2013 08:57:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2LCvmS6064833; Thu, 21 Mar 2013 12:57:48 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 21 Mar 2013 12:57:48 GMT Message-Id: <201303211257.r2LCvmS6064833@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 12:57:54 -0000 TB --- 2013-03-21 11:30:21 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-21 11:30:21 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-21 11:30:21 - starting HEAD tinderbox run for arm/arm TB --- 2013-03-21 11:30:21 - cleaning the object tree TB --- 2013-03-21 11:30:21 - /usr/local/bin/svn stat /src TB --- 2013-03-21 11:30:25 - At svn revision 248579 TB --- 2013-03-21 11:30:26 - building world TB --- 2013-03-21 11:30:26 - CROSS_BUILD_TESTING=YES TB --- 2013-03-21 11:30:26 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-21 11:30:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-21 11:30:26 - SRCCONF=/dev/null TB --- 2013-03-21 11:30:26 - TARGET=arm TB --- 2013-03-21 11:30:26 - TARGET_ARCH=arm TB --- 2013-03-21 11:30:26 - TZ=UTC TB --- 2013-03-21 11:30:26 - __MAKE_CONF=/dev/null TB --- 2013-03-21 11:30:26 - cd /src TB --- 2013-03-21 11:30:26 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Mar 21 11:30:31 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-pointer-sign -Wno-unknown-pragmas -o sgsmsg avl.o sgsmsg.o string_table.o findprime.o ===> cddl/usr.bin/zinject (all) cc -O -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/zinject.c cc -O -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c: In function 'translate_record': /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c:383: warning: passing argument 4 of 'calculate_range' discards qualifiers from pointer target type cc -O -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-pointer-sign -Wno-unknown-pragmas -o zinject zinject.o translate.o -lgeom -lm -lnvpair -lumem -luutil -lzfs_core -lzfs -lzpool /obj/arm.arm/src/tmp/usr/lib/libzpool.so: undefined reference to `atomic_subtract_64' *** [zinject] Error code 1 Stop in /src/cddl/usr.bin/zinject. *** [all] Error code 1 Stop in /src/cddl/usr.bin. *** [all] Error code 1 Stop in /src/cddl. *** [cddl.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-21 12:57:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-21 12:57:48 - ERROR: failed to build world TB --- 2013-03-21 12:57:48 - 4251.48 user 773.77 system 5246.66 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 12:57:56 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6D2E2FE1; Thu, 21 Mar 2013 12:57:56 +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 3916A647; Thu, 21 Mar 2013 12:57:56 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2LCvoHr064903; Thu, 21 Mar 2013 08:57:50 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2LCvoNI064902; Thu, 21 Mar 2013 12:57:50 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 21 Mar 2013 12:57:50 GMT Message-Id: <201303211257.r2LCvoNI064902@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on armv6/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 12:57:56 -0000 TB --- 2013-03-21 11:30:21 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-21 11:30:21 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-21 11:30:21 - starting HEAD tinderbox run for armv6/arm TB --- 2013-03-21 11:30:21 - cleaning the object tree TB --- 2013-03-21 11:30:21 - /usr/local/bin/svn stat /src TB --- 2013-03-21 11:30:25 - At svn revision 248579 TB --- 2013-03-21 11:30:26 - building world TB --- 2013-03-21 11:30:26 - CROSS_BUILD_TESTING=YES TB --- 2013-03-21 11:30:26 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-21 11:30:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-21 11:30:26 - SRCCONF=/dev/null TB --- 2013-03-21 11:30:26 - TARGET=arm TB --- 2013-03-21 11:30:26 - TARGET_ARCH=armv6 TB --- 2013-03-21 11:30:26 - TZ=UTC TB --- 2013-03-21 11:30:26 - __MAKE_CONF=/dev/null TB --- 2013-03-21 11:30:26 - cd /src TB --- 2013-03-21 11:30:26 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Mar 21 11:30:31 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-pointer-sign -Wno-unknown-pragmas -o sgsmsg avl.o sgsmsg.o string_table.o findprime.o ===> cddl/usr.bin/zinject (all) cc -O -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/zinject.c cc -O -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c: In function 'translate_record': /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c:383: warning: passing argument 4 of 'calculate_range' discards qualifiers from pointer target type cc -O -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-pointer-sign -Wno-unknown-pragmas -o zinject zinject.o translate.o -lgeom -lm -lnvpair -lumem -luutil -lzfs_core -lzfs -lzpool /obj/arm.armv6/src/tmp/usr/lib/libzpool.so: undefined reference to `atomic_subtract_64' *** [zinject] Error code 1 Stop in /src/cddl/usr.bin/zinject. *** [all] Error code 1 Stop in /src/cddl/usr.bin. *** [all] Error code 1 Stop in /src/cddl. *** [cddl.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-21 12:57:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-21 12:57:50 - ERROR: failed to build world TB --- 2013-03-21 12:57:50 - 4254.91 user 768.28 system 5248.76 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-armv6-arm.full From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 13:07:05 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 59F9FAF7; Thu, 21 Mar 2013 13:07:05 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 3EE9A71F; Thu, 21 Mar 2013 13:07:05 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.6/8.14.6) with ESMTP id r2LD01Pw031142; Thu, 21 Mar 2013 06:00:01 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.6/8.14.6/Submit) id r2LD01Ro031141; Thu, 21 Mar 2013 06:00:01 -0700 (PDT) (envelope-from sgk) Date: Thu, 21 Mar 2013 06:00:01 -0700 From: Steve Kargl To: Stefan Farfeleder Subject: Re: sysctl panic on cold boot Message-ID: <20130321130001.GA31059@troutmask.apl.washington.edu> References: <20130321082838.GA1468@mole.fafoe.narf.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130321082838.GA1468@mole.fafoe.narf.at> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 13:07:05 -0000 On Thu, Mar 21, 2013 at 09:28:38AM +0100, Stefan Farfeleder wrote: > > since r247617 my notebook consistently crashes with a page fault when I > turn it on. If I then reboot from the debugger, the system will boot > just fine. The last known working revision is r247186. I tried backing > out r247561 as this last touched kern_sysctl.c, but to no avail. This > is on amd64. > > As can be seen below, gdb isn't really a big help. Does anyone know > what's going on? See the thread started by David Wolfskill, yesterday. Title contains "Silent reboots on ..." > Loaded symbols for /boot/kernel/iwn5000fw.ko > Reading symbols from /boot/modules/nvidia.ko...done. > Loaded symbols for /boot/modules/nvidia.ko His problem involved loading nvidia.ko. -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 13:16:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C34E91C3 for ; Thu, 21 Mar 2013 13:16:45 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep15.mx.upcmail.net (fep15.mx.upcmail.net [62.179.121.35]) by mx1.freebsd.org (Postfix) with ESMTP id 182D47D9 for ; Thu, 21 Mar 2013 13:16:44 +0000 (UTC) Received: from edge04.upcmail.net ([192.168.13.239]) by viefep15-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20130321131643.ZNZN6033.viefep15-int.chello.at@edge04.upcmail.net>; Thu, 21 Mar 2013 14:16:43 +0100 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge04.upcmail.net with edge id EDGj1l00p2xdvHc04DGjeb; Thu, 21 Mar 2013 14:16:43 +0100 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id EDF056D449; Thu, 21 Mar 2013 14:16:42 +0100 (CET) Date: Thu, 21 Mar 2013 14:16:42 +0100 From: Stefan Farfeleder To: Steve Kargl Subject: Re: sysctl panic on cold boot Message-ID: <20130321131642.GB1468@mole.fafoe.narf.at> References: <20130321082838.GA1468@mole.fafoe.narf.at> <20130321130001.GA31059@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130321130001.GA31059@troutmask.apl.washington.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 13:16:45 -0000 On Thu, Mar 21, 2013 at 06:00:01AM -0700, Steve Kargl wrote: > On Thu, Mar 21, 2013 at 09:28:38AM +0100, Stefan Farfeleder wrote: > > > > since r247617 my notebook consistently crashes with a page fault when I > > turn it on. If I then reboot from the debugger, the system will boot > > just fine. The last known working revision is r247186. I tried backing > > out r247561 as this last touched kern_sysctl.c, but to no avail. This > > is on amd64. > > > > As can be seen below, gdb isn't really a big help. Does anyone know > > what's going on? > > See the thread started by David Wolfskill, yesterday. Title > contains "Silent reboots on ..." > > > Loaded symbols for /boot/kernel/iwn5000fw.ko > > Reading symbols from /boot/modules/nvidia.ko...done. > > Loaded symbols for /boot/modules/nvidia.ko > > His problem involved loading nvidia.ko. Thanks. I will try booting without nvidia. FWIW, my X and the nvidia driver are working just fine if the system managed to boot. Stefan From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 13:34:48 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 271B6848 for ; Thu, 21 Mar 2013 13:34:48 +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 B9154929 for ; Thu, 21 Mar 2013 13:34:47 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.6/8.14.6) with ESMTP id r2LDYkP4050178; Thu, 21 Mar 2013 06:34:46 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.6/8.14.6/Submit) id r2LDYkZO050177; Thu, 21 Mar 2013 06:34:46 -0700 (PDT) (envelope-from david) Date: Thu, 21 Mar 2013 06:34:46 -0700 From: David Wolfskill To: Konstantin Belousov Subject: Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver Message-ID: <20130321133446.GF42912@albert.catwhisker.org> References: <20130320160056.GG32811@albert.catwhisker.org> <20130320171340.GE3794@kib.kiev.ua> <20130320173759.GK32811@albert.catwhisker.org> <20130320174458.GG3794@kib.kiev.ua> <20130320180239.GN32811@albert.catwhisker.org> <20130320200857.GN3794@kib.kiev.ua> <20130321013610.GB42912@albert.catwhisker.org> <20130321080441.GS3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KIzF6Cje4W/osXrF" Content-Disposition: inline In-Reply-To: <20130321080441.GS3794@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 13:34:48 -0000 --KIzF6Cje4W/osXrF Content-Type: multipart/mixed; boundary="K/NRh952CO+2tg14" Content-Disposition: inline --K/NRh952CO+2tg14 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 21, 2013 at 10:04:41AM +0200, Konstantin Belousov wrote: > ... > This gives me an idea. The only so to say 'vm' change in r248508 was an > addition of the bio_transient_map submap. The vfs.unmapped_buf_allowed > tunable did not eliminated the submap creation. Please try r248569 > with vfs.unmapped_buf_allowed set to 0. OK; I believe that worked. "Believe" because (in the normal course of things) I updated to: FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #845 r2485= 75M/248575: Thu Mar 21 05:35:06 PDT 2013 root@g1-235.catwhisker.org:/us= r/obj/usr/src/sys/CANARY i386 which is a little beyond r248569. (I still have r248508 on a different slice, and figured I could update that to precisely r248569 if this test was incorrect or inconclusive.) In any case: after booting the above (r248575) to verify that it worked as long as I did not load nvidia.ko first, I then rebooted, escaped to loader prompt, set vfs.unmapped_buf_allowed=3D0; boot. And after that came up OK, I (manually) loaded nvidia.ko, then re-started X (xdm); the nVidia banner displayed just before the xdm login screen did. (I have my xdm startup script "prefer" the nvidia driver, but if nvidia.ko isn't loaded, it reverts to the nv driver automagically.) > If this combination allows the nvidia driver to start, please revert > the setting of vfs.unmapped_buf_allowed, and instead set > kern.bio_transient_maxcnt e.g. to 256 or even 128. OK; rebooting, escaping to loader, *not* setting vfs.unmapped_buf_allowed, and setting kern.bio_transient_maxcnt=3D256 also allowed nvidia driver to be used at r248575. > Also, on the machine without the tunables customization, please show > the output of sysctl kern.nbuf, kern.bio_transient_maxcnt. Also show > the output of pciconf -lvb. OK; I rebooted (to revert the vfs.unmapped_buf_allowed setting) and obtained the above (augmented a wee bit by some of the others mentioned; I've attached that as "sysctl.txt". I've also attached a copy of dmesg.boot, in case that's useful. I then tried rebooting r248575 and loading nvidia.ko *without* the tunable customization, and verified that I still saw (what looks like) a "reset" when I start X that way (as reported initially). > From what I see in your report, you use i386 arch. What is the amount > of memory installed in the machine ? 4GB. Is the above what you had in mind, or would you like me to try at precisely r248569? Anything else? Thanks again! Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --K/NRh952CO+2tg14 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="sysctl.txt" Script started on Thu Mar 21 06:07:41 2013 g1-235(10.0-C)[1] uname -a FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #845 r248575M/248575: Thu Mar 21 05:35:06 PDT 2013 root@g1-235.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 g1-235(10.0-C)[2] sysctl vfs.unmapped_buf_allowed kern.bio_transient_maxcnt kern.nbuf vfs.unmapped_buf_allowed: 1 kern.bio_transient_maxcnt: 697 kern.nbuf: 7224 g1-235(10.0-C)[3] pciconf -lvb hostb0@pci0:0:0:0: class=0x060000 card=0x02501028 chip=0x2a408086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 4 Series Chipset Memory Controller Hub' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 card=0x02501028 chip=0x2a418086 rev=0x07 hdr=0x01 vendor = 'Intel Corporation' device = 'Mobile 4 Series Chipset PCI Express Graphics Port' class = bridge subclass = PCI-PCI none0@pci0:0:3:0: class=0x078000 card=0x02501028 chip=0x2a448086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 4 Series Chipset MEI Controller' class = simple comms bar [10] = type Memory, range 64, base 0xf6fd9ef0, size 16, enabled atapci0@pci0:0:3:2: class=0x010185 card=0x02501028 chip=0x2a468086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 4 Series Chipset PT IDER Controller' class = mass storage subclass = ATA bar [10] = type I/O Port, range 32, base 0xef78, size 8, enabled bar [14] = type I/O Port, range 32, base 0xef70, size 4, enabled bar [18] = type I/O Port, range 32, base 0xef80, size 8, enabled bar [1c] = type I/O Port, range 32, base 0xef74, size 4, enabled bar [20] = type I/O Port, range 32, base 0xef90, size 16, enabled none1@pci0:0:3:3: class=0x070002 card=0x02501028 chip=0x2a478086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 4 Series Chipset AMT SOL Redirection' class = simple comms subclass = UART bar [10] = type I/O Port, range 32, base 0xef88, size 8, enabled bar [14] = type Memory, range 32, base 0xf6fda000, size 4096, enabled em0@pci0:0:25:0: class=0x020000 card=0x02501028 chip=0x10f58086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82567LM Gigabit Network Connection' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xf6fe0000, size 131072, enabled bar [14] = type Memory, range 32, base 0xf6fdb000, size 4096, enabled bar [18] = type I/O Port, range 32, base 0xefe0, size 32, enabled uhci0@pci0:0:26:0: class=0x0c0300 card=0x02501028 chip=0x29378086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801I (ICH9 Family) USB UHCI Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0x6f60, size 32, enabled uhci1@pci0:0:26:1: class=0x0c0300 card=0x02501028 chip=0x29388086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801I (ICH9 Family) USB UHCI Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0x6f80, size 32, enabled uhci2@pci0:0:26:2: class=0x0c0300 card=0x02501028 chip=0x29398086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801I (ICH9 Family) USB UHCI Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0x6fa0, size 32, enabled ehci0@pci0:0:26:7: class=0x0c0320 card=0x02501028 chip=0x293c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801I (ICH9 Family) USB2 EHCI Controller' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xfed1c400, size 1024, enabled hdac0@pci0:0:27:0: class=0x040300 card=0x02501028 chip=0x293e8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801I (ICH9 Family) HD Audio Controller' class = multimedia subclass = HDA bar [10] = type Memory, range 64, base 0xf6fdc000, size 16384, enabled pcib2@pci0:0:28:0: class=0x060400 card=0x02501028 chip=0x29408086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' device = '82801I (ICH9 Family) PCI Express Port 1' class = bridge subclass = PCI-PCI pcib3@pci0:0:28:1: class=0x060400 card=0x02501028 chip=0x29428086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' device = '82801I (ICH9 Family) PCI Express Port 2' class = bridge subclass = PCI-PCI pcib4@pci0:0:28:2: class=0x060400 card=0x02501028 chip=0x29448086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' device = '82801I (ICH9 Family) PCI Express Port 3' class = bridge subclass = PCI-PCI pcib5@pci0:0:28:3: class=0x060400 card=0x02501028 chip=0x29468086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' device = '82801I (ICH9 Family) PCI Express Port 4' class = bridge subclass = PCI-PCI uhci3@pci0:0:29:0: class=0x0c0300 card=0x02501028 chip=0x29348086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801I (ICH9 Family) USB UHCI Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0x6f00, size 32, enabled uhci4@pci0:0:29:1: class=0x0c0300 card=0x02501028 chip=0x29358086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801I (ICH9 Family) USB UHCI Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0x6f20, size 32, enabled uhci5@pci0:0:29:2: class=0x0c0300 card=0x02501028 chip=0x29368086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801I (ICH9 Family) USB UHCI Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0x6f40, size 32, enabled ehci1@pci0:0:29:7: class=0x0c0320 card=0x02501028 chip=0x293a8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801I (ICH9 Family) USB2 EHCI Controller' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xfed1c000, size 1024, enabled pcib6@pci0:0:30:0: class=0x060401 card=0x02501028 chip=0x24488086 rev=0x93 hdr=0x01 vendor = 'Intel Corporation' device = '82801 Mobile PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x02501028 chip=0x29178086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'ICH9M-E LPC Interface Controller' class = bridge subclass = PCI-ISA ahci0@pci0:0:31:2: class=0x010601 card=0x02501028 chip=0x29298086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801IBM/IEM (ICH9M/ICH9M-E) 4 port SATA Controller [AHCI mode]' class = mass storage subclass = SATA bar [10] = type I/O Port, range 32, base 0x6e70, size 8, enabled bar [14] = type I/O Port, range 32, base 0x6e78, size 4, enabled bar [18] = type I/O Port, range 32, base 0x6e80, size 8, enabled bar [1c] = type I/O Port, range 32, base 0x6e88, size 4, enabled bar [20] = type I/O Port, range 32, base 0x6ea0, size 32, enabled bar [24] = type Memory, range 32, base 0xfed1c800, size 2048, enabled ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x02501028 chip=0x29308086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801I (ICH9 Family) SMBus Controller' class = serial bus subclass = SMBus bar [10] = type Memory, range 64, base 0xf6fd9f00, size 256, enabled bar [20] = type I/O Port, range 32, base 0x1100, size 32, enabled vgapci0@pci0:1:0:0: class=0x030000 card=0x02501028 chip=0x065c10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'G96M [Quadro FX 770M]' class = display subclass = VGA bar [10] = type Memory, range 32, base 0xf5000000, size 16777216, enabled bar [14] = type Prefetchable Memory, range 64, base 0xe0000000, size 268435456, enabled bar [1c] = type Memory, range 64, base 0xf2000000, size 33554432, enabled bar [24] = type I/O Port, range 32, base 0xdf00, size 128, enabled iwn0@pci0:12:0:0: class=0x028000 card=0x11218086 chip=0x42358086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Ultimate N WiFi Link 5300' class = network bar [10] = type Memory, range 64, base 0xf1ffe000, size 8192, enabled cbb0@pci0:3:1:0: class=0x060700 card=0x02501028 chip=0x04761180 rev=0xba hdr=0x02 vendor = 'Ricoh Co Ltd' device = 'RL5c476 II' class = bridge subclass = PCI-CardBus bar [10] = type Memory, range 32, base 0xf1b00000, size 4096, enabled none2@pci0:3:1:1: class=0x0c0010 card=0x02501028 chip=0x08321180 rev=0x04 hdr=0x00 vendor = 'Ricoh Co Ltd' device = 'R5C832 IEEE 1394 Controller' class = serial bus subclass = FireWire bar [10] = type Memory, range 32, base 0xf1bff800, size 2048, enabled sdhci_pci0@pci0:3:1:2: class=0x080501 card=0x02501028 chip=0x08221180 rev=0x21 hdr=0x00 vendor = 'Ricoh Co Ltd' device = 'R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter' class = base peripheral subclass = SD host controller bar [10] = type Memory, range 32, base 0xf1bff600, size 256, enabled none3@pci0:3:1:3: class=0x088000 card=0x02501028 chip=0x08431180 rev=0x11 hdr=0x00 vendor = 'Ricoh Co Ltd' device = 'R5C843 MMC Host Controller' class = base peripheral bar [10] = type Memory, range 32, base 0xf1bff700, size 256, enabled g1-235(10.0-C)[4] exit Script done on Thu Mar 21 06:08:35 2013 --K/NRh952CO+2tg14 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.boot" Content-Transfer-Encoding: quoted-printable Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #845 r248575M/248575: Thu Mar 21 05:35:06 PDT 2013 root@g1-235.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. MEMGUARD DEBUGGING ALLOCATOR INITIALIZED: MEMGUARD map base: 0xc7000000 MEMGUARD map limit: 0xcd681000 MEMGUARD map size: 104964 KBytes CPU: Intel(R) Core(TM)2 Duo CPU T9600 @ 2.80GHz (2793.06-MHz 686-class= CPU) Origin =3D "GenuineIntel" Id =3D 0x10676 Family =3D 0x6 Model =3D 0x17= Stepping =3D 6 Features=3D0xbfebfbff Features2=3D0x8e3fd AMD Features=3D0x20100000 AMD Features2=3D0x1 TSC: P-state invariant, performance statistics real memory =3D 4294967296 (4096 MB) avail memory =3D 3616292864 (3448 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 acpi0: reservation of 0, 9f000 (3) failed acpi0: reservation of 100000, df351c00 (3) failed cpu0: on acpi0 cpu1: on acpi0 atrtc0: port 0x70-0x71,0x72-0x77 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 2 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x930,0x934 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xdf00-0xdf7f mem 0xf5000000-0xf5fff= fff,0xe0000000-0xefffffff,0xf2000000-0xf3ffffff irq 16 at device 0.0 on pci1 pci0: at device 3.0 (no driver attached) atapci0: port 0xef78-0xef7f,0xef70-0xef73,0xef80-0xe= f87,0xef74-0xef77,0xef90-0xef9f irq 18 at device 3.2 on pci0 ata2: at channel 0 on atapci0 ata3: at channel 1 on atapci0 pci0: at device 3.3 (no driver attached) em0: port 0xefe0-0xefff mem 0x= f6fe0000-0xf6ffffff,0xf6fdb000-0xf6fdbfff irq 22 at device 25.0 on pci0 em0: Using an MSI interrupt em0: Ethernet address: 00:24:e8:9c:11:0f uhci0: port 0x6f60-0x6f7f irq 20 at de= vice 26.0 on pci0 uhci0: LegSup =3D 0x2f00 usbus0 on uhci0 uhci1: port 0x6f80-0x6f9f irq 21 at de= vice 26.1 on pci0 uhci1: LegSup =3D 0x2f00 usbus1 on uhci1 uhci2: port 0x6fa0-0x6fbf irq 22 at de= vice 26.2 on pci0 uhci2: LegSup =3D 0x2f00 usbus2 on uhci2 ehci0: mem 0xfed1c400-0xfed1c7ff i= rq 22 at device 26.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 hdac0: mem 0xf6fdc000-0xf6fdffff irq 21 at de= vice 27.0 on pci0 pcib2: at device 28.0 on pci0 pci11: on pcib2 pcib3: at device 28.1 on pci0 pci12: on pcib3 iwn0: mem 0xf1ffe000-0xf1ffffff irq 17 at= device 0.0 on pci12 pcib4: at device 28.2 on pci0 pci13: on pcib4 pcib5: at device 28.3 on pci0 pci14: on pcib5 uhci3: port 0x6f00-0x6f1f irq 20 at de= vice 29.0 on pci0 uhci3: LegSup =3D 0x2f00 usbus4 on uhci3 uhci4: port 0x6f20-0x6f3f irq 21 at de= vice 29.1 on pci0 uhci4: LegSup =3D 0x2f00 usbus5 on uhci4 uhci5: port 0x6f40-0x6f5f irq 22 at de= vice 29.2 on pci0 uhci5: LegSup =3D 0x2f00 usbus6 on uhci5 ehci1: mem 0xfed1c000-0xfed1c3ff i= rq 20 at device 29.7 on pci0 usbus7: EHCI version 1.0 usbus7 on ehci1 pcib6: at device 30.0 on pci0 pci3: on pcib6 cbb0: irq 19 at device 1.0 on pci3 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pci3: at device 1.1 (no driver attached) sdhci_pci0: mem 0xf1bff600-0xf1bff6ff irq 18 at device 1.= 2 on pci3 sdhci_pci0: 1 slot(s) allocated pci3: at device 1.3 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0x6e70-0x6e77,0x6e78-0x6e7b,= 0x6e80-0x6e87,0x6e88-0x6e8b,0x6ea0-0x6ebf mem 0xfed1c800-0xfed1cfff irq 19 = at device 31.2 on pci0 ahci0: AHCI v1.20 with 4 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 ahciem0: on ahci0 ichsmb0: port 0x1100-0x111f mem 0xf6= fd9f00-0xf6fd9fff irq 19 at device 31.3 on pci0 smbus0: on ichsmb0 smb0: on smbus0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 battery1: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64,0x62,0x66 irq 1 on ac= pi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model GlidePoint, device ID 0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xce7ff,0xce800-0xcffff pnpid ORM0= 000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ata0: at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata1: at port 0x170-0x177,0x376 irq 15 on isa0 ppc0: parallel port not found. coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert enabled, nat loadable, default to deny, l= ogging disabled DUMMYNET 0 with IPv6 initialized (100409) load_dn_sched dn_sched FIFO loaded load_dn_sched dn_sched PRIO loaded load_dn_sched dn_sched QFQ loaded load_dn_sched dn_sched RR loaded load_dn_sched dn_sched WF2Q+ loaded hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 13,10 and 11,14 on hdaa0 pcm1: at nid 15 and 24 on hdaa0 pcm2: at nid 30 on hdaa0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ugen1.1: at usbus1 uhub0: on usbus1 ugen0.1: at usbus0 uhub1: on usbus0 ugen3.1: at usbus3 uhub2: on usbus3 ugen2.1: at usbus2 uhub3: on usbus2 ugen5.1: at usbus5 uhub4: on usbus5 ugen4.1: at usbus4 uhub5: on usbus4 ugen7.1: at usbus7 uhub6: on usbus7 ugen6.1: at usbus6 uhub7: on usbus6 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub7: 2 ports with 2 removable, self powered Expensive timeout(9) function: 0xc05655d0(0xce040880) 0.004837067 s ses0 at ahciem0 bus 0 scbus6 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device ada0 at ahcich0 bus 0 scbus2 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad8 cd0 at ahcich1 bus 0 scbus3 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device=20 cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - t= ray closed SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. uhub2: 6 ports with 6 removable, self powered uhub6: 6 ports with 6 removable, self powered Trying to mount root from ufs:/dev/ada0s4a [rw]... warning: total configured swap (5242880 pages) exceeds maximum recommended = amount (2097312 pages). warning: increase kern.maxswzone or reduce amount of swap. lock order reversal: 1st 0xceb8a4a4 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2177 2nd 0xc6d5e080 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:262 3rd 0xceb87ea0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2177 KDB: stack backtrace: db_trace_self_wrapper(c0fc2e4c,3236323a,a,1,5c,...) at 0xc0526b9d =3D db_tr= ace_self_wrapper+0x2d/frame 0xfe8af2c0 kdb_backtrace(c0fc5fa7,ceb87ea0,c0fae0b2,cd809f00,c0fcf3a3,...) at 0xc0a8f9= f0 =3D kdb_backtrace+0x30/frame 0xfe8af328 witness_checkorder(ceb87ea0,9,c0fcf3a3,881,ceb87ec0,...) at 0xc0aa634d =3D = witness_checkorder+0xbad/frame 0xfe8af378 __lockmgr_args(ceb87ea0,80100,ceb87ec0,0,0,...) at 0xc0a3b1d4 =3D __lockmgr= _args+0x894/frame 0xfe8af44c ffs_lock(fe8af4d0,cd805370,cd8021e0,cd8080f0,cd8021e0,...) at 0xc0cd5de7 = =3D ffs_lock+0x87/frame 0xfe8af488 VOP_LOCK1_APV(c111b600,fe8af4d0,c0fcc518,180,c112dfe8,...) at 0xc0e13722 = =3D VOP_LOCK1_APV+0x112/frame 0xfe8af4b8 _vn_lock(ceb87e6c,80100,c0fcf3a3,881,c0fce639,...) at 0xc0b0c6a1 =3D _vn_lo= ck+0xa1/frame 0xfe8af4f8 vget(ceb87e6c,80100,ce02bc00,57,0,...) at 0xc0afb1e4 =3D vget+0x74/frame 0x= fe8af530 vfs_hash_get(ce74d7e0,78c03,80000,ce02bc00,fe8af610,...) at 0xc0aeec4c =3D = vfs_hash_get+0xfc/frame 0xfe8af55c ffs_vgetf(ce74d7e0,78c03,80000,fe8af610,1,...) at 0xc0cd0727 =3D ffs_vgetf+= 0x47/frame 0xfe8af5b8 softdep_sync_buf(ceb8a470,c6d5e020,1,108,0,...) at 0xc0cc9607 =3D softdep_s= ync_buf+0x977/frame 0xfe8af620 ffs_syncvnode(ceb8a470,1,0,c10ede5c,246,...) at 0xc0cd6c63 =3D ffs_syncvnod= e+0x2a3/frame 0xfe8af678 ffs_truncate(ceb8a470,200,0,880,cd955e80,...) at 0xc0cabbae =3D ffs_truncat= e+0x69e/frame 0xfe8af830 ufs_direnter(ceb8a470,ceb87e6c,fe8af8f0,fe8afbcc,0,...) at 0xc0cde66d =3D u= fs_direnter+0x7ed/frame 0xfe8af8b0 ufs_makeinode(fe8afbb8,fe8afbcc) at 0xc0ce7d07 =3D ufs_makeinode+0x537/fram= e 0xfe8afa24 ufs_create(fe8afb10,c0fd0a38,60d,ce74d7f0,2,...) at 0xc0ce3aff =3D ufs_crea= te+0x2f/frame 0xfe8afa38 VOP_CREATE_APV(c111b600,fe8afb10,fe8afbcc,fe8afaa0,fe8afad0,...) at 0xc0e10= d30 =3D VOP_CREATE_APV+0x100/frame 0xfe8afa68 vn_open_cred(fe8afb80,fe8afbfc,1a4,0,cd955e80,ce7a53b8) at 0xc0b0bebf =3D v= n_open_cred+0x2cf/frame 0xfe8afb38 vn_open(fe8afb80,fe8afbfc,1a4,ce7a53b8,fe8afbe0,...) at 0xc0b0bbeb =3D vn_o= pen+0x3b/frame 0xfe8afb58 kern_openat(ce02bc00,ffffff9c,2882a544,0,601,1b6) at 0xc0b0453c =3D kern_op= enat+0x1ec/frame 0xfe8afc20 sys_open(ce02bc00,fe8afcc8,c1015153,e9,db,...) at 0xc0b042c8 =3D sys_open+0= x38/frame 0xfe8afc40 syscall(fe8afd08) at 0xc0dee2dd =3D syscall+0x2ed/frame 0xfe8afcfc Xint0x80_syscall() at 0xc0dd69a1 =3D Xint0x80_syscall+0x21/frame 0xfe8afcfc --- syscall (5, FreeBSD ELF32, sys_open), eip =3D 0x281fd9e7, esp =3D 0xbfb= fcd64, ebp =3D 0xbfbfce10 --- wlan0: Ethernet address: 00:21:6a:26:34:c0 Expensive timeout(9) function: 0xc0c4c0e0(0) 0.010557836 s --K/NRh952CO+2tg14-- --KIzF6Cje4W/osXrF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFLDHUACgkQmprOCmdXAD3KIgCcC7pMfETXdAcr4h0k2p+5oFd8 24IAn1Mht4ucKMg5UdIWeEvr2aHDQLVF =49S4 -----END PGP SIGNATURE----- --KIzF6Cje4W/osXrF-- From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 13:48:43 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5099FFD2; Thu, 21 Mar 2013 13:48:43 +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 270A1A0C; Thu, 21 Mar 2013 13:48:43 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2LDmgLJ039674; Thu, 21 Mar 2013 09:48:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2LDmgsD039673; Thu, 21 Mar 2013 13:48:42 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 21 Mar 2013 13:48:42 GMT Message-Id: <201303211348.r2LDmgsD039673@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 13:48:43 -0000 TB --- 2013-03-21 11:30:21 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-21 11:30:21 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-21 11:30:21 - starting HEAD tinderbox run for i386/i386 TB --- 2013-03-21 11:30:21 - cleaning the object tree TB --- 2013-03-21 11:30:21 - /usr/local/bin/svn stat /src TB --- 2013-03-21 11:30:25 - At svn revision 248579 TB --- 2013-03-21 11:30:26 - building world TB --- 2013-03-21 11:30:26 - CROSS_BUILD_TESTING=YES TB --- 2013-03-21 11:30:26 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-21 11:30:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-21 11:30:26 - SRCCONF=/dev/null TB --- 2013-03-21 11:30:26 - TARGET=i386 TB --- 2013-03-21 11:30:26 - TARGET_ARCH=i386 TB --- 2013-03-21 11:30:26 - TZ=UTC TB --- 2013-03-21 11:30:26 - __MAKE_CONF=/dev/null TB --- 2013-03-21 11:30:26 - cd /src TB --- 2013-03-21 11:30:26 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Mar 21 11:30:30 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -c /src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/tools/common/findprime.c cc -O2 -pipe -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -o sgsmsg avl.o sgsmsg.o string_table.o findprime.o ===> cddl/usr.bin/zinject (all) cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-c! onversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/zinject.c cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-c! onversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-c! onversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -o zinject zinject.o translate.o -lgeom -lm -lnvpair -lumem -luutil -lzfs_core -lzfs -lzpool /obj/i386.i386/src/tmp/usr/lib/libzpool.so: undefined reference to `atomic_subtract_64' cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [zinject] Error code 1 Stop in /src/cddl/usr.bin/zinject. *** [all] Error code 1 Stop in /src/cddl/usr.bin. *** [all] Error code 1 Stop in /src/cddl. *** [cddl.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-21 13:48:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-21 13:48:42 - ERROR: failed to build world TB --- 2013-03-21 13:48:42 - 6950.15 user 940.23 system 8301.00 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 13:58:52 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A585D5EE for ; Thu, 21 Mar 2013 13:58:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id F3760ABD for ; Thu, 21 Mar 2013 13:58:51 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2LDwbVs075740; Thu, 21 Mar 2013 15:58:37 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2LDwbVs075740 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2LDwZtZ075739; Thu, 21 Mar 2013 15:58:35 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 21 Mar 2013 15:58:35 +0200 From: Konstantin Belousov To: David Wolfskill Subject: Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver Message-ID: <20130321135835.GX3794@kib.kiev.ua> References: <20130320160056.GG32811@albert.catwhisker.org> <20130320171340.GE3794@kib.kiev.ua> <20130320173759.GK32811@albert.catwhisker.org> <20130320174458.GG3794@kib.kiev.ua> <20130320180239.GN32811@albert.catwhisker.org> <20130320200857.GN3794@kib.kiev.ua> <20130321013610.GB42912@albert.catwhisker.org> <20130321080441.GS3794@kib.kiev.ua> <20130321133446.GF42912@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cN0f9BRyJ83ABZok" Content-Disposition: inline In-Reply-To: <20130321133446.GF42912@albert.catwhisker.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 13:58:52 -0000 --cN0f9BRyJ83ABZok Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 21, 2013 at 06:34:46AM -0700, David Wolfskill wrote: > On Thu, Mar 21, 2013 at 10:04:41AM +0200, Konstantin Belousov wrote: > > ... > > This gives me an idea. The only so to say 'vm' change in r248508 was an > > addition of the bio_transient_map submap. The vfs.unmapped_buf_allowed > > tunable did not eliminated the submap creation. Please try r248569 > > with vfs.unmapped_buf_allowed set to 0. >=20 > OK; I believe that worked. >=20 > "Believe" because (in the normal course of things) I updated to: >=20 > FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #845 r24= 8575M/248575: Thu Mar 21 05:35:06 PDT 2013 root@g1-235.catwhisker.org:/= usr/obj/usr/src/sys/CANARY i386 >=20 > which is a little beyond r248569. (I still have r248508 on a > different slice, and figured I could update that to precisely r248569 > if this test was incorrect or inconclusive.) Not needed. BTW, your system uses UFS, right ? >=20 > In any case: after booting the above (r248575) to verify that it worked > as long as I did not load nvidia.ko first, I then rebooted, escaped to > loader prompt, set vfs.unmapped_buf_allowed=3D0; boot. >=20 > And after that came up OK, I (manually) loaded nvidia.ko, then > re-started X (xdm); the nVidia banner displayed just before the xdm > login screen did. (I have my xdm startup script "prefer" the nvidia > driver, but if nvidia.ko isn't loaded, it reverts to the nv driver > automagically.) >=20 > > If this combination allows the nvidia driver to start, please revert > > the setting of vfs.unmapped_buf_allowed, and instead set > > kern.bio_transient_maxcnt e.g. to 256 or even 128. >=20 > OK; rebooting, escaping to loader, *not* setting vfs.unmapped_buf_allowed, > and setting kern.bio_transient_maxcnt=3D256 also allowed nvidia driver > to be used at r248575. Ok, this is almost not a workaround but a solution (for now). See below. >=20 > > Also, on the machine without the tunables customization, please show > > the output of sysctl kern.nbuf, kern.bio_transient_maxcnt. Also show > > the output of pciconf -lvb. >=20 > OK; I rebooted (to revert the vfs.unmapped_buf_allowed setting) and > obtained the above (augmented a wee bit by some of the others > mentioned; I've attached that as "sysctl.txt". I've also attached > a copy of dmesg.boot, in case that's useful. >=20 > I then tried rebooting r248575 and loading nvidia.ko *without* the > tunable customization, and verified that I still saw (what looks > like) a "reset" when I start X that way (as reported initially). >=20 > > From what I see in your report, you use i386 arch. What is the amount > > of memory installed in the machine ? >=20 > 4GB. >=20 > Is the above what you had in mind, or would you like me to try at > precisely r248569? Anything else? r248569 is fine. > Script started on Thu Mar 21 06:07:41 2013 > g1-235(10.0-C)[1] uname -a > FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #845 r24= 8575M/248575: Thu Mar 21 05:35:06 PDT 2013 root@g1-235.catwhisker.org:/= usr/obj/usr/src/sys/CANARY i386 > g1-235(10.0-C)[2] sysctl vfs.unmapped_buf_allowed kern.bio_transient_maxc= nt kern.nbuf > vfs.unmapped_buf_allowed: 1 > kern.bio_transient_maxcnt: 697 > kern.nbuf: 7224 Could you, please, do some more measurements in the r248575M ? Please show the kern.nbuf for vfs.unmapped_buf_allowed=3D0 case. Also, from there, run "kgdb /boot/kernel/kernel /dev/mem" and do p *buffer_map. Reboot without applying any unmapped/transient tuning, run the kgdb again, and do p *buffer_map p *bio_transient_map Reboot with kern.bio_transient_maxcnt tunable set to 256 and again print the buffer_map and bio_transient_map from the kgdb. > none1@pci0:0:3:3: class=3D0x070002 card=3D0x02501028 chip=3D0x2a478= 086 rev=3D0x07 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D 'Mobile 4 Series Chipset AMT SOL Redirection' > class =3D simple comms > subclass =3D UART > bar [10] =3D type I/O Port, range 32, base 0xef88, size 8, enabled > bar [14] =3D type Memory, range 32, base 0xf6fda000, size 4096, ena= bled Oh, you do have the serial port on your notebook, usable remotely without serial cable. Your chipset seems to be AMT-capable, and you could use comms/amtterm from other machine to get a serial console. > vgapci0@pci0:1:0:0: class=3D0x030000 card=3D0x02501028 chip=3D0x065c1= 0de rev=3D0xa1 hdr=3D0x00 > vendor =3D 'NVIDIA Corporation' > device =3D 'G96M [Quadro FX 770M]' > class =3D display > subclass =3D VGA > bar [10] =3D type Memory, range 32, base 0xf5000000, size 16777216,= enabled > bar [14] =3D type Prefetchable Memory, range 64, base 0xe0000000, s= ize 268435456, enabled > bar [1c] =3D type Memory, range 64, base 0xf2000000, size 33554432,= enabled > bar [24] =3D type I/O Port, range 32, base 0xdf00, size 128, enabled My current theory is that the nvidia aperture size is 256MB, as indicated by bar at 14, and nvidia driver tries to map the whole aperture into KVA. With 4GB of RAM and i386, available 1GB of the KVA become quite tightly populated, and even small changes in the layout make the mapping of 256MB impossible. If I am right, this is more an issue with nvidia. Still, the layout should have not changed much, if at all. I want the kgdb information listed above to confirm/deny this. If you could configure AMT SOL console, then my theory about nvidia mapping the whole aperture could be confirmed or denied. Thank you. --cN0f9BRyJ83ABZok Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRSxIKAAoJEJDCuSvBvK1BHoYQAIjLimf8Vt4x9N49yPboSYBX ZrF2ZgunfsX8zMtIisTH7nm3n1XCiIqjPYmpuOLqkhoLdzxKPZx/z9WymVVmBSlI y3lYoFQA7w1mw6dRvnDQGa4nWyyN+T9DJgHj4ZUP2Ty1rwzKL+7DlHbJCzoGYu9R hFBc0mT9ElWqSULOtmHMUYiYW982LpehR+/wuCJ6rEOzUkE/vUBkIWmwkme4gmBm q4lA80O+UdqHzBmKdEBSzFuLxAmlCyU18CUy3cl8hHlVeGH4gR/r7Lu29oD3I0zz ZkLj5wW7/ow9aOi8k+bGVr/kp26RwHgVyDLzuCRSiHKTajoQ0pIrBVR7ARttMZ2b m/hE0MIw6jlO33yCxx+7Gi4Yt0lZBv036NKdty3/11orGHvhG5w4n8uoUbpJp+2M hK/z5eehxx/Va9R2ubYCU5ARodvHcruHYrl6xJBIu88N3UbExKk0jl3HBFy3f35f e2cRIBBMOw8n6sZCLizlz8ozbG0KxVIWryqVpxpKjoR2Ij68OLgZOSLwoNFqSH4F HNHeB7kfKpQBl4iBWwzygUqSbnw4ar/xUv3WvK40iUGHM5lRb/FR4D/KTbODVnYs STq1zfX8z6DbE2LMntCgDpBODmdnZd4/ohVIp3iuM/TaJ0i0UNtCG0fDo3k09gHg yQrqRKiudd9LpZsJHS1z =BZ+a -----END PGP SIGNATURE----- --cN0f9BRyJ83ABZok-- From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 14:00:23 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8D99D81F for ; Thu, 21 Mar 2013 14:00:23 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) by mx1.freebsd.org (Postfix) with ESMTP id 578B6AFC for ; Thu, 21 Mar 2013 14:00:23 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.0 cv=R4GB6KtX c=1 sm=0 a=0NJkuBbZY5VCdgJ+v5fl0w==:17 a=8jhF2qGmtvsA:10 a=AaUjGI9IrlcA:10 a=kj9zAlcOel0A:10 a=OA2lqS22AAAA:8 a=sIt-5M63AAAA:8 a=KS5gVQhY--UA:10 a=LjTOzC1lAAAA:8 a=g3k24fdcAAAA:8 a=lLcgQo_oSKqTvFPuZIsA:9 a=CjuIK1q_8ugA:10 a=KmloqkfaIt8A:10 a=6k4BJ-aj_1UA:10 a=0NJkuBbZY5VCdgJ+v5fl0w==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.mail=roberthuff@rcn.com; spf=neutral; sender-id=neutral Authentication-Results: smtp01.rcn.cmh.synacor.com header.from=roberthuff@rcn.com; sender-id=neutral Received-SPF: neutral (smtp01.rcn.cmh.synacor.com: 209.6.84.183 is neither permitted nor denied by domain of rcn.com) Received: from [209.6.84.183] ([209.6.84.183:34022] helo=jerusalem.litteratus.org.litteratus.org) by smtp.rcn.com (envelope-from ) (ecelerity 2.2.3.49 r(42060/42061)) with ESMTP id 1B/42-18243-1721B415; Thu, 21 Mar 2013 10:00:22 -0400 From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20811.4719.174493.857351@jerusalem.litteratus.org> Date: Thu, 21 Mar 2013 10:00:15 -0400 To: Kimmo Paasiala Subject: Re: troubles with buildworld/sendmail/sasl/clang In-Reply-To: References: X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid Cc: FreeBSD-STABLE Mailing List , FreeBSD current , Beat Siegenthaler X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 14:00:23 -0000 Kimmo Paasiala writes: > > =================buildworld=============== > > > > /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/usersmtp.c:1864:8: > > error: incompatible pointer types passing 'void ()' to parameter of type > > 'void (*)(char *, bool, MAILER *, struct mailer_con_info *, ENVELOPE *)' > > [-Werror,-Wincompatible-pointer-types] > > getsasldata, NULL, XS_AUTH); > > ^~~~~~~~~~~ > > /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/sendmail.h:2519:67: note: > > passing argument to parameter here > > extern int reply __P((MAILER *, MCI *, ENVELOPE *, time_t, void > > (*)__P((char *, bool, MAILER *, MCI *, ENVELOPE *)), char **, int)); > > ^ > > /usr/obj/usr/src/tmp/usr/include/sys/cdefs.h:129:21: note: expanded from > > macro '__P' > > #define __P(protos) protos /* full-blown ANSI C */ > > ^ > > 3 errors generated. > > *** [usersmtp.o] Error code 1 > > > I can not help with the error but I really have to make this question: > Does FreeBSD really have to support pre-ANSI C compilers in 2013? I have been getting this also for at least the last two months. (There is no src.conf; make.conf is appended. Current system is: FreeBSD 10.0-CURRENT #0: Sun Dec 30 12:52:09 EST 2012 amd64 and I have cyrus-sasl-2.1.26_2 installed and working with that installation.) Respectfully, Robert Huff **************** make.conf CFLAGS= -O -pipe -g STRIP= SYMVER_ENABLED= yes X_WINDOW_SYSTEM= xorg HAVE_MOTIF= yes KERNCONF=JERUSALEM # To avoid building various parts of the base system: # (copied from /usr/share/examples/etc/make.conf NO_BIND_ETC= true # Do not install files to /etc/namedb NO_BLUETOOTH= true # do not build Bluetooth related stuff NO_PROFILE= true # Avoid compiling profiled libraries # to get automatic SASL in sendmail SENDMAIL_CFLAGS+= -I/usr/local/include/ -DSASL=2 SENDMAIL_LDFLAGS+= -L/usr/local/lib SENDMAIL_LDADD+= -lsasl2 # # to make CUPS magically keep working # See: http://www.csua.berkeley.edu/~ranga/notes/freebsd_cups.html # CUPS_OVERWRITE_BASE= yes NO_LPR= true # added per /usr/ports/UPDATING entry 20090401 OVERRIDE_LINUX_BASE_PORT=f10 OVERRIDE_LINUX_NONBASE_PORTS=f10 # WITH_MOZILLA= libxul WITH_GECKO= libxul # # added 2007/03/04 per advice of # in re science/gramps # WITH_BERKELEYDB=db43 WITH_BDB_VER=43 WANT_OPENLDAP_VER=24 WANT_OPENLDAP_SASL=true # # as required by ports/UPDATING of 20121012 # SAMBA_ENABLE=YES # # PORTS: use clang unless gcc is explicitly required # # # default to using clang for all port builds, with the following # exceptions # ports which will only build with the base system GNU compiler (4.2) # # the "make index" target also seems to need this, for some reason .if target(index) | \ ${.CURDIR:M*/devel/antlr*} | \ ${.CURDIR:M*/devel/google-perftools* } | \ ${.CURDIR:M*/graphics/ImageMagick* } | \ ${.CURDIR:M*/graphics/opencv*} | \ ${.CURDIR:M*/x11/kdelibs4*} | \ USE_GCC?=4.2 .endif # ports which need *some* version of the GNU compiler (won't build with # clang or have runtime issues if built with clang) # use the highest version of gcc we have installed from ports (4.6) .if ${.CURDIR:M*/accessibility/jovie*} | \ ${.CURDIR:M*/accessibility/kdeaccessibility4*} | \ ${.CURDIR:M*/audio/grip*} | \ ${.CURDIR:M*/audio/mpg123*} | \ ${.CURDIR:M*/audio/rosegarden*} | \ ${.CURDIR:M*/databases/virtuoso*} | \ ${.CURDIR:M*/deskutils/kdepimlibs4*} | \ ${.CURDIR:M*/devel/apache-ant*} | \ ${.CURDIR:M*/devel/icu*} | \ ${.CURDIR:M*/devel/kdevelop-kde4*} | \ ${.CURDIR:M*/devel/kdevplatform*} | \ ${.CURDIR:M*/devel/log4j*} | \ ${.CURDIR:M*/games/kdegames4*} | \ ${.CURDIR:M*/graphics/tonicpoint-viewer*} | \ ${.CURDIR:M*/java/* } | \ ${.CURDIR:M*/lang/gcc* } | \ ${.CURDIR:M*/math/fftw3*} | \ ${.CURDIR:M*/multimedia/avidemux2*} | \ ${.CURDIR:M*/multimedia/kdemultimedia4*} | \ ${.CURDIR:M*/multimedia/vlc*} | \ ${.CURDIR:M*/multimedia/xbmc*} | \ ${.CURDIR:M*/net/kdenetwork4*} | \ ${.CURDIR:M*/net/mpich2*} | \ ${.CURDIR:M*/net/opal3*} | \ ${.CURDIR:M*/net-p2p/ktorrent*} | \ ${.CURDIR:M*/net-p2p/vuze*} | \ ${.CURDIR:M*/sysutils/lsof*} | \ ${.CURDIR:M*/textproc/docbook-xsl*} | \ ${.CURDIR:M*/textproc/fop*} | \ ${.CURDIR:M*/www/libxul*} | \ ${.CURDIR:M*/x11/kde4-baseapps*} | \ ${.CURDIR:M*/x11/kde4-workspace*} | \ ${.CURDIR:M*/x11/lxpanel*} | \ USE_GCC?=4.6+ .endif .if ${.CURDIR:M*/usr/ports/*} .if !defined(USE_GCC) .if !defined(CC) || ${CC} == "cc" CC=clang .endif .if !defined(CXX) || ${CXX} == "c++" CXX=clang++ .endif .if !defined(CPP) || ${CPP} == "cpp" CPP=clang-cpp .endif .endif .endif WITH_NEW_XORG=yes WITH_BSD_SORT= WITH_PKGNG=yes # added by use.perl 2013-03-11 11:53:01 PERL_VERSION=5.16.2 From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 14:16:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D3CCD3BE; Thu, 21 Mar 2013 14:16:21 +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 9AB4FD19; Thu, 21 Mar 2013 14:16:21 +0000 (UTC) Received: from irix.bris.ac.uk ([137.222.10.39] helo=ncs.bris.ac.uk) by dirg.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1UIgHp-0000Rv-9b; Thu, 21 Mar 2013 14:16:13 +0000 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 1UIgHo-0004Oh-D0; Thu, 21 Mar 2013 14:16:08 +0000 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.6/8.14.6) with ESMTP id r2LEG8oH041217; Thu, 21 Mar 2013 14:16:08 GMT (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.6/8.14.6/Submit) id r2LEG8cG041216; Thu, 21 Mar 2013 14:16:08 GMT (envelope-from mexas) Date: Thu, 21 Mar 2013 14:16:08 GMT From: Anton Shterenlikht Message-Id: <201303211416.r2LEG8cG041216@mech-cluster241.men.bris.ac.uk> To: kpaasial@gmail.com, roberthuff@rcn.com Subject: Re: troubles with buildworld/sendmail/sasl/clang In-Reply-To: <20811.4719.174493.857351@jerusalem.litteratus.org> X-Spam-Score: -4.7 X-Spam-Level: ---- Cc: freebsd-stable@freebsd.org, freebsd-current@freebsd.org, beat.siegenthaler@beatsnet.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bristol.ac.uk List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 14:16:21 -0000 Kimmo Paasiala writes: > > =================buildworld=============== > > > > /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/usersmtp.c:1864:8: > > error: incompatible pointer types passing 'void ()' to parameter of type > > 'void (*)(char *, bool, MAILER *, struct mailer_con_info *, ENVELOPE *)' > > [-Werror,-Wincompatible-pointer-types] > > getsasldata, NULL, XS_AUTH); > > ^~~~~~~~~~~ > > /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/sendmail.h:2519:67: note: > > passing argument to parameter here > > extern int reply __P((MAILER *, MCI *, ENVELOPE *, time_t, void > > (*)__P((char *, bool, MAILER *, MCI *, ENVELOPE *)), char **, int)); > > ^ > > /usr/obj/usr/src/tmp/usr/include/sys/cdefs.h:129:21: note: expanded from > > macro '__P' > > #define __P(protos) protos /* full-blown ANSI C */ > > ^ > > 3 errors generated. > > *** [usersmtp.o] Error code 1 > > > I can not help with the error but I really have to make this question: > Does FreeBSD really have to support pre-ANSI C compilers in 2013? I have been getting this also for at least the last two months. (There is no src.conf; make.conf is appended. Current system is: FreeBSD 10.0-CURRENT #0: Sun Dec 30 12:52:09 EST 2012 amd64 and I have cyrus-sasl-2.1.26_2 installed and working with that installation.) Respectfully, Robert Huff me too, also on amd64 -current no src.conf # cat /etc/make.conf SENDMAIL_CFLAGS+= -I/usr/local/include -DSASL=2 SENDMAIL_LDFLAGS+= -L/usr/local/lib SENDMAIL_LDADD+= -lsasl2 WITH_PKGNG=yes PERL_VERSION=5.16.2 Anton From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 14:29:41 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4A2368FE; Thu, 21 Mar 2013 14:29: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 16007E06; Thu, 21 Mar 2013 14:29:40 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2LETe8B059234; Thu, 21 Mar 2013 10:29:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2LETdZk059217; Thu, 21 Mar 2013 14:29:39 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 21 Mar 2013 14:29:39 GMT Message-Id: <201303211429.r2LETdZk059217@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 14:29:41 -0000 TB --- 2013-03-21 13:48:42 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-21 13:48:42 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-21 13:48:42 - starting HEAD tinderbox run for mips/mips TB --- 2013-03-21 13:48:42 - cleaning the object tree TB --- 2013-03-21 13:48:42 - /usr/local/bin/svn stat /src TB --- 2013-03-21 13:48:59 - At svn revision 248579 TB --- 2013-03-21 13:49:00 - building world TB --- 2013-03-21 13:49:00 - CROSS_BUILD_TESTING=YES TB --- 2013-03-21 13:49:00 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-21 13:49:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-21 13:49:00 - SRCCONF=/dev/null TB --- 2013-03-21 13:49:00 - TARGET=mips TB --- 2013-03-21 13:49:00 - TARGET_ARCH=mips TB --- 2013-03-21 13:49:00 - TZ=UTC TB --- 2013-03-21 13:49:00 - __MAKE_CONF=/dev/null TB --- 2013-03-21 13:49:00 - cd /src TB --- 2013-03-21 13:49:00 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Mar 21 13:49:05 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -G0 -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-pointer-sign -Wno-unknown-pragmas -o sgsmsg avl.o sgsmsg.o string_table.o findprime.o ===> cddl/usr.bin/zinject (all) cc -O -pipe -G0 -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/zinject.c cc -O -pipe -G0 -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c: In function 'translate_record': /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c:383: warning: passing argument 4 of 'calculate_range' discards qualifiers from pointer target type cc -O -pipe -G0 -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-pointer-sign -Wno-unknown-pragmas -o zinject zinject.o translate.o -lgeom -lm -lnvpair -lumem -luutil -lzfs_core -lzfs -lzpool /obj/mips.mips/src/tmp/usr/lib/libzpool.so: undefined reference to `atomic_subtract_64' *** [zinject] Error code 1 Stop in /src/cddl/usr.bin/zinject. *** [all] Error code 1 Stop in /src/cddl/usr.bin. *** [all] Error code 1 Stop in /src/cddl. *** [cddl.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-21 14:29:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-21 14:29:39 - ERROR: failed to build world TB --- 2013-03-21 14:29:39 - 1696.64 user 507.62 system 2457.02 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 14:43:16 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 06EDEB7B; Thu, 21 Mar 2013 14:43:16 +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 D2960EAB; Thu, 21 Mar 2013 14:43:15 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2LEhFfK037185; Thu, 21 Mar 2013 10:43:15 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2LEhFx4037180; Thu, 21 Mar 2013 14:43:15 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 21 Mar 2013 14:43:15 GMT Message-Id: <201303211443.r2LEhFx4037180@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 14:43:16 -0000 TB --- 2013-03-21 12:57:50 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-21 12:57:50 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-21 12:57:50 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-03-21 12:57:50 - cleaning the object tree TB --- 2013-03-21 12:57:50 - /usr/local/bin/svn stat /src TB --- 2013-03-21 12:57:53 - At svn revision 248579 TB --- 2013-03-21 12:57:54 - building world TB --- 2013-03-21 12:57:54 - CROSS_BUILD_TESTING=YES TB --- 2013-03-21 12:57:54 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-21 12:57:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-21 12:57:54 - SRCCONF=/dev/null TB --- 2013-03-21 12:57:54 - TARGET=ia64 TB --- 2013-03-21 12:57:54 - TARGET_ARCH=ia64 TB --- 2013-03-21 12:57:54 - TZ=UTC TB --- 2013-03-21 12:57:54 - __MAKE_CONF=/dev/null TB --- 2013-03-21 12:57:54 - cd /src TB --- 2013-03-21 12:57:54 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Mar 21 12:57:58 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Mar 21 14:29:34 UTC 2013 TB --- 2013-03-21 14:29:34 - generating LINT kernel config TB --- 2013-03-21 14:29:34 - cd /src/sys/ia64/conf TB --- 2013-03-21 14:29:34 - /usr/bin/make -B LINT TB --- 2013-03-21 14:29:34 - cd /src/sys/ia64/conf TB --- 2013-03-21 14:29:34 - /usr/sbin/config -m LINT TB --- 2013-03-21 14:29:34 - building LINT kernel TB --- 2013-03-21 14:29:34 - CROSS_BUILD_TESTING=YES TB --- 2013-03-21 14:29:34 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-21 14:29:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-21 14:29:34 - SRCCONF=/dev/null TB --- 2013-03-21 14:29:34 - TARGET=ia64 TB --- 2013-03-21 14:29:34 - TARGET_ARCH=ia64 TB --- 2013-03-21 14:29:34 - TZ=UTC TB --- 2013-03-21 14:29:34 - __MAKE_CONF=/dev/null TB --- 2013-03-21 14:29:34 - cd /src TB --- 2013-03-21 14:29:34 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Mar 21 14:29:34 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] {standard input}:31644: Warning: This is the location of the conflicting usage cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/fs/nfsclient/nfs_clvnops.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/fs/nfsclient/nfs_clnode.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/fs/nfsclient/nfs_clvfsops.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/fs/nfsclient/nfs_clport.c cc1: warnings being treated as errors /src/sys/fs/nfsclient/nfs_clport.c: In function 'nfscl_loadattrcache': /src/sys/fs/nfsclient/nfs_clport.c:364: warning: 'nsize' may be used uninitialized in this function *** [nfs_clport.o] Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-21 14:43:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-21 14:43:15 - ERROR: failed to build LINT kernel TB --- 2013-03-21 14:43:15 - 5153.74 user 859.62 system 6324.46 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 14:58:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 30F4A1A2 for ; Thu, 21 Mar 2013 14:58:19 +0000 (UTC) (envelope-from zaphod@berentweb.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 19708FAE for ; Thu, 21 Mar 2013 14:58:18 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UIgwc-0007tv-JV for freebsd-current@freebsd.org; Thu, 21 Mar 2013 07:58:18 -0700 Date: Thu, 21 Mar 2013 07:58:18 -0700 (PDT) From: Beeblebrox To: freebsd-current@freebsd.org Message-ID: <1363877898593-5797633.post@n5.nabble.com> Subject: compiler confusion: gcc cannot be located and causes compiler errors MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 14:58:19 -0000 I have run into this error in several different places, and it seems like a problem with one of the base tools. lang/gcc has been installed on the system from ports. 1. If I try to build emulators/kqemu-kmod-devel, I get: ===> FreeBSD 10 autotools fix applied to /usr/obj/asp/ports/emulators/kqemu-kmod-devel/work/kqemu-1.4.0pre1/configure Source path /usr/obj/asp/ports/emulators/kqemu-kmod-devel/work/kqemu-1.4.0pre1 C compiler cc Host C compiler gcc make gmake host CPU x86_64 ===> Building for kqemu-kmod-devel-1.4.0.p1_5 @ -> /asp/src/sys machine -> /asp/src/sys/amd64/include x86 -> /asp/src/sys/x86/include gcc -Wall -O2 -Werror -g -D__KERNEL__ -I.. -o genoffsets genoffsets.c gmake: gcc: Command not found gmake: *** [genoffsets] Error 127 *** [do-build] Error code 2 2. Another example of the issue: http://freebsd.1045724.n5.nabble.com/How-can-I-switch-compiler-from-clang-to-gcc46-td5796040.html#a5796083 My /etc/make.conf below (most flags are disabled for debug): #WITH_CCACHE_BUILD=yes #FORCE_MAKE_JOBS=yes MAKE_JOBS_NUMBER=9 WITH_CPUFLAGS=yes BUILD_OPTIMIZED=yes BATCH=yes #CC=gcc46 #CXX=g++46 #CPP=cpp46 #USE_GCC=any GCC_DEFAULT_VERSION= 4.6+ #CC:=${CC:C,^gcc46,/usr/local/libexec/ccache/world/gcc46,1} #CXX:=${CXX:C,^g\+\+\46,/usr/local/libexec/ccache/world/g++46,1} #.include "/etc/make/portset.conf" #.include "/etc/make/portbreak.conf" -- View this message in context: http://freebsd.1045724.n5.nabble.com/compiler-confusion-gcc-cannot-be-located-and-causes-compiler-errors-tp5797633.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 15:24:42 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E94859B0; Thu, 21 Mar 2013 15:24:42 +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 BD47B1AD; Thu, 21 Mar 2013 15:24:42 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2LFOgM3077952; Thu, 21 Mar 2013 11:24:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2LFOfuZ077948; Thu, 21 Mar 2013 15:24:41 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 21 Mar 2013 15:24:41 GMT Message-Id: <201303211524.r2LFOfuZ077948@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 15:24:43 -0000 TB --- 2013-03-21 12:57:48 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-21 12:57:48 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-21 12:57:48 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-03-21 12:57:48 - cleaning the object tree TB --- 2013-03-21 12:57:48 - /usr/local/bin/svn stat /src TB --- 2013-03-21 12:57:52 - At svn revision 248579 TB --- 2013-03-21 12:57:53 - building world TB --- 2013-03-21 12:57:53 - CROSS_BUILD_TESTING=YES TB --- 2013-03-21 12:57:53 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-21 12:57:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-21 12:57:53 - SRCCONF=/dev/null TB --- 2013-03-21 12:57:53 - TARGET=pc98 TB --- 2013-03-21 12:57:53 - TARGET_ARCH=i386 TB --- 2013-03-21 12:57:53 - TZ=UTC TB --- 2013-03-21 12:57:53 - __MAKE_CONF=/dev/null TB --- 2013-03-21 12:57:53 - cd /src TB --- 2013-03-21 12:57:53 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Mar 21 12:57:57 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -c /src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/tools/common/findprime.c cc -O2 -pipe -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -o sgsmsg avl.o sgsmsg.o string_table.o findprime.o ===> cddl/usr.bin/zinject (all) cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-c! onversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/zinject.c cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-c! onversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-c! onversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -o zinject zinject.o translate.o -lgeom -lm -lnvpair -lumem -luutil -lzfs_core -lzfs -lzpool /obj/pc98.i386/src/tmp/usr/lib/libzpool.so: undefined reference to `atomic_subtract_64' cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [zinject] Error code 1 Stop in /src/cddl/usr.bin/zinject. *** [all] Error code 1 Stop in /src/cddl/usr.bin. *** [all] Error code 1 Stop in /src/cddl. *** [cddl.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-21 15:24:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-21 15:24:41 - ERROR: failed to build world TB --- 2013-03-21 15:24:41 - 7276.12 user 1018.78 system 8813.27 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 15:32:33 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 12243C40; Thu, 21 Mar 2013 15:32:33 +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 DB3A722C; Thu, 21 Mar 2013 15:32:29 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2LFWTon025021; Thu, 21 Mar 2013 11:32:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2LFWSAm025020; Thu, 21 Mar 2013 15:32:28 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 21 Mar 2013 15:32:28 GMT Message-Id: <201303211532.r2LFWSAm025020@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips64/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 15:32:33 -0000 TB --- 2013-03-21 14:29:40 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-21 14:29:40 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-21 14:29:40 - starting HEAD tinderbox run for mips64/mips TB --- 2013-03-21 14:29:40 - cleaning the object tree TB --- 2013-03-21 14:29:40 - /usr/local/bin/svn stat /src TB --- 2013-03-21 14:29:43 - At svn revision 248579 TB --- 2013-03-21 14:29:44 - building world TB --- 2013-03-21 14:29:44 - CROSS_BUILD_TESTING=YES TB --- 2013-03-21 14:29:44 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-21 14:29:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-21 14:29:44 - SRCCONF=/dev/null TB --- 2013-03-21 14:29:44 - TARGET=mips TB --- 2013-03-21 14:29:44 - TARGET_ARCH=mips64 TB --- 2013-03-21 14:29:44 - TZ=UTC TB --- 2013-03-21 14:29:44 - __MAKE_CONF=/dev/null TB --- 2013-03-21 14:29:44 - cd /src TB --- 2013-03-21 14:29:44 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Mar 21 14:29:48 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Mar 21 15:31:51 UTC 2013 TB --- 2013-03-21 15:31:51 - cd /src/sys/mips/conf TB --- 2013-03-21 15:31:51 - /usr/sbin/config -m ADM5120 TB --- 2013-03-21 15:31:51 - skipping ADM5120 kernel TB --- 2013-03-21 15:31:51 - cd /src/sys/mips/conf TB --- 2013-03-21 15:31:51 - /usr/sbin/config -m ALCHEMY TB --- 2013-03-21 15:31:51 - skipping ALCHEMY kernel TB --- 2013-03-21 15:31:51 - cd /src/sys/mips/conf TB --- 2013-03-21 15:31:51 - /usr/sbin/config -m AP91 TB --- 2013-03-21 15:31:51 - skipping AP91 kernel TB --- 2013-03-21 15:31:51 - cd /src/sys/mips/conf TB --- 2013-03-21 15:31:51 - /usr/sbin/config -m AP93 TB --- 2013-03-21 15:31:51 - skipping AP93 kernel TB --- 2013-03-21 15:31:51 - cd /src/sys/mips/conf TB --- 2013-03-21 15:31:51 - /usr/sbin/config -m AP94 TB --- 2013-03-21 15:31:51 - skipping AP94 kernel TB --- 2013-03-21 15:31:51 - cd /src/sys/mips/conf TB --- 2013-03-21 15:31:51 - /usr/sbin/config -m AP96 TB --- 2013-03-21 15:31:51 - skipping AP96 kernel TB --- 2013-03-21 15:31:51 - cd /src/sys/mips/conf TB --- 2013-03-21 15:31:51 - /usr/sbin/config -m AR71XX_BASE TB --- 2013-03-21 15:31:51 - skipping AR71XX_BASE kernel TB --- 2013-03-21 15:31:51 - cd /src/sys/mips/conf TB --- 2013-03-21 15:31:51 - /usr/sbin/config -m AR724X_BASE TB --- 2013-03-21 15:31:51 - skipping AR724X_BASE kernel TB --- 2013-03-21 15:31:51 - cd /src/sys/mips/conf TB --- 2013-03-21 15:31:51 - /usr/sbin/config -m AR91XX_BASE TB --- 2013-03-21 15:31:51 - skipping AR91XX_BASE kernel TB --- 2013-03-21 15:31:51 - cd /src/sys/mips/conf TB --- 2013-03-21 15:31:51 - /usr/sbin/config -m BERI_DE4_MDROOT TB --- 2013-03-21 15:31:51 - building BERI_DE4_MDROOT kernel TB --- 2013-03-21 15:31:51 - CROSS_BUILD_TESTING=YES TB --- 2013-03-21 15:31:51 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-21 15:31:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-21 15:31:51 - SRCCONF=/dev/null TB --- 2013-03-21 15:31:51 - TARGET=mips TB --- 2013-03-21 15:31:51 - TARGET_ARCH=mips64 TB --- 2013-03-21 15:31:51 - TZ=UTC TB --- 2013-03-21 15:31:51 - __MAKE_CONF=/dev/null TB --- 2013-03-21 15:31:51 - cd /src TB --- 2013-03-21 15:31:51 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_MDROOT >>> Kernel build for BERI_DE4_MDROOT started on Thu Mar 21 15:31:52 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=mips64 -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/fs/nfsclient/nfs_clrpcops.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=mips64 -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/fs/nfsclient/nfs_clvnops.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=mips64 -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/fs/nfsclient/nfs_clnode.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=mips64 -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/fs/nfsclient/nfs_clvfsops.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=mips64 -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/fs/nfsclient/nfs_clport.c cc1: warnings being treated as errors /src/sys/fs/nfsclient/nfs_clport.c: In function 'nfscl_loadattrcache': /src/sys/fs/nfsclient/nfs_clport.c:364: warning: 'nsize' may be used uninitialized in this function *** [nfs_clport.o] Error code 1 Stop in /obj/mips.mips64/src/sys/BERI_DE4_MDROOT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-21 15:32:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-21 15:32:28 - ERROR: failed to build BERI_DE4_MDROOT kernel TB --- 2013-03-21 15:32:28 - 2752.80 user 640.35 system 3768.65 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-mips64-mips.full From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 16:04:26 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C8F28F16 for ; Thu, 21 Mar 2013 16:04:26 +0000 (UTC) (envelope-from lattera@gmail.com) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by mx1.freebsd.org (Postfix) with ESMTP id 89194659 for ; Thu, 21 Mar 2013 16:04:26 +0000 (UTC) Received: by mail-vc0-f178.google.com with SMTP id hz11so2401815vcb.23 for ; Thu, 21 Mar 2013 09:04:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=fK4AG/+AB/cPwXBSqWYW8nCXu4kwlb2ucT9cVPLCOAk=; b=IwNTV9NBqvJnZn7Zv5+XUGrT/+wMmjD/QhCI6o8EucpLb0Bs4VexZulrZSawLuj7RN bYrwGcfrG0JYRHbfZH/mFX9qxHKxJIk6n1QzwMZkxYvKNOwNYwv5JmzNAYyTP+3zlxc/ qwLQVsokkGolqreDSvfq9FSJuHuyH9Qimr7A3oUaowoV8UjQpKEJ75Ts/p0G7nJnuf0g Ef2ZPJlfGQ6O+UIoqEU8sa50Ca54LmplKAryuyEYrhVPFucnE4yi3PU8L8Kh1b/tQ20l Jqx5tubiO4T5s3XLGeEtA01KW5Gvxd0/e/j+1onUC0dZ9duFXcniw04EXJw4H5aH8V3b z5CA== MIME-Version: 1.0 X-Received: by 10.52.240.133 with SMTP id wa5mr11862918vdc.80.1363881859729; Thu, 21 Mar 2013 09:04:19 -0700 (PDT) Received: by 10.58.237.163 with HTTP; Thu, 21 Mar 2013 09:04:19 -0700 (PDT) In-Reply-To: <20130321135835.GX3794@kib.kiev.ua> References: <20130320160056.GG32811@albert.catwhisker.org> <20130320171340.GE3794@kib.kiev.ua> <20130320173759.GK32811@albert.catwhisker.org> <20130320174458.GG3794@kib.kiev.ua> <20130320180239.GN32811@albert.catwhisker.org> <20130320200857.GN3794@kib.kiev.ua> <20130321013610.GB42912@albert.catwhisker.org> <20130321080441.GS3794@kib.kiev.ua> <20130321133446.GF42912@albert.catwhisker.org> <20130321135835.GX3794@kib.kiev.ua> Date: Thu, 21 Mar 2013 12:04:19 -0400 Message-ID: Subject: Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver From: Shawn Webb To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 16:04:26 -0000 On Thu, Mar 21, 2013 at 9:58 AM, Konstantin Belousov wrote: > On Thu, Mar 21, 2013 at 06:34:46AM -0700, David Wolfskill wrote: > > On Thu, Mar 21, 2013 at 10:04:41AM +0200, Konstantin Belousov wrote: > > > ... > > > This gives me an idea. The only so to say 'vm' change in r248508 was an > > > addition of the bio_transient_map submap. The vfs.unmapped_buf_allowed > > > tunable did not eliminated the submap creation. Please try r248569 > > > with vfs.unmapped_buf_allowed set to 0. > > > > OK; I believe that worked. > > > > "Believe" because (in the normal course of things) I updated to: > > > > FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #845 > r248575M/248575: Thu Mar 21 05:35:06 PDT 2013 > root@g1-235.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 > > > > which is a little beyond r248569. (I still have r248508 on a > > different slice, and figured I could update that to precisely r248569 > > if this test was incorrect or inconclusive.) > Not needed. BTW, your system uses UFS, right ? > > > > > In any case: after booting the above (r248575) to verify that it worked > > as long as I did not load nvidia.ko first, I then rebooted, escaped to > > loader prompt, set vfs.unmapped_buf_allowed=0; boot. > > > > And after that came up OK, I (manually) loaded nvidia.ko, then > > re-started X (xdm); the nVidia banner displayed just before the xdm > > login screen did. (I have my xdm startup script "prefer" the nvidia > > driver, but if nvidia.ko isn't loaded, it reverts to the nv driver > > automagically.) > > > > > If this combination allows the nvidia driver to start, please revert > > > the setting of vfs.unmapped_buf_allowed, and instead set > > > kern.bio_transient_maxcnt e.g. to 256 or even 128. > > > > OK; rebooting, escaping to loader, *not* setting > vfs.unmapped_buf_allowed, > > and setting kern.bio_transient_maxcnt=256 also allowed nvidia driver > > to be used at r248575. > Ok, this is almost not a workaround but a solution (for now). See below. > > > > > > Also, on the machine without the tunables customization, please show > > > the output of sysctl kern.nbuf, kern.bio_transient_maxcnt. Also show > > > the output of pciconf -lvb. > > > > OK; I rebooted (to revert the vfs.unmapped_buf_allowed setting) and > > obtained the above (augmented a wee bit by some of the others > > mentioned; I've attached that as "sysctl.txt". I've also attached > > a copy of dmesg.boot, in case that's useful. > > > > I then tried rebooting r248575 and loading nvidia.ko *without* the > > tunable customization, and verified that I still saw (what looks > > like) a "reset" when I start X that way (as reported initially). > > > > > From what I see in your report, you use i386 arch. What is the amount > > > of memory installed in the machine ? > > > > 4GB. > > > > Is the above what you had in mind, or would you like me to try at > > precisely r248569? Anything else? > r248569 is fine. > > > > Script started on Thu Mar 21 06:07:41 2013 > > g1-235(10.0-C)[1] uname -a > > FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #845 > r248575M/248575: Thu Mar 21 05:35:06 PDT 2013 > root@g1-235.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 > > g1-235(10.0-C)[2] sysctl vfs.unmapped_buf_allowed > kern.bio_transient_maxcnt kern.nbuf > > vfs.unmapped_buf_allowed: 1 > > kern.bio_transient_maxcnt: 697 > > kern.nbuf: 7224 > Could you, please, do some more measurements in the r248575M ? > > Please show the kern.nbuf for vfs.unmapped_buf_allowed=0 case. > Also, from there, run "kgdb /boot/kernel/kernel /dev/mem" and do > p *buffer_map. > > Reboot without applying any unmapped/transient tuning, run the kgdb > again, and do > p *buffer_map > p *bio_transient_map > > Reboot with kern.bio_transient_maxcnt tunable set to 256 and again > print the buffer_map and bio_transient_map from the kgdb. > > > none1@pci0:0:3:3: class=0x070002 card=0x02501028 chip=0x2a478086 > rev=0x07 hdr=0x00 > > vendor = 'Intel Corporation' > > device = 'Mobile 4 Series Chipset AMT SOL Redirection' > > class = simple comms > > subclass = UART > > bar [10] = type I/O Port, range 32, base 0xef88, size 8, enabled > > bar [14] = type Memory, range 32, base 0xf6fda000, size 4096, > enabled > Oh, you do have the serial port on your notebook, usable remotely without > serial cable. Your chipset seems to be AMT-capable, and you could use > comms/amtterm from other machine to get a serial console. > > > vgapci0@pci0:1:0:0: class=0x030000 card=0x02501028 chip=0x065c10de > rev=0xa1 hdr=0x00 > > vendor = 'NVIDIA Corporation' > > device = 'G96M [Quadro FX 770M]' > > class = display > > subclass = VGA > > bar [10] = type Memory, range 32, base 0xf5000000, size 16777216, > enabled > > bar [14] = type Prefetchable Memory, range 64, base 0xe0000000, > size 268435456, enabled > > bar [1c] = type Memory, range 64, base 0xf2000000, size 33554432, > enabled > > bar [24] = type I/O Port, range 32, base 0xdf00, size 128, enabled > > My current theory is that the nvidia aperture size is 256MB, as indicated > by bar at 14, and nvidia driver tries to map the whole aperture into KVA. > > With 4GB of RAM and i386, available 1GB of the KVA become quite tightly > populated, and even small changes in the layout make the mapping of > 256MB impossible. If I am right, this is more an issue with nvidia. > > Still, the layout should have not changed much, if at all. I want the > kgdb information listed above to confirm/deny this. > > If you could configure AMT SOL console, then my theory about nvidia mapping > the whole aperture could be confirmed or denied. > > Thank you. > I appear to be experiencing the same issue. I've been following this thread. I have a coredump, but it's over 700mb in size. What would be the best way to get that to you guys? The revision I'm at is r248583 on amd64 (6GB RAM) with an NVIDIA Quadro FX 580. Relevant lines from `pciconf -lvb`: vgapci0@pci0:3:0:0: class=0x030000 card=0x063a10de chip=0x065910de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'G96 [Quadro FX 580]' class = display subclass = VGA bar [10] = type Memory, range 32, base 0xf6000000, size 16777216, enabled bar [14] = type Prefetchable Memory, range 64, base 0xc0000000, size 536870912, enabled bar [1c] = type Memory, range 64, base 0xf4000000, size 33554432, enabled bar [24] = type I/O Port, range 32, base 0xdc80, size 128, enabled Thanks, Shawn From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 16:12:08 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D86773E6 for ; Thu, 21 Mar 2013 16:12:08 +0000 (UTC) (envelope-from lattera@gmail.com) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by mx1.freebsd.org (Postfix) with ESMTP id 97A83706 for ; Thu, 21 Mar 2013 16:12:08 +0000 (UTC) Received: by mail-vc0-f180.google.com with SMTP id m17so2406831vca.39 for ; Thu, 21 Mar 2013 09:12:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=FesjUwFhB5iCu2Zr0NfPGI1g/Wba+V1BRAw+8QaTzCQ=; b=JnAt5L0qSwLBjZYpvUirJzhQtowu8zTuumYDgMjL0yobD31JbQv1jezZiXLemgUuDf mT1tBruYKoK5mBha17cwNaXsD5tSl1Mz0VFLPHjmDhhCeR38aXBYYUbWxbaJudJ+5ytO 3xpBIYPFHttiWsaebdqwPwH902btzVCFpLQzNR/6VhPJ1m3E/bSTeoV9uzhf5WscNrsH g1xAUdj8FjalNQqZCAqCwJlrVTx3TyxpOU4L1QP1Afu/X7t9m+WQukMQ7pQF9/REaPkB VYbmxExkBe0QLVnCIHPHOdv+6AcFs4/oH97C3l+Me28cDkPQS8p1RUmKFkbNECkJez9Z lb9Q== MIME-Version: 1.0 X-Received: by 10.220.113.137 with SMTP id a9mr14100413vcq.11.1363882327889; Thu, 21 Mar 2013 09:12:07 -0700 (PDT) Received: by 10.58.237.163 with HTTP; Thu, 21 Mar 2013 09:12:07 -0700 (PDT) In-Reply-To: References: <20130320160056.GG32811@albert.catwhisker.org> <20130320171340.GE3794@kib.kiev.ua> <20130320173759.GK32811@albert.catwhisker.org> <20130320174458.GG3794@kib.kiev.ua> <20130320180239.GN32811@albert.catwhisker.org> <20130320200857.GN3794@kib.kiev.ua> <20130321013610.GB42912@albert.catwhisker.org> <20130321080441.GS3794@kib.kiev.ua> <20130321133446.GF42912@albert.catwhisker.org> <20130321135835.GX3794@kib.kiev.ua> Date: Thu, 21 Mar 2013 12:12:07 -0400 Message-ID: Subject: Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver From: Shawn Webb To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 16:12:08 -0000 On Thu, Mar 21, 2013 at 12:04 PM, Shawn Webb wrote: > On Thu, Mar 21, 2013 at 9:58 AM, Konstantin Belousov wrote: > >> On Thu, Mar 21, 2013 at 06:34:46AM -0700, David Wolfskill wrote: >> > On Thu, Mar 21, 2013 at 10:04:41AM +0200, Konstantin Belousov wrote: >> > > ... >> > > This gives me an idea. The only so to say 'vm' change in r248508 was >> an >> > > addition of the bio_transient_map submap. The vfs.unmapped_buf_allowed >> > > tunable did not eliminated the submap creation. Please try r248569 >> > > with vfs.unmapped_buf_allowed set to 0. >> > >> > OK; I believe that worked. >> > >> > "Believe" because (in the normal course of things) I updated to: >> > >> > FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #845 >> r248575M/248575: Thu Mar 21 05:35:06 PDT 2013 >> root@g1-235.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 >> > >> > which is a little beyond r248569. (I still have r248508 on a >> > different slice, and figured I could update that to precisely r248569 >> > if this test was incorrect or inconclusive.) >> Not needed. BTW, your system uses UFS, right ? >> >> > >> > In any case: after booting the above (r248575) to verify that it worked >> > as long as I did not load nvidia.ko first, I then rebooted, escaped to >> > loader prompt, set vfs.unmapped_buf_allowed=0; boot. >> > >> > And after that came up OK, I (manually) loaded nvidia.ko, then >> > re-started X (xdm); the nVidia banner displayed just before the xdm >> > login screen did. (I have my xdm startup script "prefer" the nvidia >> > driver, but if nvidia.ko isn't loaded, it reverts to the nv driver >> > automagically.) >> > >> > > If this combination allows the nvidia driver to start, please revert >> > > the setting of vfs.unmapped_buf_allowed, and instead set >> > > kern.bio_transient_maxcnt e.g. to 256 or even 128. >> > >> > OK; rebooting, escaping to loader, *not* setting >> vfs.unmapped_buf_allowed, >> > and setting kern.bio_transient_maxcnt=256 also allowed nvidia driver >> > to be used at r248575. >> Ok, this is almost not a workaround but a solution (for now). See below. >> >> > >> > > Also, on the machine without the tunables customization, please show >> > > the output of sysctl kern.nbuf, kern.bio_transient_maxcnt. Also show >> > > the output of pciconf -lvb. >> > >> > OK; I rebooted (to revert the vfs.unmapped_buf_allowed setting) and >> > obtained the above (augmented a wee bit by some of the others >> > mentioned; I've attached that as "sysctl.txt". I've also attached >> > a copy of dmesg.boot, in case that's useful. >> > >> > I then tried rebooting r248575 and loading nvidia.ko *without* the >> > tunable customization, and verified that I still saw (what looks >> > like) a "reset" when I start X that way (as reported initially). >> > >> > > From what I see in your report, you use i386 arch. What is the amount >> > > of memory installed in the machine ? >> > >> > 4GB. >> > >> > Is the above what you had in mind, or would you like me to try at >> > precisely r248569? Anything else? >> r248569 is fine. >> >> >> > Script started on Thu Mar 21 06:07:41 2013 >> > g1-235(10.0-C)[1] uname -a >> > FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #845 >> r248575M/248575: Thu Mar 21 05:35:06 PDT 2013 >> root@g1-235.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 >> > g1-235(10.0-C)[2] sysctl vfs.unmapped_buf_allowed >> kern.bio_transient_maxcnt kern.nbuf >> > vfs.unmapped_buf_allowed: 1 >> > kern.bio_transient_maxcnt: 697 >> > kern.nbuf: 7224 >> Could you, please, do some more measurements in the r248575M ? >> >> Please show the kern.nbuf for vfs.unmapped_buf_allowed=0 case. >> Also, from there, run "kgdb /boot/kernel/kernel /dev/mem" and do >> p *buffer_map. >> >> Reboot without applying any unmapped/transient tuning, run the kgdb >> again, and do >> p *buffer_map >> p *bio_transient_map >> >> Reboot with kern.bio_transient_maxcnt tunable set to 256 and again >> print the buffer_map and bio_transient_map from the kgdb. >> >> > none1@pci0:0:3:3: class=0x070002 card=0x02501028 chip=0x2a478086 >> rev=0x07 hdr=0x00 >> > vendor = 'Intel Corporation' >> > device = 'Mobile 4 Series Chipset AMT SOL Redirection' >> > class = simple comms >> > subclass = UART >> > bar [10] = type I/O Port, range 32, base 0xef88, size 8, enabled >> > bar [14] = type Memory, range 32, base 0xf6fda000, size 4096, >> enabled >> Oh, you do have the serial port on your notebook, usable remotely without >> serial cable. Your chipset seems to be AMT-capable, and you could use >> comms/amtterm from other machine to get a serial console. >> >> > vgapci0@pci0:1:0:0: class=0x030000 card=0x02501028 chip=0x065c10de >> rev=0xa1 hdr=0x00 >> > vendor = 'NVIDIA Corporation' >> > device = 'G96M [Quadro FX 770M]' >> > class = display >> > subclass = VGA >> > bar [10] = type Memory, range 32, base 0xf5000000, size 16777216, >> enabled >> > bar [14] = type Prefetchable Memory, range 64, base 0xe0000000, >> size 268435456, enabled >> > bar [1c] = type Memory, range 64, base 0xf2000000, size 33554432, >> enabled >> > bar [24] = type I/O Port, range 32, base 0xdf00, size 128, enabled >> >> My current theory is that the nvidia aperture size is 256MB, as indicated >> by bar at 14, and nvidia driver tries to map the whole aperture into KVA. >> >> With 4GB of RAM and i386, available 1GB of the KVA become quite tightly >> populated, and even small changes in the layout make the mapping of >> 256MB impossible. If I am right, this is more an issue with nvidia. >> >> Still, the layout should have not changed much, if at all. I want the >> kgdb information listed above to confirm/deny this. >> >> If you could configure AMT SOL console, then my theory about nvidia >> mapping >> the whole aperture could be confirmed or denied. >> >> Thank you. >> > > I appear to be experiencing the same issue. I've been following this > thread. I have a coredump, but it's over 700mb in size. What would be the > best way to get that to you guys? The revision I'm at is r248583 on amd64 > (6GB RAM) with an NVIDIA Quadro FX 580. Relevant lines from `pciconf -lvb`: > > vgapci0@pci0:3:0:0: class=0x030000 card=0x063a10de chip=0x065910de > rev=0xa1 hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'G96 [Quadro FX 580]' > class = display > subclass = VGA > bar [10] = type Memory, range 32, base 0xf6000000, size 16777216, > enabled > bar [14] = type Prefetchable Memory, range 64, base 0xc0000000, size > 536870912, enabled > bar [1c] = type Memory, range 64, base 0xf4000000, size 33554432, > enabled > bar [24] = type I/O Port, range 32, base 0xdc80, size 128, enabled > > Looks like setting both vfs.unmapped_buf_allowed=0 and kern.bio_transient_maxcnt=512 worked for me. I'm now up and running smoothly. From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 16:41:32 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A74E97B5; Thu, 21 Mar 2013 16:41:32 +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 7DE1AA47; Thu, 21 Mar 2013 16:41:32 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2LGfViU024135; Thu, 21 Mar 2013 12:41:31 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2LGfVh2024106; Thu, 21 Mar 2013 16:41:31 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 21 Mar 2013 16:41:31 GMT Message-Id: <201303211641.r2LGfVh2024106@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 16:41:32 -0000 TB --- 2013-03-21 14:43:15 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-21 14:43:15 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-21 14:43:15 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-03-21 14:43:15 - cleaning the object tree TB --- 2013-03-21 14:43:15 - /usr/local/bin/svn stat /src TB --- 2013-03-21 14:43:18 - At svn revision 248579 TB --- 2013-03-21 14:43:19 - building world TB --- 2013-03-21 14:43:19 - CROSS_BUILD_TESTING=YES TB --- 2013-03-21 14:43:19 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-21 14:43:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-21 14:43:19 - SRCCONF=/dev/null TB --- 2013-03-21 14:43:19 - TARGET=powerpc TB --- 2013-03-21 14:43:19 - TARGET_ARCH=powerpc TB --- 2013-03-21 14:43:19 - TZ=UTC TB --- 2013-03-21 14:43:19 - __MAKE_CONF=/dev/null TB --- 2013-03-21 14:43:19 - cd /src TB --- 2013-03-21 14:43:19 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Mar 21 14:43:24 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas -o sgsmsg avl.o sgsmsg.o string_table.o findprime.o ===> cddl/usr.bin/zinject (all) cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/zinject.c cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c: In function 'translate_record': /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c:383: warning: passing argument 4 of 'calculate_range' discards qualifiers from pointer target type cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas -o zinject zinject.o translate.o -lgeom -lm -lnvpair -lumem -luutil -lzfs_core -lzfs -lzpool /obj/powerpc.powerpc/src/tmp/usr/lib/libzpool.so: undefined reference to `atomic_subtract_64' *** [zinject] Error code 1 Stop in /src/cddl/usr.bin/zinject. *** [all] Error code 1 Stop in /src/cddl/usr.bin. *** [all] Error code 1 Stop in /src/cddl. *** [cddl.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-21 16:41:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-21 16:41:31 - ERROR: failed to build world TB --- 2013-03-21 16:41:31 - 5970.74 user 782.49 system 7095.82 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 16:49:48 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 84891C83; Thu, 21 Mar 2013 16:49:48 +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 3D1A4ADF; Thu, 21 Mar 2013 16:49:48 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2LGnlRK066449; Thu, 21 Mar 2013 12:49:47 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2LGnlsb066448; Thu, 21 Mar 2013 16:49:47 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 21 Mar 2013 16:49:47 GMT Message-Id: <201303211649.r2LGnlsb066448@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 16:49:48 -0000 TB --- 2013-03-21 15:32:29 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-21 15:32:29 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-21 15:32:29 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-03-21 15:32:29 - cleaning the object tree TB --- 2013-03-21 15:32:29 - /usr/local/bin/svn stat /src TB --- 2013-03-21 15:32:32 - At svn revision 248579 TB --- 2013-03-21 15:32:33 - building world TB --- 2013-03-21 15:32:33 - CROSS_BUILD_TESTING=YES TB --- 2013-03-21 15:32:33 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-21 15:32:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-21 15:32:33 - SRCCONF=/dev/null TB --- 2013-03-21 15:32:33 - TARGET=sparc64 TB --- 2013-03-21 15:32:33 - TARGET_ARCH=sparc64 TB --- 2013-03-21 15:32:33 - TZ=UTC TB --- 2013-03-21 15:32:33 - __MAKE_CONF=/dev/null TB --- 2013-03-21 15:32:33 - cd /src TB --- 2013-03-21 15:32:33 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Mar 21 15:32:37 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Mar 21 16:41:22 UTC 2013 TB --- 2013-03-21 16:41:22 - generating LINT kernel config TB --- 2013-03-21 16:41:22 - cd /src/sys/sparc64/conf TB --- 2013-03-21 16:41:22 - /usr/bin/make -B LINT TB --- 2013-03-21 16:41:22 - cd /src/sys/sparc64/conf TB --- 2013-03-21 16:41:22 - /usr/sbin/config -m LINT TB --- 2013-03-21 16:41:22 - building LINT kernel TB --- 2013-03-21 16:41:22 - CROSS_BUILD_TESTING=YES TB --- 2013-03-21 16:41:22 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-21 16:41:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-21 16:41:22 - SRCCONF=/dev/null TB --- 2013-03-21 16:41:22 - TARGET=sparc64 TB --- 2013-03-21 16:41:22 - TARGET_ARCH=sparc64 TB --- 2013-03-21 16:41:22 - TZ=UTC TB --- 2013-03-21 16:41:22 - __MAKE_CONF=/dev/null TB --- 2013-03-21 16:41:22 - cd /src TB --- 2013-03-21 16:41:22 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Mar 21 16:41:22 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/fs/nfsclient/nfs_clrpcops.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/fs/nfsclient/nfs_clvnops.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/fs/nfsclient/nfs_clnode.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/fs/nfsclient/nfs_clvfsops.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/fs/nfsclient/nfs_clport.c cc1: warnings being treated as errors /src/sys/fs/nfsclient/nfs_clport.c: In function 'nfscl_loadattrcache': /src/sys/fs/nfsclient/nfs_clport.c:364: warning: 'nsize' may be used uninitialized in this function *** [nfs_clport.o] Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-21 16:49:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-21 16:49:47 - ERROR: failed to build LINT kernel TB --- 2013-03-21 16:49:47 - 3667.82 user 622.25 system 4638.40 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 18:14:31 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2F7E86AC for ; Thu, 21 Mar 2013 18:14:31 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-bk0-x229.google.com (mail-bk0-x229.google.com [IPv6:2a00:1450:4008:c01::229]) by mx1.freebsd.org (Postfix) with ESMTP id AF537188 for ; Thu, 21 Mar 2013 18:14:30 +0000 (UTC) Received: by mail-bk0-f41.google.com with SMTP id q16so1532798bkw.28 for ; Thu, 21 Mar 2013 11:14:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:x-mailer:mime-version:content-type :content-transfer-encoding; bh=ya7ytlhq6RXoJtnqvnQmNTfSI5lYQQPi7peZmyNGDws=; b=qYXvLHie+q97zSFoUy8a/lben6cwAElhAxSK8KRAR/l4h6Q8tntikpUvcTVAVozTv+ 6A40B+UN5MtwizmvyMzZfy/NtO7PpXCcpheYbXGw3+V2Dg9PCN/MJQAFA7ELwXZpVAad mR71cNcnXtAp1pMnoH8DEO+zPxphCENLHNR0DevpjcIYADy/YE9GxI4nMSa9yG5HroaE UyPCqz5hnbu9AaJWjVdH5BVPCSd5K4U8UdaLNVaUP4qiFnCXUApjgbLJ1KoCFnwAREks 9XElqkr1oLRCYkX6Mrpn+4/yN0h3IlMEXPLbOldkcT8Emf+RBTYWsSqQFOOQ+GRCUQNx kRgQ== X-Received: by 10.205.64.199 with SMTP id xj7mr13992148bkb.76.1363889669095; Thu, 21 Mar 2013 11:14:29 -0700 (PDT) Received: from ernst.jennejohn.org (p54895D77.dip.t-dialin.net. [84.137.93.119]) by mx.google.com with ESMTPS id o2sm1770194bkv.3.2013.03.21.11.14.27 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 21 Mar 2013 11:14:28 -0700 (PDT) Date: Thu, 21 Mar 2013 19:14:26 +0100 From: Gary Jennejohn To: Shawn Webb Subject: Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver Message-ID: <20130321191426.25b1b327@ernst.jennejohn.org> In-Reply-To: References: <20130320160056.GG32811@albert.catwhisker.org> <20130320171340.GE3794@kib.kiev.ua> <20130320173759.GK32811@albert.catwhisker.org> <20130320174458.GG3794@kib.kiev.ua> <20130320180239.GN32811@albert.catwhisker.org> <20130320200857.GN3794@kib.kiev.ua> <20130321013610.GB42912@albert.catwhisker.org> <20130321080441.GS3794@kib.kiev.ua> <20130321133446.GF42912@albert.catwhisker.org> <20130321135835.GX3794@kib.kiev.ua> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 18:14:31 -0000 On Thu, 21 Mar 2013 12:12:07 -0400 Shawn Webb wrote: [snip lots of stuff] > > I appear to be experiencing the same issue. I've been following this > > thread. I have a coredump, but it's over 700mb in size. What would be the > > best way to get that to you guys? The revision I'm at is r248583 on amd64 > > (6GB RAM) with an NVIDIA Quadro FX 580. Relevant lines from `pciconf -lvb`: > > > > vgapci0@pci0:3:0:0: class=0x030000 card=0x063a10de chip=0x065910de > > rev=0xa1 hdr=0x00 > > vendor = 'NVIDIA Corporation' > > device = 'G96 [Quadro FX 580]' > > class = display > > subclass = VGA > > bar [10] = type Memory, range 32, base 0xf6000000, size 16777216, > > enabled > > bar [14] = type Prefetchable Memory, range 64, base 0xc0000000, size > > 536870912, enabled > > bar [1c] = type Memory, range 64, base 0xf4000000, size 33554432, > > enabled > > bar [24] = type I/O Port, range 32, base 0xdc80, size 128, enabled > > > > > Looks like setting both vfs.unmapped_buf_allowed=0 and > kern.bio_transient_maxcnt=512 worked for me. I'm now up and running > smoothly. > I wonder whether there isn't some dependency on the graphics chip being used. I'm running r248589 AMD64 and didn't have to touch a thing to get X to start. But I'm using an older, presumably less demanding graphics chip: vgapci0@pci0:1:0:0: class=0x030000 card=0x19051462 chip=0x0a6510de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'GT218 [GeForce 210]' class = display subclass = VGA bar [10] = type Memory, range 32, base 0xfb000000, size 16777216, enabled bar [14] = type Prefetchable Memory, range 64, base 0xc0000000, size 268435456, enabled bar [1c] = type Prefetchable Memory, range 64, base 0xde000000, size 33554432, enabled bar [24] = type I/O Port, range 32, base 0xef00, size 128, enabled Above all, bar [14] is only half as large. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 18:17:49 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7259297B; Thu, 21 Mar 2013 18:17:49 +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 87F2C1D0; Thu, 21 Mar 2013 18:17:48 +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 UAA23310; Thu, 21 Mar 2013 20:17:40 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <514B4EC4.6000704@FreeBSD.org> Date: Thu, 21 Mar 2013 20:17:40 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130313 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Subject: Re: gptzfsboot problem on HP P410i Smart Array References: <51483621.2060503@FreeBSD.org> <201303191220.34088.jhb@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Bjorn Larsson , Sergey Dyatko , Christoph Hoffmann X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 18:17:49 -0000 I think it could be useful if those who have the hardware and have a support contract would try to get in touch with the _technical_ support and give them some technical details. Maybe it's something that could be easily fixed by the vendor if they know about the problem. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 18:19:50 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 44F95ACA; Thu, 21 Mar 2013 18:19:50 +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 18B581F2; Thu, 21 Mar 2013 18:19:49 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2LIJnCF096442; Thu, 21 Mar 2013 14:19:49 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2LIJn92096441; Thu, 21 Mar 2013 18:19:49 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 21 Mar 2013 18:19:49 GMT Message-Id: <201303211819.r2LIJn92096441@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 18:19:50 -0000 TB --- 2013-03-21 15:24:42 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-21 15:24:42 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-21 15:24:42 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-03-21 15:24:42 - cleaning the object tree TB --- 2013-03-21 15:24:42 - /usr/local/bin/svn stat /src TB --- 2013-03-21 15:24:45 - At svn revision 248579 TB --- 2013-03-21 15:24:46 - building world TB --- 2013-03-21 15:24:46 - CROSS_BUILD_TESTING=YES TB --- 2013-03-21 15:24:46 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-21 15:24:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-21 15:24:46 - SRCCONF=/dev/null TB --- 2013-03-21 15:24:46 - TARGET=powerpc TB --- 2013-03-21 15:24:46 - TARGET_ARCH=powerpc64 TB --- 2013-03-21 15:24:46 - TZ=UTC TB --- 2013-03-21 15:24:46 - __MAKE_CONF=/dev/null TB --- 2013-03-21 15:24:46 - cd /src TB --- 2013-03-21 15:24:46 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Mar 21 15:24:51 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu Mar 21 18:16:22 UTC 2013 TB --- 2013-03-21 18:16:22 - generating LINT kernel config TB --- 2013-03-21 18:16:22 - cd /src/sys/powerpc/conf TB --- 2013-03-21 18:16:22 - /usr/bin/make -B LINT TB --- 2013-03-21 18:16:22 - cd /src/sys/powerpc/conf TB --- 2013-03-21 18:16:22 - /usr/sbin/config -m LINT TB --- 2013-03-21 18:16:22 - skipping LINT kernel TB --- 2013-03-21 18:16:22 - cd /src/sys/powerpc/conf TB --- 2013-03-21 18:16:22 - /usr/sbin/config -m GENERIC TB --- 2013-03-21 18:16:22 - skipping GENERIC kernel TB --- 2013-03-21 18:16:22 - cd /src/sys/powerpc/conf TB --- 2013-03-21 18:16:22 - /usr/sbin/config -m GENERIC64 TB --- 2013-03-21 18:16:22 - building GENERIC64 kernel TB --- 2013-03-21 18:16:22 - CROSS_BUILD_TESTING=YES TB --- 2013-03-21 18:16:22 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-21 18:16:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-21 18:16:22 - SRCCONF=/dev/null TB --- 2013-03-21 18:16:22 - TARGET=powerpc TB --- 2013-03-21 18:16:22 - TARGET_ARCH=powerpc64 TB --- 2013-03-21 18:16:22 - TZ=UTC TB --- 2013-03-21 18:16:22 - __MAKE_CONF=/dev/null TB --- 2013-03-21 18:16:22 - cd /src TB --- 2013-03-21 18:16:22 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64 >>> Kernel build for GENERIC64 started on Thu Mar 21 18:16:22 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/fs/nfsclient/nfs_clrpcops.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/fs/nfsclient/nfs_clvnops.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/fs/nfsclient/nfs_clnode.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/fs/nfsclient/nfs_clvfsops.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/fs/nfsclient/nfs_clport.c cc1: warnings being treated as errors /src/sys/fs/nfsclient/nfs_clport.c: In function 'nfscl_loadattrcache': /src/sys/fs/nfsclient/nfs_clport.c:364: warning: 'nsize' may be used uninitialized in this function *** [nfs_clport.o] Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/GENERIC64. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-21 18:19:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-21 18:19:49 - ERROR: failed to build GENERIC64 kernel TB --- 2013-03-21 18:19:49 - 9090.73 user 1189.32 system 10506.91 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 18:30:08 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ABDF8E97 for ; Thu, 21 Mar 2013 18:30:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 1C0CC262 for ; Thu, 21 Mar 2013 18:30:07 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2LITtRh023483; Thu, 21 Mar 2013 20:29:55 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2LITtRh023483 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2LITt6O023482; Thu, 21 Mar 2013 20:29:55 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 21 Mar 2013 20:29:55 +0200 From: Konstantin Belousov To: Shawn Webb Subject: Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver Message-ID: <20130321182955.GA3794@kib.kiev.ua> References: <20130320173759.GK32811@albert.catwhisker.org> <20130320174458.GG3794@kib.kiev.ua> <20130320180239.GN32811@albert.catwhisker.org> <20130320200857.GN3794@kib.kiev.ua> <20130321013610.GB42912@albert.catwhisker.org> <20130321080441.GS3794@kib.kiev.ua> <20130321133446.GF42912@albert.catwhisker.org> <20130321135835.GX3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Usw4GpRT7CNDJhot" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 18:30:08 -0000 --Usw4GpRT7CNDJhot Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Mar 21, 2013 at 12:12:07PM -0400, Shawn Webb wrote: > Looks like setting both vfs.unmapped_buf_allowed=0 and > kern.bio_transient_maxcnt=512 worked for me. I'm now up and running > smoothly. The vfs.unmapped_buf_allowed=0 setting turns off the unmapped support, and kern.bio_transient_maxcnt value does not matter then. --Usw4GpRT7CNDJhot Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRS1GiAAoJEJDCuSvBvK1BnRYP/jGArNfl1/Nuj+BngLlUUok2 kBPkPWstqX8ByiEYu11pUDJOdc005n4A64D6b6JQXH0slTm7U4uWhBiuIxhoZAmg kCIDmTLowgtoK0qOU7a0YoyJxjIhVhe9hA48gHYAHCOBd1mu9y8UWCzNezKwFioE KOovMMAYeqwDCGBzfCCqCMh63QDu3jDTvpm5F8k9d56wyHbf/ZhgEd70id8JgScD wpnk1KqQwIxBsJ/17HgJfgSiVbvvqIHPdaLUgI8IhrXcpZqiDQb2dN/lDA7E/p3E jqiyn+3lOhqOWdOuZCnYltTVQ7AjFdRA8pERTPGkb87bUhicWMUJnMAzmoF1caSy J59vvEDlEPIcoifJyivQ757uwejkgALHTTh/9eIUvDtZZ6f4Adcg7xlG/qo9S+W1 QZ6LVYYr4PHUP9p4g7OMpBOIuPSD7VKv1LePsihq0M5crtC3YkbOpTjNMqEP7Or8 GO1mn5AXmP5qA9hEppxJt8cfta9FtC8rNXtaNjfhW8uY5S46Y/Env8MY0IvvvTd4 d2De0BDV2kqX2PFDJ9nrYpnz3suc0A940wl6BpPz6QqJOlrPFt1WVrbzRhgr/zpV 9zxzJcOrhC0/pHIh8q9wV6hFdXKvT1fcCMZtyIjVz3P8NPape42S/by07ggtQV0o EgGtECRiYnZr5DLAENZg =Iv5n -----END PGP SIGNATURE----- --Usw4GpRT7CNDJhot-- From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 18:31:09 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E1C97FB7 for ; Thu, 21 Mar 2013 18:31:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 83DB027F for ; Thu, 21 Mar 2013 18:31:09 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2LIV623024359; Thu, 21 Mar 2013 20:31:06 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2LIV623024359 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2LIV6Rd024358; Thu, 21 Mar 2013 20:31:06 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 21 Mar 2013 20:31:06 +0200 From: Konstantin Belousov To: Gary Jennejohn Subject: Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver Message-ID: <20130321183105.GB3794@kib.kiev.ua> References: <20130320174458.GG3794@kib.kiev.ua> <20130320180239.GN32811@albert.catwhisker.org> <20130320200857.GN3794@kib.kiev.ua> <20130321013610.GB42912@albert.catwhisker.org> <20130321080441.GS3794@kib.kiev.ua> <20130321133446.GF42912@albert.catwhisker.org> <20130321135835.GX3794@kib.kiev.ua> <20130321191426.25b1b327@ernst.jennejohn.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="09lCBepRY8u3UFgx" Content-Disposition: inline In-Reply-To: <20130321191426.25b1b327@ernst.jennejohn.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: current@freebsd.org, Shawn Webb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 18:31:09 -0000 --09lCBepRY8u3UFgx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 21, 2013 at 07:14:26PM +0100, Gary Jennejohn wrote: > I wonder whether there isn't some dependency on the graphics chip being > used. >=20 > I'm running r248589 AMD64 and didn't have to touch a thing to get X > to start. >=20 > But I'm using an older, presumably less demanding graphics chip: You use the amd64 kernel, which has ample KVA space. The problem is specific to i386. >=20 > vgapci0@pci0:1:0:0: class=3D0x030000 card=3D0x19051462 chip=3D0x0a651= 0de rev=3D0xa2 hdr=3D0x00 > vendor =3D 'NVIDIA Corporation' > device =3D 'GT218 [GeForce 210]' > class =3D display > subclass =3D VGA > bar [10] =3D type Memory, range 32, base 0xfb000000, size 16777216,= enabled > bar [14] =3D type Prefetchable Memory, range 64, base 0xc0000000, s= ize 268435456, enabled > bar [1c] =3D type Prefetchable Memory, range 64, base 0xde000000, s= ize 33554432, enabled > bar [24] =3D type I/O Port, range 32, base 0xef00, size 128, enabled >=20 > Above all, bar [14] is only half as large. --09lCBepRY8u3UFgx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRS1HpAAoJEJDCuSvBvK1B8sEP/iPoN7DSydkyh0N7AVwUFZDu 8Z8d4ZiN3U4Z6bbx89Xl8DDTU/BAsU9poE3JSA8+Y8BRkdMcoZeMC+7Dmqm1f3er lltJi63dAAg0JS8Z5yTJkby4O+PWrNIY84D2FCoC6ubB+i2UPKClyi+oAYFCCwFo YaHrjV2mzhB9h1s2IpdR+aecaVubwQA64361rGKvnv1au/aG/K9C49ipWHYwgSNo OvHr7DN5jEqgIg3jVegX5l9sdgKfpeaUDxFjZoTFI4rd857dlrjzGY9+NyXN58/c EdJit7osImXNLEHv0XuTOebUqM5kjZAmY/1XFvQLcnr7UBcrI4atQBctyn+WzNnA bViZ2fFX/bU+dCODgqr+Wf6C8+00aXMxo9+DbNN1UVtC8039yeKQ106XNNnwDKwW p5wKd4xne6GFvOurYqbqHMkpZQhIOhlLp2KXSf15XvM+gD7r9WzqjRivkSakRx4V sU/6yXVBwbPfqx2prHMkoTAK626HaUDoAyuWjyflammB4v5b6feDfmEmjJ2rT/6S Cx1HheqKxGIV+MSSKY2gASLOgHsuiQ0mktBg43QhkRmvYomoxEdWxn0nAY8q6jMZ 0F7YBtrGckiPgg/EEQpA6nuW5kYCe69T8P1gBGyUK534gvc9vzrfXrZZkyX/iaze f4a/RIGT8Z0HKx0kuA55 =gu/4 -----END PGP SIGNATURE----- --09lCBepRY8u3UFgx-- From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 19:32:32 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3F3F5E3D for ; Thu, 21 Mar 2013 19:32:32 +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 E11356DE for ; Thu, 21 Mar 2013 19:32:31 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.6/8.14.6) with ESMTP id r2LJWSdR052767; Thu, 21 Mar 2013 12:32:28 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.6/8.14.6/Submit) id r2LJWSan052766; Thu, 21 Mar 2013 12:32:28 -0700 (PDT) (envelope-from david) Date: Thu, 21 Mar 2013 12:32:28 -0700 From: David Wolfskill To: Konstantin Belousov Subject: Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver Message-ID: <20130321193228.GP42912@albert.catwhisker.org> References: <20130320160056.GG32811@albert.catwhisker.org> <20130320171340.GE3794@kib.kiev.ua> <20130320173759.GK32811@albert.catwhisker.org> <20130320174458.GG3794@kib.kiev.ua> <20130320180239.GN32811@albert.catwhisker.org> <20130320200857.GN3794@kib.kiev.ua> <20130321013610.GB42912@albert.catwhisker.org> <20130321080441.GS3794@kib.kiev.ua> <20130321133446.GF42912@albert.catwhisker.org> <20130321135835.GX3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WjWU9mUuKzTKEtBb" Content-Disposition: inline In-Reply-To: <20130321135835.GX3794@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 19:32:32 -0000 --WjWU9mUuKzTKEtBb Content-Type: multipart/mixed; boundary="7ZMy3ZKywLyoHonN" Content-Disposition: inline --7ZMy3ZKywLyoHonN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 21, 2013 at 03:58:35PM +0200, Konstantin Belousov wrote: > ... > > Script started on Thu Mar 21 06:07:41 2013 > > g1-235(10.0-C)[1] uname -a > > FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #845 r= 248575M/248575: Thu Mar 21 05:35:06 PDT 2013 root@g1-235.catwhisker.org= :/usr/obj/usr/src/sys/CANARY i386 > > g1-235(10.0-C)[2] sysctl vfs.unmapped_buf_allowed kern.bio_transient_ma= xcnt kern.nbuf > > vfs.unmapped_buf_allowed: 1 > > kern.bio_transient_maxcnt: 697 > > kern.nbuf: 7224 > Could you, please, do some more measurements in the r248575M ? >=20 > Please show the kern.nbuf for vfs.unmapped_buf_allowed=3D0 case. > Also, from there, run "kgdb /boot/kernel/kernel /dev/mem" and do > p *buffer_map. >=20 > Reboot without applying any unmapped/transient tuning, run the kgdb > again, and do > p *buffer_map > p *bio_transient_map >=20 > Reboot with kern.bio_transient_maxcnt tunable set to 256 and again > print the buffer_map and bio_transient_map from the kgdb. > ... OK; sorry about the delay -- I needed to use the machinie for a while (at work), and then I had a weekly staff meeting.... Anyway... I've attached results of the above. For the first & last, I did each twice -- once using the "nv" driver, and once using the "nvidia" driver. (The middle one only got the "nv" driver.) So the files are: kib_0_nv kib_0_nvidia kib_1_nv kib_2_nv kib_2_nvidia Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --7ZMy3ZKywLyoHonN Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=kib_0_nv Content-Transfer-Encoding: quoted-printable Script started on Thu Mar 21 10:39:14 2013 root@d129:~ # uname -a=0D=0D FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #845 r2485= 75M/248575: Thu Mar 21 05:35:06 PDT 2013 root@g1-235.catwhisker.org:/us= r/obj/usr/src/sys/CANARY i386=0D root@d129:~ # sysctl vfs.unmapped_buf_allowed=0D=0D vfs.unmapped_buf_allowed: 0=0D root@d129:~ # k=08=1B[Ksyst=08=1B[Kctl kern.nbuf=0D=0D kern.nbuf: 7224=0D root@d129:~ # kgdb /boot/kernel/kernel /dev/mem=0D=0D GNU gdb 6.1.1 [FreeBSD]=0D Copyright 2004 Free Software Foundation, Inc.=0D GDB is free software, covered by the GNU General Public License, and you ar= e=0D welcome to change it and/or distribute copies of it under certain condition= s.=0D Type "show copying" to see the conditions.=0D There is absolutely no warranty for GDB. Type "show warranty" for details.= =0D This GDB was configured as "i386-marcel-freebsd"...=0D Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/ker= nel/linux.ko.symbols...done.=0D done.=0D Loaded symbols for /boot/kernel/linux.ko=0D Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from /boot/= kernel/coretemp.ko.symbols...done.=0D done.=0D Loaded symbols for /boot/kernel/coretemp.ko=0D Reading symbols from /boot/kernel/iwn5000fw.ko...Reading symbols from /boot= /kernel/iwn5000fw.ko.symbols...done.=0D done.=0D Loaded symbols for /boot/kernel/iwn5000fw.ko=0D Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from /boot/ker= nel/tmpfs.ko.symbols...done.=0D done.=0D Loaded symbols for /boot/kernel/tmpfs.ko=0D Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from /boot/k= ernel/fdescfs.ko.symbols...done.=0D done.=0D Loaded symbols for /boot/kernel/fdescfs.ko=0D #0 sched_switch (td=3D0xc1312a70, newtd=3D0xcd98b900, flags=3D-1048441924)= =0D at /usr/src/sys/kern/sched_ule.c:1954=0D 1954 cpuid =3D PCPU_GET(cpuid);=0D (kgdb) p *buffer_map=0D $1 =3D {header =3D {prev =3D 0xc19cf288, next =3D 0xc19cf288, left =3D 0x0,= right =3D 0x0, =0D start =3D 3925868544, end =3D 4044226560, avail_ssize =3D 0, adj_free = =3D 0, =0D max_free =3D 0, object =3D {vm_object =3D 0x0, sub_map =3D 0x0}, offset= =3D 0, =0D eflags =3D 0, protection =3D 0 '\0', max_protection =3D 0 '\0', =0D inheritance =3D 0 '\0', read_ahead =3D 0 '\0', wired_count =3D 0, next_= read =3D 0, =0D cred =3D 0x0}, lock =3D {lock_object =3D {lo_name =3D 0xc0fc6c80 "vm ma= p (user)", =0D lo_flags =3D 36896768, lo_data =3D 0, lo_witness =3D 0xcd8022b0}, =0D sx_lock =3D 1}, system_mtx =3D {lock_object =3D {=0D lo_name =3D 0xc0fc6c52 "vm map (system)", lo_flags =3D 21168128, =0D lo_data =3D 0, lo_witness =3D 0xcd802110}, mtx_lock =3D 4}, nentries = =3D 1, =0D size =3D 84590592, timestamp =3D 5163, needs_wakeup =3D 0 '\0', =0D system_map =3D 1 '\001', flags =3D 0 '\0', root =3D 0xc19cf288, pmap =3D = 0xc13279f8, =0D busy =3D 0}=0D Current language: auto; currently minimal=0D (kgdb) p *bio_transient_map=0D Error accessing memory address 0x0: Bad address.=0D (kgdb) root@d129:~ # ^D=08=08exit=0D Script done on Thu Mar 21 10:40:35 2013 --7ZMy3ZKywLyoHonN Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=kib_0_nvidia Content-Transfer-Encoding: quoted-printable Script started on Thu Mar 21 10:43:15 2013 root@d129:~ # uname -a=0D=0D FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #845 r2485= 75M/248575: Thu Mar 21 05:35:06 PDT 2013 root@g1-235.catwhisker.org:/us= r/obj/usr/src/sys/CANARY i386=0D root@d129:~ # sysctl vfs.unmapped_buf_allowed=0D=0D vfs.unmapped_buf_allowed: 0=0D root@d129:~ # sysctl kern.nbuf=0D=0D kern.nbuf: 7224=0D root@d129:~ # kgdp=08=1B[Kb /boot/kernel/kernel /dev/mem=0D=0D GNU gdb 6.1.1 [FreeBSD]=0D Copyright 2004 Free Software Foundation, Inc.=0D GDB is free software, covered by the GNU General Public License, and you ar= e=0D welcome to change it and/or distribute copies of it under certain condition= s.=0D Type "show copying" to see the conditions.=0D There is absolutely no warranty for GDB. Type "show warranty" for details.= =0D This GDB was configured as "i386-marcel-freebsd"...=0D Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/ker= nel/linux.ko.symbols...done.=0D done.=0D Loaded symbols for /boot/kernel/linux.ko=0D Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from /boot/= kernel/coretemp.ko.symbols...done.=0D done.=0D Loaded symbols for /boot/kernel/coretemp.ko=0D Reading symbols from /boot/kernel/iwn5000fw.ko...Reading symbols from /boot= /kernel/iwn5000fw.ko.symbols...done.=0D done.=0D Loaded symbols for /boot/kernel/iwn5000fw.ko=0D Reading symbols from /boot/modules/nvidia.ko...done.=0D Loaded symbols for /boot/modules/nvidia.ko=0D Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from /boot/ker= nel/tmpfs.ko.symbols...done.=0D done.=0D Loaded symbols for /boot/kernel/tmpfs.ko=0D Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from /boot/k= ernel/fdescfs.ko.symbols...done.=0D done.=0D Loaded symbols for /boot/kernel/fdescfs.ko=0D #0 sched_switch (td=3D0xc1312a70, newtd=3D0xce18b900, flags=3D-1040053316)= =0D at /usr/src/sys/kern/sched_ule.c:1954=0D 1954 cpuid =3D PCPU_GET(cpuid);=0D (kgdb) p *buffer_map=0D $1 =3D {header =3D {prev =3D 0xc21ce630, next =3D 0xc21ce630, left =3D 0x0,= right =3D 0x0, =0D start =3D 3934257152, end =3D 4052615168, avail_ssize =3D 0, adj_free = =3D 0, =0D max_free =3D 0, object =3D {vm_object =3D 0x0, sub_map =3D 0x0}, offset= =3D 0, =0D eflags =3D 0, protection =3D 0 '\0', max_protection =3D 0 '\0', =0D inheritance =3D 0 '\0', read_ahead =3D 0 '\0', wired_count =3D 0, next_= read =3D 0, =0D cred =3D 0x0}, lock =3D {lock_object =3D {lo_name =3D 0xc0fc6c80 "vm ma= p (user)", =0D lo_flags =3D 36896768, lo_data =3D 0, lo_witness =3D 0xce0022b0}, =0D sx_lock =3D 1}, system_mtx =3D {lock_object =3D {=0D lo_name =3D 0xc0fc6c52 "vm map (system)", lo_flags =3D 21168128, =0D lo_data =3D 0, lo_witness =3D 0xce002110}, mtx_lock =3D 4}, nentries = =3D 1, =0D size =3D 85229568, timestamp =3D 5202, needs_wakeup =3D 0 '\0', =0D system_map =3D 1 '\001', flags =3D 0 '\0', root =3D 0xc21ce630, pmap =3D = 0xc13279f8, =0D busy =3D 0}=0D Current language: auto; currently minimal=0D (kgdb) p *bio_transient_map=0D Error accessing memory address 0x0: Bad address.=0D (kgdb) root@d129:~ # ^D=08=08exit=0D Script done on Thu Mar 21 10:44:35 2013 --7ZMy3ZKywLyoHonN Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=kib_1_nv Content-Transfer-Encoding: quoted-printable Script started on Thu Mar 21 10:46:18 2013 root@d129:~ # uname -a=0D=0D FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #845 r2485= 75M/248575: Thu Mar 21 05:35:06 PDT 2013 root@g1-235.catwhisker.org:/us= r/obj/usr/src/sys/CANARY i386=0D root@d129:~ # sysctl vfs.unmapped_buf_allowed=0D=0D vfs.unmapped_buf_allowed: 1=0D root@d129:~ # sysctl kern.nbuf=0D=0D kern.nbuf: 7224=0D root@d129:~ # kgdb /boot/kernel/kernel /dev/mem=0D=0D GNU gdb 6.1.1 [FreeBSD]=0D Copyright 2004 Free Software Foundation, Inc.=0D GDB is free software, covered by the GNU General Public License, and you ar= e=0D welcome to change it and/or distribute copies of it under certain condition= s.=0D Type "show copying" to see the conditions.=0D There is absolutely no warranty for GDB. Type "show warranty" for details.= =0D This GDB was configured as "i386-marcel-freebsd"...=0D Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/ker= nel/linux.ko.symbols...done.=0D done.=0D Loaded symbols for /boot/kernel/linux.ko=0D Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from /boot/= kernel/coretemp.ko.symbols...done.=0D done.=0D Loaded symbols for /boot/kernel/coretemp.ko=0D Reading symbols from /boot/kernel/iwn5000fw.ko...Reading symbols from /boot= /kernel/iwn5000fw.ko.symbols...done.=0D done.=0D Loaded symbols for /boot/kernel/iwn5000fw.ko=0D Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from /boot/ker= nel/tmpfs.ko.symbols...done.=0D done.=0D Loaded symbols for /boot/kernel/tmpfs.ko=0D Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from /boot/k= ernel/fdescfs.ko.symbols...done.=0D done.=0D Loaded symbols for /boot/kernel/fdescfs.ko=0D #0 sched_switch (td=3D0xc1312a70, newtd=3D0xcd98b600, flags=3D-1048441924)= =0D at /usr/src/sys/kern/sched_ule.c:1954=0D 1954 cpuid =3D PCPU_GET(cpuid);=0D (kgdb) p *buffer_map=0D $1 =3D {header =3D {prev =3D 0xc19ceb88, next =3D 0xc19ceb88, left =3D 0x0,= right =3D 0x0, =0D start =3D 3925868544, end =3D 4044226560, avail_ssize =3D 0, adj_free = =3D 0, =0D max_free =3D 0, object =3D {vm_object =3D 0x0, sub_map =3D 0x0}, offset= =3D 0, =0D eflags =3D 0, protection =3D 0 '\0', max_protection =3D 0 '\0', =0D inheritance =3D 0 '\0', read_ahead =3D 0 '\0', wired_count =3D 0, next_= read =3D 0, =0D cred =3D 0x0}, lock =3D {lock_object =3D {lo_name =3D 0xc0fc6c80 "vm ma= p (user)", =0D lo_flags =3D 36896768, lo_data =3D 0, lo_witness =3D 0xcd8022b0}, =0D sx_lock =3D 1}, system_mtx =3D {lock_object =3D {=0D lo_name =3D 0xc0fc6c52 "vm map (system)", lo_flags =3D 21168128, =0D lo_data =3D 0, lo_witness =3D 0xcd802110}, mtx_lock =3D 4}, nentries = =3D 1, =0D size =3D 8765440, timestamp =3D 535, needs_wakeup =3D 0 '\0', =0D system_map =3D 1 '\001', flags =3D 0 '\0', root =3D 0xc19ceb88, pmap =3D = 0xc13279f8, =0D busy =3D 0}=0D Current language: auto; currently minimal=0D (kgdb) p *bio_transient_map=0D $2 =3D {header =3D {prev =3D 0xc19c1230, next =3D 0xc19c1230, left =3D 0x0,= right =3D 0x0, =0D start =3D 4044226560, end =3D 4135583744, avail_ssize =3D 0, adj_free = =3D 0, =0D max_free =3D 0, object =3D {vm_object =3D 0x0, sub_map =3D 0x0}, offset= =3D 0, =0D eflags =3D 0, protection =3D 0 '\0', max_protection =3D 0 '\0', =0D inheritance =3D 0 '\0', read_ahead =3D 0 '\0', wired_count =3D 0, next_= read =3D 0, =0D cred =3D 0x0}, lock =3D {lock_object =3D {lo_name =3D 0xc0fc6c80 "vm ma= p (user)", =0D lo_flags =3D 36896768, lo_data =3D 0, lo_witness =3D 0xcd8022b0}, =0D sx_lock =3D 1}, system_mtx =3D {lock_object =3D {=0D lo_name =3D 0xc0fc6c52 "vm map (system)", lo_flags =3D 21168128, =0D lo_data =3D 0, lo_witness =3D 0xcd802110}, mtx_lock =3D 4}, nentries = =3D 0, =0D size =3D 0, timestamp =3D 0, needs_wakeup =3D 0 '\0', system_map =3D 1 '\= 001', =0D flags =3D 0 '\0', root =3D 0x0, pmap =3D 0xc13279f8, busy =3D 0}=0D (kgdb) root@d129:~ # ^D=08=08exit=0D Script done on Thu Mar 21 10:47:34 2013 --7ZMy3ZKywLyoHonN Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=kib_2_nv Content-Transfer-Encoding: quoted-printable Script started on Thu Mar 21 10:49:39 2013 root@d129:~ # uname -a=0D=0D FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #845 r2485= 75M/248575: Thu Mar 21 05:35:06 PDT 2013 root@g1-235.catwhisker.org:/us= r/obj/usr/src/sys/CANARY i386=0D root@d129:~ # sysctl vfs.unmapped_buf_allowed kern.bio_transient_maxcnt=0D= =0D vfs.unmapped_buf_allowed: 1=0D kern.bio_transient_maxcnt: 256=0D root@d129:~ # kgdb /boot/kernel/kernel /dev/mem=0D=0D GNU gdb 6.1.1 [FreeBSD]=0D Copyright 2004 Free Software Foundation, Inc.=0D GDB is free software, covered by the GNU General Public License, and you ar= e=0D welcome to change it and/or distribute copies of it under certain condition= s.=0D Type "show copying" to see the conditions.=0D There is absolutely no warranty for GDB. Type "show warranty" for details.= =0D This GDB was configured as "i386-marcel-freebsd"...=0D Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/ker= nel/linux.ko.symbols...done.=0D done.=0D Loaded symbols for /boot/kernel/linux.ko=0D Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from /boot/= kernel/coretemp.ko.symbols...done.=0D done.=0D Loaded symbols for /boot/kernel/coretemp.ko=0D Reading symbols from /boot/kernel/iwn5000fw.ko...Reading symbols from /boot= /kernel/iwn5000fw.ko.symbols...done.=0D done.=0D Loaded symbols for /boot/kernel/iwn5000fw.ko=0D Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from /boot/ker= nel/tmpfs.ko.symbols...done.=0D done.=0D Loaded symbols for /boot/kernel/tmpfs.ko=0D Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from /boot/k= ernel/fdescfs.ko.symbols...done.=0D done.=0D Loaded symbols for /boot/kernel/fdescfs.ko=0D #0 sched_switch (td=3D0xc1312a70, newtd=3D0xcd98b600, flags=3D-1048441924)= =0D at /usr/src/sys/kern/sched_ule.c:1954=0D 1954 cpuid =3D PCPU_GET(cpuid);=0D (kgdb) p *buffer_map=0D $1 =3D {header =3D {prev =3D 0xf64f4750, next =3D 0xf64f4750, left =3D 0x0,= right =3D 0x0, =0D start =3D 3925868544, end =3D 4044226560, avail_ssize =3D 0, adj_free = =3D 0, =0D max_free =3D 0, object =3D {vm_object =3D 0x0, sub_map =3D 0x0}, offset= =3D 0, =0D eflags =3D 0, protection =3D 0 '\0', max_protection =3D 0 '\0', =0D inheritance =3D 0 '\0', read_ahead =3D 0 '\0', wired_count =3D 0, next_= read =3D 0, =0D cred =3D 0x0}, lock =3D {lock_object =3D {lo_name =3D 0xc0fc6c80 "vm ma= p (user)", =0D lo_flags =3D 36896768, lo_data =3D 0, lo_witness =3D 0xcd8022b0}, =0D sx_lock =3D 1}, system_mtx =3D {lock_object =3D {=0D lo_name =3D 0xc0fc6c52 "vm map (system)", lo_flags =3D 21168128, =0D lo_data =3D 0, lo_witness =3D 0xcd802110}, mtx_lock =3D 4}, nentries = =3D 1, =0D size =3D 8814592, timestamp =3D 538, needs_wakeup =3D 0 '\0', =0D system_map =3D 1 '\001', flags =3D 0 '\0', root =3D 0xf64f4750, pmap =3D = 0xc13279f8, =0D busy =3D 0}=0D Current language: auto; currently minimal=0D (kgdb) p *bio_transienty_=08 =08=08 =08_map=0D $2 =3D {header =3D {prev =3D 0xc19c1230, next =3D 0xc19c1230, left =3D 0x0,= right =3D 0x0, =0D start =3D 4044226560, end =3D 4077780992, avail_ssize =3D 0, adj_free = =3D 0, =0D max_free =3D 0, object =3D {vm_object =3D 0x0, sub_map =3D 0x0}, offset= =3D 0, =0D eflags =3D 0, protection =3D 0 '\0', max_protection =3D 0 '\0', =0D inheritance =3D 0 '\0', read_ahead =3D 0 '\0', wired_count =3D 0, next_= read =3D 0, =0D cred =3D 0x0}, lock =3D {lock_object =3D {lo_name =3D 0xc0fc6c80 "vm ma= p (user)", =0D lo_flags =3D 36896768, lo_data =3D 0, lo_witness =3D 0xcd8022b0}, =0D sx_lock =3D 1}, system_mtx =3D {lock_object =3D {=0D lo_name =3D 0xc0fc6c52 "vm map (system)", lo_flags =3D 21168128, =0D lo_data =3D 0, lo_witness =3D 0xcd802110}, mtx_lock =3D 4}, nentries = =3D 0, =0D size =3D 0, timestamp =3D 0, needs_wakeup =3D 0 '\0', system_map =3D 1 '\= 001', =0D flags =3D 0 '\0', root =3D 0x0, pmap =3D 0xc13279f8, busy =3D 0}=0D (kgdb) root@d129:~ # ^D=08=08exit=0D Script done on Thu Mar 21 10:50:47 2013 --7ZMy3ZKywLyoHonN Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=kib_2_nvidia Content-Transfer-Encoding: quoted-printable Script started on Thu Mar 21 10:52:46 2013 root@d129:~ # uname -a=0D=0D FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #845 r2485= 75M/248575: Thu Mar 21 05:35:06 PDT 2013 root@g1-235.catwhisker.org:/us= r/obj/usr/src/sys/CANARY i386=0D root@d129:~ # sysctl vfs.unmapped_buf_allowed kern.bio_transient_mac=08=1B[= Kxcnt=0D=0D vfs.unmapped_buf_allowed: 1=0D kern.bio_transient_maxcnt: 256=0D root@d129:~ # kgdb /boot/kernel/kernel /dev/meme=08=1B[K=0D=0D GNU gdb 6.1.1 [FreeBSD]=0D Copyright 2004 Free Software Foundation, Inc.=0D GDB is free software, covered by the GNU General Public License, and you ar= e=0D welcome to change it and/or distribute copies of it under certain condition= s.=0D Type "show copying" to see the conditions.=0D There is absolutely no warranty for GDB. Type "show warranty" for details.= =0D This GDB was configured as "i386-marcel-freebsd"...=0D Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/ker= nel/linux.ko.symbols...done.=0D done.=0D Loaded symbols for /boot/kernel/linux.ko=0D Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from /boot/= kernel/coretemp.ko.symbols...done.=0D done.=0D Loaded symbols for /boot/kernel/coretemp.ko=0D Reading symbols from /boot/kernel/iwn5000fw.ko...Reading symbols from /boot= /kernel/iwn5000fw.ko.symbols...done.=0D done.=0D Loaded symbols for /boot/kernel/iwn5000fw.ko=0D Reading symbols from /boot/modules/nvidia.ko...done.=0D Loaded symbols for /boot/modules/nvidia.ko=0D Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from /boot/ker= nel/tmpfs.ko.symbols...done.=0D done.=0D Loaded symbols for /boot/kernel/tmpfs.ko=0D Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from /boot/k= ernel/fdescfs.ko.symbols...done.=0D done.=0D Loaded symbols for /boot/kernel/fdescfs.ko=0D #0 sched_switch (td=3D0xc1312a70, newtd=3D0xce18b600, flags=3D-1040053316)= =0D at /usr/src/sys/kern/sched_ule.c:1954=0D 1954 cpuid =3D PCPU_GET(cpuid);=0D (kgdb) p *buffer_map=0D $1 =3D {header =3D {prev =3D 0xc21cfd80, next =3D 0xc21cfd80, left =3D 0x0,= right =3D 0x0, =0D start =3D 3934257152, end =3D 4052615168, avail_ssize =3D 0, adj_free = =3D 0, =0D max_free =3D 0, object =3D {vm_object =3D 0x0, sub_map =3D 0x0}, offset= =3D 0, =0D eflags =3D 0, protection =3D 0 '\0', max_protection =3D 0 '\0', =0D inheritance =3D 0 '\0', read_ahead =3D 0 '\0', wired_count =3D 0, next_= read =3D 0, =0D cred =3D 0x0}, lock =3D {lock_object =3D {lo_name =3D 0xc0fc6c80 "vm ma= p (user)", =0D lo_flags =3D 36896768, lo_data =3D 0, lo_witness =3D 0xce0022b0}, =0D sx_lock =3D 1}, system_mtx =3D {lock_object =3D {=0D lo_name =3D 0xc0fc6c52 "vm map (system)", lo_flags =3D 21168128, =0D lo_data =3D 0, lo_witness =3D 0xce002110}, mtx_lock =3D 4}, nentries = =3D 1, =0D size =3D 8798208, timestamp =3D 537, needs_wakeup =3D 0 '\0', =0D system_map =3D 1 '\001', flags =3D 0 '\0', root =3D 0xc21cfd80, pmap =3D = 0xc13279f8, =0D busy =3D 0}=0D Current language: auto; currently minimal=0D (kgdb) p *bio_transient_map=0D $2 =3D {header =3D {prev =3D 0xc21c1230, next =3D 0xc21c1230, left =3D 0x0,= right =3D 0x0, =0D start =3D 4052615168, end =3D 4086169600, avail_ssize =3D 0, adj_free = =3D 0, =0D max_free =3D 0, object =3D {vm_object =3D 0x0, sub_map =3D 0x0}, offset= =3D 0, =0D eflags =3D 0, protection =3D 0 '\0', max_protection =3D 0 '\0', =0D inheritance =3D 0 '\0', read_ahead =3D 0 '\0', wired_count =3D 0, next_= read =3D 0, =0D cred =3D 0x0}, lock =3D {lock_object =3D {lo_name =3D 0xc0fc6c80 "vm ma= p (user)", =0D lo_flags =3D 36896768, lo_data =3D 0, lo_witness =3D 0xce0022b0}, =0D sx_lock =3D 1}, system_mtx =3D {lock_object =3D {=0D lo_name =3D 0xc0fc6c52 "vm map (system)", lo_flags =3D 21168128, =0D lo_data =3D 0, lo_witness =3D 0xce002110}, mtx_lock =3D 4}, nentries = =3D 0, =0D size =3D 0, timestamp =3D 0, needs_wakeup =3D 0 '\0', system_map =3D 1 '\= 001', =0D flags =3D 0 '\0', root =3D 0x0, pmap =3D 0xc13279f8, busy =3D 0}=0D (kgdb) ^Froot@d129:~ # =07^D=08=08exit=0D Script done on Thu Mar 21 10:53:52 2013 --7ZMy3ZKywLyoHonN-- --WjWU9mUuKzTKEtBb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFLYEwACgkQmprOCmdXAD2KVQCfRT/of1VXpph5tTpum/gcJGO6 SJcAn3VlyXPQ6dkQJXk73yvDlPkbuIXx =Weim -----END PGP SIGNATURE----- --WjWU9mUuKzTKEtBb-- From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 19:53:17 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1019A1DA; Thu, 21 Mar 2013 19:53:17 +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 D0DA379A; Thu, 21 Mar 2013 19:53:16 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2LJrGuM035318; Thu, 21 Mar 2013 15:53:16 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2LJrGgU035313; Thu, 21 Mar 2013 19:53:16 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 21 Mar 2013 19:53:16 GMT Message-Id: <201303211953.r2LJrGgU035313@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on armv6/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 19:53:17 -0000 TB --- 2013-03-21 18:20:23 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-21 18:20:23 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-21 18:20:23 - starting HEAD tinderbox run for armv6/arm TB --- 2013-03-21 18:20:23 - cleaning the object tree TB --- 2013-03-21 18:23:34 - /usr/local/bin/svn stat /src TB --- 2013-03-21 18:23:38 - At svn revision 248589 TB --- 2013-03-21 18:23:39 - building world TB --- 2013-03-21 18:23:39 - CROSS_BUILD_TESTING=YES TB --- 2013-03-21 18:23:39 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-21 18:23:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-21 18:23:39 - SRCCONF=/dev/null TB --- 2013-03-21 18:23:39 - TARGET=arm TB --- 2013-03-21 18:23:39 - TARGET_ARCH=armv6 TB --- 2013-03-21 18:23:39 - TZ=UTC TB --- 2013-03-21 18:23:39 - __MAKE_CONF=/dev/null TB --- 2013-03-21 18:23:39 - cd /src TB --- 2013-03-21 18:23:39 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Mar 21 18:23:43 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-pointer-sign -Wno-unknown-pragmas -o sgsmsg avl.o sgsmsg.o string_table.o findprime.o ===> cddl/usr.bin/zinject (all) cc -O -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/zinject.c cc -O -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c: In function 'translate_record': /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c:383: warning: passing argument 4 of 'calculate_range' discards qualifiers from pointer target type cc -O -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-pointer-sign -Wno-unknown-pragmas -o zinject zinject.o translate.o -lgeom -lm -lnvpair -lumem -luutil -lzfs_core -lzfs -lzpool /obj/arm.armv6/src/tmp/usr/lib/libzpool.so: undefined reference to `atomic_subtract_64' *** [zinject] Error code 1 Stop in /src/cddl/usr.bin/zinject. *** [all] Error code 1 Stop in /src/cddl/usr.bin. *** [all] Error code 1 Stop in /src/cddl. *** [cddl.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-21 19:53:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-21 19:53:15 - ERROR: failed to build world TB --- 2013-03-21 19:53:15 - 4347.24 user 776.01 system 5572.29 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-armv6-arm.full From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 19:53:17 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 13C541DB; Thu, 21 Mar 2013 19:53:17 +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 D21D479B; Thu, 21 Mar 2013 19:53:16 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2LJrGo1035320; Thu, 21 Mar 2013 15:53:16 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2LJrGVD035319; Thu, 21 Mar 2013 19:53:16 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 21 Mar 2013 19:53:16 GMT Message-Id: <201303211953.r2LJrGVD035319@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 19:53:17 -0000 TB --- 2013-03-21 18:20:23 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-21 18:20:23 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-21 18:20:23 - starting HEAD tinderbox run for arm/arm TB --- 2013-03-21 18:20:23 - cleaning the object tree TB --- 2013-03-21 18:23:35 - /usr/local/bin/svn stat /src TB --- 2013-03-21 18:23:38 - At svn revision 248589 TB --- 2013-03-21 18:23:39 - building world TB --- 2013-03-21 18:23:39 - CROSS_BUILD_TESTING=YES TB --- 2013-03-21 18:23:39 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-21 18:23:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-21 18:23:39 - SRCCONF=/dev/null TB --- 2013-03-21 18:23:39 - TARGET=arm TB --- 2013-03-21 18:23:39 - TARGET_ARCH=arm TB --- 2013-03-21 18:23:39 - TZ=UTC TB --- 2013-03-21 18:23:39 - __MAKE_CONF=/dev/null TB --- 2013-03-21 18:23:39 - cd /src TB --- 2013-03-21 18:23:39 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Mar 21 18:23:43 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-pointer-sign -Wno-unknown-pragmas -o sgsmsg avl.o sgsmsg.o string_table.o findprime.o ===> cddl/usr.bin/zinject (all) cc -O -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/zinject.c cc -O -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c: In function 'translate_record': /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c:383: warning: passing argument 4 of 'calculate_range' discards qualifiers from pointer target type cc -O -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-pointer-sign -Wno-unknown-pragmas -o zinject zinject.o translate.o -lgeom -lm -lnvpair -lumem -luutil -lzfs_core -lzfs -lzpool /obj/arm.arm/src/tmp/usr/lib/libzpool.so: undefined reference to `atomic_subtract_64' *** [zinject] Error code 1 Stop in /src/cddl/usr.bin/zinject. *** [all] Error code 1 Stop in /src/cddl/usr.bin. *** [all] Error code 1 Stop in /src/cddl. *** [cddl.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-21 19:53:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-21 19:53:16 - ERROR: failed to build world TB --- 2013-03-21 19:53:16 - 4350.30 user 776.02 system 5572.50 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 20:44:51 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2033E61B; Thu, 21 Mar 2013 20:44:51 +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 EA3079E8; Thu, 21 Mar 2013 20:44:50 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2LKioVf008021; Thu, 21 Mar 2013 16:44:50 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2LKioQt008020; Thu, 21 Mar 2013 20:44:50 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 21 Mar 2013 20:44:50 GMT Message-Id: <201303212044.r2LKioQt008020@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 20:44:51 -0000 TB --- 2013-03-21 18:20:23 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-21 18:20:23 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-21 18:20:23 - starting HEAD tinderbox run for i386/i386 TB --- 2013-03-21 18:20:23 - cleaning the object tree TB --- 2013-03-21 18:23:39 - /usr/local/bin/svn stat /src TB --- 2013-03-21 18:23:42 - At svn revision 248589 TB --- 2013-03-21 18:23:43 - building world TB --- 2013-03-21 18:23:43 - CROSS_BUILD_TESTING=YES TB --- 2013-03-21 18:23:43 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-21 18:23:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-21 18:23:43 - SRCCONF=/dev/null TB --- 2013-03-21 18:23:43 - TARGET=i386 TB --- 2013-03-21 18:23:43 - TARGET_ARCH=i386 TB --- 2013-03-21 18:23:43 - TZ=UTC TB --- 2013-03-21 18:23:43 - __MAKE_CONF=/dev/null TB --- 2013-03-21 18:23:43 - cd /src TB --- 2013-03-21 18:23:43 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Mar 21 18:23:47 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -c /src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/tools/common/findprime.c cc -O2 -pipe -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -o sgsmsg avl.o sgsmsg.o string_table.o findprime.o ===> cddl/usr.bin/zinject (all) cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-c! onversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/zinject.c cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-c! onversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-c! onversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -o zinject zinject.o translate.o -lgeom -lm -lnvpair -lumem -luutil -lzfs_core -lzfs -lzpool /obj/i386.i386/src/tmp/usr/lib/libzpool.so: undefined reference to `atomic_subtract_64' cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [zinject] Error code 1 Stop in /src/cddl/usr.bin/zinject. *** [all] Error code 1 Stop in /src/cddl/usr.bin. *** [all] Error code 1 Stop in /src/cddl. *** [cddl.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-21 20:44:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-21 20:44:50 - ERROR: failed to build world TB --- 2013-03-21 20:44:50 - 7102.27 user 950.33 system 8666.58 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 20:45:12 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A6811748 for ; Thu, 21 Mar 2013 20:45:12 +0000 (UTC) (envelope-from dlt@mebtel.net) Received: from mail959c35.nsolutionszone.com (mail959c35.nsolutionszone.com [209.235.152.149]) by mx1.freebsd.org (Postfix) with ESMTP id 440449FF for ; Thu, 21 Mar 2013 20:45:12 +0000 (UTC) Received: from localhost (99-194-28-143.dyn.centurytel.net [99.194.28.143]) by mail959c35.nsolutionszone.com (8.13.6/8.13.1) with ESMTP id r2LK7LCO022289; Thu, 21 Mar 2013 20:07:23 GMT Date: Thu, 21 Mar 2013 16:07:21 -0400 From: Derek Tattersall To: current@FreeBSD.org Subject: Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver Message-ID: <20130321200721.GA2149@oriental.arm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-CSC: 0 X-CHA: v=1.1 cv=HXu7G0JZfLHvLI6YsaKaGlANmZA1MslZX/Vhz8GLc0Y= c=1 sm=1 a=wom5GMh1gUkA:10 a=8dZW0WHuYTYA:10 a=P2oOn6vrs4wA:10 a=GPr01A5e9VcA:10 a=kj9zAlcOel0A:10 a=IcaekXDbmfGgJsrWNwHfZw==:17 a=xwPayol1AAAA:8 a=CjxXgO3LAAAA:8 a=pGLkceISAAAA:8 a=ddT561YyyIs65KBBziIA:9 a=CjuIK1q_8ugA:10 a=0Ob1RWNGeVAA:10 a=rC2wZJ5BpNYA:10 a=MSl-tDqOz04A:10 a=IcaekXDbmfGgJsrWNwHfZw==:117 X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A020204.514B687B.010B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Cc: Konstantin Belousov , Shawn Webb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: dlt@mebtel.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, 21 Mar 2013 20:45:12 -0000 iI am @248554 on an AMD64 box with 8 gig of memory, and a 64 bit kernel. The video is on the motherboard and is a Radeon chipset. I also experienced the panic while starting XDM. I found Shawn's suggested remedy of etting both vfs.unmapped_buf_allowed=0 and kern.bio_transient_maxcnt=512 in /boot/loader.conf allows the box to boot, XDM to start and everything seems to be working. It's probably just my imagination, but it does seem slightly slower in starting applications. It seems that the common thing between my situation and Shawn's is the recent changes to drm.ko. -- Best regards, Derek Tattersall dlt@mebtel.net dlt666@yahoo.com dtatters@gmail.com From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 20:58:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B553597F for ; Thu, 21 Mar 2013 20:58:59 +0000 (UTC) (envelope-from jrisom@gmail.com) Received: from mail-ia0-x22b.google.com (mail-ia0-x22b.google.com [IPv6:2607:f8b0:4001:c02::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 8A332A83 for ; Thu, 21 Mar 2013 20:58:59 +0000 (UTC) Received: by mail-ia0-f171.google.com with SMTP id z13so2932939iaz.16 for ; Thu, 21 Mar 2013 13:58:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=ccsU5rZYxKoqR0x5pbTrIbJF6CoFzMsr+f3pKHG4uls=; b=n+1h4T9mjwU0RmDTH0EXuCkHyzr++GehPkHV0Ck4CPPuqbnw1S4rxNHaH+dV9K1l+q LBkGYD7EjKxNhax+GK+BxE/lm7/1OJvsENAxy6tWzva5ptPGQnDmEeREUPktpF2KcyAU ZnCC9WAucxxXXBCQyw0t5yv2tkjrvqzDE6J922cvXeuzS9F3TWMsDx6vw+4CbuWziepD KeXtU1W/IriYSbT79nLtUujVC561iTN5m0vHo51Y/No8cv9A7RL5Ko4skwsugpaQS1fH 6eGFrmCYbVFKAUKcVOnuwDH1qr+Jc29twBVnxHVQiEetCKqj9Y7Z/C1fFF0vo/DpSPIM W5Dg== X-Received: by 10.50.209.4 with SMTP id mi4mr3194183igc.40.1363899539272; Thu, 21 Mar 2013 13:58:59 -0700 (PDT) Received: from [192.168.1.14] (c-98-212-197-211.hsd1.il.comcast.net. [98.212.197.211]) by mx.google.com with ESMTPS id vb15sm2396848igb.9.2013.03.21.13.58.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Mar 2013 13:58:58 -0700 (PDT) Message-ID: <514B748F.80009@gmail.com> Date: Thu, 21 Mar 2013 15:58:55 -0500 From: Joshua Isom User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Kernel panics, one starting with r248508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 20:58:59 -0000 I've been helping Adrian test the new ath improvements that support the chipset I have. The first kernel panic is on my system if I have the cd driver loaded into the kernel, I would get a panic on boot. While "Mounting local file systems:" it would panic with "Memory modified after free." Removing the driver solved it. I'd rather have wireless than cd for right now anyway. But a couple days ago a new build would always panic, a couple seconds after getty is spawned. All I get is "panic: Bio too short 0xfffffe000b1395d0." Before that, the builds worked other than occasional issues due to cleaning. The only place that panic can be generated is geom_io.c so I'm guessing I can't just remove the driver. What needs done so I can get a working kernel again? From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 21:27:16 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4CE7DFA8; Thu, 21 Mar 2013 21:27:16 +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 16F8FB79; Thu, 21 Mar 2013 21:27:15 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2LLRFYA030111; Thu, 21 Mar 2013 17:27:15 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2LLRFQj030103; Thu, 21 Mar 2013 21:27:15 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 21 Mar 2013 21:27:15 GMT Message-Id: <201303212127.r2LLRFQj030103@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 21:27:16 -0000 TB --- 2013-03-21 20:44:50 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-21 20:44:50 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-21 20:44:50 - starting HEAD tinderbox run for mips/mips TB --- 2013-03-21 20:44:50 - cleaning the object tree TB --- 2013-03-21 20:45:24 - /usr/local/bin/svn stat /src TB --- 2013-03-21 20:45:27 - At svn revision 248589 TB --- 2013-03-21 20:45:28 - building world TB --- 2013-03-21 20:45:28 - CROSS_BUILD_TESTING=YES TB --- 2013-03-21 20:45:28 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-21 20:45:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-21 20:45:28 - SRCCONF=/dev/null TB --- 2013-03-21 20:45:28 - TARGET=mips TB --- 2013-03-21 20:45:28 - TARGET_ARCH=mips TB --- 2013-03-21 20:45:28 - TZ=UTC TB --- 2013-03-21 20:45:28 - __MAKE_CONF=/dev/null TB --- 2013-03-21 20:45:28 - cd /src TB --- 2013-03-21 20:45:28 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Mar 21 20:45:32 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -G0 -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-pointer-sign -Wno-unknown-pragmas -o sgsmsg avl.o sgsmsg.o string_table.o findprime.o ===> cddl/usr.bin/zinject (all) cc -O -pipe -G0 -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/zinject.c cc -O -pipe -G0 -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c: In function 'translate_record': /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c:383: warning: passing argument 4 of 'calculate_range' discards qualifiers from pointer target type cc -O -pipe -G0 -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-pointer-sign -Wno-unknown-pragmas -o zinject zinject.o translate.o -lgeom -lm -lnvpair -lumem -luutil -lzfs_core -lzfs -lzpool /obj/mips.mips/src/tmp/usr/lib/libzpool.so: undefined reference to `atomic_subtract_64' *** [zinject] Error code 1 Stop in /src/cddl/usr.bin/zinject. *** [all] Error code 1 Stop in /src/cddl/usr.bin. *** [all] Error code 1 Stop in /src/cddl. *** [cddl.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-21 21:27:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-21 21:27:14 - ERROR: failed to build world TB --- 2013-03-21 21:27:14 - 1698.02 user 514.73 system 2544.49 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 21:30:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 56A191CE; Thu, 21 Mar 2013 21:30:19 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by mx1.freebsd.org (Postfix) with ESMTP id C4195BF7; Thu, 21 Mar 2013 21:30:18 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id hi18so3647218wib.3 for ; Thu, 21 Mar 2013 14:30:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=IjgmQ3hYws1YlgRcu+3raF7whNzjK/5bg/ac6qFILH0=; b=yqJlBJ6+s6tUdxwiNlTW1AuION2YqcdED7tWeOoIZHBpvqc9FoIeMXrj0LnQUYOFCn AR5TbzsHu2MI9KFs4cWXUiIg2br53IJooSkISWITiG2fA2zJY7oZXasSC2INDaYYW9kR FfWmq7I6UH9DI6/HJjGwJE2FJeEInF+uTBPmJbwCBz9JU5MmP5kzTyK9DuBE5eXR+cpI i9zzITp2k4s2Dy8c9vnHWVaLNu0RO1+5Zee1Ne33mZ4MOWI6CzggRUuKSoH5//4wNtGQ ROqzxL6BB+eLv4Pya1axaZdf2UDtGs2FMW+axx4bNAJyASwpKwyTWquXQ1ZNxolIM+SE Eo9w== MIME-Version: 1.0 X-Received: by 10.180.189.205 with SMTP id gk13mr4775851wic.25.1363901417966; Thu, 21 Mar 2013 14:30:17 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Thu, 21 Mar 2013 14:30:17 -0700 (PDT) In-Reply-To: <514B748F.80009@gmail.com> References: <514B748F.80009@gmail.com> Date: Thu, 21 Mar 2013 14:30:17 -0700 X-Google-Sender-Auth: qXos8JgzPHZcI-mk-MKbHxPtN3w Message-ID: Subject: Re: Kernel panics, one starting with r248508 From: Adrian Chadd To: Joshua Isom , Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 21:30:19 -0000 grr, another possible fallout from the unmapped io from kib? Kib? Adrian On 21 March 2013 13:58, Joshua Isom wrote: > I've been helping Adrian test the new ath improvements that support the > chipset I have. The first kernel panic is on my system if I have the cd > driver loaded into the kernel, I would get a panic on boot. While "Mounting > local file systems:" it would panic with "Memory modified after free." > Removing the driver solved it. I'd rather have wireless than cd for right > now anyway. But a couple days ago a new build would always panic, a couple > seconds after getty is spawned. All I get is "panic: Bio too short > 0xfffffe000b1395d0." Before that, the builds worked other than occasional > issues due to cleaning. The only place that panic can be generated is > geom_io.c so I'm guessing I can't just remove the driver. What needs done > so I can get a working kernel again? > _______________________________________________ > 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 Mar 21 22:09:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 87FD6C7D; Thu, 21 Mar 2013 22:09:15 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 49345E27; Thu, 21 Mar 2013 22:09:15 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::e55c:d560:d108:32ea] (unknown [IPv6:2001:7b8:3a7:0:e55c:d560:d108:32ea]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id C03D65C5B; Thu, 21 Mar 2013 23:09:06 +0100 (CET) Content-Type: multipart/mixed; boundary="Apple-Mail=_EA33AD19-AED4-4FCC-A396-907B0E557429" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: troubles with buildworld/sendmail/sasl/clang From: Dimitry Andric In-Reply-To: <201303211416.r2LEG8cG041216@mech-cluster241.men.bris.ac.uk> Date: Thu, 21 Mar 2013 23:09:08 +0100 Message-Id: <7DFCA510-5230-4EB6-8199-199DE7F8DE67@FreeBSD.org> References: <201303211416.r2LEG8cG041216@mech-cluster241.men.bris.ac.uk> To: mexas@bristol.ac.uk X-Mailer: Apple Mail (2.1503) Cc: kpaasial@gmail.com, roberthuff@rcn.com, freebsd-stable@freebsd.org, beat.siegenthaler@beatsnet.com, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 22:09:15 -0000 --Apple-Mail=_EA33AD19-AED4-4FCC-A396-907B0E557429 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 21, 2013, at 15:16, Anton Shterenlikht = wrote: > Kimmo Paasiala writes: ... > > > = /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/usersmtp.c:1864:8: > > > error: incompatible pointer types passing 'void ()' to = parameter of type > > > 'void (*)(char *, bool, MAILER *, struct mailer_con_info *, = ENVELOPE *)' > > > [-Werror,-Wincompatible-pointer-types] > > > getsasldata, NULL, = XS_AUTH); > > > ^~~~~~~~~~~ ... > # cat /etc/make.conf > SENDMAIL_CFLAGS+=3D -I/usr/local/include -DSASL=3D2 > SENDMAIL_LDFLAGS+=3D -L/usr/local/lib > SENDMAIL_LDADD+=3D -lsasl2 Use the port, or the attached patch, to disable usage of stdbool.h. --Apple-Mail=_EA33AD19-AED4-4FCC-A396-907B0E557429 Content-Disposition: attachment; filename=sendmail-disable-stdbool-1.diff Content-Type: application/octet-stream; x-unix-mode=0644; name="sendmail-disable-stdbool-1.diff" Content-Transfer-Encoding: 7bit Index: contrib/sendmail/include/sm/gen.h =================================================================== --- contrib/sendmail/include/sm/gen.h (revision 248230) +++ contrib/sendmail/include/sm/gen.h (working copy) @@ -51,7 +51,7 @@ ** Define bool, true, false (from the C99 standard) */ -# if SM_CONF_STDBOOL_H +# if SM_CONF_STDBOOL_H && 0 # include # else /* SM_CONF_STDBOOL_H */ # ifndef __cplusplus --Apple-Mail=_EA33AD19-AED4-4FCC-A396-907B0E557429-- From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 22:24:36 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EE203157; Thu, 21 Mar 2013 22:24:36 +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 C2F74EA4; Thu, 21 Mar 2013 22:24:36 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2LMOatK028374; Thu, 21 Mar 2013 18:24:36 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2LMOaLm028373; Thu, 21 Mar 2013 22:24:36 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 21 Mar 2013 22:24:36 GMT Message-Id: <201303212224.r2LMOaLm028373@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 22:24:37 -0000 TB --- 2013-03-21 19:53:16 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-21 19:53:16 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-21 19:53:16 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-03-21 19:53:16 - cleaning the object tree TB --- 2013-03-21 19:55:03 - /usr/local/bin/svn stat /src TB --- 2013-03-21 19:55:20 - At svn revision 248589 TB --- 2013-03-21 19:55:21 - building world TB --- 2013-03-21 19:55:21 - CROSS_BUILD_TESTING=YES TB --- 2013-03-21 19:55:21 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-21 19:55:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-21 19:55:21 - SRCCONF=/dev/null TB --- 2013-03-21 19:55:21 - TARGET=pc98 TB --- 2013-03-21 19:55:21 - TARGET_ARCH=i386 TB --- 2013-03-21 19:55:21 - TZ=UTC TB --- 2013-03-21 19:55:21 - __MAKE_CONF=/dev/null TB --- 2013-03-21 19:55:21 - cd /src TB --- 2013-03-21 19:55:21 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Mar 21 19:55:26 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -c /src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/tools/common/findprime.c cc -O2 -pipe -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -o sgsmsg avl.o sgsmsg.o string_table.o findprime.o ===> cddl/usr.bin/zinject (all) cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-c! onversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/zinject.c cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-c! onversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-c! onversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -o zinject zinject.o translate.o -lgeom -lm -lnvpair -lumem -luutil -lzfs_core -lzfs -lzpool /obj/pc98.i386/src/tmp/usr/lib/libzpool.so: undefined reference to `atomic_subtract_64' cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [zinject] Error code 1 Stop in /src/cddl/usr.bin/zinject. *** [all] Error code 1 Stop in /src/cddl/usr.bin. *** [all] Error code 1 Stop in /src/cddl. *** [cddl.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-21 22:24:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-21 22:24:36 - ERROR: failed to build world TB --- 2013-03-21 22:24:36 - 7406.70 user 1034.98 system 9079.84 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 22:38:17 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4722991C for ; Thu, 21 Mar 2013 22:38:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id B5CD4F53 for ; Thu, 21 Mar 2013 22:38:16 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2LMcDse068191; Fri, 22 Mar 2013 00:38:13 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2LMcDse068191 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2LMcDco068190; Fri, 22 Mar 2013 00:38:13 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 22 Mar 2013 00:38:13 +0200 From: Konstantin Belousov To: Joshua Isom Subject: Re: Kernel panics, one starting with r248508 Message-ID: <20130321223813.GJ3794@kib.kiev.ua> References: <514B748F.80009@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="K9RQsdPs4If48RC1" Content-Disposition: inline In-Reply-To: <514B748F.80009@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 22:38:17 -0000 --K9RQsdPs4If48RC1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 21, 2013 at 03:58:55PM -0500, Joshua Isom wrote: > I've been helping Adrian test the new ath improvements that support the= =20 > chipset I have. The first kernel panic is on my system if I have the cd= =20 > driver loaded into the kernel, I would get a panic on boot. While=20 > "Mounting local file systems:" it would panic with "Memory modified=20 > after free." Removing the driver solved it. I'd rather have wireless=20 > than cd for right now anyway. But a couple days ago a new build would=20 > always panic, a couple seconds after getty is spawned. All I get is=20 > "panic: Bio too short 0xfffffe000b1395d0." Before that, the builds=20 > worked other than occasional issues due to cleaning. The only place=20 > that panic can be generated is geom_io.c so I'm guessing I can't just=20 > remove the driver. What needs done so I can get a working kernel again? Try r248596. If it does not help, get a core dump, load it into kgdb and do "p *(struct bio *)addr", where addr is reported in the panic message. --K9RQsdPs4If48RC1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRS4vUAAoJEJDCuSvBvK1BRB4P/iX7qlTKDz2sy5IrnMY2gjHo EYP788erRZEahzG+QrBCH6Z3q1MVasyv10m6lr3efema0yUHAFMwOMsVOypnSpsT OsdTpbH2Jw8osoB55JJ9f4dwPIxqKeQGY78HxPeznNHi/ry5kHs4s0xEyvii3aEv AVfMTTWI5aLCTGpHB5wh4U3empntGYG5tt7nyD9SrMYaltOn9lXKeo1SA8P9TjRR vepMdBzjWZydWgXKbzO8MB/A90Rhw2V32ydlcGgrhKzAj1dhwTMr3qSqi7uwa+uN Sk9favi/qRpxPOiiMOAlkMDC+oPoLZ5Krquqt4LRVaOH2NhC+X29UMNIipObnzsB 0BHj8idnmoNd2bBRgJu8wTtCGzTAyH6NNlfTtaih1oKJZn+1PNICLPy+6ForwBoc 9FnQHdEIDiOJ7IrZHumI6W1Vcw6pYFRCcPRsAe1X3LSnl0IFZoGrSxjifX1WXkZq pI0wc471HBop7MS6IZXdrnSOiQjWJTZGIW+pgMMJV60ime/ns6vqRdwjinQfmtI+ qaK1lx/gl+ddx/TqqjpxQuS8KAiHZeeyfCQQzXmAQUdHbyJk9Alv2xa2IA4731Rs 1Nj6aa+4fNBRLVTK/6MOYqvXe4p8FSvAvA+mId96LZnPYMVGYYheWNtENPkPI4ys Imwd8CyTmIEK9LOLiH8K =HyZG -----END PGP SIGNATURE----- --K9RQsdPs4If48RC1-- From owner-freebsd-current@FreeBSD.ORG Thu Mar 21 22:59:33 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E6EC9FC for ; Thu, 21 Mar 2013 22:59:33 +0000 (UTC) (envelope-from jrisom@gmail.com) Received: from mail-ia0-x233.google.com (mail-ia0-x233.google.com [IPv6:2607:f8b0:4001:c02::233]) by mx1.freebsd.org (Postfix) with ESMTP id BB4626E for ; Thu, 21 Mar 2013 22:59:33 +0000 (UTC) Received: by mail-ia0-f179.google.com with SMTP id x24so2987825iak.24 for ; Thu, 21 Mar 2013 15:59:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yYbKXjJZahgeFbc1zUO6q+8zuCLAttqvmMy1e0HvlPM=; b=nOuoh3GmzbEF/Rz3svlF5tiw2l20IE9rJcCRX1pXIFusyEDcnPQLqNJ2ekH8WmO7/A 7a2CLtOYoloqfEChYTrtcMPVxYvaNmWq4QkcvFTprAoXxvxX4tyt2Quia/1wEjMZAyce LMMuNequkpIYe+9E5v29eKHp5wZd698XaQSt3+X7eb+3qdmro2hg+UcL4mNsx8oUcVAt uByCrfa2KDcHSAmjf55IqkN7TZk02T4q+r+oOXSkC7Yqy3snFrpS2QpigPTGraJKxi3A 4eE1khTfymwJp3YL1HtWC34QFELhBifuItdELunXj7D59GMSRLlo/vLEp4S9YsGzFUos 5Dcg== X-Received: by 10.50.51.167 with SMTP id l7mr3395593igo.11.1363906773507; Thu, 21 Mar 2013 15:59:33 -0700 (PDT) Received: from [192.168.1.14] (c-98-212-197-211.hsd1.il.comcast.net. [98.212.197.211]) by mx.google.com with ESMTPS id in10sm8513611igc.1.2013.03.21.15.59.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Mar 2013 15:59:32 -0700 (PDT) Message-ID: <514B90D3.7080507@gmail.com> Date: Thu, 21 Mar 2013 17:59:31 -0500 From: Joshua Isom User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Kernel panics, one starting with r248508 References: <514B748F.80009@gmail.com> <20130321223813.GJ3794@kib.kiev.ua> In-Reply-To: <20130321223813.GJ3794@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 22:59:34 -0000 On 3/21/2013 5:38 PM, Konstantin Belousov wrote: > On Thu, Mar 21, 2013 at 03:58:55PM -0500, Joshua Isom wrote: >> I've been helping Adrian test the new ath improvements that support the >> chipset I have. The first kernel panic is on my system if I have the cd >> driver loaded into the kernel, I would get a panic on boot. While >> "Mounting local file systems:" it would panic with "Memory modified >> after free." Removing the driver solved it. I'd rather have wireless >> than cd for right now anyway. But a couple days ago a new build would >> always panic, a couple seconds after getty is spawned. All I get is >> "panic: Bio too short 0xfffffe000b1395d0." Before that, the builds >> worked other than occasional issues due to cleaning. The only place >> that panic can be generated is geom_io.c so I'm guessing I can't just >> remove the driver. What needs done so I can get a working kernel again? > > Try r248596. If it does not help, get a core dump, load it into kgdb > and do "p *(struct bio *)addr", where addr is reported in the panic message. > > [jri:/var/crash] root# kgdb /boot/kernel/kernel vmcore.10 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > panic: Bio too short 0xfffffe000a224c98 > cpuid = 1 > KDB: enter: panic > > Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/zfs.ko > Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/opensolaris.ko > Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols from /boot/kernel/geom_mirror.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/geom_mirror.ko > Reading symbols from /boot/kernel/if_ath.ko...Reading symbols from /boot/kernel/if_ath.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/if_ath.ko > Reading symbols from /boot/kernel/amdtemp.ko...Reading symbols from /boot/kernel/amdtemp.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/amdtemp.ko > Reading symbols from /boot/kernel/if_ath_pci.ko...Reading symbols from /boot/kernel/if_ath_pci.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/if_ath_pci.ko > Reading symbols from /boot/kernel/ums.ko...Reading symbols from /boot/kernel/ums.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/ums.ko > Reading symbols from /boot/kernel/ulpt.ko...Reading symbols from /boot/kernel/ulpt.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/ulpt.ko > Reading symbols from /boot/kernel/uhid.ko...Reading symbols from /boot/kernel/uhid.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/uhid.ko > Reading symbols from /boot/kernel/ipfw.ko...Reading symbols from /boot/kernel/ipfw.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/ipfw.ko > kgdb: kvm_read: invalid address (0x354541500000000) > #0 0x0000000000000000 in ?? () > (kgdb) p *(struct bio *)0xfffffe000a224c98 > $1 = {bio_cmd = 1 '\001', bio_flags = 16 '\020', bio_cflags = 0 '\0', bio_pflags = 0 '\0', > bio_dev = 0x0, bio_disk = 0x0, bio_offset = 0, bio_bcount = 0, > bio_data = 0xffffff8000206000
, > bio_ma = 0xffffff80204266d0, bio_ma_offset = 0, bio_ma_n = 17, bio_error = 0, bio_resid = 0, > bio_done = 0xffffffff8078e9b0 , bio_driver1 = 0x0, bio_driver2 = 0x0, > bio_caller1 = 0x0, bio_caller2 = 0x0, bio_queue = {tqe_next = 0x0, > tqe_prev = 0xffffffff8122f418}, bio_attribute = 0x0, bio_from = 0xfffffe000a29f700, > bio_to = 0xfffffe0007486800, bio_length = 65536, bio_completed = 0, bio_children = 0, > bio_inbed = 0, bio_parent = 0xfffffe000a2c7d90, bio_t0 = {sec = 83, > frac = 2480829560582148726}, bio_task = 0, bio_task_arg = 0x0, bio_classifier1 = 0x0, > bio_classifier2 = 0x0, bio_pblkno = 0} > (kgdb) From owner-freebsd-current@FreeBSD.ORG Fri Mar 22 00:25:12 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1E34075E; Fri, 22 Mar 2013 00:25: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 E980335F; Fri, 22 Mar 2013 00:25:11 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2M0PACf077481; Thu, 21 Mar 2013 20:25:10 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2M0PAcr077477; Fri, 22 Mar 2013 00:25:10 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 22 Mar 2013 00:25:10 GMT Message-Id: <201303220025.r2M0PAcr077477@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 00:25:12 -0000 TB --- 2013-03-21 22:24:36 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-21 22:24:36 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-21 22:24:36 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-03-21 22:24:36 - cleaning the object tree TB --- 2013-03-21 22:25:27 - /usr/local/bin/svn stat /src TB --- 2013-03-21 22:25:31 - At svn revision 248589 TB --- 2013-03-21 22:25:32 - building world TB --- 2013-03-21 22:25:32 - CROSS_BUILD_TESTING=YES TB --- 2013-03-21 22:25:32 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-21 22:25:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-21 22:25:32 - SRCCONF=/dev/null TB --- 2013-03-21 22:25:32 - TARGET=powerpc TB --- 2013-03-21 22:25:32 - TARGET_ARCH=powerpc TB --- 2013-03-21 22:25:32 - TZ=UTC TB --- 2013-03-21 22:25:32 - __MAKE_CONF=/dev/null TB --- 2013-03-21 22:25:32 - cd /src TB --- 2013-03-21 22:25:32 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Mar 21 22:25:37 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas -o sgsmsg avl.o sgsmsg.o string_table.o findprime.o ===> cddl/usr.bin/zinject (all) cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/zinject.c cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c: In function 'translate_record': /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c:383: warning: passing argument 4 of 'calculate_range' discards qualifiers from pointer target type cc -O2 -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas -o zinject zinject.o translate.o -lgeom -lm -lnvpair -lumem -luutil -lzfs_core -lzfs -lzpool /obj/powerpc.powerpc/src/tmp/usr/lib/libzpool.so: undefined reference to `atomic_subtract_64' *** [zinject] Error code 1 Stop in /src/cddl/usr.bin/zinject. *** [all] Error code 1 Stop in /src/cddl/usr.bin. *** [all] Error code 1 Stop in /src/cddl. *** [cddl.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-22 00:25:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-22 00:25:10 - ERROR: failed to build world TB --- 2013-03-22 00:25:10 - 6027.89 user 746.84 system 7234.22 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Mar 22 01:02:54 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7DAC4F1A for ; Fri, 22 Mar 2013 01:02:54 +0000 (UTC) (envelope-from marcelorossi@gmail.com) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id 13C7765C for ; Fri, 22 Mar 2013 01:02:53 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id fo12so6329675lab.28 for ; Thu, 21 Mar 2013 18:02:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=e3cYpOOQH1c6Ukm6SOEb1FVp24MPS9L4+slaHO36USY=; b=cEg6POXZIjvm/9x4cDw2+YpcX7gco1XcP186Rhe+NrLwTOCZ1+Auzn3qVV2hDQvYWc 24rmo3k9/c7uWs0w6Hr6OG72fv2HUWyOy6xVR3W52HRVOd9m0Vaq9kmVa862/iJZps55 kIXbRKmbROVrVX/h6rsagbGmYDDFgZGNZggWgHcjXEaWtxl/OtIyak3TYcfi0NcBRZAG cXVD50kCxmapLswRT9cBVbaMhGh7wwzgcAoWcfxZmbg/GQCBE2T/z7bzqoLnZuncQ2Of euzWrdWdWcxhbWvf+e9dI/N1jVwz3w7/4tpjjQ+TuRGEPJxtmY8xBnOo1s9T31zDDFw1 Fqew== X-Received: by 10.112.17.196 with SMTP id q4mr154935lbd.21.1363914173006; Thu, 21 Mar 2013 18:02:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.13.33 with HTTP; Thu, 21 Mar 2013 18:02:12 -0700 (PDT) From: "Marcelo/Porks" Date: Thu, 21 Mar 2013 22:02:12 -0300 Message-ID: Subject: sysutils/fusefs-kmod problem in CURRENT To: current Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 01:02:54 -0000 Hi, I'm facing an error compiling the sysutils/fusefs-kmod. I'm using the CURRENT from today (2013-03-21). Can someone using the CURRENT confirm if this also happens in your system? How should I proceed? Thanks in advance. BARAD-DUR# portsnap fetch update Looking up portsnap.FreeBSD.org mirrors... 6 mirrors found. Fetching snapshot tag from ec2-sa-east-1.portsnap.freebsd.org... done. Latest snapshot on server matches what we already have. No updates needed. Ports tree is already up to date. BARAD-DUR# uname -a FreeBSD BARAD-DUR 10.0-CURRENT FreeBSD 10.0-CURRENT #11 r248594M: Thu Mar 21 19:47:16 BRT 2013 root@BARAD-DUR:/mnt/data/system/obj/usr/src/sys/GENERIC amd64 BARAD-DUR# cat /etc/make.conf # added by use.perl 2012-02-18 15:32:40 PERL_VERSION=5.12.4 WITH_PKGNG=yes BARAD-DUR# cat /etc/src.conf BARAD-DUR# cd /usr/ports/sysutils/fusefs-kmod BARAD-DUR# make ===> Building for fusefs-kmod-0.3.9.p1.20080208_11 ===> fuse_module (all) Warning: Object directory not changed from original /usr/ports/sysutils/fusefs-kmod/work/fuse4bsd-498acaef33b0/fuse_module awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I../include -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno -red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wne sted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c fuse_main.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I../include -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno -red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wne sted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c fuse_msg.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I../include -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno -red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wne sted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c fuse_dev.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I../include -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno -red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wne sted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c fuse_vfsops.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I../include -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno -red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wne sted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c fuse_vnops.c In file included from fuse_vnops.c:36: @/vm/vm_pager.h:127:2: error: implicit declaration of function 'rw_assert' is invalid in C99 [-Werror,-Wimplicit-function-declaration] VM_OBJECT_ASSERT_WLOCKED(object); ^ @/vm/vm_object.h:214:2: note: expanded from macro 'VM_OBJECT_ASSERT_WLOCKED' rw_assert(&(object)->lock, RA_WLOCKED) ^ In file included from fuse_vnops.c:36: @/vm/vm_pager.h:127:2: error: use of undeclared identifier 'RA_WLOCKED' VM_OBJECT_ASSERT_WLOCKED(object); ^ @/vm/vm_object.h:214:29: note: expanded from macro 'VM_OBJECT_ASSERT_WLOCKED' rw_assert(&(object)->lock, RA_WLOCKED) ^ In file included from fuse_vnops.c:36: @/vm/vm_pager.h:144:2: error: use of undeclared identifier 'RA_WLOCKED' VM_OBJECT_ASSERT_WLOCKED(object); ^ @/vm/vm_object.h:214:29: note: expanded from macro 'VM_OBJECT_ASSERT_WLOCKED' rw_assert(&(object)->lock, RA_WLOCKED) ^ In file included from fuse_vnops.c:36: @/vm/vm_pager.h:168:2: error: use of undeclared identifier 'RA_WLOCKED' VM_OBJECT_ASSERT_WLOCKED(object); ^ @/vm/vm_object.h:214:29: note: expanded from macro 'VM_OBJECT_ASSERT_WLOCKED' rw_assert(&(object)->lock, RA_WLOCKED) ^ In file included from fuse_vnops.c:36: @/vm/vm_pager.h:191:2: error: use of undeclared identifier 'RA_WLOCKED' VM_OBJECT_ASSERT_WLOCKED(m->object); ^ @/vm/vm_object.h:214:29: note: expanded from macro 'VM_OBJECT_ASSERT_WLOCKED' rw_assert(&(object)->lock, RA_WLOCKED) ^ fuse_vnops.c:3397:3: error: implicit declaration of function 'VM_OBJECT_LOCK' is invalid in C99 [-Werror,-Wimplicit-function-declaration] VM_OBJECT_LOCK(vp->v_object); ^ fuse_vnops.c:3398:3: error: implicit declaration of function 'vm_page_lock_queues' is invalid in C99 [-Werror,-Wimplicit-function-declaration] vm_page_lock_queues(); ^ fuse_vnops.c:3406:4: error: implicit declaration of function 'vm_page_unlock_queues' is invalid in C99 [-Werror,-Wimplicit-function-declaration] vm_page_unlock_queues(); ^ fuse_vnops.c:3406:4: note: did you mean 'vm_page_lock_queues'? vm_page_unlock_queues(); ^~~~~~~~~~~~~~~~~~~~~ vm_page_lock_queues fuse_vnops.c:3398:3: note: 'vm_page_lock_queues' declared here vm_page_lock_queues(); ^ fuse_vnops.c:3407:4: error: implicit declaration of function 'VM_OBJECT_UNLOCK' is invalid in C99 [-Werror,-Wimplicit-function-declaration] VM_OBJECT_UNLOCK(vp->v_object); ^ fuse_vnops.c:3407:4: note: did you mean 'VM_OBJECT_LOCK'? VM_OBJECT_UNLOCK(vp->v_object); ^~~~~~~~~~~~~~~~ VM_OBJECT_LOCK fuse_vnops.c:3397:3: note: 'VM_OBJECT_LOCK' declared here VM_OBJECT_LOCK(vp->v_object); ^ 9 errors generated. *** [fuse_vnops.o] Error code 1 Stop in /usr/ports/sysutils/fusefs-kmod/work/fuse4bsd-498acaef33b0/fuse_module. *** [all] Error code 1 Stop in /usr/ports/sysutils/fusefs-kmod/work/fuse4bsd-498acaef33b0. *** [do-build] Error code 1 Stop in /usr/ports/sysutils/fusefs-kmod. *** [build] Error code 1 Stop in /usr/ports/sysutils/fusefs-kmod. -- Marcelo Rossi "This e-mail is provided "AS IS" with no warranties, and confers no rights." "I have nothing against God, I just hate His fan club" From owner-freebsd-current@FreeBSD.ORG Fri Mar 22 01:11:58 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DE4831E8; Fri, 22 Mar 2013 01:11:58 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id B70A06DA; Fri, 22 Mar 2013 01:11:58 +0000 (UTC) Received: from glenbarber.us (nucleus.glenbarber.us [IPv6:2001:470:8:1205:2:2:ff:29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id B887523F66A; Thu, 21 Mar 2013 21:11:55 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.8.0 onyx.glenbarber.us B887523F66A Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Thu, 21 Mar 2013 21:11:53 -0400 From: Glen Barber To: Marcelo/Porks Subject: Re: sysutils/fusefs-kmod problem in CURRENT Message-ID: <20130322011153.GB1940@glenbarber.us> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EuxKj2iCbKjpUGkD" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current , mirror176@cox.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 01:11:58 -0000 --EuxKj2iCbKjpUGkD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Mar 21, 2013 at 10:02:12PM -0300, Marcelo/Porks wrote: > [...] > cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE > -nostdinc -I../include -I. -I@ -I@/contrib/altq -fno-common > -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno > -red-zone -mno-mmx -mno-sse -msoft-float > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector > -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall > -Wredundant-decls -Wne > sted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions > -Wmissing-include-dirs -fdiagnostics-show-option > -Wno-error-tautological-compare -Wno-error-empty-body > -Wno-error-parentheses-equality -c fuse_vnops.c > In file included from fuse_vnops.c:36: > @/vm/vm_pager.h:127:2: error: implicit declaration of function > 'rw_assert' is invalid in C99 > [-Werror,-Wimplicit-function-declaration] > VM_OBJECT_ASSERT_WLOCKED(object); > ^ > @/vm/vm_object.h:214:2: note: expanded from macro 'VM_OBJECT_ASSERT_WLOCKED' > rw_assert(&(object)->lock, RA_WLOCKED) > ^ > In file included from fuse_vnops.c:36: > @/vm/vm_pager.h:127:2: error: use of undeclared identifier 'RA_WLOCKED' > VM_OBJECT_ASSERT_WLOCKED(object); > ^ This looks like the same problem emulators/virtualbox-ose* had until yesterday... Maintainer is CC'd. Glen --EuxKj2iCbKjpUGkD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJRS6/ZAAoJEFJPDDeguUajju4H/jki01ALme1DTuM+rZCuxpn8 nSVmgU0fjyZhCwSAEQAgqJVGVULL9dp/WJSsiVMY3jorcRMHsfftWYYcZpcTqEGQ NCA7h4GW+ML7zDoklRuIvPouh+1H/gjOZxYc+/coby4t+x/2yTLtTYROmuLPJVyo BQrxw4k/dlx42xihNGiCn1e3yudJ67O/lfdD6HUwot5aS7/hSbsEerrVaSME4IAL BUHrD813RyjC7uintBurONlkw4zVFYh//KFDLoeZBvtVskJQepR38z1Zl8whqpxM wRrqnzfNYajf/+Z8wWnHP9wz1yLL7GFlVil7bjmNdUTgbLPciM2VXVYkyNSR7Vc= =mqIv -----END PGP SIGNATURE----- --EuxKj2iCbKjpUGkD-- From owner-freebsd-current@FreeBSD.ORG Fri Mar 22 01:33:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D31698EF for ; Fri, 22 Mar 2013 01:33:12 +0000 (UTC) (envelope-from andy@neu.net) Received: from mail.neu.net (neu.net [199.48.129.194]) by mx1.freebsd.org (Postfix) with ESMTP id 880DF7E3 for ; Fri, 22 Mar 2013 01:33:11 +0000 (UTC) Received: from neu.net (neu.net [199.48.129.194]) by mail.neu.net (8.14.6/8.14.5) with ESMTP id r2M1X2XV099779 for ; Thu, 21 Mar 2013 21:33:02 -0400 (EDT) (envelope-from andy@neu.net) Date: Thu, 21 Mar 2013 21:33:02 -0400 (EDT) From: AN To: freebsd-current@freebsd.org Subject: buildkernel fails In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.97.7 at my.mail.server X-Virus-Status: Clean X-Spam-Status: No, score=0.0 required=4.5 tests=RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.neu.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 01:33:12 -0000 FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #38 r248401: Sat Mar 16 21:39:04 CDT 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/MYKERNEL/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -g -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/MYKERNEL -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/MYKERNEL/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -g -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/MYKERNEL -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c ctfconvert -L VERSION -g tmpfs_fifoops.o /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:1596:12: error: format specifies type 'unsigned int' but the argument has type 'u_long' (aka 'unsigned long') [-Werror,-Wformat] node, node->tn_flags, node->tn_links); ^~~~~~~~~~~~~~ 1 error generated. *** [tmpfs_vnops.o] Error code 1 ctfconvert -L VERSION -g tmpfs_vfsops.o ctfconvert -L VERSION -g tmpfs_subr.o 1 error *** [all] Error code 2 1 error *** [modules-all] Error code 2 2 errors *** [buildkernel] Error code 2 1 error *** [buildkernel] Error code 2 1 error From owner-freebsd-current@FreeBSD.ORG Fri Mar 22 03:43:43 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ED00B8CF; Fri, 22 Mar 2013 03:43:43 +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 C4C2FD64; Fri, 22 Mar 2013 03:43:43 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2M3hgtB096864; Thu, 21 Mar 2013 23:43:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2M3hgU7096860; Fri, 22 Mar 2013 03:43:42 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 22 Mar 2013 03:43:42 GMT Message-Id: <201303220343.r2M3hgU7096860@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on armv6/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 03:43:44 -0000 TB --- 2013-03-22 01:50:25 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-22 01:50:25 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-22 01:50:25 - starting HEAD tinderbox run for armv6/arm TB --- 2013-03-22 01:50:25 - cleaning the object tree TB --- 2013-03-22 01:53:14 - /usr/local/bin/svn stat /src TB --- 2013-03-22 01:53:17 - At svn revision 248608 TB --- 2013-03-22 01:53:18 - building world TB --- 2013-03-22 01:53:18 - CROSS_BUILD_TESTING=YES TB --- 2013-03-22 01:53:18 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-22 01:53:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-22 01:53:18 - SRCCONF=/dev/null TB --- 2013-03-22 01:53:18 - TARGET=arm TB --- 2013-03-22 01:53:18 - TARGET_ARCH=armv6 TB --- 2013-03-22 01:53:18 - TZ=UTC TB --- 2013-03-22 01:53:18 - __MAKE_CONF=/dev/null TB --- 2013-03-22 01:53:18 - cd /src TB --- 2013-03-22 01:53:18 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Mar 22 01:53:22 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Mar 22 03:42:29 UTC 2013 TB --- 2013-03-22 03:42:29 - generating LINT kernel config TB --- 2013-03-22 03:42:29 - cd /src/sys/arm/conf TB --- 2013-03-22 03:42:29 - /usr/bin/make -B LINT TB --- 2013-03-22 03:42:29 - cd /src/sys/arm/conf TB --- 2013-03-22 03:42:29 - /usr/sbin/config -m LINT TB --- 2013-03-22 03:42:29 - skipping LINT kernel TB --- 2013-03-22 03:42:29 - cd /src/sys/arm/conf TB --- 2013-03-22 03:42:29 - /usr/sbin/config -m AC100 TB --- 2013-03-22 03:42:29 - building AC100 kernel TB --- 2013-03-22 03:42:29 - CROSS_BUILD_TESTING=YES TB --- 2013-03-22 03:42:29 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-22 03:42:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-22 03:42:29 - SRCCONF=/dev/null TB --- 2013-03-22 03:42:29 - TARGET=arm TB --- 2013-03-22 03:42:29 - TARGET_ARCH=armv6 TB --- 2013-03-22 03:42:29 - TZ=UTC TB --- 2013-03-22 03:42:29 - __MAKE_CONF=/dev/null TB --- 2013-03-22 03:42:29 - cd /src TB --- 2013-03-22 03:42:29 - /usr/bin/make -B buildkernel KERNCONF=AC100 >>> Kernel build for AC100 started on Fri Mar 22 03:42:29 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-thumb-interwork -ffreestanding -Werror /src/sys/kern/vfs_lookup.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-thumb-interwork -ffreestanding -Werror /src/sys/kern/vfs_mount.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-thumb-interwork -ffreestanding -Werror /src/sys/kern/vfs_mountroot.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-thumb-interwork -ffreestanding -Werror /src/sys/kern/vfs_subr.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-thumb-interwork -ffreestanding -Werror /src/sys/kern/vfs_syscalls.c cc1: warnings being treated as errors /src/sys/kern/vfs_syscalls.c: In function 'sys_chflagsat': /src/sys/kern/vfs_syscalls.c:2692: warning: initialization discards qualifiers from pointer target type *** [vfs_syscalls.o] Error code 1 Stop in /obj/arm.armv6/src/sys/AC100. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-22 03:43:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-22 03:43:42 - ERROR: failed to build AC100 kernel TB --- 2013-03-22 03:43:42 - 5379.56 user 946.19 system 6797.03 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-armv6-arm.full From owner-freebsd-current@FreeBSD.ORG Fri Mar 22 03:51:15 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4AED4B1A; Fri, 22 Mar 2013 03:51:15 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 2285DDC9; Fri, 22 Mar 2013 03:51:14 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2M3pEGn027759; Thu, 21 Mar 2013 23:51:14 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2M3pEaN027757; Fri, 22 Mar 2013 03:51:14 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 22 Mar 2013 03:51:14 GMT Message-Id: <201303220351.r2M3pEaN027757@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 03:51:15 -0000 TB --- 2013-03-22 01:50:25 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-22 01:50:25 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-22 01:50:25 - starting HEAD tinderbox run for arm/arm TB --- 2013-03-22 01:50:25 - cleaning the object tree TB --- 2013-03-22 01:53:14 - /usr/local/bin/svn stat /src TB --- 2013-03-22 01:53:17 - At svn revision 248608 TB --- 2013-03-22 01:53:18 - building world TB --- 2013-03-22 01:53:18 - CROSS_BUILD_TESTING=YES TB --- 2013-03-22 01:53:18 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-22 01:53:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-22 01:53:18 - SRCCONF=/dev/null TB --- 2013-03-22 01:53:18 - TARGET=arm TB --- 2013-03-22 01:53:18 - TARGET_ARCH=arm TB --- 2013-03-22 01:53:18 - TZ=UTC TB --- 2013-03-22 01:53:18 - __MAKE_CONF=/dev/null TB --- 2013-03-22 01:53:18 - cd /src TB --- 2013-03-22 01:53:18 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Mar 22 01:53:22 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Mar 22 03:42:29 UTC 2013 TB --- 2013-03-22 03:42:29 - generating LINT kernel config TB --- 2013-03-22 03:42:29 - cd /src/sys/arm/conf TB --- 2013-03-22 03:42:29 - /usr/bin/make -B LINT TB --- 2013-03-22 03:42:29 - cd /src/sys/arm/conf TB --- 2013-03-22 03:42:29 - /usr/sbin/config -m LINT TB --- 2013-03-22 03:42:29 - building LINT kernel TB --- 2013-03-22 03:42:29 - CROSS_BUILD_TESTING=YES TB --- 2013-03-22 03:42:29 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-22 03:42:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-22 03:42:29 - SRCCONF=/dev/null TB --- 2013-03-22 03:42:29 - TARGET=arm TB --- 2013-03-22 03:42:29 - TARGET_ARCH=arm TB --- 2013-03-22 03:42:29 - TZ=UTC TB --- 2013-03-22 03:42:29 - __MAKE_CONF=/dev/null TB --- 2013-03-22 03:42:29 - cd /src TB --- 2013-03-22 03:42:29 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Mar 22 03:42:29 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -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-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/fs/udf/udf_vnops.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -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-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/fs/unionfs/union_subr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -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-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/fs/unionfs/union_vfsops.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -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-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/fs/unionfs/union_vnops.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -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-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/fs/tmpfs/tmpfs_vnops.c cc1: warnings being treated as errors /src/sys/fs/tmpfs/tmpfs_vnops.c: In function 'tmpfs_print': /src/sys/fs/tmpfs/tmpfs_vnops.c:1596: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'u_long' [-Wformat] *** [tmpfs_vnops.o] Error code 1 Stop in /obj/arm.arm/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-22 03:51:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-22 03:51:14 - ERROR: failed to build LINT kernel TB --- 2013-03-22 03:51:14 - 5728.09 user 992.38 system 7248.62 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Fri Mar 22 04:02:21 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 57EDBCF2 for ; Fri, 22 Mar 2013 04:02:21 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-ia0-x22b.google.com (mail-ia0-x22b.google.com [IPv6:2607:f8b0:4001:c02::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 2E394E2E for ; Fri, 22 Mar 2013 04:02:21 +0000 (UTC) Received: by mail-ia0-f171.google.com with SMTP id z13so3178536iaz.2 for ; Thu, 21 Mar 2013 21:02:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=t24PoIe08eqphUbnpY2HogFQDRG3Y3LRvFqsgreeQB4=; b=0y6nsUXseA5s36SLdU7jcssfHV9WvgFPAmm08sF2swEwAFimYn1bIx1/W7ZGCVsCpy XhjK+JPXBuyg8G9sRt7t/uniIb78y+ZgJfa/nwFheun6My5tOIcA+631mKnbKOqkgbsd 5uRdIi7qhNDOzGtIRoUAIKU+vhKsjD573PzgRtWCtdP+m+05x+ZDe2zKnky7nHsImI44 b+TkHw0w55Z6390huJlKO8PRI2u+SLMoWBReNGdQyJv2pCV8783h3/lzSvAjbmo6NftU k1PeA8hHkdAznTls27USMclWR+k9d93apJV1bhXcSIUk7/oULfxScdZcuci95EXO08OH F/Ig== MIME-Version: 1.0 X-Received: by 10.43.103.195 with SMTP id dj3mr181734icc.3.1363924940929; Thu, 21 Mar 2013 21:02:20 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.42.117.134 with HTTP; Thu, 21 Mar 2013 21:02:20 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Mar 2013 05:02:20 +0100 X-Google-Sender-Auth: UkIEARAQbHAI4_KnIp9pHXZa5fw Message-ID: Subject: Re: sysutils/fusefs-kmod problem in CURRENT From: Attilio Rao To: "Marcelo/Porks" Content-Type: text/plain; charset=UTF-8 Cc: current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@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: Fri, 22 Mar 2013 04:02:21 -0000 On Fri, Mar 22, 2013 at 2:02 AM, Marcelo/Porks wrote: > Hi, I'm facing an error compiling the sysutils/fusefs-kmod. > > I'm using the CURRENT from today (2013-03-21). > > Can someone using the CURRENT confirm if this also happens in your system? CURRENT should not allow you to build fusefs-kmod at all. Use "option FUSEFS" from your kernel config. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Fri Mar 22 04:49:33 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 16FBF3D2; Fri, 22 Mar 2013 04:49:33 +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 E3450FC0; Fri, 22 Mar 2013 04:49:32 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2M4nWK1085731; Fri, 22 Mar 2013 00:49:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2M4nVfW085727; Fri, 22 Mar 2013 04:49:31 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 22 Mar 2013 04:49:31 GMT Message-Id: <201303220449.r2M4nVfW085727@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 04:49:33 -0000 TB --- 2013-03-22 01:50:25 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-22 01:50:25 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-22 01:50:25 - starting HEAD tinderbox run for i386/i386 TB --- 2013-03-22 01:50:25 - cleaning the object tree TB --- 2013-03-22 01:53:17 - /usr/local/bin/svn stat /src TB --- 2013-03-22 01:53:20 - At svn revision 248608 TB --- 2013-03-22 01:53:21 - building world TB --- 2013-03-22 01:53:21 - CROSS_BUILD_TESTING=YES TB --- 2013-03-22 01:53:21 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-22 01:53:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-22 01:53:21 - SRCCONF=/dev/null TB --- 2013-03-22 01:53:21 - TARGET=i386 TB --- 2013-03-22 01:53:21 - TARGET_ARCH=i386 TB --- 2013-03-22 01:53:21 - TZ=UTC TB --- 2013-03-22 01:53:21 - __MAKE_CONF=/dev/null TB --- 2013-03-22 01:53:21 - cd /src TB --- 2013-03-22 01:53:21 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Mar 22 01:53:25 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Mar 22 04:36:51 UTC 2013 TB --- 2013-03-22 04:36:51 - generating LINT kernel config TB --- 2013-03-22 04:36:51 - cd /src/sys/i386/conf TB --- 2013-03-22 04:36:51 - /usr/bin/make -B LINT TB --- 2013-03-22 04:36:51 - cd /src/sys/i386/conf TB --- 2013-03-22 04:36:51 - /usr/sbin/config -m LINT TB --- 2013-03-22 04:36:51 - building LINT kernel TB --- 2013-03-22 04:36:51 - CROSS_BUILD_TESTING=YES TB --- 2013-03-22 04:36:51 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-22 04:36:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-22 04:36:51 - SRCCONF=/dev/null TB --- 2013-03-22 04:36:51 - TARGET=i386 TB --- 2013-03-22 04:36:51 - TARGET_ARCH=i386 TB --- 2013-03-22 04:36:51 - TZ=UTC TB --- 2013-03-22 04:36:51 - __MAKE_CONF=/dev/null TB --- 2013-03-22 04:36:51 - cd /src TB --- 2013-03-22 04:36:51 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Mar 22 04:36:51 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg /src/sys/fs/unionfs/union_subr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg /src/sys/fs/unionfs/union_vfsops.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg /src/sys/fs/unionfs/union_vnops.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg /src/sys/fs/tmpfs/tmpfs_vnops.c /src/sys/fs/tmpfs/tmpfs_vnops.c:1596:12: error: format specifies type 'unsigned int' but the argument has type 'u_long' (aka 'unsigned long') [-Werror,-Wformat] node, node->tn_flags, node->tn_links); ^~~~~~~~~~~~~~ 1 error generated. *** [tmpfs_vnops.o] Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-22 04:49:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-22 04:49:31 - ERROR: failed to build LINT kernel TB --- 2013-03-22 04:49:31 - 8625.27 user 1310.74 system 10746.26 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Fri Mar 22 05:07:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 62A39628 for ; Fri, 22 Mar 2013 05:07:14 +0000 (UTC) (envelope-from zaphod@berentweb.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 4B05D129 for ; Fri, 22 Mar 2013 05:07:14 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UIuC9-0007cf-9l for freebsd-current@freebsd.org; Thu, 21 Mar 2013 22:07:13 -0700 Date: Thu, 21 Mar 2013 22:07:13 -0700 (PDT) From: Beeblebrox To: freebsd-current@freebsd.org Message-ID: <1363928833296-5797872.post@n5.nabble.com> In-Reply-To: <1363877898593-5797633.post@n5.nabble.com> References: <1363877898593-5797633.post@n5.nabble.com> Subject: Re: compiler confusion: gcc cannot be located and causes compiler errors MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 05:07:14 -0000 Another example of the problem: from compile of www/chromium: ===> FreeBSD 10 autotools fix applied to /usr/obj/asp/ports/www/chromium/work/chromium-courgette-redacted-25.0.1364.172/third_party/WebKit/Source/autotools/acinclude.m4 cd /usr/obj/asp/ports/www/chromium/work/chromium-courgette-redacted-25.0.1364.172 && GYP_DEFINES="use_cups=1 use_system_yasm=1 use_system_libxml=1 use_system_ffmpeg=0 use_system_libusb=1 use_system_libevent=1 use_system_libvpx=1 linux_strip_binary=1 linux_use_tcmalloc=0 linux_use_heapchecker=0 clang_use_chrome_plugins=0 disable_nacl=1 enable_webrtc=0 enable_openmax=1 enable_one_click_signin=1 no_gc_sections=1 os_ver=1000030 prefix_dir=/usr/local python_ver=2.7 ffmpeg_branding=Chrome proprietary_codecs=1 use_pulseaudio=1 gcc_version=46" /usr/local/bin/python2.7 ./build/gyp_chromium chrome/chrome.gyp --depth . Updating projects from gyp files... g++: not found compiler_version.py failed to execute: g++ -dumpversion Command 'g++ -dumpversion' returned non-zero exit status 127 gyp: Call to 'python ../build/compiler_version.py' returned exit status 1. while trying to load chrome/chrome.gyp *** [do-configure] Error code 1 -- View this message in context: http://freebsd.1045724.n5.nabble.com/compiler-confusion-gcc-cannot-be-located-and-causes-compiler-errors-tp5797633p5797872.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Fri Mar 22 05:22:46 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D8D8A9CB; Fri, 22 Mar 2013 05:22: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 B05631BD; Fri, 22 Mar 2013 05:22:46 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2M5Mjir081216; Fri, 22 Mar 2013 01:22:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2M5Mjeq081208; Fri, 22 Mar 2013 05:22:45 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 22 Mar 2013 05:22:45 GMT Message-Id: <201303220522.r2M5Mjeq081208@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 05:22:46 -0000 TB --- 2013-03-22 01:50:25 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-22 01:50:25 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-22 01:50:25 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-03-22 01:50:25 - cleaning the object tree TB --- 2013-03-22 01:50:25 - /usr/local/bin/svn stat /src TB --- 2013-03-22 01:50:29 - At svn revision 248608 TB --- 2013-03-22 01:50:30 - building world TB --- 2013-03-22 01:50:30 - CROSS_BUILD_TESTING=YES TB --- 2013-03-22 01:50:30 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-22 01:50:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-22 01:50:30 - SRCCONF=/dev/null TB --- 2013-03-22 01:50:30 - TARGET=amd64 TB --- 2013-03-22 01:50:30 - TARGET_ARCH=amd64 TB --- 2013-03-22 01:50:30 - TZ=UTC TB --- 2013-03-22 01:50:30 - __MAKE_CONF=/dev/null TB --- 2013-03-22 01:50:30 - cd /src TB --- 2013-03-22 01:50:30 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Mar 22 01:50:35 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Fri Mar 22 05:10:12 UTC 2013 TB --- 2013-03-22 05:10:12 - generating LINT kernel config TB --- 2013-03-22 05:10:12 - cd /src/sys/amd64/conf TB --- 2013-03-22 05:10:12 - /usr/bin/make -B LINT TB --- 2013-03-22 05:10:12 - cd /src/sys/amd64/conf TB --- 2013-03-22 05:10:12 - /usr/sbin/config -m LINT TB --- 2013-03-22 05:10:12 - building LINT kernel TB --- 2013-03-22 05:10:12 - CROSS_BUILD_TESTING=YES TB --- 2013-03-22 05:10:12 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-22 05:10:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-22 05:10:12 - SRCCONF=/dev/null TB --- 2013-03-22 05:10:12 - TARGET=amd64 TB --- 2013-03-22 05:10:12 - TARGET_ARCH=amd64 TB --- 2013-03-22 05:10:12 - TZ=UTC TB --- 2013-03-22 05:10:12 - __MAKE_CONF=/dev/null TB --- 2013-03-22 05:10:12 - cd /src TB --- 2013-03-22 05:10:12 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Mar 22 05:10:12 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] 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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg /src/sys/fs/unionfs/union_subr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg /src/sys/fs/unionfs/union_vfsops.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg /src/sys/fs/unionfs/union_vnops.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg /src/sys/fs/tmpfs/tmpfs_vnops.c /src/sys/fs/tmpfs/tmpfs_vnops.c:1596:12: error: format specifies type 'unsigned int' but the argument has type 'u_long' (aka 'unsigned long') [-Werror,-Wformat] node, node->tn_flags, node->tn_links); ^~~~~~~~~~~~~~ 1 error generated. *** [tmpfs_vnops.o] Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-22 05:22:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-22 05:22:45 - ERROR: failed to build LINT kernel TB --- 2013-03-22 05:22:45 - 9984.16 user 1685.96 system 12740.20 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Fri Mar 22 05:38:08 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B020DFA6; Fri, 22 Mar 2013 05:38:08 +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 881D1262; Fri, 22 Mar 2013 05:38:08 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2M5c7YG077349; Fri, 22 Mar 2013 01:38:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2M5c7h5077348; Fri, 22 Mar 2013 05:38:07 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 22 Mar 2013 05:38:07 GMT Message-Id: <201303220538.r2M5c7h5077348@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 05:38:08 -0000 TB --- 2013-03-22 03:51:14 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-22 03:51:14 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-22 03:51:14 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-03-22 03:51:14 - cleaning the object tree TB --- 2013-03-22 03:51:14 - /usr/local/bin/svn stat /src TB --- 2013-03-22 03:51:17 - At svn revision 248608 TB --- 2013-03-22 03:51:18 - building world TB --- 2013-03-22 03:51:18 - CROSS_BUILD_TESTING=YES TB --- 2013-03-22 03:51:18 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-22 03:51:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-22 03:51:18 - SRCCONF=/dev/null TB --- 2013-03-22 03:51:18 - TARGET=ia64 TB --- 2013-03-22 03:51:18 - TARGET_ARCH=ia64 TB --- 2013-03-22 03:51:18 - TZ=UTC TB --- 2013-03-22 03:51:18 - __MAKE_CONF=/dev/null TB --- 2013-03-22 03:51:18 - cd /src TB --- 2013-03-22 03:51:18 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Mar 22 03:51:23 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Mar 22 05:25:32 UTC 2013 TB --- 2013-03-22 05:25:32 - generating LINT kernel config TB --- 2013-03-22 05:25:32 - cd /src/sys/ia64/conf TB --- 2013-03-22 05:25:32 - /usr/bin/make -B LINT TB --- 2013-03-22 05:25:32 - cd /src/sys/ia64/conf TB --- 2013-03-22 05:25:32 - /usr/sbin/config -m LINT TB --- 2013-03-22 05:25:32 - building LINT kernel TB --- 2013-03-22 05:25:32 - CROSS_BUILD_TESTING=YES TB --- 2013-03-22 05:25:32 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-22 05:25:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-22 05:25:32 - SRCCONF=/dev/null TB --- 2013-03-22 05:25:32 - TARGET=ia64 TB --- 2013-03-22 05:25:32 - TARGET_ARCH=ia64 TB --- 2013-03-22 05:25:32 - TZ=UTC TB --- 2013-03-22 05:25:32 - __MAKE_CONF=/dev/null TB --- 2013-03-22 05:25:32 - cd /src TB --- 2013-03-22 05:25:32 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Mar 22 05:25:32 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/fs/udf/udf_vnops.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/fs/unionfs/union_subr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/fs/unionfs/union_vfsops.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/fs/unionfs/union_vnops.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/fs/tmpfs/tmpfs_vnops.c cc1: warnings being treated as errors /src/sys/fs/tmpfs/tmpfs_vnops.c: In function 'tmpfs_print': /src/sys/fs/tmpfs/tmpfs_vnops.c:1596: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'u_long' [-Wformat] *** [tmpfs_vnops.o] Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-22 05:38:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-22 05:38:07 - ERROR: failed to build LINT kernel TB --- 2013-03-22 05:38:07 - 5093.46 user 965.89 system 6413.13 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Fri Mar 22 05:52:03 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7DB71271; Fri, 22 Mar 2013 05:52:03 +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 548542D8; Fri, 22 Mar 2013 05:52:03 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2M5q2jP054025; Fri, 22 Mar 2013 01:52:02 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2M5q2pd054018; Fri, 22 Mar 2013 05:52:02 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 22 Mar 2013 05:52:02 GMT Message-Id: <201303220552.r2M5q2pd054018@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 05:52:03 -0000 TB --- 2013-03-22 04:49:32 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-22 04:49:32 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-22 04:49:32 - starting HEAD tinderbox run for mips/mips TB --- 2013-03-22 04:49:32 - cleaning the object tree TB --- 2013-03-22 04:50:02 - /usr/local/bin/svn stat /src TB --- 2013-03-22 04:50:05 - At svn revision 248608 TB --- 2013-03-22 04:50:06 - building world TB --- 2013-03-22 04:50:06 - CROSS_BUILD_TESTING=YES TB --- 2013-03-22 04:50:06 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-22 04:50:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-22 04:50:06 - SRCCONF=/dev/null TB --- 2013-03-22 04:50:06 - TARGET=mips TB --- 2013-03-22 04:50:06 - TARGET_ARCH=mips TB --- 2013-03-22 04:50:06 - TZ=UTC TB --- 2013-03-22 04:50:06 - __MAKE_CONF=/dev/null TB --- 2013-03-22 04:50:06 - cd /src TB --- 2013-03-22 04:50:06 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Mar 22 04:50:11 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Mar 22 05:50:12 UTC 2013 TB --- 2013-03-22 05:50:12 - cd /src/sys/mips/conf TB --- 2013-03-22 05:50:12 - /usr/sbin/config -m ADM5120 TB --- 2013-03-22 05:50:12 - skipping ADM5120 kernel TB --- 2013-03-22 05:50:12 - cd /src/sys/mips/conf TB --- 2013-03-22 05:50:12 - /usr/sbin/config -m ALCHEMY TB --- 2013-03-22 05:50:12 - skipping ALCHEMY kernel TB --- 2013-03-22 05:50:12 - cd /src/sys/mips/conf TB --- 2013-03-22 05:50:12 - /usr/sbin/config -m AP91 TB --- 2013-03-22 05:50:12 - building AP91 kernel TB --- 2013-03-22 05:50:12 - CROSS_BUILD_TESTING=YES TB --- 2013-03-22 05:50:12 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-22 05:50:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-22 05:50:12 - SRCCONF=/dev/null TB --- 2013-03-22 05:50:12 - TARGET=mips TB --- 2013-03-22 05:50:12 - TARGET_ARCH=mips TB --- 2013-03-22 05:50:12 - TZ=UTC TB --- 2013-03-22 05:50:12 - __MAKE_CONF=/dev/null TB --- 2013-03-22 05:50:12 - cd /src TB --- 2013-03-22 05:50:12 - /usr/bin/make -B buildkernel KERNCONF=AP91 >>> Kernel build for AP91 started on Fri Mar 22 05:50:12 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=768 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/kern/vfs_lookup.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=768 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/kern/vfs_mount.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=768 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/kern/vfs_mountroot.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=768 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/kern/vfs_subr.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=768 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/kern/vfs_syscalls.c cc1: warnings being treated as errors /src/sys/kern/vfs_syscalls.c: In function 'sys_chflagsat': /src/sys/kern/vfs_syscalls.c:2692: warning: initialization discards qualifiers from pointer target type *** [vfs_syscalls.o] Error code 1 Stop in /obj/mips.mips/src/sys/AP91. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-22 05:52:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-22 05:52:02 - ERROR: failed to build AP91 kernel TB --- 2013-03-22 05:52:02 - 2741.23 user 660.31 system 3750.07 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Fri Mar 22 06:24:16 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 716118AD; Fri, 22 Mar 2013 06:24:16 +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 4884C605; Fri, 22 Mar 2013 06:24:15 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2M6OFmL064847; Fri, 22 Mar 2013 02:24:15 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2M6OF8v064846; Fri, 22 Mar 2013 06:24:15 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 22 Mar 2013 06:24:15 GMT Message-Id: <201303220624.r2M6OF8v064846@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips64/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 06:24:16 -0000 TB --- 2013-03-22 05:22:46 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-22 05:22:46 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-22 05:22:46 - starting HEAD tinderbox run for mips64/mips TB --- 2013-03-22 05:22:46 - cleaning the object tree TB --- 2013-03-22 05:22:46 - /usr/local/bin/svn stat /src TB --- 2013-03-22 05:22:49 - At svn revision 248608 TB --- 2013-03-22 05:22:50 - building world TB --- 2013-03-22 05:22:50 - CROSS_BUILD_TESTING=YES TB --- 2013-03-22 05:22:50 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-22 05:22:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-22 05:22:50 - SRCCONF=/dev/null TB --- 2013-03-22 05:22:50 - TARGET=mips TB --- 2013-03-22 05:22:50 - TARGET_ARCH=mips64 TB --- 2013-03-22 05:22:50 - TZ=UTC TB --- 2013-03-22 05:22:50 - __MAKE_CONF=/dev/null TB --- 2013-03-22 05:22:50 - cd /src TB --- 2013-03-22 05:22:50 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Mar 22 05:22:55 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Mar 22 06:22:47 UTC 2013 TB --- 2013-03-22 06:22:47 - cd /src/sys/mips/conf TB --- 2013-03-22 06:22:47 - /usr/sbin/config -m ADM5120 TB --- 2013-03-22 06:22:47 - skipping ADM5120 kernel TB --- 2013-03-22 06:22:47 - cd /src/sys/mips/conf TB --- 2013-03-22 06:22:47 - /usr/sbin/config -m ALCHEMY TB --- 2013-03-22 06:22:47 - skipping ALCHEMY kernel TB --- 2013-03-22 06:22:47 - cd /src/sys/mips/conf TB --- 2013-03-22 06:22:47 - /usr/sbin/config -m AP91 TB --- 2013-03-22 06:22:47 - skipping AP91 kernel TB --- 2013-03-22 06:22:47 - cd /src/sys/mips/conf TB --- 2013-03-22 06:22:47 - /usr/sbin/config -m AP93 TB --- 2013-03-22 06:22:47 - skipping AP93 kernel TB --- 2013-03-22 06:22:47 - cd /src/sys/mips/conf TB --- 2013-03-22 06:22:47 - /usr/sbin/config -m AP94 TB --- 2013-03-22 06:22:47 - skipping AP94 kernel TB --- 2013-03-22 06:22:47 - cd /src/sys/mips/conf TB --- 2013-03-22 06:22:47 - /usr/sbin/config -m AP96 TB --- 2013-03-22 06:22:47 - skipping AP96 kernel TB --- 2013-03-22 06:22:47 - cd /src/sys/mips/conf TB --- 2013-03-22 06:22:47 - /usr/sbin/config -m AR71XX_BASE TB --- 2013-03-22 06:22:47 - skipping AR71XX_BASE kernel TB --- 2013-03-22 06:22:47 - cd /src/sys/mips/conf TB --- 2013-03-22 06:22:47 - /usr/sbin/config -m AR724X_BASE TB --- 2013-03-22 06:22:47 - skipping AR724X_BASE kernel TB --- 2013-03-22 06:22:47 - cd /src/sys/mips/conf TB --- 2013-03-22 06:22:47 - /usr/sbin/config -m AR91XX_BASE TB --- 2013-03-22 06:22:47 - skipping AR91XX_BASE kernel TB --- 2013-03-22 06:22:47 - cd /src/sys/mips/conf TB --- 2013-03-22 06:22:47 - /usr/sbin/config -m BERI_DE4_MDROOT TB --- 2013-03-22 06:22:47 - building BERI_DE4_MDROOT kernel TB --- 2013-03-22 06:22:47 - CROSS_BUILD_TESTING=YES TB --- 2013-03-22 06:22:47 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-22 06:22:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-22 06:22:47 - SRCCONF=/dev/null TB --- 2013-03-22 06:22:47 - TARGET=mips TB --- 2013-03-22 06:22:47 - TARGET_ARCH=mips64 TB --- 2013-03-22 06:22:47 - TZ=UTC TB --- 2013-03-22 06:22:47 - __MAKE_CONF=/dev/null TB --- 2013-03-22 06:22:47 - cd /src TB --- 2013-03-22 06:22:47 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_MDROOT >>> Kernel build for BERI_DE4_MDROOT started on Fri Mar 22 06:22:47 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=mips64 -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/kern/vfs_lookup.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=mips64 -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/kern/vfs_mount.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=mips64 -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/kern/vfs_mountroot.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=mips64 -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/kern/vfs_subr.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=mips64 -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/kern/vfs_syscalls.c cc1: warnings being treated as errors /src/sys/kern/vfs_syscalls.c: In function 'sys_chflagsat': /src/sys/kern/vfs_syscalls.c:2692: warning: initialization discards qualifiers from pointer target type *** [vfs_syscalls.o] Error code 1 Stop in /obj/mips.mips64/src/sys/BERI_DE4_MDROOT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-22 06:24:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-22 06:24:15 - ERROR: failed to build BERI_DE4_MDROOT kernel TB --- 2013-03-22 06:24:15 - 2748.27 user 588.18 system 3689.27 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-mips64-mips.full From owner-freebsd-current@FreeBSD.ORG Fri Mar 22 06:46:01 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 175E5BF5; Fri, 22 Mar 2013 06:46: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 E18EC6C1; Fri, 22 Mar 2013 06:46:00 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2M6k0QL069519; Fri, 22 Mar 2013 02:46:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2M6k0mo069515; Fri, 22 Mar 2013 06:46:00 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 22 Mar 2013 06:46:00 GMT Message-Id: <201303220646.r2M6k0mo069515@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 06:46:01 -0000 TB --- 2013-03-22 03:43:42 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-22 03:43:42 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-22 03:43:42 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-03-22 03:43:42 - cleaning the object tree TB --- 2013-03-22 03:44:30 - /usr/local/bin/svn stat /src TB --- 2013-03-22 03:44:34 - At svn revision 248608 TB --- 2013-03-22 03:44:35 - building world TB --- 2013-03-22 03:44:35 - CROSS_BUILD_TESTING=YES TB --- 2013-03-22 03:44:35 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-22 03:44:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-22 03:44:35 - SRCCONF=/dev/null TB --- 2013-03-22 03:44:35 - TARGET=pc98 TB --- 2013-03-22 03:44:35 - TARGET_ARCH=i386 TB --- 2013-03-22 03:44:35 - TZ=UTC TB --- 2013-03-22 03:44:35 - __MAKE_CONF=/dev/null TB --- 2013-03-22 03:44:35 - cd /src TB --- 2013-03-22 03:44:35 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Mar 22 03:44:39 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Mar 22 06:35:59 UTC 2013 TB --- 2013-03-22 06:35:59 - generating LINT kernel config TB --- 2013-03-22 06:35:59 - cd /src/sys/pc98/conf TB --- 2013-03-22 06:35:59 - /usr/bin/make -B LINT TB --- 2013-03-22 06:35:59 - cd /src/sys/pc98/conf TB --- 2013-03-22 06:35:59 - /usr/sbin/config -m LINT TB --- 2013-03-22 06:36:00 - building LINT kernel TB --- 2013-03-22 06:36:00 - CROSS_BUILD_TESTING=YES TB --- 2013-03-22 06:36:00 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-22 06:36:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-22 06:36:00 - SRCCONF=/dev/null TB --- 2013-03-22 06:36:00 - TARGET=pc98 TB --- 2013-03-22 06:36:00 - TARGET_ARCH=i386 TB --- 2013-03-22 06:36:00 - TZ=UTC TB --- 2013-03-22 06:36:00 - __MAKE_CONF=/dev/null TB --- 2013-03-22 06:36:00 - cd /src TB --- 2013-03-22 06:36:00 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Mar 22 06:36:00 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg /src/sys/fs/unionfs/union_subr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg /src/sys/fs/unionfs/union_vfsops.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg /src/sys/fs/unionfs/union_vnops.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg /src/sys/fs/tmpfs/tmpfs_vnops.c /src/sys/fs/tmpfs/tmpfs_vnops.c:1596:12: error: format specifies type 'unsigned int' but the argument has type 'u_long' (aka 'unsigned long') [-Werror,-Wformat] node, node->tn_flags, node->tn_links); ^~~~~~~~~~~~~~ 1 error generated. *** [tmpfs_vnops.o] Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-22 06:46:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-22 06:46:00 - ERROR: failed to build LINT kernel TB --- 2013-03-22 06:46:00 - 8752.47 user 1352.05 system 10937.13 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Fri Mar 22 07:38:42 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C2883CBC; Fri, 22 Mar 2013 07:38:42 +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 98DCC91B; Fri, 22 Mar 2013 07:38:42 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2M7cfZQ004537; Fri, 22 Mar 2013 03:38:41 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2M7cfBq004520; Fri, 22 Mar 2013 07:38:41 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 22 Mar 2013 07:38:41 GMT Message-Id: <201303220738.r2M7cfBq004520@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 07:38:42 -0000 TB --- 2013-03-22 06:24:15 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-22 06:24:15 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-22 06:24:15 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-03-22 06:24:15 - cleaning the object tree TB --- 2013-03-22 06:24:15 - /usr/local/bin/svn stat /src TB --- 2013-03-22 06:24:19 - At svn revision 248608 TB --- 2013-03-22 06:24:20 - building world TB --- 2013-03-22 06:24:20 - CROSS_BUILD_TESTING=YES TB --- 2013-03-22 06:24:20 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-22 06:24:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-22 06:24:20 - SRCCONF=/dev/null TB --- 2013-03-22 06:24:20 - TARGET=sparc64 TB --- 2013-03-22 06:24:20 - TARGET_ARCH=sparc64 TB --- 2013-03-22 06:24:20 - TZ=UTC TB --- 2013-03-22 06:24:20 - __MAKE_CONF=/dev/null TB --- 2013-03-22 06:24:20 - cd /src TB --- 2013-03-22 06:24:20 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Mar 22 06:24:25 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Mar 22 07:29:35 UTC 2013 TB --- 2013-03-22 07:29:35 - generating LINT kernel config TB --- 2013-03-22 07:29:35 - cd /src/sys/sparc64/conf TB --- 2013-03-22 07:29:35 - /usr/bin/make -B LINT TB --- 2013-03-22 07:29:35 - cd /src/sys/sparc64/conf TB --- 2013-03-22 07:29:35 - /usr/sbin/config -m LINT TB --- 2013-03-22 07:29:35 - building LINT kernel TB --- 2013-03-22 07:29:35 - CROSS_BUILD_TESTING=YES TB --- 2013-03-22 07:29:35 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-22 07:29:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-22 07:29:35 - SRCCONF=/dev/null TB --- 2013-03-22 07:29:35 - TARGET=sparc64 TB --- 2013-03-22 07:29:35 - TARGET_ARCH=sparc64 TB --- 2013-03-22 07:29:35 - TZ=UTC TB --- 2013-03-22 07:29:35 - __MAKE_CONF=/dev/null TB --- 2013-03-22 07:29:35 - cd /src TB --- 2013-03-22 07:29:35 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Mar 22 07:29:35 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/fs/udf/udf_vnops.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/fs/unionfs/union_subr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/fs/unionfs/union_vfsops.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/fs/unionfs/union_vnops.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/fs/tmpfs/tmpfs_vnops.c cc1: warnings being treated as errors /src/sys/fs/tmpfs/tmpfs_vnops.c: In function 'tmpfs_print': /src/sys/fs/tmpfs/tmpfs_vnops.c:1596: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'u_long' [-Wformat] *** [tmpfs_vnops.o] Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-22 07:38:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-22 07:38:41 - ERROR: failed to build LINT kernel TB --- 2013-03-22 07:38:41 - 3554.24 user 618.72 system 4465.98 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Fri Mar 22 08:07:15 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 14170E1E; Fri, 22 Mar 2013 08:07:15 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id DE54DA99; Fri, 22 Mar 2013 08:07:14 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2M87E3d098191; Fri, 22 Mar 2013 04:07:14 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2M87EjI098190; Fri, 22 Mar 2013 08:07:14 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 22 Mar 2013 08:07:14 GMT Message-Id: <201303220807.r2M87EjI098190@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 08:07:15 -0000 TB --- 2013-03-22 05:38:07 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-22 05:38:07 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-22 05:38:07 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-03-22 05:38:07 - cleaning the object tree TB --- 2013-03-22 05:38:55 - /usr/local/bin/svn stat /src TB --- 2013-03-22 05:38:58 - At svn revision 248608 TB --- 2013-03-22 05:38:59 - building world TB --- 2013-03-22 05:38:59 - CROSS_BUILD_TESTING=YES TB --- 2013-03-22 05:38:59 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-22 05:38:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-22 05:38:59 - SRCCONF=/dev/null TB --- 2013-03-22 05:38:59 - TARGET=powerpc TB --- 2013-03-22 05:38:59 - TARGET_ARCH=powerpc TB --- 2013-03-22 05:38:59 - TZ=UTC TB --- 2013-03-22 05:38:59 - __MAKE_CONF=/dev/null TB --- 2013-03-22 05:38:59 - cd /src TB --- 2013-03-22 05:38:59 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Mar 22 05:39:04 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Mar 22 08:00:52 UTC 2013 TB --- 2013-03-22 08:00:52 - generating LINT kernel config TB --- 2013-03-22 08:00:52 - cd /src/sys/powerpc/conf TB --- 2013-03-22 08:00:52 - /usr/bin/make -B LINT TB --- 2013-03-22 08:00:52 - cd /src/sys/powerpc/conf TB --- 2013-03-22 08:00:52 - /usr/sbin/config -m LINT TB --- 2013-03-22 08:00:52 - building LINT kernel TB --- 2013-03-22 08:00:52 - CROSS_BUILD_TESTING=YES TB --- 2013-03-22 08:00:52 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-22 08:00:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-22 08:00:52 - SRCCONF=/dev/null TB --- 2013-03-22 08:00:52 - TARGET=powerpc TB --- 2013-03-22 08:00:52 - TARGET_ARCH=powerpc TB --- 2013-03-22 08:00:52 - TZ=UTC TB --- 2013-03-22 08:00:52 - __MAKE_CONF=/dev/null TB --- 2013-03-22 08:00:52 - cd /src TB --- 2013-03-22 08:00:52 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Mar 22 08:00:52 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/fs/udf/udf_vnops.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/fs/unionfs/union_subr.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/fs/unionfs/union_vfsops.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/fs/unionfs/union_vnops.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/fs/tmpfs/tmpfs_vnops.c cc1: warnings being treated as errors /src/sys/fs/tmpfs/tmpfs_vnops.c: In function 'tmpfs_print': /src/sys/fs/tmpfs/tmpfs_vnops.c:1596: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'u_long' [-Wformat] *** [tmpfs_vnops.o] Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-22 08:07:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-22 08:07:14 - ERROR: failed to build LINT kernel TB --- 2013-03-22 08:07:14 - 7578.87 user 989.52 system 8946.14 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Mar 22 08:46:15 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 858AF27A; Fri, 22 Mar 2013 08:46:15 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5BD0AE60; Fri, 22 Mar 2013 08:46:15 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2M8kERo081783; Fri, 22 Mar 2013 04:46:14 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2M8kEek081782; Fri, 22 Mar 2013 08:46:14 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 22 Mar 2013 08:46:14 GMT Message-Id: <201303220846.r2M8kEek081782@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 08:46:15 -0000 TB --- 2013-03-22 05:52:02 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-22 05:52:02 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-22 05:52:02 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-03-22 05:52:02 - cleaning the object tree TB --- 2013-03-22 05:52:02 - /usr/local/bin/svn stat /src TB --- 2013-03-22 05:52:05 - At svn revision 248608 TB --- 2013-03-22 05:52:06 - building world TB --- 2013-03-22 05:52:06 - CROSS_BUILD_TESTING=YES TB --- 2013-03-22 05:52:06 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-22 05:52:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-22 05:52:06 - SRCCONF=/dev/null TB --- 2013-03-22 05:52:06 - TARGET=powerpc TB --- 2013-03-22 05:52:06 - TARGET_ARCH=powerpc64 TB --- 2013-03-22 05:52:06 - TZ=UTC TB --- 2013-03-22 05:52:06 - __MAKE_CONF=/dev/null TB --- 2013-03-22 05:52:06 - cd /src TB --- 2013-03-22 05:52:06 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Mar 22 05:52:11 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Fri Mar 22 08:41:54 UTC 2013 TB --- 2013-03-22 08:41:54 - generating LINT kernel config TB --- 2013-03-22 08:41:54 - cd /src/sys/powerpc/conf TB --- 2013-03-22 08:41:54 - /usr/bin/make -B LINT TB --- 2013-03-22 08:41:54 - cd /src/sys/powerpc/conf TB --- 2013-03-22 08:41:54 - /usr/sbin/config -m LINT TB --- 2013-03-22 08:41:54 - skipping LINT kernel TB --- 2013-03-22 08:41:54 - cd /src/sys/powerpc/conf TB --- 2013-03-22 08:41:54 - /usr/sbin/config -m GENERIC TB --- 2013-03-22 08:41:54 - skipping GENERIC kernel TB --- 2013-03-22 08:41:54 - cd /src/sys/powerpc/conf TB --- 2013-03-22 08:41:54 - /usr/sbin/config -m GENERIC64 TB --- 2013-03-22 08:41:54 - building GENERIC64 kernel TB --- 2013-03-22 08:41:54 - CROSS_BUILD_TESTING=YES TB --- 2013-03-22 08:41:54 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-22 08:41:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-22 08:41:54 - SRCCONF=/dev/null TB --- 2013-03-22 08:41:54 - TARGET=powerpc TB --- 2013-03-22 08:41:54 - TARGET_ARCH=powerpc64 TB --- 2013-03-22 08:41:54 - TZ=UTC TB --- 2013-03-22 08:41:54 - __MAKE_CONF=/dev/null TB --- 2013-03-22 08:41:54 - cd /src TB --- 2013-03-22 08:41:54 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64 >>> Kernel build for GENERIC64 started on Fri Mar 22 08:41:54 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/kern/vfs_lookup.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/kern/vfs_mount.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/kern/vfs_mountroot.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/kern/vfs_subr.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/kern/vfs_syscalls.c cc1: warnings being treated as errors /src/sys/kern/vfs_syscalls.c: In function 'sys_chflagsat': /src/sys/kern/vfs_syscalls.c:2692: warning: initialization discards qualifiers from pointer target type *** [vfs_syscalls.o] Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/GENERIC64. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-22 08:46:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-22 08:46:14 - ERROR: failed to build GENERIC64 kernel TB --- 2013-03-22 08:46:14 - 9094.21 user 1212.77 system 10451.73 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Mar 22 14:55:16 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4B58BC49 for ; Fri, 22 Mar 2013 14:55:16 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-ee0-f51.google.com (mail-ee0-f51.google.com [74.125.83.51]) by mx1.freebsd.org (Postfix) with ESMTP id D869A23B for ; Fri, 22 Mar 2013 14:55:15 +0000 (UTC) Received: by mail-ee0-f51.google.com with SMTP id d17so2254391eek.10 for ; Fri, 22 Mar 2013 07:55:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=TWkLwphZ+zsjEY+nXMeIrprhJ9/SUdSF4MPLkgdlTSQ=; b=wbPhkXc7yMOe3GAeHfxisz8b65KYKkZxwlueg5gpHb6PgeRWVnJNKmPiRK58l8QOeB Avj/GcSbPj3y+D2UsfJQyDPx9XxEx8WumS5smCUdRN9i3+80c32kWLz9vFwmObX8fB8M zSvI0vANbm+EHTjAUBqNc0l+6+rM3BFpJm1+/TMD5g479tSnmYZmuRd5OMJTpVMaY3hJ c1z5r5alETVweQJSX/Yl0lVFOlIF8pHwgJtvt5shCXQQI6LVRx9o0LZjyLZ+pchVbSYl dMVwqCagSk9Nwd9EbyMPqnJrCLLxoBLADAYNDtVFMaCxsh+9FHb1rqqei10/EqB7ynXF doLw== X-Received: by 10.14.223.69 with SMTP id u45mr5858357eep.23.1363964109408; Fri, 22 Mar 2013 07:55:09 -0700 (PDT) Received: from [192.168.1.80] (dsl51B63871.pool.t-online.hu. [81.182.56.113]) by mx.google.com with ESMTPS id r4sm3455697eeo.12.2013.03.22.07.55.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Mar 2013 07:55:08 -0700 (PDT) Message-ID: <514C70C6.2070603@gmail.com> Date: Fri, 22 Mar 2013 15:55:02 +0100 From: deeptech71 User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:18.0) Gecko/20100101 SeaMonkey/2.15 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: compilation error with WITHOUT_ED_CRYPTO Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 14:55:16 -0000 /usr/src/bin/ed/cbc.c:76:13: error: unused variable 'bits' [-Werror,-Wunused-variable] static char bits[] = { /* used to extract bits from a char */ ^ /usr/src/bin/ed/cbc.c:80:12: error: unused variable 'pflag' [-Werror,-Wunused-variable] static int pflag; /* 1 to preserve parity bits */ ^ /usr/src/bin/ed/cbc.c:86:22: error: unused variable 'des_buf' [-Werror,-Wunused-variable] static unsigned char des_buf[8];/* shared buffer for get_des_char/put_de... ^ /usr/src/bin/ed/cbc.c:87:12: error: unused variable 'des_ct' [-Werror,-Wunused-variable] static int des_ct = 0; /* count for get_des_char/put_des_char */ ^ /usr/src/bin/ed/cbc.c:88:12: error: unused variable 'des_n' [-Werror,-Wunused-variable] static int des_n = 0; /* index for put_des_char/get_des_char */ ^ The obvious fix: widen the scope of ``#ifdef DES'': Index: bin/ed/cbc.c =================================================================== --- bin/ed/cbc.c (revision 248614) +++ bin/ed/cbc.c (working copy) @@ -71,7 +71,6 @@ #ifdef DES static DES_cblock ivec; /* initialization vector */ static DES_cblock pvec; /* padding vector */ -#endif static char bits[] = { /* used to extract bits from a char */ '\200', '\100', '\040', '\020', '\010', '\004', '\002', '\001' @@ -79,13 +78,12 @@ static int pflag; /* 1 to preserve parity bits */ -#ifdef DES static DES_key_schedule schedule; /* expanded DES key */ -#endif static unsigned char des_buf[8];/* shared buffer for get_des_char/put_des_char */ static int des_ct = 0; /* count for get_des_char/put_des_char */ static int des_n = 0; /* index for put_des_char/get_des_char */ +#endif /* init_des_cipher: initialize DES */ void From owner-freebsd-current@FreeBSD.ORG Fri Mar 22 15:51:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 65129CC1 for ; Fri, 22 Mar 2013 15:51:25 +0000 (UTC) (envelope-from lattera@gmail.com) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) by mx1.freebsd.org (Postfix) with ESMTP id 4729E875 for ; Fri, 22 Mar 2013 15:51:25 +0000 (UTC) Received: by mail-pd0-f174.google.com with SMTP id z11so140133pdj.19 for ; Fri, 22 Mar 2013 08:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=fDp5MSmGVtFCe450kPSwWs0UwNP+5CjfCcSVRQyQPqU=; b=mvDJJ857jmQL4mDm4AiGPajNg++vxvP8S7j+bO+Zwsm2cPU8LVe4DR9pVPDHOa46XP EeUDNjDefA9+C+1GC0mR7qM9LZmWteQ1nYC6NNl1mx+kbvRylE8V2zmao99lte/5i36T O+dydkBVo7Bw5Su6U6UF2vvBGK5nY1SdBZztZE66QoQtsrGgbJ4KmYOkpN78WTJIHKZf YWvJhpd25qOp3evfKr7+50JnDSW5snyx+yO0DjP/yAL/SCYgfAZq5Y7qwzPSWZnNRwCA rCke7MEkaVmqG5YRvbLsHrCuBzlaJu7FpVA/VPyGcFy9iSE/+T0tEWH6lya3dwIWQQxr VLZA== MIME-Version: 1.0 X-Received: by 10.68.11.35 with SMTP id n3mr3281001pbb.220.1363967484797; Fri, 22 Mar 2013 08:51:24 -0700 (PDT) Received: by 10.68.247.38 with HTTP; Fri, 22 Mar 2013 08:51:24 -0700 (PDT) Date: Fri, 22 Mar 2013 11:51:24 -0400 Message-ID: Subject: r248583 Kernel panic: negative refcount 0xfffffe0031b59168 From: Shawn Webb To: FreeBSD-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 15:51:25 -0000 Hey All, I'm not sure if this is a result of r248583 or a different commit, but I hit a kernel panic when closing Chrome. I've linked to the info and core.txt files below. If you need me to ship you the vmcore file, let me know. It's 1.1GB in size. Other than the pasted files, I'm not too sure where to go from here. If there's any other info you need, please let me know. I'm a newb at submitting this kind of stuff. Paste of info file: http://ix.io/4Qo Paste of core.txt file: http://ix.io/4Qp Thanks, Shawn Webb From owner-freebsd-current@FreeBSD.ORG Fri Mar 22 19:48:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E4A0F510 for ; Fri, 22 Mar 2013 19:48:38 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) by mx1.freebsd.org (Postfix) with ESMTP id AD767FD3 for ; Fri, 22 Mar 2013 19:48:38 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.0 cv=EehKsYaC c=1 sm=0 a=0NJkuBbZY5VCdgJ+v5fl0w==:17 a=8jhF2qGmtvsA:10 a=AaUjGI9IrlcA:10 a=kj9zAlcOel0A:10 a=OA2lqS22AAAA:8 a=sIt-5M63AAAA:8 a=KS5gVQhY--UA:10 a=WIFmMkYa0n_S9hbRSjQA:9 a=CjuIK1q_8ugA:10 a=0NJkuBbZY5VCdgJ+v5fl0w==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=roberthuff@rcn.com; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=roberthuff@rcn.com; spf=neutral; sender-id=neutral Received-SPF: neutral (smtp02.rcn.cmh.synacor.com: 209.6.84.183 is neither permitted nor denied by domain of rcn.com) Received: from [209.6.84.183] ([209.6.84.183:52459] helo=jerusalem.litteratus.org.litteratus.org) by smtp.rcn.com (envelope-from ) (ecelerity 2.2.3.49 r(42060/42061)) with ESMTP id DF/34-28841-E85BC415; Fri, 22 Mar 2013 15:48:32 -0400 From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20812.46478.436088.992576@jerusalem.litteratus.org> Date: Fri, 22 Mar 2013 15:48:30 -0400 To: Dimitry Andric Subject: Re: troubles with buildworld/sendmail/sasl/clang In-Reply-To: <7DFCA510-5230-4EB6-8199-199DE7F8DE67@FreeBSD.org> References: <201303211416.r2LEG8cG041216@mech-cluster241.men.bris.ac.uk> <7DFCA510-5230-4EB6-8199-199DE7F8DE67@FreeBSD.org> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid Cc: roberthuff@rcn.com, beat.siegenthaler@beatsnet.com, kpaasial@gmail.com, freebsd-current@freebsd.org, freebsd-stable@freebsd.org, mexas@bristol.ac.uk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 19:48:39 -0000 Dimitry Andric writes: > Use the port, or the attached patch, to disable usage of > stdbool.h. Using the patch, world now compiles successfully. Thank you very much, Robert Huff From owner-freebsd-current@FreeBSD.ORG Fri Mar 22 21:13:54 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9E3B72FF for ; Fri, 22 Mar 2013 21:13:54 +0000 (UTC) (envelope-from zaphod@berentweb.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 841869CA for ; Fri, 22 Mar 2013 21:13:54 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UJ9Hd-0005vu-R9 for freebsd-current@freebsd.org; Fri, 22 Mar 2013 14:13:53 -0700 Date: Fri, 22 Mar 2013 14:13:53 -0700 (PDT) From: Beeblebrox To: freebsd-current@freebsd.org Message-ID: <1363986833835-5798199.post@n5.nabble.com> In-Reply-To: <1363928833296-5797872.post@n5.nabble.com> References: <1363877898593-5797633.post@n5.nabble.com> <1363928833296-5797872.post@n5.nabble.com> Subject: Re: compiler confusion: gcc cannot be located and causes compiler errors MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 21:13:54 -0000 I seem to have found the solution to the problem: lang/gcc needs to have symlinks in /usr/bin. Create these: # ln -s /usr/local/bin/gcc46 /usr/bin/gcc # ln -s /usr/local/bin/g++46 /usr/bin/g++ This way most, "gcc not found" errors should disappear. With many thanks to Ren=C3=A9 Ladan -- View this message in context: http://freebsd.1045724.n5.nabble.com/compiler= -confusion-gcc-cannot-be-located-and-causes-compiler-errors-tp5797633p57981= 99.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Fri Mar 22 23:29:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 36F5CF05 for ; Fri, 22 Mar 2013 23:29:36 +0000 (UTC) (envelope-from jrisom@gmail.com) Received: from mail-ia0-x22d.google.com (mail-ia0-x22d.google.com [IPv6:2607:f8b0:4001:c02::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 0C8238AA for ; Fri, 22 Mar 2013 23:29:36 +0000 (UTC) Received: by mail-ia0-f173.google.com with SMTP id h37so4031007iak.18 for ; Fri, 22 Mar 2013 16:29:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Mvng3BW4OMxbTSoChGYuS1HG4Cl0v3VaqtbH0vCQGgo=; b=aMMVvYwdMbvGAUF10nys/ehIXYoOr5cHqBcAxNdiv7L+uZtIz3cD4WUK1c+oFI064U n8LY+XgjVxPczcYOp5RLyRUNwr08ZN8KTjVOX0+STZ/Gdy/7KAEJ4796B1wzWPGbpti1 vvGL1xBCSwy0MYpjjdfgcgJCyU01tV2UTy69lWOoKqU1r5PFR6rQaBfOTNKKGpWacqYW GvAlJN0KXMmKdIPrjJZ9YIiMqbMVRXAZn1v5HPiFTcuIVgskGiz+BaxVMl2zJr8K3d3O fKKvG86Qto0eftCbjK/CH7y39+2Iu+nuqYqa5NSpReXsksoJ7fXspalq76bZTaDPh/18 /Vkw== X-Received: by 10.50.7.242 with SMTP id m18mr6145519iga.53.1363994975818; Fri, 22 Mar 2013 16:29:35 -0700 (PDT) Received: from [192.168.1.44] (c-98-212-197-211.hsd1.il.comcast.net. [98.212.197.211]) by mx.google.com with ESMTPS id i10sm9858390igz.9.2013.03.22.16.29.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Mar 2013 16:29:34 -0700 (PDT) Message-ID: <514CE95B.2090700@gmail.com> Date: Fri, 22 Mar 2013 18:29:31 -0500 From: Joshua Isom User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Kernel panics, one starting with r248508 References: <514B748F.80009@gmail.com> <20130321223813.GJ3794@kib.kiev.ua> In-Reply-To: <20130321223813.GJ3794@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 23:29:36 -0000 I updated today and tried it out, so far it's booted and is working. From owner-freebsd-current@FreeBSD.ORG Sat Mar 23 01:05:17 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4436540B; Sat, 23 Mar 2013 01:05:17 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com [IPv6:2a00:1450:4013:c01::229]) by mx1.freebsd.org (Postfix) with ESMTP id 8F5C4261; Sat, 23 Mar 2013 01:05:16 +0000 (UTC) Received: by mail-ea0-f169.google.com with SMTP id z7so1669545eaf.0 for ; Fri, 22 Mar 2013 18:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=+qj8cxrT8bjSSbKNvpnlsMJFiJMxkbZ/6H+tw/PPvTs=; b=C/B/qo80h7GipQU4n6xpd7HsQy3atnyFBpynkIlHRqCt6eW/WRU/X73ilvWc93vUn8 aQAJVm1s0YNdLKXnoXkY7Cd253BgBuCCp3uGMqg2xhjuLnSGQQdMTQEEivOFmC5XC/zw UvlZNqJc83aZw87QN5n589uB9mHSVSQyUcoBCNSwwgfb6rUyUvPShw+UmSkdeK+5bSvr Se1K88X/7eWH5MuyDW7Gs8w3SS2hhV1muNQ1FnEoZeA20u6giRoXAkK4VsbfhaaA+2r3 J9bYAo9Okzu0Uo2k83t0tasCivpMPbTd4bOdM+ZC2XApy/cOW3wHH4bqiK/enWDoXIu1 CFrg== MIME-Version: 1.0 X-Received: by 10.14.184.68 with SMTP id r44mr10183513eem.40.1364000715790; Fri, 22 Mar 2013 18:05:15 -0700 (PDT) Received: by 10.14.133.204 with HTTP; Fri, 22 Mar 2013 18:05:15 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Mar 2013 18:05:15 -0700 Message-ID: Subject: Re: hwpmc support for haswell From: hiren panchasara To: Davide Italiano Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current , Jim Harris X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 01:05:17 -0000 On Thu, Jan 31, 2013 at 6:26 PM, hiren panchasara wrote: > On Thu, Jan 31, 2013 at 5:47 PM, Davide Italiano wrote: >> On Fri, Feb 1, 2013 at 2:17 AM, hiren panchasara >> wrote: >>> Hi, >>> >>> I've prepared a patch to add core and uncore events support for >>> haswell processor. >>> I do not have the hardware to test this. It applies cleanly and >>> compiles fine though. >>> >>> http://www.strugglingcoder.info/patches/hwpmc_hw.txt >>> >>> This is initial version of patch and manpage is still missing. I will >>> add it in a few days. >>> >>> Any help in testing is appreciated. >>> >>> Thanks, >>> Hiren >> >> It seems Intel won't release this before June (at least to my knowledge). >> I would claim it'll be difficult to real test this before that date >> unless someone has prerelease hardware. > > Indeed. I've posted it here just to let larger audience know and avoid > possible duplicate work. > > We will wait till we get the hardware to test with. I recently got a ref haswell box to play with. Initial dmesg looks like this: CPU: Genuine Intel(R) CPU 0000 @ 2.60GHz (2594.05-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x306c2 Family = 0x6 Model = 0x3c Stepping = 2 Features=0xbfebfbff Features2=0x7ffafbff,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND> AMD Features=0x2c100800 AMD Features2=0x21 Standard Extended Features=0x2fbb TSC: P-state invariant, performance statistics real memory = 8589934592 (8192 MB) avail memory = 8034803712 (7662 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 Diffs at: http://www.strugglingcoder.info/patches/hwpmc_hw.txt Tests I've done: http://www.strugglingcoder.info/patches/hwpmc_hw_pmccontrol.txt http://www.strugglingcoder.info/patches/hwpmc_hw_pmctest.txt I am following 325462-045US Jan 2013 sw dev manual and below are the counters which I cannot poke at via pmcstat: Core: "L2_RQSTS.DEMAND_DATA_RD_MISS" "L2_RQSTS.DEMAND_DATA_RD_HIT" "L2_RQSTS.ALL_DEMAND_DATA_RD" "L2_RQSTS.ALL_DEMAND_MISS" "L2_RQSTS.ALL_DEMAND_REFERENCES" "L2_RQSTS.MISS" "CYCLE_ACTIVITY.STALLS_L2_PENDING" "PAGE_WALKER_LOADS.DTLB_L1" "PAGE_WALKER_LOADS.ITLB_L1" "BACLEARS.ANY" "L2_LINES_OUT.DEMAND_CLEAN" Uncore: "UNC_CBO_XSNP_RESPONSE.INVAL_M" "UNC_CBO_CACHE_LOOKUP.ES" For all of them, I get error like this: # pmcstat -p L2_RQSTS.MISS ls pmcstat: ERROR: Cannot allocate process-mode pmc with specification "L2_RQSTS.MISS": Invalid argument Box does not panic or anything. I've tried to double check my changes without success. Is it possible that the documentation has some inconsistencies? Cheers, Hiren From owner-freebsd-current@FreeBSD.ORG Sat Mar 23 01:16:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 77D5F727 for ; Sat, 23 Mar 2013 01:16:15 +0000 (UTC) (envelope-from andy@neu.net) Received: from mail.neu.net (neu.net [199.48.129.194]) by mx1.freebsd.org (Postfix) with ESMTP id 2632E350 for ; Sat, 23 Mar 2013 01:16:14 +0000 (UTC) Received: from neu.net (neu.net [199.48.129.194]) by mail.neu.net (8.14.6/8.14.5) with ESMTP id r2N1GDOu065537 for ; Fri, 22 Mar 2013 21:16:13 -0400 (EDT) (envelope-from andy@neu.net) Date: Fri, 22 Mar 2013 21:16:13 -0400 (EDT) From: AN To: freebsd-current@freebsd.org Subject: buildworld fails In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.97.7 at my.mail.server X-Virus-Status: Clean X-Spam-Status: No, score=0.0 required=4.5 tests=RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.neu.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 01:16:15 -0000 FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #38 r248401: Sat Mar 16 21:39:04 CDT 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 # svn info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 248631 Is anyone else seeing this? ===> gnu/usr.bin/texinfo/infokey (all) cc -O2 -pipe -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/infokey/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/infokey/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/infokey/../../../../contrib/texinfo/info/infokey.c cc -O2 -pipe -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/infokey/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/infokey/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/infokey/../../../../contrib/texinfo/info/key.c gzip -cn /usr/src/gnu/usr.bin/texinfo/infokey/../../../../contrib/texinfo/doc/infokey.1 > infokey.1.gz cc -O2 -pipe -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/infokey/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/infokey/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -o infokey infokey.o key.o /usr/obj/usr/src/gnu/usr.bin/texinfo/infokey/../libtxi/libtxi.a ===> gnu/usr.bin/texinfo/install-info (all) cc -O2 -pipe -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/util/install-info.c gzip -cn /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/doc/install-info.1 > install-info.1.gz /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/util/install-info.c:1179:28: warning: expression result unused [-Wunused-value] bindtextdomain (PACKAGE, LOCALEDIR); ^~~~~~~~~ :2:19: note: expanded from macro 'LOCALEDIR' #define LOCALEDIR "/usr/share/locale" ^~~~~~~~~~~~~~~~~~~ /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/lib/gettext.h:54:63: note: expanded from macro 'bindtextdomain' # define bindtextdomain(Domainname, Dirname) ((const char *) (Dirname)) ^ /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/util/install-info.c:1180:15: warning: expression result unused [-Wunused-value] textdomain (PACKAGE); ^~~~~~~ /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/config.h:338:17: note: expanded from macro 'PACKAGE' #define PACKAGE "texinfo" ^~~~~~~~~ /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/lib/gettext.h:53:50: note: expanded from macro 'textdomain' # define textdomain(Domainname) ((const char *) (Domainname)) ^ 2 warnings generated. cc -O2 -pipe -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -o install-info install-info.o /usr/obj/usr/src/gnu/usr.bin/texinfo/install-info/../libtxi/libtxi.a ===> gnu/usr.bin/texinfo/texindex (all) cc -O2 -pipe -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/util/texindex.c gzip -cn /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/doc/texindex.1 > texindex.1.gz /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/util/texindex.c:166:28: warning: expression result unused [-Wunused-value] bindtextdomain (PACKAGE, LOCALEDIR); ^~~~~~~~~ :2:19: note: expanded from macro 'LOCALEDIR' #define LOCALEDIR "/usr/share/locale" ^~~~~~~~~~~~~~~~~~~ /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/lib/gettext.h:54:63: note: expanded from macro 'bindtextdomain' # define bindtextdomain(Domainname, Dirname) ((const char *) (Dirname)) ^ /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/util/texindex.c:167:15: warning: expression result unused [-Wunused-value] textdomain (PACKAGE); ^~~~~~~ /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/config.h:338:17: note: expanded from macro 'PACKAGE' #define PACKAGE "texinfo" ^~~~~~~~~ /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/lib/gettext.h:53:50: note: expanded from macro 'textdomain' # define textdomain(Domainname) ((const char *) (Domainname)) ^ 2 warnings generated. cc -O2 -pipe -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -o texindex texindex.o /usr/obj/usr/src/gnu/usr.bin/texinfo/texindex/../libtxi/libtxi.a ===> gnu/usr.bin/texinfo/doc (all) makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/info.texi -o info.info makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/info-stnd.texi -o info-stnd.info ln -fs /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/texinfo.txi texinfo.texi makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc texinfo.texi -o texinfo.info gzip -cn info.info > info.info.gz gzip -cn info-stnd.info > info-stnd.info.gz gzip -cn texinfo.info > texinfo.info.gz 2 errors *** [everything] Error code 2 1 error *** [buildworld] Error code 2 1 error From owner-freebsd-current@FreeBSD.ORG Sat Mar 23 02:32:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9012B5BA; Sat, 23 Mar 2013 02:32:06 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id 4FBFC9E8; Sat, 23 Mar 2013 02:32:06 +0000 (UTC) Received: from glenbarber.us (nucleus.glenbarber.us [IPv6:2001:470:8:1205:2:2:ff:29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 7A17823F66A; Fri, 22 Mar 2013 22:32:05 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.8.0 onyx.glenbarber.us 7A17823F66A Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Fri, 22 Mar 2013 22:32:02 -0400 From: Glen Barber To: AN Subject: Re: buildworld fails Message-ID: <20130323023202.GB1512@glenbarber.us> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="St7VIuEGZ6dlpu13" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 02:32:06 -0000 --St7VIuEGZ6dlpu13 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 22, 2013 at 09:16:13PM -0400, AN wrote: > FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #38 r248401: Sat > Mar 16 21:39:04 CDT 2013 > root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 >=20 >=20 > # svn info > Path: . > Working Copy Root Path: /usr/src > URL: svn://svn.freebsd.org/base/head > Repository Root: svn://svn.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 248631 >=20 >=20 > Is anyone else seeing this? >=20 > =3D=3D=3D> gnu/usr.bin/texinfo/infokey (all) > cc -O2 -pipe -DHAVE_CONFIG_H -DLOCALEDIR=3D\"/usr/share/locale\" > -I/usr/src/gnu/usr.bin/texinfo/infokey/../../../../contrib/texinfo -I/usr= /src/gnu/usr.bin/texinfo/infokey/../../../../contrib/texinfo/lib > -std=3Dgnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bi= n/texinfo/infokey/../../../../contrib/texinfo/info/infokey.c > cc -O2 -pipe -DHAVE_CONFIG_H -DLOCALEDIR=3D\"/usr/share/locale\" > -I/usr/src/gnu/usr.bin/texinfo/infokey/../../../../contrib/texinfo -I/usr= /src/gnu/usr.bin/texinfo/infokey/../../../../contrib/texinfo/lib > -std=3Dgnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bi= n/texinfo/infokey/../../../../contrib/texinfo/info/key.c > gzip -cn /usr/src/gnu/usr.bin/texinfo/infokey/../../../../contrib/texinfo= /doc/infokey.1 > >infokey.1.gz > cc -O2 -pipe -DHAVE_CONFIG_H -DLOCALEDIR=3D\"/usr/share/locale\" > -I/usr/src/gnu/usr.bin/texinfo/infokey/../../../../contrib/texinfo -I/usr= /src/gnu/usr.bin/texinfo/infokey/../../../../contrib/texinfo/lib > -std=3Dgnu99 -Qunused-arguments -fstack-protector -o infokey > infokey.o key.o > /usr/obj/usr/src/gnu/usr.bin/texinfo/infokey/../libtxi/libtxi.a > =3D=3D=3D> gnu/usr.bin/texinfo/install-info (all) > cc -O2 -pipe -DHAVE_CONFIG_H -DLOCALEDIR=3D\"/usr/share/locale\" -I/usr/= src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo -I/usr/src= /gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/lib > -std=3Dgnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bi= n/texinfo/install-info/../../../../contrib/texinfo/util/install-info.c > gzip -cn /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/te= xinfo/doc/install-info.1 > >install-info.1.gz > /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/uti= l/install-info.c:1179:28: > warning: expression result unused [-Wunused-value] > bindtextdomain (PACKAGE, LOCALEDIR); > ^~~~~~~~~ > :2:19: note: expanded from macro 'LOCALEDIR' > #define LOCALEDIR "/usr/share/locale" > ^~~~~~~~~~~~~~~~~~~ > /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/lib= /gettext.h:54:63: > note: expanded from macro 'bindtextdomain' > # define bindtextdomain(Domainname, Dirname) ((const char *) (Dirname)) > ^ > /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/uti= l/install-info.c:1180:15: > warning: expression result unused [-Wunused-value] > textdomain (PACKAGE); > ^~~~~~~ > /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/con= fig.h:338:17: > note: expanded from macro 'PACKAGE' > #define PACKAGE "texinfo" > ^~~~~~~~~ > /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/lib= /gettext.h:53:50: > note: expanded from macro 'textdomain' > # define textdomain(Domainname) ((const char *) (Domainname)) > ^ > 2 warnings generated. > cc -O2 -pipe -DHAVE_CONFIG_H -DLOCALEDIR=3D\"/usr/share/locale\" -I/usr/= src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo -I/usr/src= /gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/lib > -std=3Dgnu99 -Qunused-arguments -fstack-protector -o install-info > install-info.o > /usr/obj/usr/src/gnu/usr.bin/texinfo/install-info/../libtxi/libtxi.a > =3D=3D=3D> gnu/usr.bin/texinfo/texindex (all) > cc -O2 -pipe -DHAVE_CONFIG_H -DLOCALEDIR=3D\"/usr/share/locale\" > -I/usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo -I/us= r/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/lib > -std=3Dgnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bi= n/texinfo/texindex/../../../../contrib/texinfo/util/texindex.c > gzip -cn /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinf= o/doc/texindex.1 > >texindex.1.gz > /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/util/te= xindex.c:166:28: > warning: expression result unused [-Wunused-value] > bindtextdomain (PACKAGE, LOCALEDIR); > ^~~~~~~~~ > :2:19: note: expanded from macro 'LOCALEDIR' > #define LOCALEDIR "/usr/share/locale" > ^~~~~~~~~~~~~~~~~~~ > /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/lib/get= text.h:54:63: > note: expanded from macro 'bindtextdomain' > # define bindtextdomain(Domainname, Dirname) ((const char *) (Dirname)) > ^ > /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/util/te= xindex.c:167:15: > warning: expression result unused [-Wunused-value] > textdomain (PACKAGE); > ^~~~~~~ > /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/config.= h:338:17: > note: expanded from macro 'PACKAGE' > #define PACKAGE "texinfo" > ^~~~~~~~~ > /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/lib/get= text.h:53:50: > note: expanded from macro 'textdomain' > # define textdomain(Domainname) ((const char *) (Domainname)) > ^ > 2 warnings generated. > cc -O2 -pipe -DHAVE_CONFIG_H -DLOCALEDIR=3D\"/usr/share/locale\" > -I/usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo -I/us= r/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/lib > -std=3Dgnu99 -Qunused-arguments -fstack-protector -o texindex > texindex.o > /usr/obj/usr/src/gnu/usr.bin/texinfo/texindex/../libtxi/libtxi.a > =3D=3D=3D> gnu/usr.bin/texinfo/doc (all) > makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I > /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc /usr/src= /gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/info.texi > -o info.info > makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I > /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc /usr/src= /gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/info-stnd.texi > -o info-stnd.info > ln -fs /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/t= exinfo.txi > texinfo.texi > makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I > /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc > texinfo.texi -o texinfo.info > gzip -cn info.info > info.info.gz > gzip -cn info-stnd.info > info-stnd.info.gz > gzip -cn texinfo.info > texinfo.info.gz > 2 errors > *** [everything] Error code 2 > 1 error > *** [buildworld] Error code 2 > 1 error >=20 No, not with this error. Although, I am not using clang. Can you please provide your /etc/make.conf and /etc/src.conf ? Glen --St7VIuEGZ6dlpu13 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJRTRQiAAoJEFJPDDeguUajgWAH/0q09vK4/8xcOLHrxGuIsa3k zBtfcQpMSvPhlDsHptVZ/iN+l6kDe/34lM41tivTLaBYgTwtNR+kwVOmySrnjroe sUv9TY5/8AbyQtTB8irAJWSjD6r3vYyiEF5nWbcJC5+3XiA3RSQCNEV4Gk/hL3Z+ ROYvBXc4C/lzXK4k5u0hPTaKHUexVJ9RB6xguI5YCOkWkSCsyg/jWBLY9PS4Oys0 7y40i1At3hY3bAULRg3hFKReh+7hYzhQgT0MeERXQpNJWUr/RQAig+7Q2a5GugSa VrAxPt9ASIjobl2RwJrNsd4rAfles1xjkwa3pHo7cv4mQ3nMfJh85Uvz3AOBDcE= =nAKB -----END PGP SIGNATURE----- --St7VIuEGZ6dlpu13-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 23 02:33:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B471D7C5; Sat, 23 Mar 2013 02:33:03 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id 8DEF6A08; Sat, 23 Mar 2013 02:33:03 +0000 (UTC) Received: from glenbarber.us (nucleus.glenbarber.us [IPv6:2001:470:8:1205:2:2:ff:29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id BD14123F66A; Fri, 22 Mar 2013 22:33:02 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.8.0 onyx.glenbarber.us BD14123F66A Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Fri, 22 Mar 2013 22:33:00 -0400 From: Glen Barber To: AN Subject: Re: buildworld fails Message-ID: <20130323023300.GC1512@glenbarber.us> References: <20130323023202.GB1512@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qtZFehHsKgwS5rPz" Content-Disposition: inline In-Reply-To: <20130323023202.GB1512@glenbarber.us> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 02:33:03 -0000 --qtZFehHsKgwS5rPz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 22, 2013 at 10:32:02PM -0400, Glen Barber wrote: > > gzip -cn info.info > info.info.gz > > gzip -cn info-stnd.info > info-stnd.info.gz > > gzip -cn texinfo.info > texinfo.info.gz > > 2 errors > > *** [everything] Error code 2 > > 1 error > > *** [buildworld] Error code 2 > > 1 error > >=20 >=20 > No, not with this error. Although, I am not using clang. Can you > please provide your /etc/make.conf and /etc/src.conf ? >=20 And of course, my local build just made a liar out of me... Yes, I see this too. Glen --qtZFehHsKgwS5rPz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJRTRRcAAoJEFJPDDeguUajaygIAK21AVKzScB17g108HQ5wMlA Lld+8ktFXh//qpFii00p1YBfU49WDhYr0sKZmyeiw1IwinOoQkTrByInO1mTndks /2uJW5NsmJ1myX40xnnTjU/jA+chvofVtSUZgw8t1sYBUUeKXGwXbUmWB938j9oF wc0F1/PY3GvtJepleVUmbni9l1uKm/QK+Tn14fWt92x8lQlh4341Rgd75yq4hHep M0qSgPW8fxU0cNV8mQUyhH2E3QC2+ZovaFFc3WT2tjsVCu8EpxlQ602d5/tEWBDy jyjDUb13eIzt6LjOuzURv3AtoHXtFHFqKlmE5R+4EfNPhrtusCTz0IZOxCgt6BQ= =hUpv -----END PGP SIGNATURE----- --qtZFehHsKgwS5rPz-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 23 02:45:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 61A1DA26; Sat, 23 Mar 2013 02:45:19 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id 3731AA38; Sat, 23 Mar 2013 02:45:19 +0000 (UTC) Received: from glenbarber.us (nucleus.glenbarber.us [IPv6:2001:470:8:1205:2:2:ff:29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 109C323F66A; Fri, 22 Mar 2013 22:45:17 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.8.0 onyx.glenbarber.us 109C323F66A Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Fri, 22 Mar 2013 22:45:15 -0400 From: Glen Barber To: AN Subject: Re: buildworld fails Message-ID: <20130323024515.GD1512@glenbarber.us> References: <20130323023202.GB1512@glenbarber.us> <20130323023300.GC1512@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pQhZXvAqiZgbeUkD" Content-Disposition: inline In-Reply-To: <20130323023300.GC1512@glenbarber.us> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 02:45:19 -0000 --pQhZXvAqiZgbeUkD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 22, 2013 at 10:33:00PM -0400, Glen Barber wrote: > On Fri, Mar 22, 2013 at 10:32:02PM -0400, Glen Barber wrote: > > > gzip -cn info.info > info.info.gz > > > gzip -cn info-stnd.info > info-stnd.info.gz > > > gzip -cn texinfo.info > texinfo.info.gz > > > 2 errors > > > *** [everything] Error code 2 > > > 1 error > > > *** [buildworld] Error code 2 > > > 1 error > > >=20 > >=20 > > No, not with this error. Although, I am not using clang. Can you > > please provide your /etc/make.conf and /etc/src.conf ? > >=20 >=20 > And of course, my local build just made a liar out of me... Yes, I see > this too. >=20 Ok, I suspect you are using '-jN' with make(1). The real error is: (cd /usr/src/rescue/rescue/../../sbin/fsdb && /usr/obj/usr/src/make.amd64/make -DRESCUE CRUNCH_CFLAGS=3D-DRESCUE DIRPRFX=3Drescue/rescue/fsdb/ depend && /usr/obj/usr/src/make.amd64/make -DRESCUE CRUNCH_CFLAGS=3D-DRESCUE DIRPRFX=3Drescue/rescue/fsdb/ fsdb.o fsdbutil.o dir.o ea.o fsutil.o inode.o pass1.o pass1b.o pass2.o pass3.o pass4.o pass5.o setup.o utilities.o ffs_subr.o ffs_tables.o) /usr/local/libexec/ccache/world/cc -O2 -pipe -I/usr/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=3Dgnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsdb/fsdb.c /usr/src/sbin/fsdb/fsdb.c: In function 'findblk': /usr/src/sbin/fsdb/fsdb.c:444: error: 'cgrp' undeclared (first use in this function) /usr/src/sbin/fsdb/fsdb.c:444: error: (Each undeclared identifier is reported only once /usr/src/sbin/fsdb/fsdb.c:444: error: for each function it appears in.) /usr/src/sbin/fsdb/fsdb.c:476: error: 'cgblk' undeclared (first use in this function) *** [fsdb.o] Error code 1 Stop in /usr/src/sbin/fsdb. *** [fsdb_make] Error code 1 This is ... known at the moment, and is being resolved. Please hang in there a bit until this change is either fixed or reverted. Glen --pQhZXvAqiZgbeUkD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJRTRc7AAoJEFJPDDeguUajATkH/3S5DxEXp+E/4UeB4xKuV1c3 u55xY+dbYhmtq/Yh8ET3gHcA7aZWVjOOTp0Ps/89c6EWuXQBNqQmXfHrt05LRGID N9WyYLITssRW0fIO/SuxxIv5f+UgARY5TRin251Jn88F4Vy/sLIzgl/tVGKTOjPW amaMWdH07gGUeunjUcryFpKq9jIJz944OEN7bCSS2aHi6loitrfke13SfVQFqPyb Cy4MKZJd+u5kjqll/BoIOpmn6NkxOP4nAzm6S8STU4HZoQ0vPW6tlcno79/YdWtS fNxO7mMTaREuZX+L5mt0fUE5s7nftFqHFLz7mIalV1KU4gX6InuuvBkyw0mk7do= =Vq7N -----END PGP SIGNATURE----- --pQhZXvAqiZgbeUkD-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 23 05:16:10 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0B5AB8A2; Sat, 23 Mar 2013 05:16:10 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by mx1.freebsd.org (Postfix) with ESMTP id 82253131; Sat, 23 Mar 2013 05:16:09 +0000 (UTC) Received: by mail-ob0-f181.google.com with SMTP id ni5so4595711obc.26 for ; Fri, 22 Mar 2013 22:16:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:cc:content-type; bh=Xg9biQo4hvXnDZDmfUnmAJkH4uMFiiJChxAMJbJiIfU=; b=csXqoJ8NCCxVAT14MWn8XLBNaZSf26wNcLNO8TixvzLrCDu9h+RhjQ6HA5hNeklU0t d5+ocn/XQvOVw81HEzwajuFPX+m5ML86lyUgzggvMlY7SXjv0BTnQrxlw75OkQokixMD IU5nu0u5QedqGDDmk6Fz9VfLUljnWiZrTmgHenRp09hvnyKF0BVjiH9XpD5WrTomeeus SQ7JiqUngm6eU44fXtBmlDkVW4Va+Y934bmypubEu+E6YUGVf3dZ5bO0CIF2N9e6gYIm yCsRctKgPi6KNxKo0rwvJqpraO5v4IDJVwl6xgH+F43KAz38leLKd5O7m8B9n0eeSUiR qQDg== MIME-Version: 1.0 X-Received: by 10.60.24.197 with SMTP id w5mr4237667oef.6.1364015769149; Fri, 22 Mar 2013 22:16:09 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.76.33.7 with HTTP; Fri, 22 Mar 2013 22:16:09 -0700 (PDT) Date: Fri, 22 Mar 2013 22:16:09 -0700 X-Google-Sender-Auth: hQA7GG9DWwcxXZbk16pfMKWxRwQ Message-ID: Subject: Report on issues with fusefs From: Kevin Oberman To: Attilio Rao Content-Type: text/plain; charset=UTF-8 Cc: Florian Smeets , Peter Holm , bdrewery@freebsd.org, FreeBSD FS , George Neville-Neil , freebsd-current@freebsd.org, =?UTF-8?Q?Gustau_P=C3=A9rez?= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 05:16:10 -0000 I've now been using fusefs regularly for a few months and I have found a few issues that i wanted to report. Most disturbing is corrupted NTFS systems. On several occasions I have found an NTFS system could not be written to with either FreeBSD or Windows. I had to user Windows disk check to repair the file system, but a few files were lost. this may be an issue with either fusefs or ntfs-3g. Not sure which, but it is likely tied to the next issue. On several occasions an attempt to re-boot my systems when NTFS volumes were mounted failed. After a power cycle the system came back, but te file systems were not clean and had to be fscked. All UFS systems checked clean and had no errors at all. I suspect that fusefs or ntfs-3g was the cause as I have been manually unmounted the NTFS systems before issuing the shutdown. The unmount has always succeeded in an odd way (issue 3), and the system has always shut down cleanly. The failures only seem to have happened when the NTFS volumes have been written to. The final issue is that I can't unmount a single NTFS volume. I normally have two NTFS volumes mounted, but issuing a umount on either will unmount both. This is rather annoying. I assume it is the result of all fusefs filesystems being /dev/fuse. I have not been able to figure out any way to unmount only one volume. I can't say whether this has any link to the file system corruptions. Could there be an issue with one of the volumes not actually being properly unmounted when both are unmounted by a single umount? While these are a bit of an annoyance, I continue to use fusefs with ntfs-3g and it generally is working fine. -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Sat Mar 23 05:33:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 645C7FC8; Sat, 23 Mar 2013 05:33:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id CFF8B1CB; Sat, 23 Mar 2013 05:33:34 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2N5XVLI013827; Sat, 23 Mar 2013 07:33:31 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2N5XVLI013827 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2N5XVqc013826; Sat, 23 Mar 2013 07:33:31 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 23 Mar 2013 07:33:31 +0200 From: Konstantin Belousov To: hiren panchasara Subject: Re: hwpmc support for haswell Message-ID: <20130323053331.GB3794@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3sYk/T6r7KJrPUiA" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Davide Italiano , freebsd-current , Jim Harris X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 05:33:35 -0000 --3sYk/T6r7KJrPUiA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Mar 22, 2013 at 06:05:15PM -0700, hiren panchasara wrote: > CPU: Genuine Intel(R) CPU 0000 @ 2.60GHz (2594.05-MHz K8-class CPU) > Origin = "GenuineIntel" Id = 0x306c2 Family = 0x6 Model = 0x3c > Stepping = 2 > Features=0xbfebfbff > Features2=0x7ffafbff,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND> Not related to hwpmc. Bit 11 of the %ecx seems to be declared as reserved even in the SDM rev. 045. I have no idea what is it for. --3sYk/T6r7KJrPUiA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRTT6qAAoJEJDCuSvBvK1BHaIP/jr3igLSb7s1lbvswpIIrQf9 XQljXoAV4KK86qyfM8xItMKZ/fIYcCh9bdyS/1x/rECu6xjGHxldqkcsP9oHPR+H P1Tv26UFDsg1ss4XawgXzTRYemvCWNissbmymm4pY8SiRrlWZiyMIVz9v+Xt1F2I JuEca4OB5XeeXkzJQ0Jo3fCj4yUx+gqIDbW+moYO6ecYTFaof5f3Cegty2HV79Ek gZKulFDqI38dQ0mHC3Lq1LNkTKw0GxgMXYvqC8ZKHHprsv1rE89FmGidhstGDTDj FCrD3LDc+aZw/9/erIJq3PEq/4WGF4fmTuOBQ4t/GZglZcmEi7pb7D5/hpx4p9V5 NdxDlKqznC7I2hbj8xbYt8HMzbuXObrEXRz9VeCDe9TH3AEl3wwZALY3k/wCjnB/ 0j/JL+j7Y9913JLDbHyT0D/GEHgPhtW2IroRu3blJpDlPnBWu0qDhMa9dIN+rki/ HG4h/Zr1yGM2AAzpmRbIblFDOZMuhja/pxW5sBHpKRSlg+nlU9ea0JUhF1r7iAE8 KVOz5gJnMUvXyeEo1kkUoDUwhsehbw5rIlQqQwbHT4YH5JHntZpgZ2PqK6QuCUR5 nVaRHpxmL8IghMo+2/mHcb2HD1Wd6xkz/AqESiX+0alFB4WspaAisZb50+g2n77L eSztwdtwU4PdRTyCiAQb =30X7 -----END PGP SIGNATURE----- --3sYk/T6r7KJrPUiA-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 23 05:48:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 546E5478; Sat, 23 Mar 2013 05:48:26 +0000 (UTC) (envelope-from jim.harris@gmail.com) Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by mx1.freebsd.org (Postfix) with ESMTP id 8ED3621D; Sat, 23 Mar 2013 05:48:25 +0000 (UTC) Received: by mail-ee0-f41.google.com with SMTP id c1so160958eek.28 for ; Fri, 22 Mar 2013 22:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=hqybHd8Hf60LVffF6OUkhSACzjLQqtpPzGIGPDjYap4=; b=CzcyMkNK+OPscTjGcnxRBcOBLjfshdpW9exNTm43PU3QRDnK2uvDsHjxrxfxo6f1ys PLHL21RXm2BgvXJYfh2b+yrRzq6dS8v3ZlANOxgNsZKE/Y4WAgT1xfi2Pgwhc7tFAEEO aXdzjXHBrh1pGMzokhzK3TKeItmNkkmT+4+Pse9PMdzQMkjbtVlpWS4vJXVtgCSGzqez bzOYysf/g5ojmvTIfOS0mQbQMAGQlrktR2xWPYYOVsrwo6N/pKGpiIN8PhsReOjNk5J7 H275SkqXPiaH2forfVsGW9DUDO/Nxb5CccZxUguhvvrXJv3378eigE74pq0yhphIAEm+ JL+g== MIME-Version: 1.0 X-Received: by 10.14.3.133 with SMTP id 5mr11526442eeh.43.1364017704054; Fri, 22 Mar 2013 22:48:24 -0700 (PDT) Received: by 10.14.96.129 with HTTP; Fri, 22 Mar 2013 22:48:23 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Mar 2013 22:48:23 -0700 Message-ID: Subject: Re: hwpmc support for haswell From: Jim Harris To: hiren panchasara Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Davide Italiano , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 05:48:26 -0000 On Friday, March 22, 2013, hiren panchasara wrote: > On Thu, Jan 31, 2013 at 6:26 PM, hiren panchasara > > wrote: > > On Thu, Jan 31, 2013 at 5:47 PM, Davide Italiano > > wrote: > >> On Fri, Feb 1, 2013 at 2:17 AM, hiren panchasara > >> > wrote: > >>> Hi, > >>> > >>> I've prepared a patch to add core and uncore events support for > >>> haswell processor. > >>> I do not have the hardware to test this. It applies cleanly and > >>> compiles fine though. > >>> > >>> http://www.strugglingcoder.info/patches/hwpmc_hw.txt > >>> > >>> This is initial version of patch and manpage is still missing. I will > >>> add it in a few days. > >>> > >>> Any help in testing is appreciated. > >>> > >>> Thanks, > >>> Hiren > >> > >> It seems Intel won't release this before June (at least to my > knowledge). > >> I would claim it'll be difficult to real test this before that date > >> unless someone has prerelease hardware. > > > > Indeed. I've posted it here just to let larger audience know and avoid > > possible duplicate work. > > > > We will wait till we get the hardware to test with. > > I recently got a ref haswell box to play with. > > Initial dmesg looks like this: > > CPU: Genuine Intel(R) CPU 0000 @ 2.60GHz (2594.05-MHz K8-class CPU) > Origin = "GenuineIntel" Id = 0x306c2 Family = 0x6 Model = 0x3c > Stepping = 2 > > Features=0xbfebfbff > > Features2=0x7ffafbff,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND> > AMD Features=0x2c100800 > AMD Features2=0x21 > Standard Extended Features=0x2fbb > TSC: P-state invariant, performance statistics > real memory = 8589934592 (8192 MB) > avail memory = 8034803712 (7662 MB) > Event timer "LAPIC" quality 600 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 2 > cpu3 (AP): APIC ID: 3 > cpu4 (AP): APIC ID: 4 > cpu5 (AP): APIC ID: 5 > cpu6 (AP): APIC ID: 6 > cpu7 (AP): APIC ID: 7 > > Diffs at: > http://www.strugglingcoder.info/patches/hwpmc_hw.txt > Tests I've done: > http://www.strugglingcoder.info/patches/hwpmc_hw_pmccontrol.txt > http://www.strugglingcoder.info/patches/hwpmc_hw_pmctest.txt > > I am following 325462-045US Jan 2013 sw dev manual and below are the > counters > which I cannot poke at via pmcstat: > > Core: > "L2_RQSTS.DEMAND_DATA_RD_MISS" > "L2_RQSTS.DEMAND_DATA_RD_HIT" > "L2_RQSTS.ALL_DEMAND_DATA_RD" > "L2_RQSTS.ALL_DEMAND_MISS" > "L2_RQSTS.ALL_DEMAND_REFERENCES" > "L2_RQSTS.MISS" > "CYCLE_ACTIVITY.STALLS_L2_PENDING" > "PAGE_WALKER_LOADS.DTLB_L1" > "PAGE_WALKER_LOADS.ITLB_L1" > "BACLEARS.ANY" > "L2_LINES_OUT.DEMAND_CLEAN" > > Uncore: > "UNC_CBO_XSNP_RESPONSE.INVAL_M" > "UNC_CBO_CACHE_LOOKUP.ES" > > For all of them, I get error like this: > > # pmcstat -p L2_RQSTS.MISS ls > pmcstat: ERROR: Cannot allocate process-mode pmc with specification > "L2_RQSTS.MISS": Invalid argument > > Box does not panic or anything. > > I've tried to double check my changes without success. > Is it possible that the documentation has some inconsistencies? > > It looks like IAF_F_FM is missing from most (all?) of the new event w/ umask entries you added that are specific to Haswell. Can you try adding these and see if it clears anything up? A cursory look seemed to show most of these failures are on event/umasks that are missing this flag. Thanks, -Jim From owner-freebsd-current@FreeBSD.ORG Sat Mar 23 06:48:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1BA8A495; Sat, 23 Mar 2013 06:48:42 +0000 (UTC) (envelope-from zec@fer.hr) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) by mx1.freebsd.org (Postfix) with ESMTP id A2D473E2; Sat, 23 Mar 2013 06:48:41 +0000 (UTC) Received: from tpx32.lan (89.164.207.80) by MAIL.fer.hr (161.53.72.233) with Microsoft SMTP Server (TLS) id 14.2.309.2; Sat, 23 Mar 2013 07:48:33 +0100 From: Marko Zec To: Subject: Re: Report on issues with fusefs Date: Sat, 23 Mar 2013 07:47:54 +0100 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <201303230747.55405.zec@fer.hr> X-Originating-IP: [89.164.207.80] Cc: FreeBSD FS , Florian Smeets , George Neville-Neil , Peter Holm , bdrewery@freebsd.org, Attilio Rao , Kevin Oberman , Gustau =?iso-8859-1?q?P=E9rez?= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 06:48:42 -0000 On Saturday 23 March 2013 06:16:09 Kevin Oberman wrote: > I've now been using fusefs regularly for a few months and I have found > a few issues that i wanted to report. > > Most disturbing is corrupted NTFS systems. On several occasions I have > found an NTFS system could not be written to with either FreeBSD or > Windows. I had to user Windows disk check to repair the file system, > but a few files were lost. this may be an issue with either fusefs or > ntfs-3g. Not sure which, but it is likely tied to the next issue. +1. This can be reproduced fairly easily by copying large file hierarchies to a NTFS volume (such as a snapshot of our src tree). Marko > On several occasions an attempt to re-boot my systems when NTFS > volumes were mounted failed. After a power cycle the system came back, > but te file systems were not clean and had to be fscked. All UFS > systems checked clean and had no errors at all. I suspect that fusefs > or ntfs-3g was the cause as I have been manually unmounted the NTFS > systems before issuing the shutdown. The unmount has always succeeded > in an odd way (issue 3), and the system has always shut down cleanly. > The failures only seem to have happened when the NTFS volumes have > been written to. > > The final issue is that I can't unmount a single NTFS volume. I > normally have two NTFS volumes mounted, but issuing a umount on either > will unmount both. This is rather annoying. I assume it is the result > of all fusefs filesystems being /dev/fuse. I have not been able to > figure out any way to unmount only one volume. I can't say whether > this has any link to the file system corruptions. Could there be an > issue with one of the volumes not actually being properly unmounted > when both are unmounted by a single umount? > > While these are a bit of an annoyance, I continue to use fusefs with > ntfs-3g and it generally is working fine. From owner-freebsd-current@FreeBSD.ORG Sat Mar 23 08:29:55 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BE46762E for ; Sat, 23 Mar 2013 08:29:55 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-bk0-x235.google.com (mail-bk0-x235.google.com [IPv6:2a00:1450:4008:c01::235]) by mx1.freebsd.org (Postfix) with ESMTP id 51691A8A for ; Sat, 23 Mar 2013 08:29:55 +0000 (UTC) Received: by mail-bk0-f53.google.com with SMTP id e19so184781bku.40 for ; Sat, 23 Mar 2013 01:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:x-mailer:mime-version:content-type :content-transfer-encoding; bh=KwZw+f6qYmXmmoqIAX7OSVu3gO3I1Af00n1DtNpoO54=; b=t/zADu3Ieo8L1kgPbs15pI/sNzPXCniiPjmnI4ouGz6eQvcAlnFSFryfhb8VDP6xUS XtvpTpvlfQpA70XVc7LXp4RkhHH9OdORb3WtkC8FgIpM3PZCgo5EX0PnoGbBBJ5SgQbq RtT4az50vhlsnGsxbRba4genF4t9lT/5IVVSXPDXLDhaKtXUbLRH3zXCkKkjqeKs20w4 0EqrkRtWif5nL+QuzCkCHqrsVLK9eNXbBEmpLPjtBOG1gMMhGnEZ/oPSuwBW3gbgQKda sakrrofuNBffSyftyacoptQ1GihCvgSQSHTKrMBMbLsONMU+OKHOv9cW4w9W7abvTOmh dwOA== X-Received: by 10.205.39.3 with SMTP id tk3mr2393556bkb.113.1364027394353; Sat, 23 Mar 2013 01:29:54 -0700 (PDT) Received: from ernst.jennejohn.org (p578E2BD7.dip.t-dialin.net. [87.142.43.215]) by mx.google.com with ESMTPS id x18sm1170150bkw.4.2013.03.23.01.29.52 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 23 Mar 2013 01:29:53 -0700 (PDT) Date: Sat, 23 Mar 2013 09:29:51 +0100 From: Gary Jennejohn To: Konstantin Belousov Subject: Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver Message-ID: <20130323092951.0be9c3b8@ernst.jennejohn.org> In-Reply-To: <20130321183105.GB3794@kib.kiev.ua> References: <20130320174458.GG3794@kib.kiev.ua> <20130320180239.GN32811@albert.catwhisker.org> <20130320200857.GN3794@kib.kiev.ua> <20130321013610.GB42912@albert.catwhisker.org> <20130321080441.GS3794@kib.kiev.ua> <20130321133446.GF42912@albert.catwhisker.org> <20130321135835.GX3794@kib.kiev.ua> <20130321191426.25b1b327@ernst.jennejohn.org> <20130321183105.GB3794@kib.kiev.ua> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, Shawn Webb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 08:29:55 -0000 On Thu, 21 Mar 2013 20:31:06 +0200 Konstantin Belousov wrote: > On Thu, Mar 21, 2013 at 07:14:26PM +0100, Gary Jennejohn wrote: > > I wonder whether there isn't some dependency on the graphics chip being > > used. > > > > I'm running r248589 AMD64 and didn't have to touch a thing to get X > > to start. > > > > But I'm using an older, presumably less demanding graphics chip: > You use the amd64 kernel, which has ample KVA space. > The problem is specific to i386. > > > > > vgapci0@pci0:1:0:0: class=0x030000 card=0x19051462 chip=0x0a6510de rev=0xa2 hdr=0x00 > > vendor = 'NVIDIA Corporation' > > device = 'GT218 [GeForce 210]' > > class = display > > subclass = VGA > > bar [10] = type Memory, range 32, base 0xfb000000, size 16777216, enabled > > bar [14] = type Prefetchable Memory, range 64, base 0xc0000000, size 268435456, enabled > > bar [1c] = type Prefetchable Memory, range 64, base 0xde000000, size 33554432, enabled > > bar [24] = type I/O Port, range 32, base 0xef00, size 128, enabled > > > > Above all, bar [14] is only half as large. In the part you deleted Shawn Webb reports that he's also using AMD64. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Sat Mar 23 08:41:56 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D31FD79A; Sat, 23 Mar 2013 08:41:56 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D57EFACF; Sat, 23 Mar 2013 08:41:55 +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 KAA14977; Sat, 23 Mar 2013 10:41:47 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UJK1K-000Dml-Ox; Sat, 23 Mar 2013 10:41:46 +0200 Message-ID: <514D6AC5.8010409@FreeBSD.org> Date: Sat, 23 Mar 2013 10:41:41 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130321 Thunderbird/17.0.4 MIME-Version: 1.0 To: FreeBSD Current , freebsd-rc@FreeBSD.org Subject: rc.subr: disabling globbing while processing devfs rules X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 08:41:56 -0000 Any objections / concerns for the following change? An example. This rule in devfs.rules: add path da* mode 660 group operator and this directory: /data result in the following rule being actually installed: 100 path data group operator mode 660 Of course, I could refine the pattern in the rule, but I shouldn't have to do it, because the pattern is for /dev/ entries, not arbitrary files in the filesystem namespace. commit 7ce5e9ca5c107e2669f18efa472c1ab14999247c Author: Andriy Gapon Date: Sat Mar 23 10:29:39 2013 +0200 rc.subr: disabling globbing while processing devfs rules in devfs_rulesets_from_file() The rules themselves typically have shell-like patterns and it is incorrect when they get replaced with matching filesystem entries. Shell magic by: jilles diff --git a/etc/rc.subr b/etc/rc.subr index f37ede7..9952c82 100644 --- a/etc/rc.subr +++ b/etc/rc.subr @@ -1301,7 +1301,7 @@ make_symlink() # devfs_rulesets_from_file() { - local file _err _me + local file _err _me _opts file="$1" _me="devfs_rulesets_from_file" _err=0 @@ -1314,6 +1314,11 @@ devfs_rulesets_from_file() debug "$_me: no such file ($file)" return 0 fi + + # Disable globbing so that the rule patterns are not expanded + # by accident with matching filesystem entries. + _opts=$-; set -f + debug "reading rulesets from file ($file)" { while read line do @@ -1360,6 +1365,7 @@ devfs_rulesets_from_file() break fi done } < $file + case $_opts in *f*) ;; *) set +f ;; esac return $_err } -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat Mar 23 09:48:56 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1BC84BFD; Sat, 23 Mar 2013 09:48:56 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E8C2FD32; Sat, 23 Mar 2013 09:48:54 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA15528; Sat, 23 Mar 2013 11:48:53 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UJL4G-000Dtf-O0; Sat, 23 Mar 2013 11:48:52 +0200 Message-ID: <514D7A82.9000105@FreeBSD.org> Date: Sat, 23 Mar 2013 11:48:50 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130321 Thunderbird/17.0.4 MIME-Version: 1.0 To: FreeBSD Current , freebsd-hackers@FreeBSD.org, freebsd-acpi@FreeBSD.org Subject: Re: call suspend_cpus() under smp_ipi_mtx References: <5114AB2E.2050909@FreeBSD.org> In-Reply-To: <5114AB2E.2050909@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 09:48:56 -0000 Looks like this issue needs more thinking and discussing. The basic idea is that suspend_cpus() must be called with smp_ipi_mtx held (on SMP systems). This is for exactly the same reasons as to why we first take smp_ipi_mtx before calling stop_cpus() in the shutdown path. Essentially one CPU could be holding smp_ipi_mtx (and thus with interrupts disabled[*]) and waiting for an acknowledgement from other CPUs (e.g. in smp_rendezvous or in a TLB shootdown), while another CPU could be with interrupts disabled (explicitly - like in the shutdown or ACPI suspend paths) and trying to deliver an IPI to other CPUs. In my opinion, we must consistently use the same lock, smp_ipi_mtx, for all regular (non-NMI) synchronous IPI-based communication between CPUs. Otherwise a deadlock is quite possible. Some obstacles for just going ahead and making the suggested change: - acpi_sleep_machdep() calls intr_suspend() with interrupts disabled; currently witness(9) is not aware of that, but if smp_ipi_mtx spin-lock is used, then we would have to make intr_table_lock and msi_lock the spin-locks as well; - AcpiLeaveSleepStatePrep() (from ACPICA) is called with interrupts disabled and currently it performs an action that requires memory allocation; again, with interrupts disabled via intr_disable() this fact is not visible to witness, etc, but with smp_ipi_mtx it needs to be somehow handled. I talked to ACPICA guys about the last issue and they told me that what is currently done in AcpiLeaveSleepStatePrep does not need to be with interrupts disabled and can be moved to AcpiLeaveSleepState. This is after the _BFS and _GTS support was removed. What do you think? Thank you. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat Mar 23 11:26:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 92446D33; Sat, 23 Mar 2013 11:26:35 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm2.ukr.net (fsm2.ukr.net [195.214.192.121]) by mx1.freebsd.org (Postfix) with ESMTP id 49C39FD8; Sat, 23 Mar 2013 11:26:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:Mime-Version:Message-ID:Subject:Cc:To:From:Date; bh=2Vu0GcpIclmq4/Hm7Fm9rWClMRWGQJd/jDjD27SSl38=; b=xQN11Xr0oYmqYXpB8WXm+Ac1htgbxQkPYEgZANHevdGkk9b9e/s8IEPvM7Rex0SBny6c3WgF9TI0nP1Ehs5nv+/HHG/zI0JS/o24yvSsofH938hVV+iv6kSo7qwGi9o5A+CRA8eNFSuR05QC1PJxQrKXD5DChFdPMRjD1KjKZP8=; Received: from [178.137.138.140] (helo=nonamehost) by fsm2.ukr.net with esmtpsa ID 1UJMai-000Ki0-7F ; Sat, 23 Mar 2013 13:26:28 +0200 Date: Sat, 23 Mar 2013 13:26:27 +0200 From: Ivan Klymenko To: freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: Kernel panic CURRENT r248596 at virtualbox-ose-kmod module load Message-ID: <20130323132627.04bf7ef4@nonamehost> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.17; amd64-portbld-freebsd10.0) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEWpqak/Pz/i4uIfHx8GBwZwcHAQEBA6o92AAAACHElEQVQ4jWWUTY7bMAyF6QzUPSEoa8PFHEBgqwuM4bVVg7MvZOj+R+ijpMTpjIwgkT7z75EKrdfattpXERG6zqvUOtAr2LCRYfEKcB4l/Q+2cc6XjQH7hv+2YZYreIk5nevZEPvuzUzptizHLzgDMnC5Wpbl7ewJlOEqlQF+DlCjgVLki0WV6FMDMsBxjlJiQulIznwZ+DxHiQyDyIg0wN3Oo6o6ZQ5s5AIfar+W2Wlmz+kCcb8tg6j3voMEwNrBQk69dDBDqw/urpqJH+m+Q6u/4QnoAeYpnUXC/s1iup9rhCd6xMgAqdDyAyFegbKkVAHeLCcOulPLawaoUIDos4M88iLNrVkU7uu5ccTDO6naJzWLum51C6Yb7y4HKKbdArLWir0PBiS8glJRBZHeyHl7J9lENpAC6qT9NlNG4u5hsVYDyJP6mlJJtY3oVju4WSUzHal1sDU17NASoBWSk40J2eBLBJhYrVmzC5gVALGpNIAiQgN6eGstOp9Oa6zFbbLTISYi28BGZDRUJKWeroECkCEkzXjUtbmmaKMfAx2RfbT69/cO+tgHcmx6AfyZOmj3NDIah0F0GB66d4CrdIoplNFFGHSpSheRxbo0W4S8azNItEoMWbw3uXAeJgCrmX5joz7CGXqSg6PcryEhnFr/C1C2ntPxBOYbdwY+8dO3+wZJyFlbMX9s8zNnvp/tLwAv03NB4j3HVpn8Awwm+GrlP6MVAAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 11:26:35 -0000 I have uname -a FreeBSD nonamehost 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r248596: Fri Mar 22 01:17:08 EET 2013 ivan@nonamehost:/usr/obj/usr/src/sys/GENERIC amd64 I updated the ports tree to r314921 and recompiled virtualbox-ose-kmod After load the module a have kernel panic. Panic String: Lock vm object not exclusively locked @ /usr/src/sys/vm/vm_page.c:1396 http://pkgupdate.nevosoft.ru/backtrace.txt From owner-freebsd-current@FreeBSD.ORG Sat Mar 23 15:28:31 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8E333159; Sat, 23 Mar 2013 15:28:31 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by mx1.freebsd.org (Postfix) with ESMTP id E253D96A; Sat, 23 Mar 2013 15:28:30 +0000 (UTC) Received: by mail-la0-f46.google.com with SMTP id fq12so9059636lab.33 for ; Sat, 23 Mar 2013 08:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=QSw+r6zQk7j/kAN0Ew8/Cpr6JBogqtSEMXoG5loultw=; b=UJPBm2rWe/BtFVU78hELzLeczd23EiNUSGaIsHLu93+v1lpGncGveEEMMEHJo2W+EL vMpO7PzsDj7nIB7iIVYFMOe9nuLbXIDJ4j9eLziCoqlvbrbiqNypghljNzFpL7v8MDnm Taj8zMdB9TWokFa9KoGkXUQUBy1/RmVkZys7xrkWcubw/CWzyjSg+AXPcOOnajPxrzYv s65zy/hoKiWvtlP/PR0Ldp5+4kJ/xJx/YzPcKuzYy38LuYloLSOJvszRd22HviCdMDdE pSThoTSUsh6hPNGktBwzuc0Ypa1oBYDrqFImGYn7mENYZDlvlkj9WqJTB9LB9LYCfvS4 hhmQ== MIME-Version: 1.0 X-Received: by 10.112.100.166 with SMTP id ez6mr3009128lbb.86.1364052509743; Sat, 23 Mar 2013 08:28:29 -0700 (PDT) Received: by 10.112.104.35 with HTTP; Sat, 23 Mar 2013 08:28:29 -0700 (PDT) In-Reply-To: References: Date: Sat, 23 Mar 2013 16:28:29 +0100 Message-ID: Subject: Re: hwpmc support for haswell From: Oliver Pinter To: hiren panchasara Content-Type: text/plain; charset=ISO-8859-1 Cc: Davide Italiano , freebsd-current , Jim Harris X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 15:28:31 -0000 On 3/23/13, hiren panchasara wrote: > On Thu, Jan 31, 2013 at 6:26 PM, hiren panchasara > wrote: >> On Thu, Jan 31, 2013 at 5:47 PM, Davide Italiano >> wrote: >>> On Fri, Feb 1, 2013 at 2:17 AM, hiren panchasara >>> wrote: >>>> Hi, >>>> >>>> I've prepared a patch to add core and uncore events support for >>>> haswell processor. >>>> I do not have the hardware to test this. It applies cleanly and >>>> compiles fine though. >>>> >>>> http://www.strugglingcoder.info/patches/hwpmc_hw.txt >>>> >>>> This is initial version of patch and manpage is still missing. I will >>>> add it in a few days. >>>> >>>> Any help in testing is appreciated. >>>> >>>> Thanks, >>>> Hiren >>> >>> It seems Intel won't release this before June (at least to my >>> knowledge). >>> I would claim it'll be difficult to real test this before that date >>> unless someone has prerelease hardware. >> >> Indeed. I've posted it here just to let larger audience know and avoid >> possible duplicate work. >> >> We will wait till we get the hardware to test with. > > I recently got a ref haswell box to play with. > > Initial dmesg looks like this: > > CPU: Genuine Intel(R) CPU 0000 @ 2.60GHz (2594.05-MHz K8-class CPU) > Origin = "GenuineIntel" Id = 0x306c2 Family = 0x6 Model = 0x3c > Stepping = 2 > > Features=0xbfebfbff > > Features2=0x7ffafbff,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND> > AMD Features=0x2c100800 > AMD Features2=0x21 > Standard Extended Features=0x2fbb > TSC: P-state invariant, performance statistics > real memory = 8589934592 (8192 MB) > avail memory = 8034803712 (7662 MB) > Event timer "LAPIC" quality 600 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 2 > cpu3 (AP): APIC ID: 3 > cpu4 (AP): APIC ID: 4 > cpu5 (AP): APIC ID: 5 > cpu6 (AP): APIC ID: 6 > cpu7 (AP): APIC ID: 7 > > Diffs at: > http://www.strugglingcoder.info/patches/hwpmc_hw.txt > Tests I've done: > http://www.strugglingcoder.info/patches/hwpmc_hw_pmccontrol.txt > http://www.strugglingcoder.info/patches/hwpmc_hw_pmctest.txt > > I am following 325462-045US Jan 2013 sw dev manual and below are the > counters > which I cannot poke at via pmcstat: > > Core: > "L2_RQSTS.DEMAND_DATA_RD_MISS" > "L2_RQSTS.DEMAND_DATA_RD_HIT" > "L2_RQSTS.ALL_DEMAND_DATA_RD" > "L2_RQSTS.ALL_DEMAND_MISS" > "L2_RQSTS.ALL_DEMAND_REFERENCES" > "L2_RQSTS.MISS" > "CYCLE_ACTIVITY.STALLS_L2_PENDING" > "PAGE_WALKER_LOADS.DTLB_L1" > "PAGE_WALKER_LOADS.ITLB_L1" > "BACLEARS.ANY" > "L2_LINES_OUT.DEMAND_CLEAN" > > Uncore: > "UNC_CBO_XSNP_RESPONSE.INVAL_M" > "UNC_CBO_CACHE_LOOKUP.ES" > > For all of them, I get error like this: > > # pmcstat -p L2_RQSTS.MISS ls > pmcstat: ERROR: Cannot allocate process-mode pmc with specification > "L2_RQSTS.MISS": Invalid argument > > Box does not panic or anything. > > I've tried to double check my changes without success. > Is it possible that the documentation has some inconsistencies? Hi! I'm working on SMAP feature, when I have a mostly complete patchset, can you please test? > > Cheers, > Hiren > _______________________________________________ > 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 Mar 23 15:47:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D91DE65C for ; Sat, 23 Mar 2013 15:47:59 +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 95FB1A05 for ; Sat, 23 Mar 2013 15:47:59 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:cd63:a817:556f:dff2]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 0795A4AC58; Sat, 23 Mar 2013 19:47:47 +0400 (MSK) Date: Sat, 23 Mar 2013 19:47:40 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1908925614.20130323194740@serebryakov.spb.ru> To: Oliver Pinter Subject: Re: hwpmc support for haswell In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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: Sat, 23 Mar 2013 15:47:59 -0000 Hello, Oliver. You wrote 23 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2013 =D0=B3., 19:28:29: OP> I'm working on SMAP feature, when I have a mostly complete patchset, OP> can you please test? WOW! At last! At 20 years of Pentium, Intel added SMAP! --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Sat Mar 23 15:57:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7C170ACB; Sat, 23 Mar 2013 15:57:36 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id DE6F2A66; Sat, 23 Mar 2013 15:57:35 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id c41so2720709eek.13 for ; Sat, 23 Mar 2013 08:57:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Gk/mbUaHuqbykvyLRYJrvl+bg/ZTEjDs27utZ1WfkRE=; b=eGwCvSd5EKfeeCdpuylOQDqqd0Xb0z+hrokK+uVU+l21RP2Moqd2+BSS6WmL6VT5Ld jgnnGohC1h9e9249gGfiT+5AKc2F8w2JEHzrOatCEyVaVP01AeWnWX/ZPESJgMKKbdfU KDirqhhjnsL7Oq69u7U3Fuf+mCgU0UdjVPuugNRuaqHwGwfhxxWfIuK5rGpgBJpY1dXG EAiCZCCgzJ0p2w0DlUogfPeJxZbiEWgGeztE9bwrJwohVUR8LmTofk8mdQdKlr/5uvC9 L6reMxYWGzdp9U4Qj3h1T99nha3ieXtdm6Onc0xnFGKeE7BtlDQ3YUA9QH9GIbOro5pO G43A== MIME-Version: 1.0 X-Received: by 10.15.22.76 with SMTP id e52mr7145820eeu.7.1364054248613; Sat, 23 Mar 2013 08:57:28 -0700 (PDT) Received: by 10.14.133.204 with HTTP; Sat, 23 Mar 2013 08:57:28 -0700 (PDT) Received: by 10.14.133.204 with HTTP; Sat, 23 Mar 2013 08:57:28 -0700 (PDT) In-Reply-To: References: Date: Sat, 23 Mar 2013 08:57:28 -0700 Message-ID: Subject: Re: hwpmc support for haswell From: hiren panchasara To: Oliver Pinter Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Davide Italiano , freebsd-current , Jim Harris X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 15:57:36 -0000 On Mar 23, 2013 8:28 AM, "Oliver Pinter" wrote: > > On 3/23/13, hiren panchasara wrote: > > On Thu, Jan 31, 2013 at 6:26 PM, hiren panchasara > > wrote: > >> On Thu, Jan 31, 2013 at 5:47 PM, Davide Italiano > >> wrote: > >>> On Fri, Feb 1, 2013 at 2:17 AM, hiren panchasara > >>> wrote: > >>>> Hi, > >>>> > >>>> I've prepared a patch to add core and uncore events support for > >>>> haswell processor. > >>>> I do not have the hardware to test this. It applies cleanly and > >>>> compiles fine though. > >>>> > >>>> http://www.strugglingcoder.info/patches/hwpmc_hw.txt > >>>> > >>>> This is initial version of patch and manpage is still missing. I will > >>>> add it in a few days. > >>>> > >>>> Any help in testing is appreciated. > >>>> > >>>> Thanks, > >>>> Hiren > >>> > >>> It seems Intel won't release this before June (at least to my > >>> knowledge). > >>> I would claim it'll be difficult to real test this before that date > >>> unless someone has prerelease hardware. > >> > >> Indeed. I've posted it here just to let larger audience know and avoid > >> possible duplicate work. > >> > >> We will wait till we get the hardware to test with. > > > > I recently got a ref haswell box to play with. > > > > Initial dmesg looks like this: > > > > CPU: Genuine Intel(R) CPU 0000 @ 2.60GHz (2594.05-MHz K8-class CPU) > > Origin = "GenuineIntel" Id = 0x306c2 Family = 0x6 Model = 0x3c > > Stepping = 2 > > > > Features=0xbfebfbff > > > > Features2=0x7ffafbff,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND> > > AMD Features=0x2c100800 > > AMD Features2=0x21 > > Standard Extended Features=0x2fbb > > TSC: P-state invariant, performance statistics > > real memory = 8589934592 (8192 MB) > > avail memory = 8034803712 (7662 MB) > > Event timer "LAPIC" quality 600 > > ACPI APIC Table: > > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > > FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads > > cpu0 (BSP): APIC ID: 0 > > cpu1 (AP): APIC ID: 1 > > cpu2 (AP): APIC ID: 2 > > cpu3 (AP): APIC ID: 3 > > cpu4 (AP): APIC ID: 4 > > cpu5 (AP): APIC ID: 5 > > cpu6 (AP): APIC ID: 6 > > cpu7 (AP): APIC ID: 7 > > > > Diffs at: > > http://www.strugglingcoder.info/patches/hwpmc_hw.txt > > Tests I've done: > > http://www.strugglingcoder.info/patches/hwpmc_hw_pmccontrol.txt > > http://www.strugglingcoder.info/patches/hwpmc_hw_pmctest.txt > > > > I am following 325462-045US Jan 2013 sw dev manual and below are the > > counters > > which I cannot poke at via pmcstat: > > > > Core: > > "L2_RQSTS.DEMAND_DATA_RD_MISS" > > "L2_RQSTS.DEMAND_DATA_RD_HIT" > > "L2_RQSTS.ALL_DEMAND_DATA_RD" > > "L2_RQSTS.ALL_DEMAND_MISS" > > "L2_RQSTS.ALL_DEMAND_REFERENCES" > > "L2_RQSTS.MISS" > > "CYCLE_ACTIVITY.STALLS_L2_PENDING" > > "PAGE_WALKER_LOADS.DTLB_L1" > > "PAGE_WALKER_LOADS.ITLB_L1" > > "BACLEARS.ANY" > > "L2_LINES_OUT.DEMAND_CLEAN" > > > > Uncore: > > "UNC_CBO_XSNP_RESPONSE.INVAL_M" > > "UNC_CBO_CACHE_LOOKUP.ES" > > > > For all of them, I get error like this: > > > > # pmcstat -p L2_RQSTS.MISS ls > > pmcstat: ERROR: Cannot allocate process-mode pmc with specification > > "L2_RQSTS.MISS": Invalid argument > > > > Box does not panic or anything. > > > > I've tried to double check my changes without success. > > Is it possible that the documentation has some inconsistencies? > > Hi! > > I'm working on SMAP feature, when I have a mostly complete patchset, > can you please test? Sure, Hiren > > > > > Cheers, > > Hiren > > _______________________________________________ > > 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 Mar 23 15:58:30 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D42A7BE0; Sat, 23 Mar 2013 15:58:30 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 195C6A7D; Sat, 23 Mar 2013 15:58:29 +0000 (UTC) Received: by mail-ea0-f173.google.com with SMTP id h14so1749379eak.18 for ; Sat, 23 Mar 2013 08:58:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=vldPR4vWTh3ZHcF0ysoKEfDEP3g/JzcKLYhOYXHXNFg=; b=aeOe1cV1onHeDMXeo+EV0S/hNqs8xeQTUmnREbvYSMCmcuTpB3Cn1bMaYCgQQ3bj0z VDfRJ8sQBs9prvUW13KoxF0iVpJqwTZkdA0svpWvDayRYExA8zIz7FvsixaV4j1VMliZ zE3+0fEi4N/HDntPAfO4BuxmFM/1DE6AAdgo0OPmIgQby4zQy6TBqxdvV/hSop2y3XYk 3PDo6+MraUR3zh6GZfjVIKIVVgq826hDSreN5LtxK34AZiU7xjZJARdlaUeNFNgCDrQd BJf77DWcLEkBxCTSO9ff7of2p75cGZgbZU08I/nSAF9M4X4NadPBmLLpaqwPjunvYRPd JoFg== MIME-Version: 1.0 X-Received: by 10.14.194.198 with SMTP id m46mr15652830een.8.1364054308992; Sat, 23 Mar 2013 08:58:28 -0700 (PDT) Received: by 10.14.133.204 with HTTP; Sat, 23 Mar 2013 08:58:28 -0700 (PDT) Received: by 10.14.133.204 with HTTP; Sat, 23 Mar 2013 08:58:28 -0700 (PDT) In-Reply-To: References: Date: Sat, 23 Mar 2013 08:58:28 -0700 Message-ID: Subject: Re: hwpmc support for haswell From: hiren panchasara To: Jim Harris Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Davide Italiano , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 15:58:30 -0000 On Mar 22, 2013 10:48 PM, "Jim Harris" wrote: > > > > On Friday, March 22, 2013, hiren panchasara wrote: >> >> On Thu, Jan 31, 2013 at 6:26 PM, hiren panchasara >> wrote: >> > On Thu, Jan 31, 2013 at 5:47 PM, Davide Italiano wrote: >> >> On Fri, Feb 1, 2013 at 2:17 AM, hiren panchasara >> >> wrote: >> >>> Hi, >> >>> >> >>> I've prepared a patch to add core and uncore events support for >> >>> haswell processor. >> >>> I do not have the hardware to test this. It applies cleanly and >> >>> compiles fine though. >> >>> >> >>> http://www.strugglingcoder.info/patches/hwpmc_hw.txt >> >>> >> >>> This is initial version of patch and manpage is still missing. I will >> >>> add it in a few days. >> >>> >> >>> Any help in testing is appreciated. >> >>> >> >>> Thanks, >> >>> Hiren >> >> >> >> It seems Intel won't release this before June (at least to my knowledge). >> >> I would claim it'll be difficult to real test this before that date >> >> unless someone has prerelease hardware. >> > >> > Indeed. I've posted it here just to let larger audience know and avoid >> > possible duplicate work. >> > >> > We will wait till we get the hardware to test with. >> >> I recently got a ref haswell box to play with. >> >> Initial dmesg looks like this: >> >> CPU: Genuine Intel(R) CPU 0000 @ 2.60GHz (2594.05-MHz K8-class CPU) >> Origin = "GenuineIntel" Id = 0x306c2 Family = 0x6 Model = 0x3c >> Stepping = 2 >> Features=0xbfebfbff >> Features2=0x7ffafbff,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND> >> AMD Features=0x2c100800 >> AMD Features2=0x21 >> Standard Extended Features=0x2fbb >> TSC: P-state invariant, performance statistics >> real memory = 8589934592 (8192 MB) >> avail memory = 8034803712 (7662 MB) >> Event timer "LAPIC" quality 600 >> ACPI APIC Table: >> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs >> FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP): APIC ID: 1 >> cpu2 (AP): APIC ID: 2 >> cpu3 (AP): APIC ID: 3 >> cpu4 (AP): APIC ID: 4 >> cpu5 (AP): APIC ID: 5 >> cpu6 (AP): APIC ID: 6 >> cpu7 (AP): APIC ID: 7 >> >> Diffs at: >> http://www.strugglingcoder.info/patches/hwpmc_hw.txt >> Tests I've done: >> http://www.strugglingcoder.info/patches/hwpmc_hw_pmccontrol.txt >> http://www.strugglingcoder.info/patches/hwpmc_hw_pmctest.txt >> >> I am following 325462-045US Jan 2013 sw dev manual and below are the counters >> which I cannot poke at via pmcstat: >> >> Core: >> "L2_RQSTS.DEMAND_DATA_RD_MISS" >> "L2_RQSTS.DEMAND_DATA_RD_HIT" >> "L2_RQSTS.ALL_DEMAND_DATA_RD" >> "L2_RQSTS.ALL_DEMAND_MISS" >> "L2_RQSTS.ALL_DEMAND_REFERENCES" >> "L2_RQSTS.MISS" >> "CYCLE_ACTIVITY.STALLS_L2_PENDING" >> "PAGE_WALKER_LOADS.DTLB_L1" >> "PAGE_WALKER_LOADS.ITLB_L1" >> "BACLEARS.ANY" >> "L2_LINES_OUT.DEMAND_CLEAN" >> >> Uncore: >> "UNC_CBO_XSNP_RESPONSE.INVAL_M" >> "UNC_CBO_CACHE_LOOKUP.ES" >> >> For all of them, I get error like this: >> >> # pmcstat -p L2_RQSTS.MISS ls >> pmcstat: ERROR: Cannot allocate process-mode pmc with specification >> "L2_RQSTS.MISS": Invalid argument >> >> Box does not panic or anything. >> >> I've tried to double check my changes without success. >> Is it possible that the documentation has some inconsistencies? >> > > It looks like IAF_F_FM is missing from most (all?) of the new event w/ umask entries you added that are specific to Haswell. Can you try adding these and see if it clears anything up? A cursory look seemed to show most of these failures are on event/umasks that are missing this flag. > Ah, good point. Let me try that and let you know. Thanks, Hiren. > Thanks, > > -Jim From owner-freebsd-current@FreeBSD.ORG Sat Mar 23 19:05:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1346639B6 for ; Sat, 23 Mar 2013 19:05:37 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by mx1.freebsd.org (Postfix) with ESMTP id E7615D1B for ; Sat, 23 Mar 2013 19:05:36 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r2NJ5U8C094872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Mar 2013 12:05:30 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r2NJ5U9A094871; Sat, 23 Mar 2013 12:05:30 -0700 (PDT) (envelope-from jmg) Date: Sat, 23 Mar 2013 12:05:30 -0700 From: John-Mark Gurney To: deeptech71 Subject: Re: compilation error with WITHOUT_ED_CRYPTO Message-ID: <20130323190530.GN88785@funkthat.com> Mail-Followup-To: deeptech71 , freebsd-current@freebsd.org References: <514C70C6.2070603@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <514C70C6.2070603@gmail.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 23 Mar 2013 12:05:30 -0700 (PDT) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 19:05:37 -0000 deeptech71 wrote this message on Fri, Mar 22, 2013 at 15:55 +0100: > The obvious fix: widen the scope of ``#ifdef DES'': Thanks, committed in r248656. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Sat Mar 23 21:52:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4D8CF272 for ; Sat, 23 Mar 2013 21:52:41 +0000 (UTC) (envelope-from gorshkov.pavel@gmail.com) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id CBEA8B75 for ; Sat, 23 Mar 2013 21:52:40 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id er20so9347259lab.18 for ; Sat, 23 Mar 2013 14:52:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :x-operating-system:x-editor:user-agent; bh=fYeU8efKyQDtn3EvdHT0m4ljmlAQRimHWHPBTHKVcKM=; b=zjZmr4FP4BSsMYEyjQTUH10d5I4XiQ7wlfwrWOrgLZXFS3bEgKPErGPe1xpJd/mtwF e6dAcUraMqbeSxSlGQUMRYAKU+YZMz0+o7Y4dcjJr9WJ0rnnyuW3sPnKclK1qje0Pd5x yF4OjtMKlbUfDDnbfLFOp7XF7+/WTDIvTPHHGMbIMy7FDA+rgC7XLbFms4XYE12gaeuU otZjL+odwGd/DGxXmS4np16fPhR2YwtxbcwfMoe67mhaN6BYd0bpFtJvC2N+j8740wDm JbqXyrlcw98JKLTep7bOgYYeHc/mt8RfJRrWOtC8zpCu2XFVKolhB33P4wh3ffZuuVxV N2iQ== X-Received: by 10.112.133.137 with SMTP id pc9mr3360962lbb.74.1364075559822; Sat, 23 Mar 2013 14:52:39 -0700 (PDT) Received: from localhost (ppp91-79-77-110.pppoe.mtu-net.ru. [91.79.77.110]) by mx.google.com with ESMTPS id fz10sm2885942lbb.12.2013.03.23.14.52.38 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 23 Mar 2013 14:52:39 -0700 (PDT) Date: Sun, 24 Mar 2013 01:52:36 +0400 From: Pavel Gorshkov To: Kevin Oberman Subject: Re: Report on issues with fusefs Message-ID: <20130323215236.GA17446@localhost> References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 9.1-RELEASE amd64 X-Editor: Vim-703 http://www.vim.org User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, Marko Zec X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 21:52:41 -0000 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Mar 22, 2013 at 10:16:09PM -0700, Kevin Oberman wrote: > I've now been using fusefs regularly for a few months and I have found > a few issues that i wanted to report. > > Most disturbing is corrupted NTFS systems. On several occasions I have > found an NTFS system could not be written to with either FreeBSD or > Windows. I had to user Windows disk check to repair the file system, > but a few files were lost. this may be an issue with either fusefs or > ntfs-3g. Not sure which, but it is likely tied to the next issue. This patch, also referenced in ports/169165, might help solve at least some of the issues: http://www.mail-archive.com/freebsd-users-jp@jp.freebsd.org/msg04947.html http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/169165 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=patch-fuse-vnops --- fuse_vnops.c.old 2012-02-13 11:59:35.000000000 +0900 +++ fuse_vnops.c 2012-02-13 12:00:15.000000000 +0900 @@ -175,6 +175,11 @@ /* file ops */ static fo_close_t fuse_close_f; +#if __FreeBSD_version > 900040 +static fo_chmod_t fuse_chmod_dummy; +static fo_chown_t fuse_chown_dummy; +#endif + /* vnode ops */ static vop_getattr_t fuse_getattr; static vop_reclaim_t fuse_reclaim; @@ -219,6 +224,10 @@ .fo_kqfilter = NULL, .fo_stat = NULL, .fo_close = fuse_close_f, +#if __FreeBSD_version > 900040 + .fo_chmod = fuse_chmod_dummy, + .fo_chown = fuse_chown_dummy, +#endif .fo_flags = DFLAG_PASSABLE | DFLAG_SEEKABLE }; @@ -3659,3 +3668,17 @@ return (0); } #endif + +#if __FreeBSD_version > 900040 +static int +fuse_chmod_dummy(struct file *fp, mode_t mode, + struct ucred *active_cred, struct thread *td) { + return (ENOSYS); +} + +static int +fuse_chown_dummy(struct file *fp, uid_t uid, gid_t gid, + struct ucred *active_cred, struct thread *td) { + return (ENOSYS); +} +#endif --VbJkn9YxBvnuCH5J--