Date: Mon, 2 Apr 2001 14:15:55 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: "Bruce R. Montague" <brucem@mail.cruzio.com> Cc: freebsd-hardware@FreeBSD.ORG, freebsd-small@FreeBSD.ORG Subject: Re: movsl generic_bcopy hang using NSC GX Geode CPU Message-ID: <Pine.BSF.4.21.0104021344040.21022-100000@besplex.bde.org> In-Reply-To: <200104012212.f31MC7u00385@mail.cruzio.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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-hardware" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0104021344040.21022-100000>