Re: Strange kernel build breakage (after r314283?)

On Tue, Mar 7, 2017 at 12:36 PM, Chris H <bsd-lists_at_bsdforge.com> wrote:
> On Tue, 7 Mar 2017 09:13:58 -0800 Kevin Oberman <rkoberman_at_gmail.com> wrote
>
>> On Mon, Mar 6, 2017 at 9:18 AM, Lev Serebryakov <lev_at_freebsd.org> 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. :-)

Hmmm, looks like I broke this... Meaning the static config. I'll look
at it more closely.

Warner