Date: Fri, 13 Sep 1996 12:55:44 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com> To: smp@csn.net (Steve Passe) Cc: freebsd-smp@freebsd.org, peter@spinner.dialix.com Subject: Re: writing new apic_startup Message-ID: <199609131955.MAA01166@GndRsh.aac.dev.com> In-Reply-To: <199609131900.NAA26181@clem.systemsix.com> from Steve Passe at "Sep 13, 96 01:00:16 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> Hi,
>
> I'm starting to re-code apic_startup() armed with the knowqledge we've gained
> the last several days. One of the things I want to do is use real timing
> loops.
>
> Is there a kernel facility available at the point apic_startup()
> is called (middle of init386() in machdep.c) that will give me
> blocking delays in the order of 10 usec to 10 msec?
>
> Failing that does anyone see any reason why I shouldn't use the APIC timer?
> Is it currently used on the boot CPU for anything else?
The very reason Intel added a timer to the APIC was because of the need to
do these timings during SMP initilization. Please do write your code to use
the APIC timer.
Please do write a set of acquire_apic_timer(), release_apic_timer() lock
functions as well as a set_apic_timer() and read_apic_timer() so that we
can insure exclusive use of the timer:
if (acquire_apic_timer())
panic("APIC timer in use when attempting to aquire");
/* Do what you need to do with timing */
if (release_apic_timer())
panic("APIC timer was already released");
The panics could be initially imbeded in the acquire/release, but that
would not allow for more generized use of the apic timer for other
purposes that can deal with the fact that it is already in use (ie, block
the process/thread).
--
Rod Grimes rgrimes@gndrsh.aac.dev.com
Accurate Automation Company Reliable computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609131955.MAA01166>