| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Submitted by: Gavin Atkinson <gavin.atkinson@ury.york.ac.uk>
|
|
|
|
|
|
|
|
|
|
|
|
| |
a vlan interface attached to a fxp(4) card when it has not been
initialized yet. We now set the links from our internel TX descriptor
structure to the TX command blocks at attach time rather than at init
time. While I'm here, slightly improve the style in fxp_attach().
PR: kern/78112
Reported by: Gavin Atkinson <gavin.atkinson@ury.york.ac.uk> and others
Tested by: flz, Gavin Atkinson <gavin.atkinson@ury.york.ac.uk>
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
testing it to know whether we should enable the 82503 serial mode...
Move code to the right location and disallow the use of the 82503
serial mode if the sc->revision field is 0 again. This makes fxp(4)
work correctly with ATMEL 350 93C46 cards (3 port 82559 based with a
82555 PHY), as well as with the older ATMEL 220 93C46 (same flavour)
and with the even older 10Mbps-only 82557 cards with the 82503 serial
interface.
Tested by: Andre Albsmeier <andrer@albsmeier.net>, krion
MFC after: 2 weeks
|
|
|
|
| |
OK'ed by: njl, rwatson, sam
|
|
|
|
|
|
|
| |
unexpected surprises when a system panics or is left in the debugger.
Requested by: kris
MFC after: 3 days
|
| |
|
|
|
|
|
|
|
|
|
| |
interface as well. This is not an expected revision id per the
datasheet, but unfortunately there are such cards out there with
a 82557 chipset, and they want to use the 82503.
PR: kern/75739
Reported by: Andre Albsmeier <andre.albsmeier@siemens.com>
|
|
|
|
|
|
|
|
|
| |
datasheet says it is only valid for such chipsets and shouldn't be used
with others. This fixes some 82559 based cards which otherwise only
work at 10Mbit.
MFC after: 5 days
Tested by: krion
|
|
|
|
|
|
|
| |
Also change struct ucode.length to be in number of elements (u_int32_t)
to help endian handling.
MFC after: 2 weeks
|
|
|
|
|
|
| |
This is a RELENG_5 candidate.
Submitted by: Mike Tancsa <mike@sentex.net>
|
|
|
|
|
| |
introduced in if_fxp.c revision 1.180. The bug fix committed in
revision 1.180 fixed the packet truncation problem.
|
|
|
|
|
|
|
|
|
|
|
| |
following drivers: bfe(4), em(4), fxp(4), lnc(4), tun(4), de(4) rl(4),
sis(4) and xl(4)
More patches are pending on: http://peoples.freebsd.org/~mlaier/ Please take
a look and tell me if "your" driver is missing, so I can fix this.
Tested-by: many
No-objection: -current, -net
|
|
|
|
| |
The bus does this now.
|
|
|
|
|
| |
mtx_assert() and mtx_owned(), as it is done in other places,
for instance proc locking.
|
|
|
|
|
|
|
|
|
|
|
| |
sysctls were global (hw.fxp_rnr and hw.fxp_noflow), all of them are
now per-device. Sample output of "sysctl dev.fxp0" with this patch,
with the standard %foo nodes removed :
dev.fxp0.int_delay: 1000
dev.fxp0.bundle_max: 6
dev.fxp0.rnr: 0
dev.fxp0.noflow: 0
|
| |
|
|
|
|
|
|
|
|
| |
In particular, disabling it was likely to break configurations
involving ng_vlan(4) since the latter couldn't control
the parent's VLAN_MTU in the way vlan(4) did.
Pointed out by: ru
|
| |
|
|
|
|
|
|
|
|
| |
Now reception of extended frames can be toggled
through ioctl(SIOCSIFCAP).
The card will also receive extended frames when
in promiscuous mode.
|
| |
|
|
|
|
|
|
|
| |
if_capenable unless the interface driver is actually able
to toggle the respective capability on and off.
Reviewed by: ru
|
|
|
|
| |
for us.
|
|
|
|
|
| |
Set capability bits in a consistent way.
Add a comment on why the VLAN_MTU stuff comes after ether_ifattach().
|
|
|
|
| |
so let VLAN_MTU be marked in if_capenable from the beginning.
|
| |
|
|
|
|
|
| |
Submitted by: Stefan Bethke
PR: 61320
|
|
|
|
|
| |
Submitted by: Mark Santcroos <marks@ripe.net>
Reviewed by: imp, dfr, bde
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
this problem put these lines back in. While they should be
unnecessary, they appear to be sometimes necessary.
Reviewed in concept: dfr
Approved by: re (scottl@)
|
|
|
|
|
|
|
| |
to the pci attachment. Cardbus is a derived class of pci so all pci
drivers are automatically available for matching against cardbus devices.
Reviewed by: imp
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
if_xname, if_dname, and if_dunit. if_xname is the name of the interface
and if_dname/unit are the driver name and instance.
This change paves the way for interface renaming and enhanced pseudo
device creation and configuration symantics.
Approved By: re (in principle)
Reviewed By: njl, imp
Tested On: i386, amd64, sparc64
Obtained From: NetBSD (if_xname)
|
| |
|
| |
|
|
|
|
| |
Sponsored by: FreeBSD Foundation
|
|
|
|
|
| |
Glanced over by: imp, gibbs
Tested by: i386 LINT
|
|
|
|
| |
Also some minor style cleanups.
|
|
|
|
|
| |
tree for two or more years now), except in a few places where there's
code to be compatible with older versions of FreeBSD.
|
|
|
|
|
|
|
| |
8255x chips more precisely. The information was obtained from Intel's
Open Source Software Developer Manual for the 8255x.
MFC after: 1 day
|
| |
|
|
|
|
|
|
| |
code size by 3616 bytes. Furthemore, it was previously ignored by GCC.
While I'm at it, fix some bogus comments.
|
|
|
|
|
|
|
| |
the lock when using DEVICE_POLLING.
Tested by: Robin P. Blanchard <Robin.Blanchard@gactr.uga.edu>
Reviewed by: njl
|
|
|
|
|
|
|
|
|
|
| |
However, they are presently necessary due to bigger bogusness in the
pci bus layer not doing the right thing on suspend/resume or on
initial device probe. This is exactly the sort of thing that the
BURN_BRIDGES option was invented for. Mark all of them as
BURN_BRIDGES. As soon as I have the powerstate stuff properly
integrated into the pci bus code, I intend to remove all these
workarounds.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add two new arguments to bus_dma_tag_create(): lockfunc and lockfuncarg.
Lockfunc allows a driver to provide a function for managing its locking
semantics while using busdma. At the moment, this is used for the
asynchronous busdma_swi and callback mechanism. Two lockfunc implementations
are provided: busdma_lock_mutex() performs standard mutex operations on the
mutex that is specified from lockfuncarg. dftl_lock() is a panic
implementation and is defaulted to when NULL, NULL are passed to
bus_dma_tag_create(). The only time that NULL, NULL should ever be used is
when the driver ensures that bus_dmamap_load() will not be deferred.
Drivers that do not provide their own locking can pass
busdma_lock_mutex,&Giant args in order to preserve the former behaviour.
sparc64 and powerpc do not provide real busdma_swi functions, so this is
largely a noop on those platforms. The busdma_swi on is64 is not properly
locked yet, so warnings will be emitted on this platform when busdma
callback deferrals happen.
If anyone gets panics or warnings from dflt_lock() being called, please
let me know right away.
Reviewed by: tmm, gibbs
|
|
|
|
|
|
|
|
|
| |
in the netisr case. This would result in a lock reversal. This
fixes the net.isr.enable=1 case. Better performance might be
obtained by chaining all packets received, dropping the lock, and
then calling if_input() on each one.
Reported by: hmp
|
|
|
|
| |
Submitted by: Tom Alsberg <alsbergt@cs.huji.ac.il>
|
|
|
|
|
|
| |
No actual bug with the existing code, just tidying things up.
Submitted by: hmp
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
structure, which is new to the 82550 and 82551, is used to transmit
a packet. This appears to fix the packet truncation problem that was
observed when using 82550-based fxp cards to transmit ICMP or fragmented
UDP packets of certain lengths which only had one to three bytes in the
second and final mbuf of the packet. This matches a note in the "Intel
8255x 10/100 Mbps Ethernet Controller Family Open Source Software Developer
Manual", which says that the hardware parse bit should be set when sending
these types of packets.
There have also been unconfirmed reports of similar problems when
transmitting TCP packets, which should not be affected by the above
mentioned change because the hardware parse bit was already being set
if the stack requested hardware checksumming of the packet. If the
problem remains, the use of the IPCB structure can be disabled to
cause the driver to fall back to using the older 82559 interface with
82550-based cards by setting
hint.fxp.UNIT_NUMBER.ipcbxmit_disable
to a non-zero value at boot time, or using kenv to set this variable
before using kldload to load the fxp driver.
Approved by: re (jhb)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
on if_fxp cards. When flow control is enabled, if the operating system
doesn't acknowledge the packet buffer filling, the card will begin to
generate ethernet quench packets, but appears to get into a feedback
loop of some sort, hosing local switches. This is a temporary workaround
for 5.1: the ability to configure flow control should probably be
exposed by some or another management interface on ethernet link layer
devices.
Approved by: re (bmah)
Reviewed by: mux
|
|
|
|
|
|
|
| |
give the fxp_ipcb structure a name in the fxp_rfa structure.
Submitted by: peter
Approved by: re (jhb)
|