it could happen that we unblanked while vesaproc was
currently blanking (when manually blanking using vgactl
for example). the wakeup of the unblank is lost.
disabled LAPIC entries overwrote the bootstrap processor
apic causing the machine panic with: "no bootstrap processor".
(problem with lenovo X230)
just ignore entries that are disabled or collide with
entries already found. (should not happen)
the issues with the previous tsc change where not related to the tsc
but where problems with timesync using an old frequency file. a
patch to fix timesync was commited, so so we reintroduce the *notsc=
again.
the frequency tolerance used by timesync was from a 10th to 10 times
the frequency of the system clock! switching a system from tsc to pic
timer changes the system clock frequency from 300MHz to arround 1.8Ghz
on a x200s laptop resulting in time running way too slow or way too fast.
so we change timesync to only accept frequencies from half to double the
system clock which still seems huge, but at least catches the case above
resulting in timesync ignoring the old frequency file.
aux/wpa needs to reset its reply counter on deassociation to
properly restart key negotiation. we signal this with a zero
length read on the connections filtering for eapol protocol.
allow the driver to associate the node with a new aid right after
we receive the association response, not just when we transmit
a packet which usualy does not happen as eapol is initiated by
the access point so there are no transmit calls. we just call
transmit from the wifiproc with a nil block to introduce the node.
the splhi() and apictimerlock in the Mach isnt neccesary, as
portclock always holds the ilock of the per mach timer queue
when calling timerset().
as fastticks() and the portclock timers are all handled on a
per processor basis, i think it should be theoretically possible
for the lapics to run at different frequencies. so we measure
the lapic frequency for each individual lapic and keep them in
a per processor Apictimer structure instead of assuming them
to be the same.
loading the divider before programming one shot mode *sometimes*
gives the wrong frequency. (X200s got 192Mhz vs. 266Mhz, after
5 boot attempts)
also reload the divider after programming periodic mode. (from
http://wiki.osdev.org/APIC_timer)