the lock instead of queueing it to a task.
- Do not invoke jme_rxintr() to reclaim any unprocessed but received
packets when shutting down the interface. Instead, just drop these
packets to match the behavior of other drivers.
- Hold the driver lock in the interrupt handler to avoid races with
ioctl requests to down the interface.
Reviewed by: yongari
limit maximum RX buffer size to RE_RX_DESC_BUFLEN instead of
blindly configuring it to 16KB. Due to lack of documentation, re(4)
didn't allow jumbo frame on these controllers. However it seems
controller is confused with jumbo frame such that it can DMA the
received frame to wrong address instead of splitting it into
multiple RX buffers. Of course, this caused panic.
Since re(4) does not support jumbo frames on these controllers,
make controller drop frame that is longer than RE_RX_DESC_BUFLEN
sized frame. Fortunately RTL810x controllers, which do not support
jumbo frame, have no such issues but this change also limited
maximum RX buffer size allowed to RTL810x controllers. Allowing
16KB RX buffer for controllers that have no such capability is
meaningless.
MFC after: 3 days
- failure code in em_xmit got mangled along the way
and was not properly handling errors.
- local timer code had a leftover UNLOCK call that
should be removed.
MFC after 3 days
and just show old (cached) values. Controller will not respond to
the command unless MAC is enabled so DUMP request for down
interface caused request timeout.
RealTek changed TX descriptor format for later controllers so these
controllers require MSS configuration in different location of TX
descriptor. TSO is enabled by default for controllers that use new
descriptor format.
For old controllers, TSO is still disabled by default due to broken
frames under certain conditions but users can enable it.
Special thanks to Hayes Wang at RealTek.
MFC after: 2 weeks
These controllers consist of two Marvell 88SE9128 6Gbps SATA chips and
PLX PCIe bridge. As result, they seem to be agree to work with ahci(4)
as usual HBAs. The only noticed issue is that RAID BIOS disables all
drive caches during boot, though `camcontrol cmd ...` is able to fix that.
Those who wants RAID functionality can still use closed proprietary driver
from HighPoint site.
MFC after: 1 week
install or remove non-SCI interrupt handlers per ACPI Component Architecture
User Guide and Programmer Reference. ACPICA may install such interrupt
handler when a GPE block device is found, for example. Add a wrapper for
ACPI_OSD_HANDLER, convert its return values to ours, and make it a filter.
Prefer KASSERT(9) over panic(9) as we have never seen those in reality.
Clean up some style(9) nits and add my copyright.
DMA boundary bug and runs with PCI-X mode. watchdog timeout was
observed on BCM5704 which lives behind certain PCI-X bridge(e.g.
AMD 8131 PCI-X bridge). It's still not clear whether the root
cause came from that PCI-X bridge or not. The watchdog timeout
indicates the issue is in TX path. If the bridge reorders TX
mailbox write accesses it would generate all kinds of problems but
I'm not sure. This should be revisited.
Tested by: Michael L. Squires (mikes <> siralan dot org)
issue seen on PCIX BCM5704 controller. r216970 fixed the issue but
the DMA address space restriction was applied to all bge(4)
controllers such that it caused unnecessary performance degradation
for controllers that have no such issues.
all new devices added between our r211022 and their git revision
93ad03d60b5b18897030038234aa2ebae8234748
Also correct a Foxconn entry.
MFC after: 1 week
bus_dma(9)'s capability which honors boundary restrictions of DMA
tag for dynamic buffers. However it seems this does not work well
and it triggered watchodg timeouts on controller that has the
hardware bug. It's not clear whether there is still another
hardware bug not mentioned in errata. This should be revisited
since this change shall make use of bounce buffers which in turn
reduces performance a lot on systems that have more than 4GB
memory.
Reported by: Michael L. Squires (mikes <> siralan dot org)
Tested by: Michael L. Squires (mikes <> siralan dot org)
MFC after: 3 days
mechanical change. This opens the door for using PV device drivers
under Xen HVM on i386, as well as more general harmonisation of i386
and amd64 Xen support in FreeBSD.
Reviewed by: cperciva
MFC after: 3 weeks
After controller updates control word in a RX LE, driver converts
it to host byte order. The checksum value in the control word is
stored in big endian form by controller. r205091 didn't account for
the host byte order conversion such that the checksum value was
incorrectly interpreted on big endian architectures which in turn
made all TCP/UDP frames dropped. Make RX checksum offload work
on any architectures by swapping the checksum value.
Reported by: Sreekanth M. ( kanthms <> netlogicmicro dot com )
Tested by: Sreekanth M. ( kanthms <> netlogicmicro dot com )
supposed to be APs and the later 24 are pre-configured as STAs. A wrong
condition during initialization is responsible for not configuring the last
8 array members. This is results in being able to create more than 8,
possible uninitialized, AP-VAPs.
PR: kern/153549
Submitted by: Erik Fonnesbeck <efonnes at gmail.com>
MFC after: 2 weeks
The controller is commonly found on DM&P Vortex86 x86 SoC. The
driver supports all hardware features except flow control. The
flow control was intentionally disabled due to silicon bug.
DM&P Electronics, Inc. provided all necessary information including
sample board to write driver and answered many questions I had.
Many thanks for their support of FreeBSD.
H/W donated by: DM&P Electronics, Inc.
modification of memory which was already free'd and eventually in:
wpi0: could not map mbuf (error 12)
wpi0: wpi_rx_intr: bus_dmamap_load failed, error 12
and an usuable device.
PR: kern/144898
MFC after: 3 days
