| Age | Commit message (Collapse) | Author |
|---|
|
Tested by naddy@
|
|
This should take care of the simpler ones (i.e., timeout values of
integer multiples of hz).
ok krw@, art@
|
|
change. Prevents us from getting stuck in LINK_STATE_UNKNOWN. Fixes PR 5914.
tested by deraadt@, sthen@
ok deraadt@
|
|
Move calling ether_ioctl() from the top of the ioctl function, which
at the moment does absolutely nothing, to the default switch case.
Thus allowing drivers to define their own ioctl handlers and then
falling back on ether_ioctl(). The only functional change this results
in at the moment is having all Ethernet drivers returning the proper
errno of ENOTTY instead of EINVAL/ENXIO when encountering unknown
ioctl's.
Shrinks the i386 kernels by..
RAMDISK - 1024 bytes
RAMDISKB - 1120 bytes
RAMDISKC - 832 bytes
Tested by martin@/jsing@/todd@/brad@
Build tested on almost all archs by todd@/brad@
ok jsing@
|
|
|
|
Found by LLVM/Clang Static Analyzer.
ok henning@ brad@
|
|
The exact details are unknown (possibly hw errata?) but the Windows
and Linux drivers have never supported Jumbos on this chipset and since
it is so old and rare it is not that big of a deal.
From FreeBSD
ok dlg@ awhile ago.
|
|
address 0x1a and 0x1e, and that's not where the PCIe capability stuff
lives. Potentially it was mucking with an IO BAR (super dangerous).
But probably it was achieving nothing at all.
ok dlg@, marco@, brad@
|
|
rx_abs_int_delay to be non-zero when rx_int_delay is zero appears
to trigger a bug elsewhere in the kernel for certain em revisions.
Based on a diff from beck@. OK beck@ marco@ henning@ brad@
|
|
nothing uses them and it saves a few bytes in the kernel.
ok claudio@
|
|
the driver for about 292 bytes on i386.
ok reyk@
|
|
state reporting code in the MII layer / em(4) and vge(4) will never
fall back to the point of only reporting the link as being UP without
the duplex setting being reported, so simplify the code a bit here.
ok dlg@
|
|
the start routine instead of once per packet.
tested on various archs including amd64, i386, and sparc64.
|
|
will not return any flow control status so just return no status (0)
instead of reading copper PHY registers and not returning anything
anyway.
ok kettenis@
|
|
m_free() to free the mbuf cluster.
ok krw@ mglocker@
|
|
for the IFF_OACTIVE flag.
Tested by brad@, johan@, krw@, wilfried@
From mickey
|
|
Initial diff from Henry Precheur based on a commit from matthias@dragonflybsd
which was derived from the FreeBSD driver. Additional Flash changes from
sephe@dragonflybsd which was derived from the FreeBSD driver. Typo fixes
in Henry's diff and a few other improvements from the FreeBSD driver from
brad@.
Tested on a variety of different em(4) adapters in addition to ICH8/9.
ok dlg@
|
|
From FreeBSD
ok dlg@
|
|
and into a separate function which was modeled after the MII
frameworks mii_phy_flowstatus() function. This was done so as to
make em_media_status() a little nicer looking and so that when flow
control status is added for fiber adapters that em_media_status()
won't look so ugly. No functional change.
Tested by wilfried@ and brad@
ok dlg@
|
|
for the newer generations of em(4) chipsets independently
from the first two generations (82542/82543). The first
two generations have hardware errata limiting the upper
maximum to 256 descriptors. The number of RX descriptors
has not been adjusted yet.
ok beck@ henning@ dlg@
|
|
obvious.
|
|
prevents another round of autonegotiation (and thus, few seconds outage)
with every address change that had to be reintroduced a few revs ago
because of the watchdog timeout problems people were seeing.
this gives the benifit from both with the problems of neither ;)
tested by daniel polak on a system that saw the watchdog timeouts before
ok theo
|
|
Bring the flow control delay time down to what the comment says it should
be. By using a smaller flow control pause time when the buffer isn't full,
my em(4) goes about 20Mbps faster.
|
|
the other interrupt moderation schemes.
ok beck drahn
|
|
|
|
random addresses in some cases, causing watchdog timeouts.
tested by many; ok deraadt@
|
|
|
|
the interface will fail to initialize with an EEPROM error if the interface
does not have a link upon boot.
Tested by mk@ and janek@
From Jack Vogel@Intel via brad
|
|
|
|
From brad@
|
|
From brad@
|
|
PCIe to 4k.
>From kmacy@FreeBSD
Tested by mk@ and Johan Mson Lindman <tybollt at solace dot mh dot se>
with the 82573 chipset.
ok brad@ mglocker@ mk@
|
|
ok brad@
|
|
longer necessary.
|
|
|
|
|
|
available TX descriptors in the case that em_encap() has tried to reclaim
descriptors.
From Jack Vogel@Intel
Tested by brad@, mk@, Gabriel Kihlman <gk at stacken dot kth dot se>,
Johan Mson Lindman <tybollt at solace dot mh dot se>
Tested on amd64/i386/sparc64
|
|
the EOP descriptor in the first descriptor of the packet. In em_txeof()
search for the DD bit set only in the EOP descriptors, embedding the
cleanup of all packet's descriptors into the inner loop.
This change is important for future chips, where the DD bit is going
to be set only in the EOP descriptors.
From Jack Vogel@Intel
Tested by brad@, mk@, reyk@, Gabriel Kihlman <gk at stacken dot kth dot se>,
Johan Mson Lindman <tybollt at solace dot mh dot se>, Jason Dixon and a few
others.
Tested on i386/amd64/sparc64.
|
|
per packet sent.
Tested by brad@, ckuethe@, Gabriel Kihlman <gk at stacken dot kth dot se>
and Tim Wiess <tim at nop dot cx>.
Tested with amd64/i386/sparc64.
ok damien@
|
|
- Use bus_dmamap_load_mbuf() instead of bus_dmamap_load() + mtod().
- Only BUS_DMASYNC_PREREAD is necessary for the bus_dmamap_sync().
em_allocate_receive_structures():
- Clean up error handling for receive buffer allocation and just
have everything done by em_free_receive_structures() now.
em_free_receive_structures():
- A few changes here to allow this function to be called from
em_stop() as well as em_allocate_receive_structures().
Tested on i386/amd64/sparc64.
ok reyk@
|
|
for a few newer Intel PCIe boards, some code removal and cleaning
and a few bug fixes.
From: Jack Vogel@Intel
Tested by mk@ wilfried@ brad@ dlg@, Marc Winiger, Gabriel Kihlman,
Jason Dixon, Johan Mson Lindman, and a few other end users.
Tested with 82543, 82544, 82540, 82545, 82541, 82547, 82546 and 82573.
|
|
from the chipset, so remove it.
|
|
ok brad@
|
|
|
|
issuing a watchdog reset of the interface.
From yongari@FreeBSD
|
|
- Create a spare DMA map for RX handler to recover from
bus_dmamap_load() failure.
- Make sure to update status bit in RX descriptors even if we failed
to allocate a new buffer.
- Don't blindly unload DMA map. Reuse loaded DMA map if received
packet has errors.
From yongari@FreeBSD
Tested by myself and a number of end-users on i386/amd64/sparc64
|
|
the proper alignment requirement for the VLAN layer on strict alignment
architectures. This would result in Jumbo's working fine as long as VLANs
were not in use. If VLANs were in use and a packet comes in with a size
of 2046 bytes or larger, it would be corrupted as it came up through the
VLAN layer. Also check the hw max frame size, instead of the MTU, so the
alignment fixup is done as appropriate.
Fixes PR 5185.
Tested by Rui DeSousa with macppc and myself with alpha/sparc64.
|
|
the HW max frame size and only call m_adj() if the size is less
than or equal to MCLBYTES - ETHER_ALIGN (2046).
- Set the HW long packet enable bit on all adapters, even 82573
based adapters which are capable of Jumbo's.
- Only do RX alignment fixup on adapters capable of Jumbo frames.
ok jason@
|
|
since E1000_FDX_COLLISION_DISTANCE and E1000_HDX_COLLISION_DISTANCE
use the same values.
From glebius@FreeBSD
|
|
|
