From owner-svn-src-all@freebsd.org Thu Mar 24 17:34:05 2016 Return-Path: Delivered-To: svn-src-all@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 31851ADCF78; Thu, 24 Mar 2016 17:34:05 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 BA1F51621; Thu, 24 Mar 2016 17:34:04 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-wm0-x22a.google.com with SMTP id l68so76486072wml.1; Thu, 24 Mar 2016 10:34:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=APgaStEf8Xi/R1c5bMdA501hLR901axiIFnqn5xUa5w=; b=RmvxKXjWhWsPjtlQdqhG2MDlSXMZS37PGIXvzViQRN0UDZ+sKvRFmo+JhJ9Sn8aQWc tLvvf+bfpeF2YrFEJ1wxlcaMIHhavwh3/vItQ2VsaSnxfu4WPvEWXaG08ZYHCbyO0ke8 /XXusi+HjvlZ2XbXLrPStFHRkgqTLFgWBidGOLVTHD5Evbxo/HIEf3OiVromOYr5ahlJ Wx6MeYNnki6dVTqaLx8BQVdANyubnPueQ5ADLR3uHkGc9fMPbwwnndBjPQLmn0HYBKp/ ADGDlxbzc7IUlW0wuupcGIGoDIZCwwckpLWsgP9jJXK899kHEcVu93QjZzrBi6Xx7rmB g/QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=APgaStEf8Xi/R1c5bMdA501hLR901axiIFnqn5xUa5w=; b=PS1XeBKINmAyM2bJkfgj3SmanB/poJ5cfFwXUnagQqI6oAyvthKsXLxUVe54y88afq y4hmot4QbPXU2KpyDjx4/wBS1+j59kd+3F4FbADZjZoJvDwXNgjbFqUouqMVdR1VFREt IEUneah2udgMy7vkf/Z6OKWyp0EF85W1kJUTyfIpLQtQvsG5NM/prPuM+Ld1Rnwdy7sy OdyU3yXcqVGaQZf/7bZ9EZOogXHUNUDw+HbthNxFsTuoDvXJprsfn00CYUayqEpKD8za lSIGafSzMneYQjVhCFZc/izqiPO1+plnHAdtC2L2zHim6KfcCkBjiweQnEf5MsI6CqNb PUTQ== X-Gm-Message-State: AD7BkJLr3q5eNypZgVxK7koY4h8SNgeUcYCnfkcFA8wzqzyA10i9QIk9mpy/33xKU0aBHg== X-Received: by 10.194.174.231 with SMTP id bv7mr11178887wjc.17.1458840842986; Thu, 24 Mar 2016 10:34:02 -0700 (PDT) Received: from brick.home (etj156.neoplus.adsl.tpnet.pl. [83.20.155.156]) by smtp.gmail.com with ESMTPSA id j18sm28119917wmd.2.2016.03.24.10.34.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Mar 2016 10:34:02 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Thu, 24 Mar 2016 18:33:59 +0100 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Warner Losh Cc: Ian Lepore , Alexander Motin , =?iso-8859-1?Q?Jean-S=E9bastien_P=E9dron?= , src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Subject: Re: svn commit: r297190 - head/sys/kern Message-ID: <20160324173359.GA1238@brick.home> Mail-Followup-To: Warner Losh , Ian Lepore , Alexander Motin , =?iso-8859-1?Q?Jean-S=E9bastien_P=E9dron?= , src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" References: <201603221346.u2MDk1XH029623@repo.freebsd.org> <1458662141.1091.16.camel@freebsd.org> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2016 17:34:05 -0000 On 0324T1015, Warner Losh wrote: > On Thu, Mar 24, 2016 at 9:46 AM, Ian Lepore wrote: > > > On Thu, 2016-03-24 at 16:01 +0100, Edward Tomasz Napierała wrote: > > > On 0324T1609, Alexander Motin wrote: > > > > On 24.03.16 15:42, Edward Tomasz Napierała wrote: > > > > > On 0324T1032, Jean-Sébastien Pédron wrote: > > > > > > On 23/03/2016 18:45, Edward Tomasz Napierala wrote: > > > > > > > > So maybe callouts are disabled in this situation. If there > > > > > > > > is a way to > > > > > > > > detect that, then vt(4) can go back to a "synchronous mode" > > > > > > > > where it > > > > > > > > refreshes the screen after each typed character, like it > > > > > > > > does when ddb > > > > > > > > is active. > > > > > > > > > > > > > > Looks like that's the case: for some reason the callouts > > > > > > > don't work. > > > > > > > This trivial hack is a (mostly) working workaround: > > > > > > > > > > > > > > Index: svn/head/sys/kern/kern_cons.c > > > > > > > ============================================================= > > > > > > > ====== > > > > > > > --- svn/head/sys/kern/kern_cons.c (revision 297210) > > > > > > > +++ svn/head/sys/kern/kern_cons.c (working copy) > > > > > > > @@ -430,6 +430,7 @@ cngets(char *cp, size_t size, int > > > > > > > visible) > > > > > > > lp = cp; > > > > > > > end = cp + size - 1; > > > > > > > for (;;) { > > > > > > > + pause("meh", 1); > > > > > > > > > > > > Could you please explain how this works to me? Does calling > > > > > > pause() here > > > > > > give a chance to interrupt handlers or other threads of > > > > > > running? > > > > > > > > > > It looks like it allows the callout to run. I've did an > > > > > experiment > > > > > and added a simple callout that printed something each second; > > > > > during > > > > > the root mount prompt it doesn't get run unless you type '.', > > > > > which > > > > > calls pause(9). > > > > > > > > Kernel threads run with absolute priorities, so if somehow this > > > > threads > > > > happen to have higher or equal priority then callout thread, or the > > > > kernel is built without PREEMPTION, then the last may never be > > > > executed > > > > until this thread get to sleep or at least call sched_yield(). > > > > > > The callout's td_priority seems to be 40; the thread running the > > > prompt > > > is 84, so it's lower. > > > > > > 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 it > > actually appear without having to enter a '.' several times. > > > > It would be nice if the pause were done with pause_sbt() and a shorter > > timeout, maybe a millisecond or even 100uS. Otherwise things like > > pasting text at that prompt in a serial console is likely to drop > > chars. > > > > Hmmm... speaking of the geli pw prompt... what's the locking situation > > 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 character, > perhaps a better solution would be to call kern_yield() instead? We could > do that instead of cpu_waitspin() inside of cngetc, but that would break > the debugger's use of it.... 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 be ok, and the thread that's calling this has a lower priority than the callouts 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 break 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.