Date: Sat, 26 Mar 2016 04:08:43 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= <trasz@freebsd.org> Cc: Bruce Evans <brde@optusnet.com.au>, Warner Losh <imp@bsdimp.com>, Ian Lepore <ian@freebsd.org>, Alexander Motin <mavbsd@gmail.com>, =?iso-8859-1?Q?Jean-S=E9bastien_P=E9dron?= <jean-sebastien.pedron@dumbbell.fr>, src-committers <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r297190 - head/sys/kern Message-ID: <20160326031834.O911@besplex.bde.org> In-Reply-To: <20160325144445.GA1549@brick.home> References: <56F29654.8030806@dumbbell.fr> <20160323174537.GA1826@brick.home> <56F3B441.6030602@dumbbell.fr> <20160324134222.GA1442@brick.home> <56F3F52F.9040705@gmail.com> <20160324150151.GA1277@brick.home> <1458834410.1091.54.camel@freebsd.org> <CANCZdfr9b=2DnVxgpJN=3q634tgMDX3mO8B127or682-5Z35bw@mail.gmail.com> <20160324173359.GA1238@brick.home> <20160325071420.K2059@besplex.bde.org> <20160325144445.GA1549@brick.home>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 25 Mar 2016, Edward Tomasz [utf-8] Napiera=C5~Ba wrote: > On 0325T0809, Bruce Evans wrote: >> On Thu, 24 Mar 2016, Edward Tomasz [utf-8] Napiera=C5~Ba wrote: >> >>> On 0324T1015, Warner Losh wrote: >>>> On Thu, Mar 24, 2016 at 9:46 AM, Ian Lepore <ian@freebsd.org> wrote: >>>> >>>>> On Thu, 2016-03-24 at 16:01 +0100, Edward Tomasz Napiera=C5=82a wrote= : >>>>>> [...] >>>>>> I've just noticed another curious thing, though: when you press >>>>>> ScrLk, >>>>>> the screen gets immediately refreshed; also, pressing arrows works >>>>>> just >>>>>> the way it should. In other words, the refresh is broken except for >>>>>> the ScrlLk mode, where it works as it should. >>>>> >>>>> Since cngets() is used only by the mountroot prompt and the geli pw >>>>> entry, pausing/yielding within the input loop seems like a good idea. >>>>> It would allow for things like plugging in a usb device and having i= t >>>>> actually appear without having to enter a '.' several times. >>>>> >>>>> It would be nice if the pause were done with pause_sbt() and a shorte= r >>>>> timeout, maybe a millisecond or even 100uS. Otherwise things like >>>>> pasting text at that prompt in a serial console is likely to drop >>>>> chars. Serial consoles should work already due to their use of grab/ungrab, and this use being easier to get right for serial consoles. I still see problems with sio. It doesn't use grab/ungrab yet, although grab/ungrab were designed by me in ~1988 for my serial drivers older than sio. Note that cngetc() was broken by multiple console support in ~2000. Before that, cngetc() waited with device interrupts disabled. This prevented the interrupt handler eating the interrupts. Now it polls and is still broken since its polling loop is not wrapped by grab/ungrab. cngets() was broken before multiple consoles, but was fairly usable. You just had to type reasonably slowly so that the characters arrive in the low-level polling loop while device interrupts are disabled. >>>>> Hmmm... speaking of the geli pw prompt... what's the locking situatio= n >>>>> there? Will there be any problems calling pause() from that context? >>>> >>>> PVM isn't an ideal priority to wait at. PWAIT would be better. However= , >>>> if the only reason to call pause is run the scheduler after each chara= cter, >>>> perhaps a better solution would be to call kern_yield() instead? We co= uld >>>> do that instead of cpu_waitspin() inside of cngetc, but that would bre= ak >>>> the debugger's use of it.... >> >> Console drivers can't block or depend on timeouts. Perhaps cngets() can= , >> because it is only called in simple contexts, but the simple contexts >> make it especially easy for it to work using the same synchronous i/o th= at >> is needed in more complicated contexts. > > Note that this particular problem doesn't seem to be caused by the consol= e > driver as such. One of the things I've tried was to add a callout that > prints out something each second, and then enter an infinite loop. The > assumption is, the loop in proc0 should get preempted by the callout. > For some reason this doesn't happen. But it is a bug for (low level) console drivers to ever wait. They should assert that they don't. >>> I think we should first try to figure out why this doesn't work in the = first >>> place. >>> >>> Basically, even though the interrupts are running, scheduler seems to b= e ok, >>> and the thread that's calling this has a lower priority than the callou= ts >>> thread, it can't be preempted. This doesn't seem to be caused by vt(4)= ; >>> with syscons the callouts don't get called either (it just doesn't brea= k >>> the echo in this case). To demonstrate the problem you can add add >>> a callout that calls printf each second and then does an infinite loop. >> >> cngets() is even correctly wrapped by cngrab()/cnungrab(). This is supp= osed >> to put the console driver in a special synchronous mode for the duration= of >> the grabbing. (Console drivers still need to be reentrant, so that they >> can do i/o when the grabbed section is reentered for ddb or another >> non-maskable trap.) syscons and vt have similar too-simple grab handler= s >> which start with a screen switch in the !cold case. This should refresh >> the screen and/or switch it to special low-level console screen(s). > > So basically, what you're suggesting is to make cngrab() set a flag that > switches vt, and its video drivers, into a mode that doesn't use any kind > of callouts, right? That seems like a proper solution, but still doesn't > explain the root of the problem here. Yes. They already increment an xx_grabbed counter, but only use it to do nothing for nested grabs. (Doing nothing is too simple.) >> Screen switching in ddb is noticeably more broken for vt than for syscon= s. >> Indeed, it just doesn't work in vt (except for the initial switch to vty= 0). >> This might be related. > > Yeah; I remember some strange problems with keyboard state when > entering/leaving ddb. Both syscons and vt hang fairly quickly in -current for the ddb command 's/p,1000'. vt just hangs sooner. I think I fixed this in an old version of syscons, but I only tested the fix on systems with not as many CPUs as the one that shows the most problems. Printing after every instruction in ddb is a good way to stress its i/o, except the i/o is very slow so it takes too long to step through a few trillion instructions needed for a good test. A few trillion instructions might be enough to reach most parts of the kernel. The 'n' command is also good for stressing all paths, but not so good for seeing the instruction that deadlocks, and the repeat count doesn't work for it. In -current with both syscons and vt, 's/p,1000' usually hangs on a harmless-looking instruction nar the ithread loop. But last time I tried it hung on a known deadlock in scrn_update() (a lock cmpxchgl for the bad locking there). The trace showed interesting interleaving of scrn_update() with handlevents(), presumably running on different CPUs. An old bug in single stepping in ddb is that it loses control on every step. SMP enlarges this bug. The trace flag apparently got set on different CPUs, though I thought I fixed that. This shows that every debugger entry that prints anything should print some pcpu info. Bruce From owner-svn-src-head@freebsd.org Fri Mar 25 19:12:15 2016 Return-Path: <owner-svn-src-head@freebsd.org> Delivered-To: svn-src-head@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 0A1A1ADD580; Fri, 25 Mar 2016 19:12:15 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D08E61DD3; Fri, 25 Mar 2016 19:12:14 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id u2PJCExS062347; Fri, 25 Mar 2016 19:12:14 GMT (envelope-from bdrewery@FreeBSD.org) Received: (from bdrewery@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id u2PJCEKA062346; Fri, 25 Mar 2016 19:12:14 GMT (envelope-from bdrewery@FreeBSD.org) Message-Id: <201603251912.u2PJCEKA062346@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: bdrewery set sender to bdrewery@FreeBSD.org using -f From: Bryan Drewery <bdrewery@FreeBSD.org> Date: Fri, 25 Mar 2016 19:12:14 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r297269 - head X-SVN-Group: head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: SVN commit messages for the src tree for head/-current <svn-src-head.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/svn-src-head>, <mailto:svn-src-head-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/svn-src-head/>; List-Post: <mailto:svn-src-head@freebsd.org> List-Help: <mailto:svn-src-head-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/svn-src-head>, <mailto:svn-src-head-request@freebsd.org?subject=subscribe> X-List-Received-Date: Fri, 25 Mar 2016 19:12:15 -0000 Author: bdrewery Date: Fri Mar 25 19:12:13 2016 New Revision: 297269 URL: https://svnweb.freebsd.org/changeset/base/297269 Log: LIBRARIES_ONLY should only be defined during install32. r245561 added it to prevent extra files from being installed during the install32 phase (to prevent duplicates in the meta log with -DNO_ROOT). The flag should not be passed during build32 though since it may prevent staging of includes during the 'make includes' phase on library directories. Sponsored by: EMC / Isilon Storage Division Modified: head/Makefile.libcompat Modified: head/Makefile.libcompat ============================================================================== --- head/Makefile.libcompat Fri Mar 25 16:01:40 2016 (r297268) +++ head/Makefile.libcompat Fri Mar 25 19:12:13 2016 (r297269) @@ -79,7 +79,6 @@ LIBCOMPATWMAKEENV+= MAKEOBJDIRPREFIX=${L LIBCOMPATWMAKEFLAGS+= CC="${XCC} ${LIBCOMPATCFLAGS}" \ CXX="${XCXX} ${LIBCOMPATCFLAGS}" \ DESTDIR=${LIBCOMPATTMP} \ - -DLIBRARIES_ONLY \ -DNO_CPU_CFLAGS \ MK_CTF=no \ -DNO_LINT \ @@ -87,7 +86,8 @@ LIBCOMPATWMAKEFLAGS+= CC="${XCC} ${LIBCO LIBCOMPATWMAKE+= ${LIBCOMPATWMAKEENV} ${MAKE} ${LIBCOMPATWMAKEFLAGS} \ MK_MAN=no MK_HTML=no LIBCOMPATIMAKE+= ${LIBCOMPATWMAKE:NINSTALL=*:NDESTDIR=*:N_LDSCRIPTROOT=*} \ - MK_TOOLCHAIN=no ${IMAKE_INSTALL} + MK_TOOLCHAIN=no ${IMAKE_INSTALL} \ + -DLIBRARIES_ONLY .if ${XCC:N${CCACHE_BIN}:M/*} LIBCOMPATCFLAGS+= --sysroot=${WORLDTMP}
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160326031834.O911>