corresponding variable `rc_wakeup_started' in rev.1.36 but broken
again in rev.1.37. This bug only caused excessive polling (it gave
NRC activations for each of the SWI handler and the timeout handler
instead of 1 of each).
Moved cdevsw attachment from the driver probe routine to the driver
attach routine.
The cdevsw_add() function now finds the major number(s) in the
struct cdevsw passed to it. cdevsw_add_generic() is no longer
needed, cdevsw_add() does the same thing.
cdevsw_add() will print an message if the d_maj field looks bogus.
Remove nblkdev and nchrdev variables. Most places they were used
bogusly. Instead check a dev_t for validity by seeing if devsw()
or bdevsw() returns NULL.
Move bdevsw() and devsw() functions to kern/kern_conf.c
Bump __FreeBSD_version to 400006
This commit removes:
72 bogus makedev() calls
26 bogus SYSINIT functions
if_xe.c bogusly accessed cdevsw[], author/maintainer please fix.
I4b and vinum not changed. Patches emailed to authors. LINT
probably broken until they catch up.
Reformat and initialize correctly all "struct cdevsw".
Initialize the d_maj and d_bmaj fields.
The d_reset field was not removed, although it is never used.
I used a program to do most of this, so all the files now use the
same consistent format. Please keep it that way.
Vinum and i4b not modified, patches emailed to respective authors.
The old version only worked right when the time was read strictly
more often than every 1/HZ seconds, but we only guarantee reading
it every (1/HZ + epsilon) seconds. Part of rev.1.126-1.127 attempted
to fix this but didn't succeed. Detect counter rollover using the
heuristic from the old version of microtime() with additional
complications for supporting calls from fast interrupt handlers.
This works provided i8254 interrupts are not delayed by more than
1/(2*HZ) seconds.
This needs more comments, and cleanups for the SMP case, and more
testing of the SMP case before it is merged into RELENG_3.
Tested by: jhay
disable_intr() does non-recursive locking in the SMP case. This should
fix cy-driver-related panics when SMP is configured.
Broken in: rev.1.73 (3.1 and -current)
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.
