| Age | Commit message (Collapse) | Author |
|---|
|
reference for making transferral of meta-information possible from
readdisklabel to bounds_check_with_label. The first (and maybe only)
thing that will use this is the multi-disklabel-format code on the
alpha where the labelsector is passed via cpu_disklabel so the label
write-protection can work correctly no matter what label was found.
Also use a new macro DKBAD to get at the dkbad field of the cpu_disklabel
implementations that contain it. This too is for multi-disklabel
architectures where the "bad" field can be inside a union. Use this
macro as a means for a driver to check if an architecture supports
dkbad constructs.
Remove proto of bounds_check_with_label from all MD disklabel.h as it
is in sys/disklabel.h.
I have not been able to test the changes everywhere, if I break anything
I apologize, and promise to fix it as soon as I become aware of it.
|
|
|
|
|
|
|
|
GENERIC currently compiles and runs; some devices (isp) are not complete and
not yet enabled.
|
|
|
|
|
|
|
|
Add options NETATALK to your config to try it out.
|
|
|
|
supposedly adds additional instruction scheduling for better performance,
where -mv8 seems to only "allow" the multiply and div instructions. This
is what I got from the gcc docs anyway.. Reading the RTL for sparc seems
to agree with this hypothesis, and the man pages..
|
|
failures in innocent programs. Typically something like a make build
of libc or something executing a large number of shell commands would
fail, dumping core in sh or random faults in as or cc*.
According to Chris Torek, the problem is that he make the destination
pages for zero and copy be non-cached to prevent wiping otherwise
relevant stuff from the cache.
On systems with a L2 cache like the SS10 modules with cache, setting
the pages as non-cacheable inhibits updating the chache, and also
disable PA chache snooping, doesn't do anything about possible dirty
lines in the L2 cache, which may eventually get flushed and corrupt the
nice new page.
It's not clear that he's got the failure mode 100% correct, but making
the pages cacheable does seem to avoid the symptoms and testing the
e-cache flush hypothesis is difficult.
Aaron Brown proposed a fix that was conditional on mmutype, and netbsd-current
has it conditional on a cpu.quirk, at the moment this is unconditional, the
performance hit is arguable...
|
|
make time_t int not int32_t.
|
|
lint-free code when these differ in name accross platforms.
Fundamnetal type has not changed (was int on alpha and long on others).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
usage in new ip_* code, since fixed. Added usage notes to prevent future
confusion in this regard.
|
|
of the other special virtual addresses and also provide visibility
needed for bsd_fd.s to reference it...
|
|
really doesn't make a lot of sense if you're actually going to use these
as some recent changes to netinet/* want to do. (x) or (u_int*_t) (x)
would be the ticket, and since the rest of the ports settle for (x)...
Note that powerpc has this same problem and needs to be fixed!
|
|
and uses our fdformat interface (same code base as NetBSD, with differently
named ioctls, but we have always preserved the names of the original code's
authors, unlike NetBSD...)
|
|
|
|
|
|
|
|
supported on that machine, it just turns off...)
|
|
|
|
|
|
russ@madhaus.utcs.utoronto.ca (Russell P. Sutherland).
Kernel compile errors when AUDIO_C_HANDLER is defined, due to a
syntax error: *(foo->bar)++ is an odd bit of coding.
|
|
and non-functional.
|
|
netbsd PR. Also change the panic text to something more descriptive so that
pv_unlink0 is no more and make use of typedef vm_offset_type is consistently
used for "va" and friends thoughout pmap.c instead of mixed int, u_int and
vm_offset_type...
|
|
|
|
|
|
sparc can use libkvm vs. libkvm.old and update sparc pmap.c and machdep.c to make dumps compatible with the new libkvm's notions.
|
|
|
|
requirements, since vm & pm aren't much different in the install environment
|
|
|
|
intended
|
|
and root isn't really going to be mounted on the floppy, i.e. ramdisk...
|
|
|
|
|
|
|
|
|
