From owner-svn-src-head@freebsd.org Tue Sep 3 14:06:05 2019 Return-Path: Delivered-To: svn-src-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 849D0DC197; Tue, 3 Sep 2019 14:06:00 +0000 (UTC) (envelope-from yuripv@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46N7yv5ggLz4P4r; Tue, 3 Sep 2019 14:05:59 +0000 (UTC) (envelope-from yuripv@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1452) id B2CCB19F52; Tue, 3 Sep 2019 14:05:53 +0000 (UTC) X-Original-To: yuripv@localmail.freebsd.org Delivered-To: yuripv@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 7300B1C4EA; Sun, 31 Mar 2019 14:51:40 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 26A3F85005; Sun, 31 Mar 2019 14:51:40 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 538) id 0F7A31C4E8; Sun, 31 Mar 2019 14:51:40 +0000 (UTC) Delivered-To: src-committers@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 375B41C4E6 for ; Sun, 31 Mar 2019 14:51:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 89E8284FF7; Sun, 31 Mar 2019 14:51:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x2VEpO3a000811 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 31 Mar 2019 17:51:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x2VEpO3a000811 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x2VEpMJn000810; Sun, 31 Mar 2019 17:51:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f From: Konstantin Belousov To: Bruce Evans Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r345696 - head/lib/libvgl Message-ID: <20190331145122.GL1923@kib.kiev.ua> References: <201903291557.x2TFv9AW097226@repo.freebsd.org> <20190329182100.GZ1923@kib.kiev.ua> <20190330142319.I1011@besplex.bde.org> <20190330094558.GA1923@kib.kiev.ua> <20190331214235.K961@besplex.bde.org> <20190331121015.GK1923@kib.kiev.ua> <20190331231926.M1259@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190331231926.M1259@besplex.bde.org> User-Agent: Mutt/1.11.4 (2019-03-13) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home Precedence: bulk X-Loop: FreeBSD.org Sender: owner-src-committers@freebsd.org X-Rspamd-Queue-Id: 26A3F85005 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.96 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.96)[-0.961,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Status: O X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 03 Sep 2019 14:06:06 -0000 X-Original-Date: Sun, 31 Mar 2019 17:51:22 +0300 X-List-Received-Date: Tue, 03 Sep 2019 14:06:06 -0000 On Mon, Apr 01, 2019 at 12:04:45AM +1100, Bruce Evans wrote: > Serial consoles are not always available. > > Better debuggers switch the screen mode as necessary. > > I recently noticed another mode switching problem. On i386, cycling > through about 50 modes to test them all takes a small fraction of a > second for each mode switch (done directly in syscons or by a vm86 > BIOS call) even when the monitor takes too long to resync (the monitor > resyncs are coalesced, so 50 resyncs take about 5 seconds instead of > 250). But on amd64, mode switches to VESA mode and back take about > 20 seconds. They are not coalesced, and most of the system is stopped > waiting for them (at least remote network access is stopped). amd64 > can't use vm86, so it emulates BIOS calls. Why does the emulation stop > the rest of the system and take so long? How many CPUs do you have ? x86bios.c x86bios_call() does spinlock_enter() around emulator calls. This disables interrupts. If you have only one CPU, the consequences are obvious. If you have more than one, then perhaps next IPI targeted to this CPU blocks the originator, if IPI requires ack, which typically true for most common TLB shutdown IPIs. Then both this CPU and originator block any other CPU trying to send an IPI. For this reason I have to come through several hoops to not disable interrupts for duration of EFI runtime calls, otherwise spinlocks die due to 'spin lock held too long' on other CPUs.