other allocations/initializations have been successful. I kinda
doubt it will fix the recent breakage that some people are seeing,
but this could have caused problems for sure.
This patch is rather big because I had to significantly redesign
the driver to make the busdma conversion possible. Most notably,
hardware and software structures were carefully splitted to get
rid of all the structs overlapping evilness.
Special thanks to phk and Richard Puga <puga@mauibuilt.com> for
providing me with fxp(4) hardware to do this work.
Thanks to marcel for testing this on ia64, and to Fred Clift
<fclift@verio.net> for testing this on alpha.
Tested on: i386, ia64, alpha
the fxp driver. This is enabled only for the 82550/82551 chips
(PCI revision code 12 or 13). RX and TX checksum offload are
both supported. Transmit offload is limited to TCP and UDP only
right now: there seems to be a problem with IP header checksumming
on transmit in some cases.
This chip has hardware VLAN support as well. I hope to enable
support for this eventually.
o don't strip the Ethernet header from inbound packets; pass packets
up the stack intact (required significant changes to some drivers)
o reference common definitions in net/ethernet.h (e.g. ETHER_ALIGN)
o track ether_ifattach/ether_ifdetach API changes
o track bpf changes (use BPF_TAP and BPF_MTAP)
o track vlan changes (ifnet capabilities, revised processing scheme, etc.)
o use if_input to pass packets "up"
o call ether_ioctl for default handling of ioctls
Reviewed by: many
Approved by: re
just limited to the DEVICE_POLLING case. This removes the FXP_RFA_RNRMARK
hack, and replaces it with a softc flag that is used to record when
the handling of a no-resource condition was deferred due to running
out of DEVICE_POLLING cycles. This was tested on -stable, but the
code is essentially the same as in -current. It should only affect
the case where DEVICE_POLLING is defined.
The details of the mechanism behind the crashes are still uncertain
but the most likely cause seems to be some kind of hardware confusion
when the no-resource recovery code is accidentally invoked while
the receiver is still active. This could have happened if the
hardware left the 0x4000 bit of the RFA status word set. The comments
in the commit log for revision 1.142 stating that the driver could
clash with the hardware writing to this status word were not correct.
Tested by: Guy Helmer <ghelmer@palisadesys.com>
behaviour of the hardware: a possibly reserved bit of the receive
descriptor (RFA) `status' field is borrowed to record no-resource
(RNR) events, and the same status field is read and written to at
a time that may clash with the hardware updating this field.
There is no hardware documentation available to determine if these
things are safe to do; the second issue almost certainly isn't, and
the first is only safe if there is documentation saying that this
bit is free to be used by the driver. The PR referenced below
provides extremely convincing evidence that the changes cause random
crashes on some (unusual) hardware.
Since these features are only required by the DEVICE_POLLING case,
this commit makes their use conditional on that option. It does not
change the DEVICE_POLLING case, but at least people with the rare
hardware on which this code causes problems can now avoid the crashes
by not enabling DEVICE_POLLING.
PR: kern/42260
Reviewed by: luigi
Problem revision found by: Pawel Malachowski <pawmal@unia.3lo.lublin.pl>
Tested by: Pawel Malachowski <pawmal@unia.3lo.lublin.pl>
MFC after: 1 week
Linux driver defines 0x103[B-E] so add those as well.
Obtained from: Intel Linux e100 driver
MFC: Immediately if re@ allows it, otherwise after 4.7-RELEASE
Also take this chance to cleanup the code in fxp_intr_body.
Add a missing block of code to disable interrupts when
reinitializing the interface while doing polling (the RELENG_4
version was correct).
MFC after: 3 days
1.131 is slightly broken, and I would commit the fix to that here, but it
has been reported that any deviation from the original code is causing
problems with some 82557 chips, causing them to lock hard.
Until those issues have been figured out, going back to the original
code is the best plan.
Frustrated: Silby
are packets queued for transmission.
This driver is strange -- it never sets IFF_OACTIVE, so all
transmissions always cause a call to fxp_start. However, if the
link gets stuck, there was nothing to reset it, so there was still
a possibility of lockups.
MFC after: 3 days
most cases NULL is passed, but in some cases such as network driver locks
(which use the MTX_NETWORK_LOCK macro) and UMA zone locks, a name is used.
Tested on: i386, alpha, sparc64
instead of relying on the previous filters to be present.
Back out r1.125, as a reset is needed to unload any existing microcode,
(which clears the multicast addresses), as it is superceded by this change.
Non-SMP, i386-only, no polling in the idle loop at the moment.
To use this code you must compile a kernel with
options DEVICE_POLLING
and at runtime enable polling with
sysctl kern.polling.enable=1
The percentage of CPU reserved to userland can be set with
sysctl kern.polling.user_frac=NN (default is 50)
while the remainder is used by polling device drivers and netisr's.
These are the only two variables that you should need to touch. There
are a few more parameters in kern.polling but the default values
are adequate for all purposes. See the code in kern_poll.c for
more details on them.
Polling in the idle loop will be implemented shortly by introducing
a kernel thread which does the job. Until then, the amount of CPU
dedicated to polling will never exceed (100-user_frac).
The equivalent (actually, better) code for -stable is at
http://info.iet.unipi.it/~luigi/polling/
and also supports polling in the idle loop.
NOTE to Alpha developers:
There is really nothing in this code that is i386-specific.
If you move the 2 lines supporting the new option from
sys/conf/{files,options}.i386 to sys/conf/{files,options} I am
pretty sure that this should work on the Alpha as well, just that
I do not have a suitable test box to try it. If someone feels like
trying it, I would appreciate it.
NOTE to other developers:
sure some things could be done better, and as always I am open to
constructive criticism, which a few of you have already given and
I greatly appreciated.
However, before proposing radical architectural changes, please
take some time to possibly try out this code, or at the very least
read the comments in kern_poll.c, especially re. the reason why I
am using a soft netisr and cannot (I believe) replace it with a
simple timeout.
Quick description of files touched by this commit:
sys/conf/files.i386
new file kern/kern_poll.c
sys/conf/options.i386
new option
sys/i386/i386/trap.c
poll in trap (disabled by default)
sys/kern/kern_clock.c
initialization and hardclock hooks.
sys/kern/kern_intr.c
minor swi_net changes
sys/kern/kern_poll.c
the bulk of the code.
sys/net/if.h
new flag
sys/net/if_var.h
declaration for functions used in device drivers.
sys/net/netisr.h
NETISR_POLL
sys/dev/fxp/if_fxp.c
sys/dev/fxp/if_fxpvar.h
sys/pci/if_dc.c
sys/pci/if_dcreg.h
sys/pci/if_sis.c
sys/pci/if_sisreg.h
device driver modifications
and packet bundling. Make the microcode settings controllable via sysctl
and loader tunables.
Submitted by: Marko Zec <zec@tel.fer.hr>
(with some munging and dynamic sysctl support by me)
Also extend the workaround for Dynamic Standby mode to later '559 chips,
not just the ICH2 variants.
the chip can cause a PCI protocol violation in under certain scenarios.
The workaround is to rewrite the EEPROM to disable Dynamic Standby Mode.
Once the EEPROM is rewritten, the system needs to be rebooted in order
to pick up the new settings.
This has been tested on several ICH2/ICH2-M systems, found in 815E based
boards, and usually identified by the presence of the 82562 ET/EM PHY.
Thanks to: Mike Tansca, Paul Saab for samples of the problematic boards.
of " &= ". Also change the MII PHY device mask to check the correct bits.
Cookie to: Andre Albsmeier <andre.albsmeier@mchp.siemens.de>
Pointy hat to: me
a 82557 (e.g.: a newer chip) then:
+ enable MWI, if the PCI configuration indicates the system supports it
+ enable usage of extended TxCB, for better performance
+ enable hardware flow control. FC frames will be passed up to the
host only if promiscuous mode is enabled.
