The #ifdef IPXIP in netipx/ipx_if.h is OK (used from ipx_usrreq.c and
ifconfig.c only).
I also fixed a typo IPXTUNNEL -> IPTUNNEL (and #ifdef'ed out the code
inside, as it never could have compiled - doh.)
(mutant) Crystal CSS4236 chip on the Intel PR440FX SMP motherboard.
XXX this uses some rather ugly PnP bootstrap code that is *NOT* compatable
with 'controller pnp0' or *ANY* other PnP devices. If you use some other
PnP devices, enabling css0 will burn your house down. :-] The
"simplified" PnP init sequence directly blats your config(8) settings onto
the chip. I'm pretty sure 'css0' will conflict with 'mss0', this whole
area desperately needs a cleanup.
I have been using the following with some success on the PR440FX:
controller snd0
device css0 at isa? port 0x534 irq 5 drq 1 flags 0x08 vector adintr
device opl0 at isa? port 0x388
device mpu0 at isa? port 0x330 irq 10 vector mpuintr
mode. Currently, the only supported controller is the Cirrus Logic
PD6832, but others can be supported with docs on them.
Submitted by: Ted Faber <faber@ISI.EDU>
Here are the remanding changes required to support the Ensoniq
Soundscape using FreeBSD 3.0-current.
Notes:
1) ad1848_init already has code to detect if DMA_DUPLEX should
be set so it is not necessary (and is in fact a mistake) to
hard code setting it. Not all soundcards (i.e. the current
sscape driver) are capable of using DMA_DUPLEX.
2) The other changes are hopefully self explanatory. Feel free
to let me know if you need additional information.
Submitted by: john@feith.com (John Wehle)
Obtained from: Whistle Communications tree
Add an option to the way UFS works dependent on the SUID bit of directories
This changes makes things a whole lot simpler on systems running as
fileservers for PCs and MACS. to enable the new code you must
1/ enable option SUIDDIR on the kernel.
2/ mount the filesystem with option suiddir.
hopefully this makes it difficult enough for people to
do this accidentally.
see the new chmod(2) man page for detailed info.
hope i've found out all files that actually depend on this dependancy.
IMHO, it's not very good practice to change the size of internal
structs depending on kernel options.
follow.
* Rename/reorder all of the pccard structures, change many of the member
names to be descriptive, and follow more closely other 'bus' drivers
naming schemes.
* Rename a bunch of parameter and local variable names to be more
consistant in the code.
* Renamed the PCCARD 'crd' device to be the 'card' device
* KNF and make the code consistant where it was obvious.
* ifdef'd out some unused code
variables were lost when we removed -W, and 23 new ones including at
least one serious one have crept in for LINT.
Restored -Winline to CFLAGS. This gives only 3 old warnings and 1 new
for LINT.
i was at it, do no longer insist on `PCVT_FREEBSD' being declared in
the config file, but default it to a reasonable value.
More cleanup to follow, but this part is safe for RELENG_2_2, too.
1. Add new file "sys/kern/vfs_default.c" where default actions for
VOPs go. Implement proper defaults for ABORTOP, BWRITE, LEASE,
POLL, REVOKE and STRATEGY. Various stuff spread over the entire
tree belongs here.
2. Change VOP_BLKATOFF to a normal function in cd9660.
3. Kill VOP_BLKATOFF, VOP_TRUNCATE, VOP_VFREE, VOP_VALLOC. These
are private interface functions between UFS and the underlying
storage manager layer (FFS/LFS/MFS/EXT2FS). The functions now
live in struct ufsmount instead.
4. Remove a kludge of VOP_ functions in all filesystems, that did
nothing but obscure the simplicity and break the expandability.
If a filesystem doesn't implement VOP_FOO, it shouldn't have an
entry for it in its vnops table. The system will try to DTRT
if it is not implemented. There are still some cruft left, but
the bulk of it is done.
5. Fix another VCALL in vfs_cache.c (thanks Bruce!)
- CPU_CYRIX_NO_LOCK enables weak locking. If this option is not set and
FAILESAFE is defined, NO_LOCK bit of CCR1 is cleared.
- CPU_WT_ALLOC enables write-through allocation.
of multiple PCI IDE controllers(Dyson), and some updates and cleanups from
John Hood, who originally made our IDE DMA stuff work :-).
I have run tests with 7 IDE drives connected to my system, all in DMA
mode, with no errors. Modulo any bugs, this stuff makes IDE look
really good (within it's limitations.)
Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
internal modems. Currently detects a USR modem, and a couple Supra
modems... vendor id's for sio capabile cards welcomed...
document new option EXTRA_SIO that will increase sio's internal data
structures to support X more serial ports... these are used by the
PnP part of sio for attaching... If you don't have it specified, it
will default to 2... This is defaulted to 0 if you don't have PnP
compiled into your kernel...
also document that if you set the PnP flags (pnp x flags y) to 0x1 that
the modem will be refused to be recognized by the sio driver... this
is for people that want the traditional isa driver to probe and attach
the modem... (for keeping legacy sio numbering)
Hide the bogus FDC ``chip type'' display behind a (mostly) undocumented
option, since people started to trust the bogus claim. Once we're going
to handle 2.88 MB controllers, we have to redo the chip detection, by
now just leave it hidden.
files.i386.
We aren't sure if this new code and the old sound code will co-exist in a
kernel, so the device pcm0 line is left commented out in LINT.
Submitted-by: Luigi Rizzo
you don't want this (and the documentation explains why), but if you
use ipfw as an as-needed casual filter as needed which normally runs as
'allow all' then having the kernel and /sbin/ipfw get out of sync is a
*MAJOR* pain in the behind.
PR: 4141
Submitted by: Heikki Suonsivu <hsu@mail.clinet.fi>
* lots of fixes to error handling-- mostly works now
* improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive
still untested
* generally improve DMA config in many ways-- mostly cleanup
* clean up boot-time messages
* rewrite PRD generation algorithm
* first wd timeout is now longer, to handle drive spinup
Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
- We now have enough per-cpu idle context, the real idle loop has been
revived (cpu's halt now with nothing to do).
- Some preliminary support for running some operations outside the
global lock (eg: zeroing "free but not yet zeroed pages") is present
but appears to cause problems. Off by default.
- the smp_active sysctl now behaves differently. It's merely a 'true/false'
option. Setting smp_active to zero causes the AP's to halt in the idle
loop and stop scheduling processes.
- bootstrap is a lot safer. Instead of sharing a statically compiled in
stack a number of times (which has caused lots of problems) and then
abandoning it, we use the idle context to boot the AP's directly. This
should help >2 cpu support since the bootlock stuff was in doubt.
- print physical apic id in traps.. helps identify private pages getting
out of sync. (You don't want to know how much hair I tore out with this!)
More cleanup to follow, this is more of a checkpoint than a
'finished' thing.
2.3.0 -> 2.3.1 changes, but I seem to recall that there are certain
"issues" with 2.3.1 (I'm not sure if it's just pppd or the whole lot, I
am not quite that far). The present pppd seems to work with it just fine
for the time being.
Among the changes are that zlib (aka LZ77 aka deflate aka gzip) compression
is implemented as well as the original compress(1) LZW style.
I changed a few bits here and there, mainly renaming wd82371.c
to ide_pci.c now that it's supposed to handle different chipsets.
It runs on my P6 natoma board with two Maxtor drives, and also
on a Fujitsu machine I have at work with an Opti chipset and
a Quantum drive.
Submitted by:cgull@smoke.marlboro.vt.us <John Hood>
Original readme:
*** WARNING ***
This code has so far been tested on exactly one motherboard with two
identical drives known for their good DMA support.
This code, in the right circumstances, could corrupt data subtly,
silently, and invisibly, in much the same way that older PCI IDE
controllers do. It's ALPHA-quality code; there's one or two major
gaps in my understanding of PCI IDE still. Don't use this code on any
system with data that you care about; it's only good for hack boxes.
Expect that any data may be silently and randomly corrupted at any
moment. It's a disk driver. It has bugs. Disk drivers with bugs
munch data. It's a fact of life.
I also *STRONGLY* recommend getting a copy of your chipset's manual
and the ATA-2 or ATA-3 spec and making sure that timing modes on your
disk drives and IDE controller are being setup correctly by the BIOS--
because the driver makes only the lamest of attempts to do this just
now.
*** END WARNING ***
that said, i happen to think the code is working pretty well...
WHAT IT DOES:
this code adds support to the wd driver for bus mastering PCI IDE
controllers that follow the SFF-8038 standard. (all the bus mastering
PCI IDE controllers i've seen so far do follow this standard.) it
should provide busmastering on nearly any current P5 or P6 chipset,
specifically including any Intel chipset using one of the PIIX south
bridges-- this includes the '430FX, '430VX, '430HX, '430TX, '440LX,
and (i think) the Orion '450GX chipsets. specific support is also
included for the VIA Apollo VP-1 chipset, as it appears in the
relabeled "HXPro" incarnation seen on cheap US$70 taiwanese
motherboards (that's what's in my development machine). it works out
of the box on controllers that do DMA mode2; if my understanding is
correct, it'll probably work on Ultra-DMA33 controllers as well.
it'll probably work on busmastering IDE controllers in PCI slots, too,
but this is an area i am less sure about.
it cuts CPU usage considerably and improves drive performance
slightly. usable numbers are difficult to come by with existing
benchmark tools, but experimentation on my K5-P90 system, with VIA
VP-1 chipset and Quantum Fireball 1080 drives, shows that disk i/o on
raw partitions imposes perhaps 5% cpu load. cpu load during
filesystem i/o drops a lot, from near 100% to anywhere between 30% and
70%. (the improvement may not be as large on an Intel chipset; from
what i can tell, the VIA VP-1 may not be very efficient with PCI I/O.)
disk performance improves by 5% or 10% with these drives.
real, visible, end-user performance improvement on a single user
machine is about nil. :) a kernel compile was sped up by a whole three
seconds. it *does* feel a bit better-behaved when the system is
swapping heavily, but a better disk driver is not the fix for *that*
problem.
THE CODE:
this code is a patch to wd.c and wd82371.c, and associated header
files. it should be considered alpha code; more work needs to be
done.
wd.c has fairly clean patches to add calls to busmaster code, as
implemented in wd82371.c and potentially elsewhere (one could imagine,
say, a Mac having a different DMA controller).
wd82371.c has been considerably reworked: the wddma interface that it
presents has been changed (expect more changes), many bugs have been
fixed, a new internal interface has been added for supporting
different chipsets, and the PCI probe has been considerably extended.
the interface between wd82371.c and wd.c is still fairly clean, but
i'm not sure it's in the right place. there's a mess of issues around
ATA/ATAPI that need to be sorted out, including ATAPI support, CD-ROM
support, tape support, LS-120/Zip support, SFF-8038i DMA, UltraDMA,
PCI IDE controllers, bus probes, buggy controllers, controller timing
setup, drive timing setup, world peace and kitchen sinks. whatever
happens with all this and however it gets partitioned, it is fairly
clear that wd.c needs some significant rework-- probably a complete
rewrite.
timing setup on disk controllers is something i've entirely punted on.
on my development machine, it appears that the BIOS does at least some
of the necessary timing setup. i chose to restrict operation to
drives that are already configured for Mode4 PIO and Mode2 multiword
DMA, since the timing is essentially the same and many if not most
chipsets use the same control registers for DMA and PIO timing.
does anybody *know* whether BIOSes are required to do timing setup for
DMA modes on drives under their care?
error recovery is probably weak. early on in development, i was
getting drive errors induced by bugs in the driver; i used these to
flush out the worst of the bugs in the driver's error handling, but
problems may remain. i haven't got a drive with bad sectors i can
watch the driver flail on.
complaints about how wd82371.c has been reindented will be ignored
until the FreeBSD project has a real style policy, there is a
mechanism for individual authors to match it (indent flags or an emacs
c-mode or whatever), and it is enforced. if i'm going to use a source
style i don't like, it would help if i could figure out what it *is*
(style(9) is about half of a policy), and a way to reasonably
duplicate it. i ended up wasting a while trying to figure out what
the right thing to do was before deciding reformatting the whole thing
was the worst possible thing to do, except for all the other
possibilities.
i have maintained wd.c's indentation; that was not too hard,
fortunately.
TO INSTALL:
my dev box is freebsd 2.2.2 release. fortunately, wd.c is a living
fossil, and has diverged very little recently. included in this
tarball is a patch file, 'otherdiffs', for all files except wd82371.c,
my edited wd82371.c, a patch file, 'wd82371.c-diff-exact', against the
2.2.2 dist of 82371.c, and another patch file,
'wd82371.c-diff-whitespace', generated with diff -b (ignore
whitespace). most of you not using 2.2.2 will probably have to use
this last patchfile with 'patch --ignore-whitespace'. apply from the
kernel source tree root. as far as i can tell, this should apply
cleanly on anything from -current back to 2.2.2 and probably back to
2.2.0. you, the kernel hacker, can figure out what to do from here.
if you need more specific directions, you probably should not be
experimenting with this code yet.
to enable DMA support, set flag 0x2000 for that drive in your config
file or in userconfig, as you would the 32-bit-PIO flag. the driver
will then turn on DMA support if your drive and controller pass its
tests. it's a bit picky, probably. on discovering DMA mode failures
or disk errors or transfers that the DMA controller can't deal with,
the driver will fall back to PIO, so it is wise to setup the flags as
if PIO were still important.
'controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff
vector wdintr' should work with nearly any PCI IDE controller.
i would *strongly* suggest booting single-user at first, and thrashing
the drive a bit while it's still mounted read-only. this should be
fairly safe, even if the driver goes completely out to lunch. it
might save you a reinstall.
one way to tell whether the driver is really using DMA is to check the
interrupt count during disk i/o with vmstat; DMA mode will add an
extremely low number of interrupts, as compared to even multi-sector
PIO.
boot -v will give you a copious register dump of timing-related info
on Intel and VIAtech chipsets, as well as PIO/DMA mode information on
all hard drives. refer to your ATA and chipset documentation to
interpret these.
WHAT I'D LIKE FROM YOU and THINGS TO TEST:
reports. success reports, failure reports, any kind of reports. :)
send them to cgull+ide@smoke.marlboro.vt.us.
i'd also like to see the kernel messages from various BIOSes (boot -v;
dmesg), along with info on the motherboard and BIOS on that machine.
i'm especially interested in reports on how this code works on the
various Intel chipsets, and whether the register dump works
correctly. i'm also interested in hearing about other chipsets.
i'm especially interested in hearing success/failure reports for PCI
IDE controllers on cards, such as CMD's or Promise's new busmastering
IDE controllers.
UltraDMA-33 reports.
interoperation with ATAPI peripherals-- FreeBSD doesn't work with my
old Hitachi IDE CDROM, so i can't tell if I've broken anything. :)
i'd especially like to hear how the drive copes in DMA operation on
drives with bad sectors. i haven't been able to find any such yet.
success/failure reports on older IDE drives with early support for DMA
modes-- those introduced between 1.5 and 3 years ago, typically
ranging from perhaps 400MB to 1.6GB.
failure reports on operation with more than one drive would be
appreciated. the driver was developed with two drives on one
controller, the worst-case situation, and has been tested with one
drive on each controller, but you never know...
any reports of messages from the driver during normal operation,
especially "reverting to PIO mode", or "dmaverify odd vaddr or length"
(the DMA controller is strongly halfword oriented, and i'm curious to
know if any FreeBSD usage actually needs misaligned transfers).
performance reports. beware that bonnie's CPU usage reporting is
useless for IDE drives; the best test i've found has been to run a
program that runs a spin loop at an idle priority and reports how many
iterations it manages, and even that sometimes produces numbers i
don't believe. performance reports of multi-drive operation are
especially interesting; my system cannot sustain full throughput on
two drives on separate controllers, but that may just be a lame
motherboard.
THINGS I'M STILL MISSING CLUE ON:
* who's responsible for configuring DMA timing modes on IDE drives?
the BIOS or the driver?
* is there a spec for dealing with Ultra-DMA extensions?
* are there any chipsets or with bugs relating to DMA transfer that
should be blacklisted?
* are there any ATA interfaces that use some other kind of DMA
controller in conjunction with standard ATA protocol?
FINAL NOTE:
after having looked at the ATA-3 spec, all i can say is, "it's ugly".
*especially* electrically. the IDE bus is best modeled as an
unterminated transmission line, these days.
for maximum reliability, keep your IDE cables as short as possible and
as few as possible. from what i can tell, most current chipsets have
both IDE ports wired into a single buss, to a greater or lesser
degree. using two cables means you double the length of this bus.
SCSI may have its warts, but at least the basic analog design of the
bus is still somewhat reasonable. IDE passed beyond the veil two
years ago.
--John Hood, cgull@smoke.marlboro.vt.us
Moved description of sio 16650A flag to the sio section and rewrote the
description. It was in the generic console flags section.
Added undocumented options CPU_UPGRADE_HW_CACHE and WLDEBUG.
- Added the psm options PSM_HOOKAPM and PSM_RESETAFTERSUSPEND.
LINT:
- Added the psm options PSM_HOOKAPM and PSM_RESETAFTERSUSPEND.
- Added comments on the flag 0x20 for syscons.
- Clarified descriptions on the flags (0x02, 0x04) regarding the cursor
shape in syscons.
fix stopped it being used in all cases, because substitution on unset
variables does not work.
When profiling, put -malign-functions=4 in CFLAGS instead of in PROF.
This fixes the histogram counts for profiling support functions. It
gives bogus but harmless extra alignment for genassym etc.
This eliminates a lot of #ifdef SMP type code. Things like _curproc reside
in a data page that is unique on each cpu, eliminating the expensive macros
like: #define curproc (SMPcurproc[cpunumber()])
There are some unresolved bootstrap and address space sharing issues at
present, but Steve is waiting on this for other work. There is still some
strictly temporary code present that isn't exactly pretty.
This is part of a larger change that has run into some bumps, this part is
standalone so it should be safe. The temporary code goes away when the
full idle cpu support is finished.
Reviewed by: fsmp, dyson
like bsd.lib.mk and bsd.prog.mk. It doesn't add it to CXXINCLUDES, I
don't think anybody has written a kernel module with C++. (Not that I
think DavidG will allow it anyway. :)
Reviewed by: bde
NETNATM --> NATM
reported by Bruce Evans.
Bruce also pointed out that NATM is confusing since config(8) defines
NATM as the number of atm pseudo device in "BUILD_DIR/atm.h".
We might change the name in the future but leave it as it is for now.
that I snuck in to our GDB last year. This allows you to debug headless
machines by sharing the console port between the debugger and the system
console. It's not 100% reliabile, but it works well. It's optional
and disabled by default.
Submitted by: Juniper Networks
is incompatible with -pg. (We use a different version of mcount for
profiling frame-pointer-less assembler functions, but gcc doesn't know
about this.)
Added a missing dependency.
Cleaned up trailing backslashes.
Added comment about config's limitations/bugs handling dependencies and
backslashe/newlines.
Finished removing support for isdn drivers.
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
Remove "setdefs.h" and arrange to generate it automatically at
ELF kernel build time.
"gensetdefs.c" is a utility which scans a set of ELF object files
and outputs a line ``DEFINE_SET(name, length);'' for each linker
set that it finds. When generating an ELF kernel, this is run just
before the final link to generate "setdefs.h".
Remove the init_sets() function from "setdef0.c", and its call from
"machdep.c". Since "gensetdefs.c" calculates the length of each
set, it is no longer necessary in an ELF kernel to count the set
elements at kernel initialization time. Also remove "set_of_sets"
which was used for this purpose.
Link "setdef0" and "setdef1" into the kernel only if building for
ELF. Since init_sets() is no longer used, there is no need to link
them into an a.out kernel.
to fill in the nfs_diskless structure, at the cost of some kernel
bloat. The advantage is that this code works on a wider range of
network adapters than netboot. Several new kernel options are
documented in LINT.
Obtained from: parts of the code comes from NetBSD.
the patches in freefall:/home/dfr/ld.diffs to your ld sources and set
BINFORMAT to aoutkld when linking the kernel.
Library changes and userland utilities will appear in a later commit.
. It makes cd9660 root f/s working again.
. It makes CD9660 a new-style option.
. It adds support to mount an ISO9660 multi-session CD-ROM as the root
filesystem (the last session actually, but that's what is expected
behaviour).
Sigh. The CDIOREADTOCENTRYS did a copyout() of its own, and thus has
been unusable for me for this work. Too bad it didn't simply stuff
the max 100 entries into the struct ioc_read_toc_entry, but relied on
a user supplied data buffer instead. :-( I now had to reinvent the
wheel, and created a CDIOREADTOCENTRY ioctl command that can be used
in a kernel context.
While doing this, i noticed the following bogosities in existing CD-ROM
drivers:
wcd: This driver is likely to be totally bogus when someone tries
two succeeding CDIOREADTOCENTRYS (or now CDIOREADTOCENTRY)
commands with requesting MSF format, since it apparently
operates on an internal table.
scd: This driver apparently returns just a single TOC entry only for
the CDIOREADTOCENTRYS command.
I have only been able to test the CDIOREADTOCENTRY command with the
cd(4) driver. I hereby request the respective maintainers of the
other CD-ROM drivers to verify my code for their driver. When it
comes to merging this CD-ROM multisession stuff into RELENG_2_2 i will
only consider drivers where i've got a confirmation that it actually
works.
opt_smp_invltlb.h
from:
SMPHDRS= opt_smp.h opt_smp_invltlb.h
SMP_INVLTLB is no longer a valid config option, the invalidation of the TLB
via inter-CPU IPIs is now standard when APIC_IO is used.
make world fails when it tries to build LKMs because the files
opt_smp.h
opt_smp_invltbl.h
are missing.
This patch to /usr/src/share/mk/bsd.kmod.mk is a temporary workaround.
Note that LKMs built in this way may or may NOT work properly with an
SMP kernel.
source files via a 'cc -include opt_global.h ...' type arrangement.
This means we can untangle certain header files.
options.i386 has a placeholder until it has a real member so we can avoid
having to teach config about it just yet.
Reviewed by: bde
There are various options documented in i386/conf/LINT, there is more to
come over the next few days.
The kernel should run pretty much "as before" without the options to
activate SMP mode.
There are a handful of known "loose ends" that need to be fixed, but
have been put off since the SMP kernel is in a moderately good condition
at the moment.
This commit is the result of the tinkering and testing over the last 14
months by many people. A special thanks to Steve Passe for implementing
the APIC code!
have successfully built, booted, and run a number of different ELF
kernel configurations, including GENERIC. LINT also builds and
links cleanly, though I have not tried to boot it.
The impact on developers is virtually nil, except for two things.
All linker sets that might possibly be present in the kernel must be
listed in "sys/i386/i386/setdefs.h". And all C symbols that are
also referenced from assembly language code must be listed in
"sys/i386/include/asnames.h". It so happens that failure to do
these things will have no impact on the a.out kernel. But it will
break the build of the ELF kernel.
The ELF bootloader works, but it is not ready to commit quite yet.
supports All Cyrix CPUs, IBM Blue Lightning CPU and NexGen (now AMD)
Nx586 CPU, and initialize special registers of Cyrix CPU and msr of
IBM Blue Lightning CPU.
If revision of Cyrix 6x86 CPU < 2.7, CPU cache is enabled in
write-through mode. This can be disabled by kernel configuration
options.
Reviewed by: Bruce Evans <bde@freebsd.org> and
Jordan K. Hubbard <jkh@freebsd.org>
Added obsolete option GATEWAY so that kern_opt.c gets tested.
Added undocumented options LOCKF_DEBUG and SIMPLELOCK_DEBUG so
that these options get tested. The addition of LOCKF_DEBUG shows
that all of kern/kern_lockf.c shouldn't have been moved from ufs.
The debugging parts are very fs-dependent.
probing anytime soon, make EISA_SLOTS a fully supported option. It's
required for the HP NetServer LC series machines.
Next stop: make dset(8) aware of it as well.
become impractical to distinguish versions using "real" release dates, so
might as well make it correspond to real version number (-current is
on the 3.0 branch) so at least the feature increments are guaranteed to
be linear.
Silently approved by: current list
changes, so don't expect to be able to run the kernel as-is (very well)
without the appropriate Lite/2 userland changes.
The system boots and can mount UFS filesystems.
Untested: ext2fs, msdosfs, NFS
Known problems: Incorrect Berkeley ID strings in some files.
Mount_std mounts will not work until the getfsent
library routine is changed.
Reviewed by: various people
Submitted by: Jeffery Hsu <hsu@freebsd.org>
Put obsolete GATEWAY option back in opt_defunct.h. It's the only
significant option that has gone away since 2.1.6, so warning about
it might be useful.
SEM* and SHM*. These are already supported in the options files. I
mostly used the default value plus 1. This ensures that the LINT kernel
depends on the options headers.
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>
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
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
compile again. The code to protect users from combining the dedicated
PCCARD drivers and the generic code is a warning if the above option
is included in the config file.
Demanded by: bde
the profiling level in config and decide what to do in makefiles.
Makefile.i386:
Align functions to 16-byte boundaries if profiling is enabled. This
will allow a fourfold reduction in the size of the profiling buffers.
uses /usr/include/sys/*, which may point to a different build tree. I'm
not sure that this is necessary, but there was a question mark over what
/usr/include/sys points to when building the "user mode" binaries in the
kernel code, especially when building the smp tree.
I suspect that the "right" line here is to use ${INCLUDES}, but that
causes warnings about unused static inline functions in stdio.h and ctype.h
aic7xxx cards failing on certain motherboards, reverse the logic used to
control this feature. AHC_FORCE_PIO is replaced with AHC_ALLOW_MEMIO.
GENERIC no longer needs to specify the AHC_FORCE_PIO option since this is
the default.
synthesizer. The utilities for this will appear as port submissions soon
afterwards, according to the submitter.
Submitted-By: Randall Hopper <rhh@ct.picker.com>
Written-By: Takashi Iwai <iwai@dragon.mm.t.u-tokyo.ac.jp>
the other two trees. Bump RELDATE to Feb 1997, one greater than 2.2.
Now I can go update my porting.sgml.
NOT a 2.2 candidate, in case phk's wondering. :)
syscons and psm, curtesy Kazutaka Yokota with minor changes by
me. This contains an update of the psm driver as well.
This also fixes the breakage that I introduced to the psm driver by
making syscons poll for keyboard events in the atempt to fix the
hanging keyboard problem.
It works perfectly for me, and I'd like to hear from all that
have had keyboard/ps/2 mouse problems if this is the cure...
Submitted by: Kazutaka YOKOTA (yokota@zodiac.mech.utsunomiya-u.ac.jp)
sys/pc98/i386/machdep.c: sync with i386/i386/machdep.c
sys/pc98/conf/options.pc98: sync with i386/conf/options.i386
sys/i386/isa/sound: DMA auto initialize mode support for PC98.
contributed by: Akio Morita <amorita@bird.scphys.kyoto-u.ac.jp>
Definite 2.2 material, I believe.
Submitted by: The FreeBSD (98) Development Team
getting the same behavior using the flags, which can be done inside of
UserConfig. (Also document other syscons flags which were previously
undocumented).
Requested by: bde
negative-logic flags (flags 0x01 and 0x02 for npx0, defaulting to unset = on).
This changes the default from off to on. The options have been in current
for several months with no problems reported.
Added a boot-time negative-logic flag for the old I5886_FAST_BCOPY option
which went away too soon (flag 0x04 for npx0, defaulting to unset = on).
Added a boot-time way to set the memory size (iosiz in config, iosize in
userconfig for npx0).
LINT:
Removed old options. Documented npx0's flags and iosiz.
options.i386:
Removed old options.
identcpu.c:
Don't set the function pointers here. Setting them has to be delayed
until after userconfig has had a chance to disable them and until after
a good npx0 has been detected.
machdep.c:
Use npx0's iosize instead of MAXMEM if it is nonzero.
support.s:
Added vectors and glue code for copyin() and copyout().
Fixed ifdefs for i586_bzero().
Added ifdefs for i586_bcopy().
npx.c:
Set the function pointers here.
Clear hw_float when an npx exists but is too broken to use.
Restored style from a year or three ago in npxattach().
2.2 are more obvious. -Winline is unimportant, but -W gives thousands
of warnings for comparisions. Turning off -W also loses warnings for:
- auto variables clobbered by longjmp. Not much of a problem in the kernel.
- functions returning without a value. I don't like losing this.
- an expression statement or the left side of a comma operand contains no
side effects. Turning this off also stops warnings for the low quality
debugging macros in gsc.c and lpt.c.
Should be in 2.2.
if I586_CPU is defined. Note there is a runtime check so the code
won't be run for non-Pentium CPUs anyway.
2.2 candidate, this code has been tested for almost half year in -current.
will be renamed.
Fixed comments about unsupported network protocols.
ncr0 is a controller, not a device. This make no difference.
Added undocumented options DEVFS_ROOT, I586_CTR_GUPROF and I586_PMC_GUPROF.
Sorted undocumented options.
3COM 3C590 Etherlink III PCI,
3COM 3C595 Fast Etherlink PCI,
3COM 3C592 Etherlink III EISA,
3COM 3C590 Fast Etherlink EISA,
3COM 3C900 Etherlink XL PCI and
3COM 3C905 Fast Etherlink XL PCI.
This driver is based on OpenBSD's driver. I modified it to run under FreeBSd
and made it actually work usefully.
Afterwards, nao@tom-yam.or.jp (HAMADA Naoki) added EISA support as well as
early support for 3C900 Etherlink XL PCI and 3C905 Fast Etherlink XL PCI.
He also split up the driver in a bus independant and bus dependant parts.
Especially the 3c59X support should be pretty stable now.
Submitted by: partly nao@tom-yam.or.jp (HAMADA Naoki)
Obtained from:partly OpenBSD
