WaveLAN's radio modem. The default is whatever the NIC uses since NICs
sold in different countries may default to different frequencies. (The
Lose95/LoseNT software doesn't let you select the channel so it's probably
not really meant to be changed.)
- Change to the same transmit scheme as the PNIC driver.
- Dynamically set the cache alignment, and set burst size the same as
the PNIC driver in mx_init().
- Enable 'store and forward' mode by default. This is the slowest option
and it does reduce 100Mbps performance somewhat, but it's the most
reliable setting I can find. I'm more interested in having the driver
work reliably than trying to squeeze the best performance out of it.
The reason I'm doing this is that on *some* systems you may see a lot
of transmit underruns (which I can't explain: these are *fast* test
systems) and these errors seem to cause unusual and decidedly
non-tulip-like behavior. In normal 10Mbps mode, performance is fine
(you can easily saturate a 10Mbps link).
Also tweak some of the other drivers:
- Increase the size of the TX ring for the Winbond, ASIX, VIA Rhine
and PNIC drivers.
- Set a larger value for ifq_maxlen in the ThunderLAN driver. The setting
of TL_TX_LIST_CNT - 1 is too low (the ThunderLAN driver only allocates
20 transmit descriptors, and I don't want to fiddle with that now
because the ThunderLAN's descriptor structure is an oddball size
compared to the others).
for elf kernels (it is broken for all kernels due to lack of egcs support).
Renaming of many assembler labels is avoided by declaring by declaring
the labels that need to be visible to gprof as having type "function"
and depending on the elf version of gprof being zealous about discarding
the others. A few type declarations are still missing, mainly for SMP.
PR: 9413
Submitted by: Assar Westerlund <assar@sics.se> (initial parts)
INIT_PATH config option.
Also fix two bugs which caused an infinite loop in none of the programs
in the init_path were found. That code was obviously not tested!
adapter (and some workalikes). Also add man pages and a wicontrol
utility to manipulate some of the card parameters.
This driver was written using information gleaned from the Lucent HCF Light
library, though it does not use any of the HCF Light code itself, mainly
because it's contaminated by the GPL (but also because it's pretty gross).
The HCF Light lacks certain featurs from the full (but proprietary) HCF
library, including 802.11 frame encapsulation support, however it has
just enough register information about the Hermes chip to allow someone
with enough spare time and energy to implement a proper driver. (I would
have prefered getting my hands on the Hermes manual, but that's proprietary
too. For those who are wondering, the Linux driver uses the proprietary
HCF library, but it's provided in object code form only.)
Note that I do not have access to a WavePOINT access point, so I have
only been able to test ad-hoc mode. The wicontrol utility can turn on
BSS mode, but I don't know for certain that the NIC will associate with
an access point correctly. Testers are encouraged to send their results
to me so that I can find out if I screwed up or not.
network adapters. These are all PCMCIA devices (the ISA version is a
PCMCIA to ISA bridge with a PCMCIA card plugged into it). Also add a
wicontrol utility to read and write some of the card's parameters.
Note: I do not have access to a WavePOINT access point, so I have only
been able to test this driver in ad-hoc (point to point) mode. The
wicontrol utility allows programming the desired service set name (SSID)
and enabling BSS mode, but I can't tell for sure if it works (I know the
card switches modes, but I can't verify that it joins a service set
correctly).
This driver was written using information gleaned from the Lucent HCF Light
library, which is an API library designed to simplify driver development
for devices based on the Lucent Hermes chip. Unfortunately, the HCF Light
is missing certain features (like 802.11 frame encapsulation!) which are
available only in the proprietary complete HCF code, which is not available
to the public. This driver uses none of the HCF Light code: it's very ugly
and contaminated by the GPL. IP and ARP packets are encapsulated as 802.11
frames, everything else is encapsulated as 802.3.
(It would be easier to just get the Hermes programming manual, but that's
not publically available either. For those who are wondering, the Linux
WaveLAN/IEEE driver uses the proprietary HCF code, which is provided in
object code form only. So much for supporting open source sofware.)
Multicast filter support is implemented, however it appears that the
filter doesn't work: programming in one IP mutlicast group enables them
all.
handler. This fixes pnp interrupts and would have fixed pccard interrupts
but a workaround has been applied there.
This the sound driver problems which people have reported with new-bus.
uses the AUI port with an on-board AUI to 10baseFL transceiver, not the
10baseT port like I had earlier suspected. The 3c900B-FL should be properly
supported now.
routines. The descriptor contains parameters which could be used
within those routines (eg. ip_output() ).
On passing, add IPPROTO_PGM entry to netinet/in.h
abuses its argument, which is supposed to be an integer unit number, as
a pointer to the head of the 'struct slot' list. When this code was
hacked^Wupdated for newbus, a new mechanism for registering slot_irq_handler()
was put in place and the significance of the unit number was overlooked.
When registering an interrupt, we have both device_id and unit. The unit
number is passed as 'unit' but /sys/i386/usa/intr_machdep.c:register_intr()
drops unit on the floor and uses device_id instead. Since pccard_alloc_intr()
always sets device_id to 0, this means the unit number is always zero, and
slot_irq_handler() is always called with 0, which becomes a NULL pointer
which slot_irq_handler() tries to dereference and the kernel explodes.
Result: if you assign a PCMCIA driver in the kernel config file like this:
device wi0 at isa? port? irq?
Then the system will panic the moment a PCMCIA device is attached and
an interrupt is triggered.
The quick fix: make pccard_alloc_intr() pass the unit number as both
the device_id and unit arguments to register_pcic_intr(). The correct fix
would be to rewrite /sys/pccard to be less disgusting.
+ plug an mbuf leak when dummynet used with bridging
+ make prototype of dummynet_io consistent with usage
+ code cleanup so that now bandwidth regulation is precise to the
bit/s and not to (8*HZ) bit/s as before.
