an X seesion. Really stupid error of me, and I've been looking at
this code SO many times. Thanks to Kazutaka YOKOTA for seeing this..
Submitted by: Kazutaka YOKOTA
the page to be unbusy, and it caused some algorithmic problems
as a result. There were some other problems with it also, so
this is a general cleanup of the code.
Submitted by: Douglas Crosher <dtc@scrooge.ee.swin.oz.au> and myself.
one in draw_mouse causes spontanious hangs on my p5-100 when I
move the mouse excessively. Forgot that on the last commit, so
using the mouse or destructive cursor would produce large amounts
of flicker..
now dead sys/pci/if_pdq.c which has been committed about by the same
time i made my tests with Matt's code.
LINT should compile now again.
Well, that's a clear case where ``CVS writer locks'' would certainly
(not) have helped. :-]
to -current.
Thanks goes to Ulrike Nitzsche <ulrike@ifw-dresden.de> for giving me
a chance to test this. Only the PCI driver is tested though.
One final patch will follow in a separate commit. This is so that
everything up to here can be dragged into 2.2, if we decide so.
Reviewed by: joerg
Submitted by: Matt Thomas <matt@3am-software.com>
importing it onto a vendor branch first, in the hope that this will
make future maintenance easier.
The conflicts are (hopefully) unimportant. More commits that actually
bring this into the source tree will follow.
Submitted by: Matt Thomas (thomas@lkg.dec.com)
cur_console is NULL when copy_font() is first called from scinit(). This
is apparently harmless when scinit() is called early from sccninit() -
page 0 is apparently mapped r/w then, and 0->status contains suitable
garbage. However, when there is a serial console, scinit() is first
called from scattach() when the page tables are completely initialized,
so the NULL pointer causes a panic.
Submitted by: bruce
called early for console i/o. The timer is usually in BIOS mode
if it isn't explicitly initialized. Then it counts twice as fast
and has a max count of 65535 instead of 11932. The larger count
tended to cause infinite loops for delays of > 20 us. Such delays
are rare. For syscons and kbdio, DELAY() is only called early
enough to matter for ddb input after booting with -d, and the delay
is too small to matter (and too small to be correct) except in the
PC98 case. For pcvt, DELAY() is not used for small delays (pcvt
uses its own broken routine instead of the standard broken one),
but some versions call DELAY() with a large arg when they unnecessarily
initialize the keyboard for doing console output. The problem is
more serious for pcvt because there is always some early console
output.
Guard against the i8254 timer being partially or incorrectly
initialized. This would have prevented the endless loop.
Should be in 2.2.
on it.
makesyscalls.sh:
This parsed $Id$. Fixed(?) to parse $FreeBSD$. The output is wrong when
the id is not expanded in the source file.
syscalls.master:
Fixed declaration of sigsuspend(). There are still some bogons and
spam involving sigset_t.
Use `struct foo *' instead of the equivalent `foo_t *' for some nfs and
lfs syscalls so that <sys/sysproto.h> doesn't depend on <sys/mount.h>.
variable `kern.maxvnodes' which gives much better control over vnode
allocation than EXTRAVNODES (except in -current between 1995/10/28 and
1996/11/12, kern.maxvnodes was read-only and thus useless).
I have no idea if this works since I don't have one of the cards to test.
I also don't know what the LINT and GENERIC entries should look like,
so I just made up some values for now and left them commented out.
Someone who knows the factory settings for a Pro/10, please contact me!
Submitted-By: Javier Martín Rueda <jmrueda@diatel.upm.es>
when allocating memory for network buffers at interrupt time. This is due
to inadequate checking for the new mcl_map. Fixed by merging mb_map and
mcl_map into a single mb_map.
Reviewed by: wollman
rev.1.10 two years ago. Children continued to run at splhigh()
after returning from vm_fork(). This mainly affected kernel
processes and init. For ordinary processes, interrupts are normally
unmasked a few instructions later after fork() returns (it may be
important for syscall() not to reschedule the child processes).
Kernel processes had workarounds for the problem. Init manages to
start because some routines "know" that it is safe to go to sleep
despite their caller starting them at a high ipl. Then its ipl
gets fixed on its first normal return from a syscall.
