Mark Dawson holds teh copyright on this and has releases from
Compaq to allow him to do so..
Not functional in 4.0 yet but being checked in to allow the functional
3.x version to be branched at this point.
manager and prevented IOPort allocation beyond the first EISA slot from
working. subr_rman.c should have trapped this on the way into the system
rather than tripping over the wreckage.
Head banged into wall repeatedly by: "Matthew N. Dodd" <winter@jurai.net>
on systems with no FFS.
- Remove all references to mfs from cpu_rootconf(). mfs_init is
called prior to cpu_rootconf(), so it can set mountrootfsname to mfs
and (more imporantly) set rootdev using the (bogus in Bruce's opinion)
special major number of 255.
- Mention that the 6Mbps turbo adapters are supported in HARDWARE.TXT
and RELNOTES.TXT and the wi.4 man page
- Mention turbo adapters in the wicontrol.8 man page and provide a
complete table of available transmit speed settings
* Re-work the resource allocation code to use helper functions in subr_bus.c.
* Add simple isa interface for manipulating the resource ranges which can be
allocated and remove the code from isa_write_ivar() which was previously
used for this purpose.
ADMtek AL981 "Comet" chipset. The AL981 is yet another DEC tulip clone,
except with simpler receive filter options. The AL981 has a built-in
transceiver, power management support, wake on LAN and flow control.
This chip performs extremely well; it's on par with the ASIX chipset
in terms of speed, which is pretty good (it can do 11.5MB/sec with TCP
easily).
I would have committed this driver sooner, except I ran into one problem
with the AL981 that required a workaround. When the chip is transmitting
at full speed, it will sometimes wedge if you queue a series of packets
that wrap from the end of the transmit descriptor list back to the
beginning. I can't explain why this happens, and none of the other tulip
clones behave this way. The workaround this is to just watch for the end
of the transmit ring and make sure that al_start() breaks out of its
packet queuing loop and waiting until the current batch of transmissions
completes before wrapping back to the start of the ring. Fortunately, this
does not significantly impact transmit performance.
This is one of those things that takes weeks of analysis just to come
up with two or three lines of code changes.
Implement priorities.
GENERIC, LINT, files:
Remove remarks about ordering of device names.
GENERIC, LINT:
Sort the devices alphabetically in LINT and GENERIC.
motherboard will have a card for the "motherboard" on slot 0.
eisa0: <EISA bus> on motherboard
mainboard0: <ASU5101 (System Board)> at slot 0 on eisa0
This should stop the probe "detecting" an EISA bus everywhere that has
a 'controller eisa0' line regardless of whether it's really there.
A very nice i/o board with 16 open collector outputs (capable of driving 5-40v)
and 16 inputs
Also has 2 16 bit cascadable counters (10Mhz clock) capable of
generating interrupts.
It is a PCI card, and emulates the Intel 8254 timer.
It uses the PLX PCI-9050 PCI bus interface to map the
8254 style hardware and the i/o registers into the IO space.
Developed by Jennifer Clark <jen@vulture.dmem.strath.ac.uk>
Strathclyde University Transparent Telepresence Research Group
Clean up the handling of failure modes in our attach so we don't free
resources twice. ahc_free() will do all of the work for us (as would
be required by an unload event) so we only need to handle resources that
the softc has not taken ownership of.
though, on systems (386 mostly) that still have a seperate fpu, but it
might be possible to find systems where the FPU coprocessor is wired to
a different IRQ pin.
instances to a parent bus.
* Define a new method BUS_ADD_CHILD which can be called from DEVICE_IDENTIFY
to add new instances.
* Add a generic implementation of DEVICE_PROBE which calls DEVICE_IDENTIFY
for each driver attached to the parent's devclass.
* Move the hint-based isa probe from the isa driver to a new isahint driver
which can be shared between i386 and alpha.
udev_t in the kernel but still called dev_t in userland.
Provide functions to manipulate both types:
major() umajor()
minor() uminor()
makedev() umakedev()
dev2udev() udev2dev()
For now they're functions, they will become in-line functions
after one of the next two steps in this process.
Return major/minor/makedev to macro-hood for userland.
Register a name in cdevsw[] for the "filedescriptor" driver.
In the kernel the udev_t appears in places where we have the
major/minor number combination, (ie: a potential device: we
may not have the driver nor the device), like in inodes, vattr,
cdevsw registration and so on, whereas the dev_t appears where
we carry around a reference to a actual device.
In the future the cdevsw and the aliased-from vnode will be hung
directly from the dev_t, along with up to two softc pointers for
the device driver and a few houskeeping bits. This will essentially
replace the current "alias" check code (same buck, bigger bang).
A little stunt has been provided to try to catch places where the
wrong type is being used (dev_t vs udev_t), if you see something
not working, #undef DEVT_FASCIST in kern/kern_conf.c and see if
it makes a difference. If it does, please try to track it down
(many hands make light work) or at least try to reproduce it
as simply as possible, and describe how to do that.
Without DEVT_FASCIST I belive this patch is a no-op.
Stylistic/posixoid comments about the userland view of the <sys/*.h>
files welcome now, from userland they now contain the end result.
Next planned step: make all dev_t's refer to the same devsw[] which
means convert BLK's to CHR's at the perimeter of the vnodes and
other places where they enter the game (bootdev, mknod, sysctl).
with other reset handling in rev.1.83 but broke it in rev.1.120. The
breakage didn't seem to cause any problems even on the system which had
problems ("extra" interrupts and botched handling thereof) before rev.1.83.
It only affects multi-floppy systems anyway.
manuals specifically say that reading the counters using the rdmsr
instruction returns a 64 bit value of which the higher 24 bits are
undefined. The code that reads the counters should then clear the
high 24 bits.
PR: i386/10632
but was fairly harmless because not many devices have statically
configured msizes (none should have, but old-bus is missing post-probe
checks for maddr/msize conflicts, so sizes had to be statically
configured for maddr/msize conflict checking to actually work).
PR: 11146 (side issue)