just limited to the DEVICE_POLLING case. This removes the FXP_RFA_RNRMARK
hack, and replaces it with a softc flag that is used to record when
the handling of a no-resource condition was deferred due to running
out of DEVICE_POLLING cycles. This was tested on -stable, but the
code is essentially the same as in -current. It should only affect
the case where DEVICE_POLLING is defined.
The details of the mechanism behind the crashes are still uncertain
but the most likely cause seems to be some kind of hardware confusion
when the no-resource recovery code is accidentally invoked while
the receiver is still active. This could have happened if the
hardware left the 0x4000 bit of the RFA status word set. The comments
in the commit log for revision 1.142 stating that the driver could
clash with the hardware writing to this status word were not correct.
Tested by: Guy Helmer <ghelmer@palisadesys.com>
to use the same start condition as the i386 version. However, since
Alpha's only have one fake "slice" from sysinstall's perspective we don't
need to use a loop, but can just write out the BSD label in the first
fake "slice".
remove global variable in_vm86call, set vm86 calling flag in PCB flags.
2.Fix vm86 BIOS calling preempted problem by changing vm86_lock mutex type
from MTX_DEF to MTX_SPIN. vm86pcb is not remembered in thread struct,
when the thread calling vm86 BIOS is preempted by interrupt thread,
and later switching back to the thread would cause incorrect context be
loaded into CPU registers, this leads to kernel crash.
argument is an expression you can end up casting part of it to void *.
This resulted in bogus warnings about pointer arith using void *'s for
the ep(4) driver.
from being MI in any fashion. It currently "assumes" that it can get
a kernel virtual address for a phyiscal address by adding KERNBASE to the
physical address. It also tries to read values out of a the PC BIOS on
all archs. It also uses "manual" inb() and outb()'s to talk to the mcclock
device which just happens to be at that location on both i386 and alpha.
This driver should likely be i386-only.
not look like the prerequisites to fill it in properly will be in the tree
for the upcoming release, but it's mostly done, so there is no need for these
to stay around to remind us.
to run patches to make(1) by. Hopefully this will make it easier to get bugs
fixed in make(1), as well as get review by people with experience working on,
in, around, etc., make(1).
Currently it points to two people who have demonstrated maintainership (ru@
and myself) and one person interested in helping (alane@). That list is
subject to expansion and contraction.
