* Add new sysctl "machdep.ieee_disable". This can be used to disable the
in kernel ieee trap handler. Then a usermode version of the code can be
used for debugging. Thank's to Ian Dall for this suggestion.
present and initialize a few things. No color support, yet.
- Properly disable interrupts for DAFB.
- Rearrange for better nubus display card interrupt support. Only register
an interrupt if we know how to clear it.
- Complain if we don't know about a given display card and can not install
an interrupt handler.
- Change MYSTERY stuff to cb264--still need to get the DrSW so we can
actually call the routine to clear an interrupt from this card.
tweaks and bug fixes by yours truly.
Here's what Denny had to say:
nubus.h:
- add a drsw entry for my card
[ I also added a couple of constants for more display cards ]
if_sn.c:
- allocate sc->space using malloc (Scott wanted this).
- make csr accesses use NIC_PUT/GET, remove sc->sc_csr.
- add multicast and IFF_PROMISC support. multicast isn't
well tested, but I made sure the unicast case still
works.
- finish the new arp interface, remove sc->sc_enaddr
if_snreg.h:
- remove struct sonic_reg
if_snvar.h:
- add NIC_PUT and NIC_GET macros a la if_ae
- remove sc_txhead, it isn't used.
if_sn_nubus.c:
- clean up support for my SE/30 card.
- Move add_nubus_intr from if_sn.c (to keep if_sn.c MI)
if_sn_obio.c:
- make Q610, C610, Q650, C650, Q800 use EXBUS.
- PB500 had a "return" where "break" was intended. PB500
probably wasn't working.
- move add_nubus_intr from if_sn.c.
- add an "explanation" why Apple's ethernet addr is encoded
in token ring format in the PROM.
correct, but unfortunately in trap.c trapsignal(p, SIGSEGV, code) passes
the address of the fault in code, instead of the trap code. So we punt for
now doing checking for trap code validity until this gets fixed.
- adjust for new ipl_attach()/ipl_detach() names.
- In ipl_load(), so not implicitly call ipl_attach(), since
doing so would be inconsistent with the behavior exhibited
by the statically-configured version.
Description:
- A BSD pseudo-device initialization routine is declared as
void <pseudo-device name>attach __P((int count));
in ioconf.c by config(8). main() calls these functions
from a table.
- IP Filter has functions iplattach() and ipldetach() (or,
in the NetBSD case, were erroneously renamed ipfilterattach()
and ipfilterdetach()). These functions are used to establish
and disestablish the IP Filter "filter rule check" hook in
the IP input/output stream. They are declared:
int iplattach __P((void));
int ipldetach __P((void));
..and are expected to return a value by iplioctl().
- When main() calls (by sheer coincidence!) iplattach(),
the filter hook is established, and the IP Filter machinery
labeled as "initialized". This causes all packets, whether or
not the user intents to use filter rules, to be passed to
the filter rule checker if "ipfilter" is configured into the
kernel.
- As a result of the above, a kludge existed to default to
passing all packets (I can only assume that when this was
originally committed, the symptom of the bug was noticed by
the integrator, but the bug not actually found/fixed).
- In iplioctl(), if the SIOCFRENB ioctl is issued with an
argument of "enable" (i.e. user executed "ipf -E"), iplattach()
will notice that the machinery is already initialized and
return EBUSY.
Fix:
- Rename iplattach()/ipldetach() to ipl_enable() and ipl_disable().
- Create a pseudo-device entry stub named ipfilterattach()
(NetBSD case) or iplattach() (all other). This is a noop; none
of the machinery should be initialized until the caller expicitly
enables the filter with ipf -E. Add a comment to note that.
XXX !!! XXX !!!
I noticed a few semi-serious bugs while doing this merge, one of which
has existed for a fairly long time. Some of them are addressed in this
commit (because they caused the kernel to not compile), and are annoted
by "XXX" and "--thorpej". The other one will be addressed shortly in
a future commit, and, as far as I can tell, affects all operating systems
which IP Filter supports.
- new MD variable: sc_initmodemedia, 79c960 cards can select
between two ports, but this needs to be done in the MI init mode page
- new defines for PCnet-ISA cards (79c960)
- new MD variable: sc_initmodemedia, 79c960 cards can select
between two ports, but this needs to be done in the MI init mode page
- new defines for PCnet-ISA cards (79c960)
- new MD variable: sc_initmodemedia, 79c960 cards can select
between two ports, but this needs to be done in the MI init mode page
- new defines for PCnet-ISA cards (79c960)
external storage. Highlights:
- additional "void *" argument to (*ext_free)(), an opaque
cookie for use by the free function.
- MCLALLOC() and MCLFREE() calls are gone. They are replaced
by MEXTADD() (add external storage to mbuf), MEXTMALLOC()
(malloc() external storage and attach to mbuf), and
MEXTREMOVE() (remove external storage from mbuf).
- completely new external storage reference counting
mechanism; mclrefcnt[] is gone.
These changes will eventually be used to pass driver DMA buffers up
the network stack, and reduce/eliminate copies in certain code paths
(e.g. NFS writes).
From Matt Thomas <matt@3am-software.com> and myself <thorpej@nas.nasa.gov>,
with some input from Chris Demetriou <cgd@cs.cmu.edu> and review by
Charles Hannum <mycroft@mit.edu>.
particularly older ones, don't do a SAVE DATA POINTER before disconnecting.
When the driver reconnects, it does an implicit RESTORE POINTERS, and
restores the data pointer from *before* the last transfer. If the driver
calculates the residual using the data pointer and doesn't account for
this, the residual will be wrong.
What we do is test for the SDEV_AUTOSAVE quirk when we see a disconnect
message, falling through to do a SAVE DATA POINTER if the quirk applies
to this target.
The workaround was suggested by Mycroft, who also provided the explanation
of the problem. Actual code was (mostly) ripped off from the 53C9x driver.
helper functions. This cuts down the number of needless function calls
by approx. 80%, which has a healthy effect on the responsiveness of
a machine under heavy process creation/teardown loads.
The VM system seems to be fond of asking to delete page mappings
which aren't there..
matthias