had ever worked, but if it had, it had bit-rotted so far that it
almost all needed replacing. The new version support both 8-bit sound
on the VIDC20 and 16-bit sound on the ARM7500 and ARM7500FE.
sysbeep() support has been lost, but I'm not sure whether that belongs
here or in audio(4) anyway. Support for 16-bit sound on the VIDC20
isn't present because I don't have the hardware to test it. Donations
welcome!
virtual memory reservation and a private pool of memory pages -- by a scheme
based on memory pools.
This allows better utilization of memory because buffers can now be allocated
with a granularity finer than the system's native page size (useful for
filesystems with e.g. 1k or 2k fragment sizes). It also avoids fragmentation
of virtual to physical memory mappings (due to the former fixed virtual
address reservation) resulting in better utilization of MMU resources on some
platforms. Finally, the scheme is more flexible by allowing run-time decisions
on the amount of memory to be used for buffers.
On the other hand, the effectiveness of the LRU queue for buffer recycling
may be somewhat reduced compared to the traditional method since, due to the
nature of the pool based memory allocation, the actual least recently used
buffer may release its memory to a pool different from the one needed by a
newly allocated buffer. However, this effect will kick in only if the
system is under memory pressure.
exactly twice by me) which causes the code at the top of copyin which
word-aligns the destination pointer to copy more bytes than necessary,
resulting in an alignment fault later on.
The bug is difficult to reproduce, but as far as I can tell it seems
to be as a result of the condition codes being corrupted, possibly
following a page fault caused by the first ldrbt/strb instructions.
The subsequent ldr<cc>bt/str<cc>b instructions then _always_ execute.
I can't think of any obvious reason why this would happen, though.
base offset before using it. This makes it work the same as every other
implementation, and makes wdc at pioc on acorn32 work again. Fix the only
caller I found which depended on the old behaviour.
Gone are the old kern_sysctl(), cpu_sysctl(), hw_sysctl(),
vfs_sysctl(), etc, routines, along with sysctl_int() et al. Now all
nodes are registered with the tree, and nodes can be added (or
removed) easily, and I/O to and from the tree is handled generically.
Since the nodes are registered with the tree, the mapping from name to
number (and back again) can now be discovered, instead of having to be
hard coded. Adding new nodes to the tree is likewise much simpler --
the new infrastructure handles almost all the work for simple types,
and just about anything else can be done with a small helper function.
All existing nodes are where they were before (numerically speaking),
so all existing consumers of sysctl information should notice no
difference.
PS - I'm sorry, but there's a distinct lack of documentation at the
moment. I'm working on sysctl(3/8/9) right now, and I promise to
watch out for buses.
In the interrupt dispatch loop, make sure to handle any pending interrupts
which came in while we were dealing with the first interrupt(s), and which
are enabled at the current spl.
This fixes a problem where the intr_enabled/hw mask is not updated to
allow pending interrupts through until the next splx(). In some case,
interrupts could be delayed until the next clock tick.
which came in while we were dealing with the first interrupt(s), and which
are enabled at the current spl.
This fixes a problem where the intr_enabled/hw mask is not updated to
allow pending interrupts through until the next splx(). In some case,
interrupts could be delayed until the next clock tick.
the functionality of ixp425_bs_tag.
- Add missing stream_{read,write}_1 ops to ixp425_bs_tag.
- Re-work the delay() implementation to use the free-running Time-
Stamp counter. This removes the need to bootstrap TMR0 early on.
the idle loop. They seem to have gone AWOL sometime in the past.
Fixes port-arm/23390.
- While here, tidy up the idle loop.
- Add a cheap DIAGNOSTIC check for run queue sanity.
returns non-zero and we want to shortcut out. This avoids a bogus pagefault
condition being detected in sa_switch().
Many thanks to Christian Limpach for finding this, obviating my band-aid
patch to kern_sa.c (posted on tech-kern).
the call to data_abort_fixup() as the fixup routines also try to
de-reference the fault pc.
- If a fault came from kernel mode, and the fault address looks to be in
the kernel's address space, and pcb_onfault is *set*, check the
instruction which caused the fault. If it's LDR{B,}T or STR{B,}T
then one of the copy in/out routines is trying to read/write a
kernel address with the wrong privilege. If that address is actually
mapped, we could end up in an infinite loop because we failed to
notice that it's really a 'user mode' access. Yay for "crashme".
I suspect this also fixes PR port-arm/23052.
Note: This *could* be fixed by adding sanity checks to copyin et al,
but that would add extra overhead to the non-error path...
- Fix a couple of __predict_false cases.
to determine if a fault is read or write, make sure tf->tf_pc is 32-bit
aligned before dereferencing it.
Otherwise, deliver an illegal instruction signal to the process. We don't
support execution of Thumb code at this time.
copyin() or copyout().
uvm_useracc() tells us whether the mapping permissions allow access to
the desired part of an address space, and many callers assume that
this is the same as knowing whether an attempt to access that part of
the address space will succeed. however, access to user space can
fail for reasons other than insufficient permission, most notably that
paging in any non-resident data can fail due to i/o errors. most of
the callers of uvm_useracc() make the above incorrect assumption. the
rest are all misguided optimizations, which optimize for the case
where an operation will fail. we'd rather optimize for operations
succeeding, in which case we should just attempt the access and handle
failures due to insufficient permissions the same way we handle i/o
errors. since there appear to be no good uses of uvm_useracc(), we'll
just remove it.