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. WarnerReceived on Tue Mar 07 2017 - 18:43:44 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:10 UTC