If it does, don't then try reprogramming the NF "cap" values (ie
what values are the "maximum" value the NF can be) - instead,
just leave the current CCA value as the NF cap.
This was inspired by some similar work from ath9k. It isn't
a 100% complete solution (as there may be some reason where a
high NF CCA/cap is written, causing the baseband to stop thinking it
is able to transmit, leading to stuck beacon and interface reset)
which I'll investigate and look at fixing in a later commit.
Obtained from: Linux
AR5416 and later chipsets.
ath_hal_calibrateN() calls the HAL calibrateN function with rxchainmask=0x1.
This is not necessarily the case for AR5416 and later chipsets.
list of devices supported by uplcom(4) with the following sources:
NetBSD src/sys/dev/usb/uplcom.c 1.70
OpenBSD src/sys/dev/usb/uplcom.c 1.52
Linux drivers/usb/serial/pl2303.h from kernel 2.6.35
BeOS usb_serial/driver.c 1.32
Give several devices better descriptions, and rename
PROLIFIC2 -> NETINDEX while here to match everybody else.
MFC after: 6 weeks (after r211111)
flag immediately so it's only set once per longcal interval.
Without this, the current AR5416 code will continuously spam NF
calibrations during a periodic calibration if the longcal flag
is set. The longcal flag wouldn't be cleared until the calibration
method indicates that calibrations are "complete".
This drops the rate of NF calibration updates down from "once every
shortcal" (ie, every 100ms) during a periodic calibration, to only
once per "longcal" interval. Spamming NF calibrations every 100ms
caused some potentially horrific issues in noisy environments as
NF calibrations can take longer than 100ms and this spamming can
cause invalid NF calibration results to be read back - leading to
missed beacons, and thus leading to a stuck beacon situation.
Stuck beacons cause interface resets, which restart calibrations.
This means that the longcal calibration runs every 100ms (shortcal)
until all initial calibrations are completed. This spamming can then
cause the above issues which leads to stuck beacons, leading to
interface resets, etc, etc. Quite annoying.
within the device table. This code uses the same algorithm as used in the
Linux, NetBSD and DragonflyBSD driver.
While investigating this, it became apparent that the Linux driver always
initialises the device, and not just in the PL2303HX case. Change
uplcom(4) to do the same.
This change allows us to synchronize our device ID list with Linux and
NetBSD, without requiring knowledge of the chipset in use.
Reviewed by: hselasky
MFC after: 6 weeks
controller. These controllers are known as L1D(AR8151) and
L2CB/B2(AR8152). This change adds supports for the following
controllers.
o AR8151 v1.0(L1D) gigabit ethernet controller
o AR8151 v2.0(L1D) gigabit ethernet controller
o AR8152 v1.1(L2CB) fast ethernet controller
o AR8152 v2.0(L2CB2) fast ethernet controller
These controllers have the same feature of AR8131/AR8132 and
support improved power saving control. The user visible change at
this moment is reduced jumbo frame size from 9KB to 6KB. Many
thanks to Atheros for continuing to support FreeBSD.
HW donated by: Atheros Communications, Inc.
- Increase target limit from 4 to 64; this limit will be removed entirely
at a later time.
- Improve recovery from lost network connections.
- Fix some potential deadlocks and a serious memory leak.
- Fix incorrect use of MH_ALIGN (instead of M_ALIGN), which makes no
practical difference, but triggers a KASSERT with INVARIANTS.
- Fix some warnings in iscontrol(8) and improve the man page somewhat.
Submitted by: Daniel Braniss <danny@cs.huji.ac.il>
Sponsored by: Dansk Scanning A/S, Data Robotics Inc.
like memory mapped register access. Typical problem from the issue
was MII access returned unreliable values. I'm not sure this comes
from lack of register flushing in MII access after accessing
STE_PHYCTL register though.
To address the issue, read hints data that controls which type of
memory mapping should be used in driver. ste(4) still prefers
memory mapping to io mapping but honor hints entered by user except
for controllers that have problems with memory mapping.
The hint to use iomapping could be given by adding the following
line to /boot/device.hints file.
hint.ste.0.prefer_iomap="1"
PR: kern/149285
MFC after: 5 days
suspend state. Also disable master clock after PHY power down,
this is supposed to save more power. The master clock should be
enabled if WOL is active.
and BeOS. The devices supported by uslcom(4) are now in sync with:
NetBSD src/sys/dev/usb/uslsa.c 1.11
OpenBSD src/sys/dev/usb/uslcom.c 1.20
Linux source/drivers/usb/serial/cp210x.c from kernel 2.6.35
BeOS usb_serial/driver.c 1.32
Two vendor/product IDs from Linux have not been added to uslcom(4):
SILABS SAEL - This device has special code in u3g to support it
SILABS GSM2228 - I suspect this should also be covered by u3g(4).
MFC after: 1 week
vendor ID in the vendor section, and by symbolic name in the product
section. Products are sorted by product ID. While here, get rid of a
duplicate Microsoft Mouse entry, revealed by sorting.
MFC after: 1 week
value resulted in poor performance for UDP packets. With this
change, UDP bulk transfer performance is more than 940Mbps.
While I'm here fix a wrong register definition.
bus_generic_resume() since the pci_link(4) driver was added.
- Change the ACPI PCI-PCI bridge driver to inherit most of its methods
from the generic PCI-PCI bridge driver. In particular, this will now
restore PCI config registers for ACPI PCI-PCI bridges.
Tested by: Oleg Sharoyko osharoiko of gmail
infrastructure, not us. This appears to be a leftover from an older
version of the driver.
Submitted by: avg
Tested by: Anton Shterenlikht <mexas bristol.ac.uk>
MFC after: 1 week
X-MFC-Note: To stable/8 and stable/7 only
This way we would have an opportunity to hide the
Tj(target) value doesn't seem right stuff if we know
it's not working there.
Add temperature value for Core2 Duo Extreme Mobile that
I have access to.
Xeon 5500/5600 series:
- Utilize IA32_TEMPERATURE_TARGET, a.k.a. Tj(target) in place
of Tj(max) when a sane value is available, as documented
in Intel whitepaper "CPU Monitoring With DTS/PECI"; (By sane
value we mean 70C - 100C for now);
- Print the probe results when booting verbose;
- Replace cpu_mask with cpu_stepping;
- Use CPUID_* macros instead of rolling our own.
Approved by: rpaulo
MFC after: 1 month
a PMC. It was possible that we could have turned a bit on but
never cleared it.
Extend the calls to rdmsr() to all necessary functions, not
just those which previously caused a panic.
Pointed out by: jhb@
MFC after: 1 week
the official vendor listed for 0x076b, rather than Omnikey, as in the PR.
PR: usb/123351
Submitted by: Marcin Cieslak <saper SYSTEM.PL>
MFC after: 1 week
This patch is different to that provided in the PR, due to the changes in
this driver since 7.x.
PR: usb/129945
Submitted by: Antonio Hilario <avahilario gmail.com>
MFC after: 1 week
- Bring in several other devices from OpenBSD while here. Use the
official manufacturer name over the OpenBSD name in the case of
GEMALTO. Reorder list slightly to aid future syncing.
- Remove duplicate SILABS CP2102 define from usbdevs
PR: usb/131912 [1]
Submitted by: Jack Twilley <mathuin gmail.com> [1]
MFC after: 1 week
plug. Note that the Vendor ID 0x04b4 is officially assigned to Cypress,
so use that instead of adding a second vendor with an identical ID, in the
same way other similar cases are treated in usb/usbdevs.
PR: usb/132785
Submitted by: Dirk-Willem van Gulik <dirkx webweaving.org>
MFC after: 1 week
10G cards. 1G cards are x4 only.
- Use constants from pcireg.h for reading the current link width.
- Use pci_set_max_read_req() rather than implementing it by hand.
Reviewed by: np
MFC after: 1 week
This is similar to a fix in r189305 but for earlier ICH versions (<= 5).
Reported by: someone via attilio
Discussed with: des, attilio
MFC after: 1 week
tail pointers of the tx and rx queues. We needed a SYSCTL_PROC
to correctly get the values at run time.
Submitted by: Andrew Boyer aboyer at averesystems.com
MFC after: 1 week
This version adds support for ARC1880; additionally this version fixed
an issue where all devices on a SAS port gets offlined when any device
failed on the port [1].
Many thanks to Areca for continuing to support FreeBSD.
PR: kern/148502 [1]
Submitted by: Ching-Lung Huang <ching2048 areca com tw>
Obtained from: Areca
Tested by: Rich Ercolani <rercola acm jhu edu> [1]
MFC after: 2 weeks
lengths. Make MI wrapper code to validate periods in request. Make kernel
clock management code to honor these hardware limitations while choosing hz,
stathz and profhz values.
- Fixed the interface probe routine to only attach to USB interfaces the driver
actually supports. This allows other drivers to attach to things like
MicroSD slots etc.
- Fixed network interface enumeration to be globally sequential instead of
relying on the USB interface numbers. This make sure the first network
interface always is at uhso0 and the second at usho1 and so on.
- Added a radio kill switch; exposed through sysctl.
- Updated the manual page to be verbose about the number of serial ports and
include iCON 452 in the set of tested hardware.
Submitted by: Fredrik Lindberg
calls. Also add BUS_DMA_COHERENT flag to bus_dmamem_alloc(9) to
take advantage of efficient synchronization for architectures that
support that feature.
Reviewed by: davidch
return code. If context was not setup correctly give up
initialization. While I'm here move variable declarations to the
beginning of the function.
Reviewed by: davidch
AcpiOsMapMemory()/AcpiOsUnmapMemory() (-> pmap_mapbios()/pmap_unmapbios())
for AcpiOsReadMemory() and AcpiOsWriteMemory(). Although they do not sound
too obvious, these functions are exclusively used to access memory mapped
IO in ACPICA.
According to ACPICA User Guide and Programmer Reference, the read data must
be zero extended to fill the 64-bit return value even if the bit width of
the location is less than 64.
- Return error when 64-bit access is requested as we do not support 64-bit
PCI register access (yet). XXX We may have to split it up into two 32-bit
accesses if it is really required.
According to ACPICA User Guide and Programmer Reference, the read data must
be zero extended to fill the 32-bit return value even if the bit width of
the port is less than 32.
- Remove 64-bit read/write from AcpiOsReadMemory() and AcpiOsWriteMemory().
These functions do not support 64-bit access (yet). Clean up style nits
and unnecessary bit masking while I am here.
Reported by: Liu, Jinsong (jinsong dot liu at intel dot com) via
Lin Ming (ming dot m dot lin at intel dot com) [1]
- The 6000 series WiMAX devices need a separate firmware.
- The b-gen devices are not hooked because the hardware revision type
is not know.
Obtained from: OpenBSD
MFC after: 1 week
r165114 added that code and that change ignored the same logic
committed in r135772. In addition, data FIFO protection should be
selectively enabled instead of applying to all PCIe devices.
While I'm here add BCM5785 to devices that do not require this
fix.
and remove a buffer overflow:
- Remove the array of per-type dispatch functions. Instead, pass each
structure to a single callback. The callback should check the type of
each table entry to take appropriate action. This matches the behavior
of other table walkers such as for the MP Table and MADT.
- Don't attempt to save an array of string pointers for each structure
entry. Instead, just skip the strings. If this code is reused to
provide a generic SMBIOS table walker in the future we could provide
a method that looks up a specific string N for a given structure record
instead of pre-populating an array of pointers. This fixes a buffer
overflow for structure entries with more than 20 strings.
PR: kern/148546
Reported by: Spencer Minear @ McAfee
MFC after: 3 days
The code in question verifies that all register write operations only change
bits that are defined (in the register definition file) for that effected
register. The bug effectively disabled this checking.
o Fix the check by testing the opcode against all supported read ("and" based)
operands.
o Add missing bit definitions to the aic7xxx and aic79xx register definition
files so that the warning (treated as a fatal error) does not spuriously
fire.
Reported by: Pawel Worach <pawel.worach@gmail.com>
MFC after: 1 week
All of the necessary wrmsr calls are now preceded by a rdmsr
and we leave the reserved bits alone.
Document the bits in the relevant registers for future reference.
Tested by: mdf
MFC after: 1 week
was missed in r209599.
Reported and tested by: Michael Moll
- Declare mpt_dma_buf_alloc() static just like mpt_dma_buf_free(), both are
used in mpt.c only.
Reviewed by: ken
MFC after: r209599
a packet has only a header in the first mbuf, the
checksum code will dereference a pointer into the
non-existing IP header. Do a check for the size and
pullup if needed. Thanks to Michael Tuexen for this
fix.
MFC: asap - should be in 8.1 IMHO
Do not grab lock while setting up interrupt, as it causes LOR with
allocation code. Instead make interrupt handler check that CAM bus
initialization completed before touching it.
While there, slightly improve attach errors handling.
Reported by: kib
The following systems are affected:
- MPC8555CDS
- MPC8572DS
This overhaul covers the following major changes:
- All integrated peripherals drivers for Freescale MPC85XX SoC, which are
currently in the FreeBSD source tree are reworked and adjusted so they
derive config data out of the device tree blob (instead of hard coded /
tabelarized values).
- This includes: LBC, PCI / PCI-Express, I2C, DS1553, OpenPIC, TSEC, SEC,
QUICC, UART, CFI.
- Thanks to the common FDT infrastrucutre (fdtbus, simplebus) we retire
ocpbus(4) driver, which was based on hard-coded config data.
Note that world for these platforms has to be built WITH_FDT.
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
start so we should adjust the mbuf if the driver is running in PIO mode.
Now it should work well with WPA authentication and association for LP
PHY devices.
Tested by: Warren Block <wblock at wonkity.com>
MFC after: 1 month
checksum offloading is enabled. The frame has a valid checksum
value so payload might be modified during TX checksum calculation.
Disable TX checksum offloading but give users chance to enable it
when they know their controller works without problems with TX
checksum offloading.
Reported by: Andrzej Tobola <ato <> iem dot pw dot edu dot pl>
- Run the adapter's tick at 1Hz and remove link state checks from it.
Instead, have each port check its link state. Delay the check so that
it takes place slightly after the driver is notified of a change in
link state. This is a cheap way to debounce these notifications if
many are received in rapid succession. POLL_LINK_1ST_TIME flag can
also be eliminated as a side effect of these changes.
- Do not reset the PHY when link goes down.
- Clear port's link_fault flag if the PHY indicates link is down.
- get_link_status_r should leave speed and duplex alone when link is down.
MFC after: 1 month
checksum is enabled in sge_init_locked().
While I'm here do not set RX checksum bits in RX descriptor
initialization. It is controller's job to set these bits.
Tested by: xclin <xclin <> cs dot nctu dot edu dot tw >
configuration to get IPv4 TSO work on BCM57780. While I'm here
apply the same fix to BCM5785 which shares similar hardware feature
of BCM57780. This change makes TSO work on BCM57780.
Tested by: Tong Liu <nemoliu <> gmail dot com>
it. This can happen in some cases when plugging in SD/SmartCard PC
Cards with empty slots. It is better to detect this bogosity, and
refuse to attach rather than panic with a division by zero (in one of
many places) down stream.
the core changes but left out the shared code, lol.
Well, and a couple fixes to the core... hopefully
this will all be complete now.
Happy happy joy joy :)
What this provides is support for the 'virtual function'
interface that a FreeBSD VM may be assigned from a host
like KVM on Linux, or newer versions of Xen with such
support.
When the guest is set up with the capability, a special
limited function 82576 PCI device is present in its virtual
PCI space, so with this driver installed in the guest that
device will be detected and function nearly like the bare
metal, as it were.
The interface is only allowed a single queue in this configuration
however initial performance tests have looked very good.
Enjoy!!
limit the advertised speed of an SFP+ to 1G, effectively
"forcing" link at that lower speed. It is off by default
and is enabled by sysctl dev.ix.0.force_gig=1, 0 will
set it back to the norm.
The mpt driver previously didn't report a 'maxio' size to CAM, and so the
da(4) driver limited I/O sizes to DFLTPHYS (64K) by default. The number
of scatter gather segments allowed, as reported to busdma, was
(128K / PAGE_SIZE) + 1, or 33 on architectures with 4K pages.
Change things around so that we wait until we've determined how many
segments the adapter can support before creating the busdma tag used for
buffers, so we can potentially support more S/G segments and therefore
larger I/O sizes.
Also, fix some things that were broken about the module unload path. It
still gets hung up inside CAM, though.
mpt.c: Move some busdma initialization calls in here, and call
them just after we've gotten the IOCFacts, and know how
many S/G segments this adapter can support.
mpt.h: Get rid of MPT_MAXPHYS, it is no longer used.
Add max_cam_seg_cnt, which is used to report our maximum
I/O size up to CAM.
mpt_cam.c: Use max_cam_seg_cnt to report our maximum I/O size to CAM.
Fix the locking in mpt_cam_detach().
mpt_pci.c: Pull some busdma initialization and teardown out and put
it in mpt.c. We now delay it until we know many scatter
gather segments the adapter can support, and therefore
how to setup our busdma tags.
mpt_raid.c: Make sure we wake up the right wait channel to get the
raid thread to wake up when we're trying to shut it down.
Reviewed by: gibbs, mjacob
MFC after: 2 weeks
This prevents a kernel fault by dividing with zero because the initial
rate was 0 and didn't be initialized.
Tested by: Warren Block <wblock at wonkity.com>
MFC after: 3 days
changed to RUN because ic->ic_newassoc isn't set anywhere now. In the
previous bwi_newassoc() is used to initialize AMRR rate routines.
Tested by: Warren Block <wblock at wonkity.com>
MFC after: 3 days
It has more features than acpi_aiboost(4) and it will eventually replace
acpi_aiboost(4).
Submitted by: Constantine A. Murenin <cnst at FreeBSD.org>
Reviewed by: freebsd-acpi, imp
MFC after: 1 month
FPU registers for copying. Remove the switch table and jumps from
bcopy/bzero/... to the actual implementation.
As a side-effect, i486-optimized bzero is removed.
Reviewed by: bde
Tested by: pho (previous version)
properly short terminate their transfers. This fixes a problem where input
appears several seconds late.
Reported by: Alexander Yerenkow
Submitted by: Hans Petter Selasky
HPET to steal IRQ0 from i8254 and IRQ8 from RTC timers. It can be suitable
for HPETs without FSB interrupts support, as it gives them two unshared
IRQs. It allows them to provide one per-CPU event timer on dual-CPU system,
that should be suitable for further tickless kernels.
To enable it, such lines may be added to /boot/loader.conf:
hint.atrtc.0.clock=0
hint.attimer.0.clock=0
hint.hpet.0.legacy_route=1
writing event timer drivers, for choosing best possible drivers by machine
independent code and for operating them to supply kernel with hardclock(),
statclock() and profclock() events in unified fashion on various hardware.
Infrastructure provides support for both per-CPU (independent for every CPU
core) and global timers in periodic and one-shot modes. MI management code
at this moment uses only periodic mode, but one-shot mode use planned for
later, as part of tickless kernel project.
For this moment infrastructure used on i386 and amd64 architectures. Other
archs are welcome to follow, while their current operation should not be
affected.
This patch updates existing drivers (i8254, RTC and LAPIC) for the new
order, and adds event timers support into the HPET driver. These drivers
have different capabilities:
LAPIC - per-CPU timer, supports periodic and one-shot operation, may
freeze in C3 state, calibrated on first use, so may be not exactly precise.
HPET - depending on hardware can work as per-CPU or global, supports
periodic and one-shot operation, usually provides several event timers.
i8254 - global, limited to periodic mode, because same hardware used also
as time counter.
RTC - global, supports only periodic mode, set of frequencies in Hz
limited by powers of 2.
Depending on hardware capabilities, drivers preferred in following orders,
either LAPIC, HPETs, i8254, RTC or HPETs, LAPIC, i8254, RTC.
User may explicitly specify wanted timers via loader tunables or sysctls:
kern.eventtimer.timer1 and kern.eventtimer.timer2.
If requested driver is unavailable or unoperational, system will try to
replace it. If no more timers available or "NONE" specified for second,
system will operate using only one timer, multiplying it's frequency by few
times and uing respective dividers to honor hz, stathz and profhz values,
set during initial setup.
measured interval as upper bound. It should be more precise then just
assuming hz/2. For idle CPU it should be quite precise, for busy - not
worse then before.
state lower than the lowest one supported by the current CPU. This closes
some races with changes to the hw.acpi.cpu_cx_lowest sysctl while Cx
states for individual CPUs were changing (e.g. unplugging the AC adapter
of a laptop) that could result in panics.
Submitted by: Giovanni Trematerra
Tested by: David Demelier demelier dot david of gmail
MFC after: 3 days
Although the sysctls are marked with CTLFLAG_RD and the values will stay
immutable, current sysctl implementation stores value pointer in
void* type, which means that const qualifier is discarded anyway
and some newer compilers complaint about that.
We can't use de-const trick in sysctl implementation, because in that
case we could miss an opposite situation where a const value is used
with CTLFLAG_RW sysctl.
Complaint from: gcc 4.4, clang
MFC after: 2 weeks
beginning with the highest available rate. Currently we always use
54m for the first retry no matter what AMRR has choosen. Fix this
by setting the index to the next lower rate.
Approved by: rpaulo (mentor)
Tested by: Brandon Gooch <jamesbrandongooch at gmail.com>
MFC after: 2 weeks
callback function will be executed, and that the key won't be deleted during
the init process.
- txmic and rxmic are written into the chip the same place regardless of
opmode.
- Make the hardware generate 802.11 sequence numbers.
Submitted by: Akinori Furukoshi
Obtained from: git://gitorious.org/run/run.git
The following systems are involved:
- DB-88F5182
- DB-88F5281
- DB-88F6281
- DB-78100
- SheevaPlug
This overhaul covers the following major changes:
- All integrated peripherals drivers for Marvell ARM SoC, which are
currently in the FreeBSD source tree are reworked and adjusted so they
derive config data out of the device tree blob (instead of hard coded /
tabelarized values).
- Since the common FDT infrastrucutre (fdtbus, simplebus) is used we say
good by to obio / mbus drivers and numerous hard-coded config data.
Note that world needs to be built WITH_FDT for the affected platforms.
Reviewed by: imp
Sponsored by: The FreeBSD Foundation.
The T3 ASIC can provide an incoming packet's timestamp instead of its RSS hash.
The timestamp is just a counter running off the card's clock. With a 175MHz
clock an increment represents ~5.7ns and the 32 bit value wraps around in ~25s.
# sysctl -d dev.cxgbc.0.pkt_timestamp
dev.cxgbc.0.pkt_timestamp: provide packet timestamp instead of connection hash
# sysctl -d dev.cxgbc.0.core_clock
dev.cxgbc.0.core_clock: core clock frequency (in KHz)
# sysctl dev.cxgbc.0.core_clock
dev.cxgbc.0.core_clock: 175000
Remove unneeded rxtx handler, make que handler generic.
Do not allocate header mbufs in rx ring if not doing hdr split.
Release the lock in rxeof call to stack.
MFC for 8.1 asap
via %s
Most of the cases looked harmless, but this is done for the sake of
correctness. In one case it even allowed to drop an intermediate buffer.
Found by: clang
MFC after: 2 week
support FreeBSD.
1) Timeout ioctl command timeouts.
Do not reset the controller if ioctl command completed
successfully.
2) Remove G66_WORKAROUND code (this bug never shipped).
3) Remove unnecessary interrupt lock (intr_lock).
4) Timeout firmware handshake for PChip reset (don't wait forever).
5) Handle interrupts inline.
6) Unmask command interrupt ONLY when adding a command to the pending
queue.
7) Mask command interrupt ONLY after removing the last command from
the pending queue.
8) Remove TW_OSLI_DEFERRED_INTR_USED code.
9) Replace controller "state" with separate data fields to avoid races:
TW_CLI_CTLR_STATE_ACTIVE ctlr->active
TW_CLI_CTLR_STATE_INTR_ENABLED ctlr->interrupts_enabled
TW_CLI_CTLR_STATE_INTERNAL_REQ_BUSY ctlr->internal_req_busy
TW_CLI_CTLR_STATE_GET_MORE_AENS ctlr->get_more_aens
TW_CLI_CTLR_STATE_RESET_IN_PROGRESS ctlr->reset_in_progress
TW_CLI_CTLR_STATE_RESET_PHASE1_IN_PROGRESS ctlr->reset_phase1_in_progress
10) Fix "req" leak in twa_action() when simq is frozen and req is NOT
null.
11) Replace softc "state" with separate data fields to avoid races:
TW_OSLI_CTLR_STATE_OPEN sc->open
TW_OSLI_CTLR_STATE_SIMQ_FROZEN sc->simq_frozen
12) Fix reference to TW_OSLI_REQ_FLAGS_IN_PROGRESS in
tw_osl_complete_passthru()
13) Use correct CAM status values.
Change CAM_REQ_CMP_ERR to CAM_REQ_INVALID.
Remove use of CAM_RELEASE_SIMQ for physical data addresses.
14) Do not freeze/ release the simq with non I/O commands.
When it is appropriate to temporarily freeze the simq with an I/O
command use:
xpt_freeze_simq(sim, 1);
ccb->ccb_h.status |= CAM_RELEASE_SIMQ;
otherwise use:
xpt_freeze_simq(sim, 1);
xpt_release_simq(sim, 1);
Submitted by: Tom Couch <tom.couch lsi.com>
PR: kern/147695
MFC after: 3 days
- Re-enable TSO. This was broken previously due to CSUM_TSO clearing the
CSUM_TCP flag, so our checksum flags were incorrectly set going to the
netback driver. That was fixed in r206844 in tcp_output.c, so we can
turn TSO back on here.
- Fix the way transmit slots are calculated, so that we can't overfill
the ring.
- Avoid sending packets with more fragments/segments than netback can
handle. The Linux netback code can only handle packets of
MAX_SKB_FRAGS, which turns out to be 18 on machines with 4K pages. We
can easily generate packets with 32 or so fragments with TSO turned on.
Right now the solution is just to drop the packets (since netback
doesn't seem to handle it gracefully), but we should come up with a way
to allow a driver to tell the TCP stack the maximum number of fragments
it can handle in a single packet.
- Fix the way the consumer is tracked in the receive path. It could get
out of sync fairly easily.
- Use standard Xen ring macros to make it clearer how netfront is using
the rings.
- Get rid of Linux-ish negative errno return values.
- Added more documentation to the driver.
- Refactored code to make it easier to read.
- Some other minor fixes.
Reviewed by: gibbs
Reviewed by: gibbs
Sponsored by: Spectra Logic
MFC after: 7 days
