This code was eliminated when the PEND_INTS algorithm was added. But it was
discovered that PEND_INTS only worsen latency for FAST_INTR() routines,
which can't be marked pending.
Noticed & debugged by: dave adkins <adkin003@gold.tc.umn.edu>
Initially functionality is confined to 32-bit BIOS functions, however
it is envisioned that BIOS support may be enlisted for other
activities in the future.
Mask the read value from the count register in order to return zero correctly
after TC, as per intel datasheet : "If it is not autoinitialised, this
register will have a count of FFFFH after TC"
comments. Remove reduntant extra addition that was unncessary, and
unneeded mask (asuming inb works correctly).
Submitted by: Stephen McKay <syssgm@dtir.qld.gov.au>
handlers don't skew the results of isa_dmastatus. The function can be
safely called with interrupts disabled.
Submitted by: Stephen McKay <syssgm@dtir.qld.gov.au>
- removed TEST_ALTTIMER.
- removed APIC_PIN0_TIMER.
- removed TIMER_ALL.
mplock.s:
- minor update of try_mplock for new algorithm where a CPU uses try_mplock
instead of get_mplock in the ISRs.
- removed TEST_ALTTIMER.
- removed APIC_PIN0_TIMER.
- removed TIMER_ALL.
apic_vector.s:
- new algorithm where a CPU uses try_mplock instead of get_mplock:
if successful continue as before.
if fail set ipending bit, mask INT (to avoid recursion), cleanup & iret.
This allows the CPU to return to successful work, while the ISR will be run
by the CPU holding the lock as part of the doreti dance.
Macros to convert the Lite2 lock manager primitives to the names used
in the kernel proper. This allows us to hide them from the lock
manager till they can be turned on.
smp.h:
declarations for the new simplelock functions.
- s_lock_init()
- s_lock()
- s_lock_try()
- s_unlock()
Created lock for IO APIC and apic_imen (SMP version of imen)
- imen_lock
Code to use imen_lock for access from apic_ipl.s and apic_vector.s.
Moved this code *outside* of mp_lock.
It seems to work!!!
and he says he's happy to see forward movement in aligning our defaults
with a 16 bit world, the 8 bit folk already being veterans by this
point who know how to use userconfig.
In any case, perhaps Warner will soon come to save us all with his Dynamic
Probing(tm) feature and this will all become totally moot in any case,
so it's probably not worth arguing about either way.
1) Make sure that the region mapped by a 4MB page is
properly aligned.
2) Don't turn on the PG_G flag in locore for SMP. I plan
to do that later in startup anyway.
3) Make sure the 2nd processor has PSE enabled, so that 4MB
pages don't hose it.
We don't use PG_G yet on SMP -- there is work to be done to make that
work correctly. It isn't that important anyway...
of the kernel, and also most of the dynamic parts of the kernel. Additionally,
4MB pages will be allocated for display buffers as appropriate (only.)
The 4MB support for SMP isn't complete, but doesn't interfere with operation
either.
