From owner-freebsd-current@freebsd.org Tue Mar 7 19:34:31 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0BA08D01BF5 for ; Tue, 7 Mar 2017 19:34:31 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D6B5C166A; Tue, 7 Mar 2017 19:34:30 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id v27JaNVQ005674; Tue, 7 Mar 2017 11:36:29 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: Lev Serebryakov , Kevin Oberman Cc: FreeBSD CURRENT , In-Reply-To: References: <0b702c55-aa92-193f-77e1-c5c8aa1a668f@FreeBSD.org> <12f82f8b-658e-23e0-c017-c917dd8cd638@FreeBSD.org>, From: "Chris H" Subject: Re: Strange kernel build breakage (after r314283?) Date: Tue, 07 Mar 2017 11:36:29 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: 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, 07 Mar 2017 19:34:31 -0000 On Tue, 7 Mar 2017 09:13:58 -0800 Kevin Oberman wrote > On Mon, Mar 6, 2017 at 9:18 AM, Lev Serebryakov wrote: > > > On 06.03.2017 20:10, Lev Serebryakov wrote: > > > > > I've got this error when tried to update my -CURRENT VM to r314772: > > > > > > /data/src/sys/cam/cam_xpt.c:84:1: error: static_assert failed > > > "XPT_PRINT_LEN is too large" > > > _Static_assert(XPT_PRINT_LEN <= XPT_PRINT_MAXLEN, "XPT_PRINT_LEN is too > > > large"); > > > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > I didn't define any XPT_xxxx macro by hands, but I have > > > > > > options PRINTF_BUFR_SIZE=1024 > > > > > > in my kernel config. > > Yep, removing this option helps, but it is surprising and not obvious > > at all! > > > > -- > > // Lev Serebryakov > > > > If my memory is good (and it may not be), this option was recommended to > prevent garbled syslog and console entries, but that was back in v8 days, > long, long ago. I have not had his problem for a long time and I think that > the option is no longer required and even they, 1024 was a LOT bigger than > was recommended at the time. 128 or 256 seems tike the value recommended. Relax. You're memory is still in good order. :-) It was in fact the reason. I had to add the then suggested amount: PRINTF_BUFR_SIZE=128 to my KERNCONF even into early 9. But haven't required it since ~mid-9. OTOH I'm now seeing something similar on CURRENT. Only somewhat in reverse. The last message I receive on the console following halt(8) is the message telling me the NIC has been brought down. It then sits there until I hit the enter key to reboot(8). But that's another topic for another thread. :-) --Chris > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkoberman@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683