From owner-svn-src-all@freebsd.org Thu Mar 24 16:15:56 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 0AC10ADCD8A for ; Thu, 24 Mar 2016 16:15:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 C19031BBF for ; Thu, 24 Mar 2016 16:15:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x233.google.com with SMTP id 124so88969989iov.3 for ; Thu, 24 Mar 2016 09:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=l4OxAXzrL2ogzMuVZyIIObqphoEdIrPQ4X/hIiJC48M=; b=QzJMmHc9xaY0Ca4RAzfPdqsCamyLKkZydXP0dXB7I2nXmaMiteutdBJxu3cQPTDL4b zKvXYmTNFkLF3JeIZekpAQAbm2uvlguUiUHQfhUMz5CCufeQ8m6qyWEKQG/B6Tb1kHVi 66Epf5CWfV9LRzlHT/s2QA5Z3fbYKToaktVi1nBVVzu5usRgoMYMTy66F35hc8fEtoRR bUScxRl1pRPVLhEWA+Y9jNzMztab8w1BKLat+xWbRmJSvfASLofi66nPvYk/OUBsSiyr Tk/0rd5GWjiZ019sA2VsFQzEYr/5IOITkphmKsYTaCwtRWvowvhiGWPOCZcj8D/guJkP QoAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=l4OxAXzrL2ogzMuVZyIIObqphoEdIrPQ4X/hIiJC48M=; b=UKtGbukiAQ/QDwpBQJ1eKztgBXBM/25cvcM418VAcL1jugnkKDROLZBoPlZWU4O9RJ 7EMTEDT0piHm1NjRGXjvReWtjL/Is1qIrf9Spw8SZs9A5XWnD0xrSP+yjCQ1ACN00ceG zwuw+gt0q8rhDcholOBDbbfCcibRxY0x1W7vXCtNcrPSRerMOakqEG6lGedPD8BYt2Fu aY3QSHDI0nkUXLvoUMPWbAo3iDZnYls4P55TYJp+mdqFaxaduml5+/B3I5w41oM/G9tV MxEhI8DFUN4hf9EhPRiFNE7NyeqHFRyQPvndMTdHcZrxpqmbjAsCzujRj12gtkOR7KFt K7eQ== X-Gm-Message-State: AD7BkJK77e3/4/WNRo51flQavf6PFsOoaFDEtr6r0SsFhpwyO77ZqpIYcOIL4oAWd2bn51QsQ1ew2zMDv5Z2fQ== MIME-Version: 1.0 X-Received: by 10.107.14.209 with SMTP id 200mr9488694ioo.73.1458836154785; Thu, 24 Mar 2016 09:15:54 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.36.65.230 with HTTP; Thu, 24 Mar 2016 09:15:54 -0700 (PDT) X-Originating-IP: [69.53.245.20] In-Reply-To: <1458834410.1091.54.camel@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> Date: Thu, 24 Mar 2016 10:15:54 -0600 X-Google-Sender-Auth: 0ruP_cq6E2T_3qy2ZKi03-rPdbQ Message-ID: Subject: Re: svn commit: r297190 - head/sys/kern From: Warner Losh To: Ian Lepore Cc: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= , Alexander Motin , =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= , src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 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 16:15:56 -0000 On Thu, Mar 24, 2016 at 9:46 AM, Ian Lepore wrote: > On Thu, 2016-03-24 at 16:01 +0100, Edward Tomasz Napiera=C5=82a wrote: > > On 0324T1609, Alexander Motin wrote: > > > On 24.03.16 15:42, Edward Tomasz Napiera=C5=82a wrote: > > > > On 0324T1032, Jean-S=C3=A9bastien P=C3=A9dron 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 > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > =3D=3D=3D=3D=3D=3D > > > > > > --- 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 =3D cp; > > > > > > end =3D 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.... Warner