From owner-freebsd-small Sun Apr 1 21:17:26 2001 Delivered-To: freebsd-small@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 8032837B71A; Sun, 1 Apr 2001 21:17:19 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id OAA00088; Mon, 2 Apr 2001 14:17:08 +1000 Date: Mon, 2 Apr 2001 14:15:55 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: "Bruce R. Montague" Cc: freebsd-hardware@FreeBSD.ORG, freebsd-small@FreeBSD.ORG Subject: Re: movsl generic_bcopy hang using NSC GX Geode CPU In-Reply-To: <200104012212.f31MC7u00385@mail.cruzio.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 1 Apr 2001, Bruce R. Montague wrote: > System hangs on "rep movsl" in "generic_bcopy()" in > "i386/i386/support.s" using NSC Geode (586) CPU. > ... > Problem: Pressing backspace (or delete, or cntrl-H) > on the console with even number of text characters > on the display line hangs the CPU. System/network > otherwise runs fine. Backspace when using telnet > into the system always works fine. Problem has > never been reproduced under any other circumstances > except console backspace with even number of cmd-line > (or display-line) chars. > > The machine hangs on the "rep movsl" instruction in > "generic_bcopy" (called via "bcopy_toio()" in > syscons code "sc_vtb_copy()/scvtb.c" to scroll screen > image). The code-block _will_ work if the equivalent > "rep movsb" code is used instead of a movsl, _OR_ > the unmodified "rep movsl" can be made to work if > an immediately prior byte-wise scan has been made > of the movsl source/dest buffers (just a for-loop > *p++ before the "bcopy_toio()". > > The code path is routinely used w/o problems; when > the "backspace-on-odd" problem occurs the input > arguments appear `normal' although I have not > attempted to check related buffer alloc/memory > mapping... both the "from" and "to" addresses are > often word (not longword) aligned, apparently without > ill effect (the CR0 Alignment Check bit is set on > in "locore.s" at system init and stays on). Alignment Check is only active at non-kernel privilege, and then only when enabled in eflags. > ... > This all suggests a mid--rep-instruction fault-failure > scenario...? But... any additional advice, hints, > ... I think it is more likely to be an alignment and/or access problem, caused by a combination of hardware and software bugs. Syscons shouldn't use generic_bcopy to access hardware. Note that it already knows not to use bcopy for hardware accesses. It abuses the implementation detail `generic_bcopy' on i386's and uses the unusual bcopy_{from,to}_io functions on other machines. It should use the bus space functions on all machines, but then it would have the problem of determining the ones with the correct width and/or alignment and/or highest efficiency (at least on alphas, the bcopy_{from,to}_io functions give the largest chance of working and the lowest efficiency by using a width of 1). However, frame buffers are supposed to look like ordinary memory. However2, video device memory has caused problems before: - syscons used to use plain bcopy in a few places. This caused problems when bcopy is i586_bcopy (which does 8-byte wide accesses). - pcvt still says that some chipsets have problems with even 16-bit accesses and uses bcopyb (byte copy) to access font memory. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message