From owner-freebsd-hackers  Sat Dec 24 04:06:22 1994
Return-Path: hackers-owner
Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id EAA27047 for hackers-outgoing; Sat, 24 Dec 1994 04:06:22 -0800
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id MAA27036 for <freebsd-hackers@freebsd.org>; Sat, 24 Dec 1994 12:06:07 GMT
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id XAA03357; Sat, 24 Dec 1994 23:02:36 +1100
Date: Sat, 24 Dec 1994 23:02:36 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199412241202.XAA03357@godzilla.zeta.org.au>
To: bde@zeta.org.au, hosokawa@mt.cs.keio.ac.jp
Subject: Re: DX4/100 BUG
Cc: freebsd-hackers@freebsd.org
Sender: hackers-owner@freebsd.org
Precedence: bulk

>  #ifdef APM
>          call    _apm_cpu_idle
>          call    _apm_cpu_busy
>  #else
>          sti
>          hlt                                     /* wait for interrupt */
>  #endif
>          jmp     idle_loop

>   If the HLT is removed from here, almost all idle loop is executed
>   without accepting interrupts.  The system will be down.  What is
>   the most appropriate solution?  I think these CMPL and JNE pairs
>   are atomic operations.

Only one instruction after the `sti' is required for excepting interrupts.

>(2) How Linux probes this DX4 HLT bug?

hlt_works_ok defaults to 1.  It is cleared if to boot loader passes the
string "no-hlt" on the command line.  FreeBSD could use a new boot flag.

HLT is probed by attempting to execute it (if (hlt_works_ok)) so that the
system hangs early (after printing a message without a newline) if HLT
doesn't work.  HLT is easier to test than WAIT because execution resumes
at the next instruction after an interrupt terminates the HLT.

Bruce