From owner-freebsd-hackers@freebsd.org Sat Apr 21 13:03:03 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8681CFA4043 for ; Sat, 21 Apr 2018 13:03:03 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: from mail-ot0-x242.google.com (mail-ot0-x242.google.com [IPv6:2607:f8b0:4003:c0f::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1A747727A5; Sat, 21 Apr 2018 13:03:03 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-ot0-x242.google.com with SMTP id q10-v6so7780109oth.9; Sat, 21 Apr 2018 06:03:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HD51phsHu4tOe0xTwak0SgtMLdMdOjn8B1WCeq3mahE=; b=RRPz2Tevgmj0M7yH8v4K6I1/tn80umM9KVFz1d9G6aj1uLk9cCxnFBOdSG5uYzotfH 1AZpY4D0dB3Cfu1n0p7X1Lz+gQghOAbf+aYf/MehdmukEHNcWt2z6NxS3JL1G+z8sAvf owdVKvFSHa34RIP+2phHoRfmTd7ChzTn6av3WI5qG2Npb9tXhhJQFNyC2lRnQgXuSymi gDKlUQiO2HPASrFmIKqaaRaqPvTJR7eL2uRZowlqIIn5bGpbh5PVYgMUSF5SNVKGGSd6 7EHb3fF8sSNy8DY7y5vRgI0Mxp/a8CAYM92r64U0GREQviDm0FG/WO4aBHbMAiVmHQzJ 4jvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HD51phsHu4tOe0xTwak0SgtMLdMdOjn8B1WCeq3mahE=; b=fWvQ+CJlY9mlV2JEzZAYuXNBxP9gt0iigH7Z4HHohq2d9HRNlJdUoWzoz16Mz8utfk itglIWUAIsr0ygxB7+ruv92LsSWqqfAiilL7QKBtNMxIZ8ABdhdYYGUpHWJExYmJx//V 8aVckTLxtPER3dy+eTKzyGHKZOU6ybA2PQBlcl8mufD7g6TASl3g7WvDDzOFaZxuZeir Oi409wK25E3tN21omAfhHBhWkHhatj3IfePPfuic5RbwYDpGO5AxBaEZMgDQeEUxoUUb n7pjOkUoitOk4qyUYhrwVUhmf2J37M8E5yze+qBa67/eFxIzGGDHBoXDIW2XtSkICvra ZOBQ== X-Gm-Message-State: ALQs6tCe8mkB2JmuscwDUqj8Tql9lfpuXM8pf/dBwaM/GUTxCXGM1rmF 4K1ZAkwSVyuvmTm+4TSR+Yf2b5hxzLq4SJwWpUI= X-Google-Smtp-Source: AB8JxZovFyGbYzdurgb72q5RYmRWGqA40cMlGwnWCrtz7qapuksT+DKdfsgEG0MnAvTP4Mq/Pi6YNx7rdbBaZ6nKcTs= X-Received: by 2002:a9d:fad:: with SMTP id d42-v6mr4339181otd.358.1524315782315; Sat, 21 Apr 2018 06:03:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.60.135 with HTTP; Sat, 21 Apr 2018 06:03:01 -0700 (PDT) In-Reply-To: <20180421123544.56d7e690@ernst.home> References: <01000162df15f856-1e5d2641-2a72-4250-8d8e-adcd47bc5db4-000000@email.amazonses.com> <20180419204405.GE6887@kib.kiev.ua> <20180419214550.GF6887@kib.kiev.ua> <01000162e58a466e-98f0305b-1723-467a-bc49-342c3fa9fc5b-000000@email.amazonses.com> <20180421092049.GM6887@kib.kiev.ua> <20180421123544.56d7e690@ernst.home> From: Stefan Blachmann Date: Sat, 21 Apr 2018 15:03:01 +0200 Message-ID: Subject: Re: RFC: Hiding per-CPU kernel output behind bootverbose To: gljennjohn@gmail.com Cc: Konstantin Belousov , "freebsd-hackers@freebsd.org" , Colin Percival , Conrad Meyer Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 13:03:03 -0000 There are not many places that call the cpu initializing routine. Thus it should be easy to add a pointer to the output function to be used. What about solving the problem using simple code like I did this in sysutils/cpupdate? (https://github.com/kernschmelze/cpupdate) [BEGIN PSEUDOCODE SNIPPET] print_cpu_stats( stringbuffer *info, int from, int to) { print( "Core %d to %d: %s", from, to, info); } initialize_all_cpus() { int startcore = 0; int ncore = 1; stringbuffer *ncoreinfo, *startcoreinfo = initializeCPU(0, functionPointerPrintToStringBuffer); for ( ; ncore < numCores ; ++ncore) { ncoreinfo = initialize_one_CPU(ncore, functionPointerPrintToStringBuffer); if ( ) { // core #ncore is different than core #startcore..#(ncore-1). // Print core info for that block print_cpu_stats( startcoreinfo, startcore, ncore - 1); startcore = ncore; startcoreinfo = ncoreinfo; } } // make sure also the last block of identical cores are shown if (startcore < ncore) print_cpu_stats( startcoreinfo, startcore, ncore - 1); } [END PSEUDOCODE SNIPPET] Only such a small change would be necessary in the bootup code and in cpuctl.c to avoid massive spamming when updating microcode. But I have given up attempting to contribute to FreeBSD, because of the gross lack of interest on core developers' side in things important to people running FreeBSD on bare metal. For example, it is just amazing to see how all reports about massive flaws in kernel microcode detection/updating and all offered patches are being blatantly ignored for many years. See for example: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192487 Sad, very sad! On 4/21/18, Gary Jennejohn wrote: > On Sat, 21 Apr 2018 12:20:49 +0300 > Konstantin Belousov wrote: > >> On Sat, Apr 21, 2018 at 12:11:07AM +0000, Colin Percival wrote: >> > On 04/19/18 14:45, Konstantin Belousov wrote: >> > > On Thu, Apr 19, 2018 at 02:37:56PM -0700, Conrad Meyer wrote: >> > >> On Thu, Apr 19, 2018 at 1:44 PM, Konstantin Belousov wrote: >> > >>> The 'CPU XX Launched' messages are very useful for initial >> > >>> diagnostic >> > >>> of the SMP startup failures. You need to enable bootverbose to see >> > >>> the >> > >>> hang details, but for initial hint they are required. Unfortunately, >> > >>> AP >> > >>> startup hangs occur too often to pretend that this can be delegated >> > >>> to >> > >>> very specific circumstances. >> > >> >> > >> Really? I don't know that I've ever seen an AP startup hang. How >> > >> often do they occur? >> > > >> > > It was epidemic with Sandy Bridge, mostly correlated to specific BIOS >> > > supplier and its interaction with the x2APIC enablement, see >> > > madt.c:170 >> > > and below. >> > > >> > > There were several recent reports of the issue with Broadwell Xeon >> > > machines, no additional data or resolution. >> > > >> > > There are sporadic reports of the problem, where I do not see >> > > a clear commonality. >> > >> > Would it be sufficient for debugging purposes if I change the >> > !bootverbose >> > case from printing many lines of >> > >> > SMP: AP CPU #N Launched! >> > >> > to instead have a single >> > >> > SMP: Launching AP CPUs: 86 73 111 21 8 77 100 28 57 42 10 60 87 88 41 >> > 113 36 >> > 19 72 46 92 52 24 81 90 3 107 96 9 14 80 118 29 121 62 74 56 55 1 12 63 >> > 18 67 >> > 13 45 102 33 94 69 68 93 83 48 31 30 32 51 89 71 78 64 84 123 61 40 47 >> > 37 22 >> > 54 101 38 4 97 44 17 109 104 5 85 43 2 99 39 65 95 53 58 66 91 125 23 >> > 115 16 >> > 35 79 112 103 82 7 75 11 6 98 15 126 127 20 70 34 105 27 50 116 120 49 >> > 25 108 >> > 106 122 117 114 26 110 59 76 124 119 >> > >> > ? (With each AP printing its number as it reaches the appropriate >> > point?) >> > >> > This yields almost the same gain as silencing the launch messages >> > completely, >> > while still allowing you to see each CPU announcing itself. >> I am fine with the behaviour, but I am not sure how would you implement >> this. printf(9) buffers the output, you need to flush it somehow. >> > > And printf(9) calls vprintf(9) which in turn calls _vprintf which > will allocate a buffer on the stack (bad idea) if the option > PRINTF_BUFR_SIZE is set in the kernel config file. So it seems > that output may even be double buffered. > > -- > Gary Jennejohn > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >