similar to the PNIC I (supported by the pn driver). In fact, it's really
a Macronix 98715A with wake on LAN support added. According to LinkSys,
the PNIC II was jointly developed by Lite-On and Macronis. I get the
feeling Macronix did most of the work. (The datasheet has the Macronix
logo on it, and is in fact nearly identical to the 98715 datasheet, except
for the extra wake on LAN registers.) In any case, the PNIC II works just
fine with the Macronix driver.
The changes are:
- Move PCI ID for the PNIC II from the pn driver to the mx driver.
- Mention PNIC II support in mx.4.
- Mention PNIC II support in RELNOTES.TXT and HARDWARE.TXT.
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)
easier to use and more flexible.
* Change BUS_ADD_CHILD to take an order argument instead of a place.
* Define a partial ordering for isa devices so that sensitive devices are
probed before non-sensitive ones.
(default 1) disables PMTUD globally. Although PMTUD can be disabled in
the standard case by locking the MTU on a static route (including the
default route), this method doesn't work in the face of dynamic routing
protocols like gated.
Compaq XP1000, AlphaServer DS20, AlphaServer DS10, and DP264
This has been tested *only* on XP1000's. I'll be interested to hear from
owners of other types of DEC_ST6600 alphas.
I'd like to thank Don Rice of Compaq for providing the documentation required
to support this platform on FreeBSD. I'd also like to thank Doug Rabson for newbus,
and for helping me get a multiple hoses working with newbus.
Reviewed by: Doug Rabson <dfr@nlsystems.com>
Allow chipset drivers to specify the direct-mapped DMA window's mask in
preparation for tsunami support. Previous chipsets' direct-mapped DMA
mask was always 1024*1024*1024. The Tsunami chipset needs it to be
2*1024*1024*1024
Reviewed by: Doug Rabson <dfr@nlsystems.com>
preparation for tsunami support. Previous chipsets' direct-mapped DMA
mask was always 1024*1024*1024. The Tsunami chipset needs it to be
2*1024*1024*1024
These changes should not affect the i386 port
Reviewed by: Doug Rabson <dfr@nlsystems.com>
- Clear the IFF_OACTIVE flag when al_txeof() runs down the last TX mbuf chain.
- Mark the workaround for the transmitter stalling bug with
#ifdef AL_TX_STALL_WAR/#endif.
only support 'mirroring' the vendor and device ids, so we don't
lose any information. Certain revisions of the aic7880 will not
perform the mirroring so to match all possiblities would double
the number of table entries. This change also allows us to match
things like the 2944B which I missed in the original table.
The XPT doesn't have a problem with this itself, but some controllers
drivers may have been caught off guard by the old behavior.
XPT_CONT_TARGET_IO is also a valid ccb type for cam_periph_unmapmem.
commands are outstanding. You'd think they'd just clear the IDLE bit,
but alas, no. Delay until all pending mailbox commands have completed
in aha_cmd to work around this.
Report sync rates correctly on Fast Adaptec cards. Clones may still be
reported incorrectly since there is no documenation on how they report
extended sync values.
Clean up some unused fields in the aha softc.
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.
|revision 1.13
|date: 1995/09/15 23:49:23; author: davidg; state: Exp; lines: +15 -2
|Check for page being resident when doing I/O with /dev/kmem and return
|EFAULT if it is not resident. This prevents the system from manufacturing
|a zero-fill page for unused but allocated areas of the kernel's VM.
writing, we want to be able to read the buffer. If we're reading, we want
to be able to write to the buffer.
PR: kern/11870
Submitted by: Andrew Mobbs <amobbs@allstor-sw.co.uk>
This is an old OPTi chipset.
If you use a Bt878 card with this chipset, be sure to enable
the SIS/VIA chipset compatiblity mode workaround.
Tested By: Ben Laurie <ben@algroup.co.uk>
SIS/VIA/ OPTi chipset PCI bus workarounds.
These make the Bt878/879 chips stabler on certain
older and non-intel motherboards.
Use options BKTR_430_FX_MODE
or options BKTR_SIS_VIA_MODE
to enable these modes.
Also rename 849 to 849A
in the transmit code: the TX descriptor ring, and a 'shadow' ring of mbuf
pointers, one for each TX descriptor. When transmitting a packet that
consists of several fragments in an mbuf chain, we link each fragment
to a descriptor in the TX ring, but we only save a pointer to the mbuf
chain. This pointer is saved in the shadow ring entry which corresponds
to the first fragment in the packet. Later, ti_txeof() can release the
whole chain with a single m_freem() call. (We need the second ring to
keep track of the virtual addresses of the mbuf chains.)
The problem with this is that the Tigon isn't actually through with the
mbuf chain until it reaches the last fragment (which has the TI_BDFLAG_END
bit set), however the current scheme releases the mbuf chain as soon as
the first fragment is consumed. This is wrong, since the mbufs can then
be yanked out from under the Tigon and modified before the other fragments
can be transmitted.
The fix is to make a one line change to ti_encap() so that it saves the
mbuf chain pointer in the shadow ring entry that corresponds to the last
fragment in TX ring instead of the first. This prevents the mbufs from
being released until the last fragment is transmitted.
Painstakingly diagnosed and fixed by: Robert Picco <picco@mail.wevinc.com>
Brought to my attention by: dg
+ add a missing call to dn_rule_delete() when flushing firewall
rules, thus preventing possible panics due to dangling pointers
(this was already done for single rule deletes).
+ improve "usage" output in ipfw(8)
+ add a few checks to ipfw pipe parameters and make it a bit more
tolerant of common mistakes (such as specifying kbit instead of Kbit)
PR: kern/10889
Submitted by: Ruslan Ermilov
